Runtime conditionals

[donkey]

Hi mitchi,

CCall (CInvoke) from macros.a in the header project, GoAsm already handles this fine. I wrote it but don't use it myself, useless macro in my opinion, I just wrote it for others who might like this sort of thing.

Code Select Expand

#IFNDEF CInvoke
// By Donkey
CInvoke(%Function,%0,%1,%2,%3,%4,%5,%6,%7,%8,%9) MACRO
#IF ARGCOUNT = 11
push %9
#ENDIF
#IF ARGCOUNT > 9
push %8
#ENDIF
#IF ARGCOUNT > 8
push %7
#ENDIF
#IF ARGCOUNT > 7
push %6
#ENDIF
#IF ARGCOUNT > 6
push %5
#ENDIF
#IF ARGCOUNT > 5
push %4
#ENDIF
#IF ARGCOUNT > 4
push %3
#ENDIF
#IF ARGCOUNT > 3
push %2
#ENDIF
#IF ARGCOUNT > 2
push %1
#ENDIF
#IF ARGCOUNT > 1
push %0
#ENDIF
call %Function
#IF ARGCOUNT = 11
add esp,40
#ENDIF
#IF ARGCOUNT = 10
add esp,36
#ENDIF
#IF ARGCOUNT = 9
add esp,32
#ENDIF
#IF ARGCOUNT = 8
add esp,28
#ENDIF
#IF ARGCOUNT = 7
add esp,24
#ENDIF
#IF ARGCOUNT = 6
add esp,20
#ENDIF
#IF ARGCOUNT = 5
add esp,16
#ENDIF
#IF ARGCOUNT = 4
add esp,12
#ENDIF
#IF ARGCOUNT = 3
add esp,8
#ENDIF
#IF ARGCOUNT = 2
add esp,4
#ENDIF
ENDM
#ENDIF

[jorgon]

Hi Mitchi

If I could get confused by #IF or .IF ?
No way, There's just no way.

How about this:-

Code Select Expand

WndProc FRAME hWnd, uMsg, wParam, lParam
.IF uMsg=WM_PAINT
PAINT:
#IF VERSION=1
CALL NORMAL_PAINT
RET
#ELSE
CALL SPECIAL_PAINT
RET
#ENDIF
.IF uMsg=WM_CREATE
CREATE:
#IF VERSION=1
CALL NORMAL_CREATE
RET
#ELSE
CALL SPECIAL_CREATE
RET
#ENDIF
.ENDIF
RET
ENDF
It's fine if you wrote it yourself, but try explaining it to your friend who wants to learn assembler.

[mitchi]

Coding with compile-time conditionals inside your code is always going to be ugly...
It's ugly in C, it's ugly in MASM, it's ugly in every language  :bg
There's nothing you can do about it.

Besides, these compile time conditionals, I never use them. I see them used in Cross-platform compilers and librairies but for personal projects I have never needed any of them.

[jorgon]

Hi Mitchi

As you can see from Edgar's example, GoAsm handles macros with arguments, and code.  You can include in the macro code procedures and stuff.  And GoAsm handles data in macros.  You can declare a structure in a GoAsm macro too but I have no idea why anyone would want to do this since a structure is a kind of macro already (a word is used which means something else).

Is this not sufficient macro support?

[mitchi]

Well I don't really like to play with the macro creator. I've always  prefered to use the standard macros offered by the language. I generally don't use macros when I code in ASM, except for if/else. They are very well adapted to some situations. I don't have to type a label and the code is clean to read.

I'll say it again, I would like GoAsm to have a standard if / else  :bg

[jorgon]

I'll say it again, I would like GoAsm to have a standard if / else 

But Mitchi, on the assumption that it is the functionality of a runtime if/else that you want then you would be just as happy with SWITCH/CASE.

Would you be just as happy with SWITCH/CASE?

If "no" please explain why not.

[donkey]

The only place where IF/ELSE would be more convenient is on one-shot compares. For example the following code is a bit difficult in GoAsm..

(from Help2 Viewer)

Code Select Expand

movzx eax,W[wParam]
// Process accelerators
cmp eax,ACL_COPY
jne >>
invoke GetFocus
mov ebx,eax
invoke GetClassName,eax,offset url,1024
invoke lstrcmp,offset url,offset IEWndClass
test eax,eax
jnz >.1
CoInvoke(pIWebBrowser2,IWebBrowser2.ExecWB,OLECMDID_COPY,OLECMDEXECOPT_DODEFAULT,NULL,NULL)
jmp >>.EXIT
.1
invoke SendMessage,ebx,WM_COPY,0,0
jmp >>.EXIT
:
cmp eax,ACL_ALL
jne >
invoke GetFocus
mov ebx,eax
invoke GetClassName,eax,offset url,1024
invoke lstrcmp,offset url,offset IEWndClass
test eax,eax
jnz >.2
CoInvoke(pIWebBrowser2,IWebBrowser2.ExecWB,OLECMDID_SELECTALL,OLECMDEXECOPT_DODEFAULT,NULL,NULL)
jmp >>.EXIT
.2
invoke SendMessage,ebx,EM_SETSEL,0,-1
jmp >>.EXIT
:

As you can see the .1 and .2 are needed because at some point I had decided I didn't need to worry about labeling every case and later found that I needed to insert some conditions inside each message handler. This is handled well enough using the numbered anonymous labels but SWITCH/CASE would not save any typing..

Code Select Expand

SWITCH eax
CASE ACL_COPY:
invoke GetFocus
mov ebx,eax
invoke GetClassName,eax,offset url,1024
invoke lstrcmp,offset url,offset IEWndClass
SWITCH eax
CASE 0
invoke SendMessage,ebx,WM_COPY,0,0
jmp >>.EXIT
ENDSWITCH
CoInvoke(pIWebBrowser2,IWebBrowser2.ExecWB,OLECMDID_COPY,OLECMDEXECOPT_DODEFAULT,NULL,NULL)
jmp >>.EXIT
CASE ACL_ALL:
...


It would be clearer to have a quicky comparison operator like WHERE in addition to SWITCH/CASE

Code Select Expand

SWITCH eax
CASE ACL_COPY:
invoke GetFocus
mov ebx,eax
invoke GetClassName,eax,offset url,1024
invoke lstrcmp,offset url,offset IEWndClass
WHERE eax <> 0
invoke SendMessage,ebx,WM_COPY,0,0

ELSEWHERE
CoInvoke(pIWebBrowser2,IWebBrowser2.ExecWB,OLECMDID_COPY,OLECMDEXECOPT_DODEFAULT,NULL,NULL)

ENDW
jmp >>.EXIT
CASE ACL_ALL:
...

As I said in a previous post, IF/ENDIF does not have to be the syntax, there is no good reason to follow MASM syntax and as you said at least one good reason not to. So scrap IF/ENDIF and implement WHERE/ENDW in its place for one-shot comparisons, it makes code a bit more readable and gives one more tool for the kit.

Edgar

[mitchi]

I really don't understand why you guys don't believe in the power of if/else. Did you never program in C ? I really believe it's convenient but maybe it's because I have a HLL background.

Switch / case will be a great addition  :cheekygreen: .
How is it going to be implemented ? Jump table + lookup table for not perfect case orders OR successive conditional jumps ?

Donkey :
I don't mind your WHERE syntax. It's not standard but it looks okay.

[Mark Jones]

WHERE/ELSEW/ELSE/ENDW? Provides the same functionality as if/then/else and switch/case/default with a simpler usage in my opinion. Good eye Donkey. :U

What if it accepted both types of operands? Possible, not possible? Just postulating ideas.

[ecube]

To quote BogdanOntanu on why this is so important

"MACRO's and .IF .ELSEIF and INVOKE and STUCT's and PROCS with ARGS and LOCALS are of the essence for modern ASM development.

Without them ASM becomes a primitive language that can be used only for a few optimizations here and there.

With them ASM becomes a powerfully language that is well above HLL languages in both simplicity and speed of development and ease of code management. I speak from my own experience of developing huge application in ASM and comparing it with a life time of professional development in HLL.

Assemblers have become powerful when they did evolved into a "macro assembler". Removing such things as .IF / .ELSEIF from assemblers means returning to the 1970 era."

the lack of .IF, .ELSEIF etc is the only thing holding me back from using GoASM, overall it seems to be very well done and the nice 64bit support is exciting, but due to the size of my existing projects in MASM I can't convert over until you provide support for .if, .elseif etc... if for some reason you decide to never add support, then thats going to signifigantly deter people from using GoASM including myself. The WHERE syntax looks ugly imo, why does this have to be so difficult, .IF works great in MASM, it beautifies everything and theres no confusion.

[donkey]

I really don't understand why you guys don't believe in the power of if/else. Did you never program in C ? I really believe it's convenient but maybe it's because I have a HLL background.

I have never programmed in any language other than ASM, with the exception of wading through a bit of C once to write a small PDA utility.

Switch / case will be a great addition  :cheekygreen: .

I agree

Donkey :
I don't mind your WHERE syntax. It's not standard but it looks okay.

It neatly solves the syntax issue and borrows from SQL so the keyword is still familiar and LTR readable.

[mitchi]

I really don't understand why you guys don't believe in the power of if/else. Did you never program in C ? I really believe it's convenient but maybe it's because I have a HLL background.

I have never programmed in any language other than ASM, with the exception of wading through a bit of C once to write a small PDA utility.

Switch / case will be a great addition  :cheekygreen: .

I agree

Donkey :
I don't mind your WHERE syntax. It's not standard but it looks okay.

It neatly solves the syntax issue and borrows from SQL so the keyword is still familiar and LTR readable.

How old are you ? Pure asm programmers are getting rare. Everyone starts with HLL at school these days.

[donkey]

I'm 47 but I am not a programmer by trade and I did not take programming in university, its just a hobby for me. ASM was the first package I ran into when I was looking for a language for my hobby, actually ran across Hiro's forum and chatted with Iczelion a bit and was convinced it was the way to go, haven't regretted it since and I have rarely found anything that could not be done in assembly language.

Actually I guess I should note that I did sell 2 commercial applications written in GoAsm, one a database program and the other a data management program, however they were so narrowly targeted I don't think there would be more than 20 potential users world-wide. (The PDA C thingy was a component of the data management program).

Edgar

[GregL]

I would prefer IF over WHERE.  I really don't see that it's a problem.

[donkey]

I would prefer IF over WHERE.  I really don't see that it's a problem.

Well, given that the potential confusion over IF is a concern of Jeremy's and that in reality there is no good reason to choose one over the other beside making it syntactically close to MASM, I prefer WHERE. Being close in syntax to MASM is not something that I see as necessary or desirable since I rarely even look at code from that assembler anymore. As well automating the translation of source from MASM to GoAsm would be the same task regardless of the actual keyword name. Though Jeremy's example of potential confusion might have been a bit far fetched in the main body of code, it is not so unthinkable in a macro or include file where compile-time and run-time conditionals will more than likely have to co-exist, having a distinct keyword for each is preferable IMO.