Runtime conditionals

[donkey]

Hi Jeremy,

Lately I have been having a bit of a change of heart and would like to change my vote to YES for run-time conditionals (that is if you're still considering it), an implementation of IF / ELSEIF / ENDIF or alternatively SWITCH / CASE would be a nice feature to add to the overall package. I can't say how often I would use it but it would be nice to have the choice for some projects.

Edgar

[Mark Jones]

I've long-since wished for the option of if/else/elseif/endif and switch/case/default/endsw. But alas, it's Jeremy's call. They could make large switch blocks (and WinProcs) much clearer though, for those of us whom opted to use them.

[Vortex]

Nice idea Edgar. That would add a great potential to GoAsm.

[jorgon]

I would consider this if GoAsm users were in favour, but what I have always disliked is the confusion in syntax between #IF and IF and similar conditionals which do two entirely different things (the former being an assemble-time conditional and the latter a run-time conditional).  I already had #IF in my resource compiler (GoRC), and so I wanted also to use it in GoAsm.  Hence IF could not be considered, because of the syntax confusion issue.
SWITCH/CASE may be a possibility.  It might look like this:-

Code Select Expand


WndProc FRAME hWnd, uMsg, wParam, lParam
SWITCH uMsg
CASE PAINT:
XOR EAX,EAX
RET
BREAK
CASE CREATE:
XOR EBX,EBX
RET
BREAK
CASE DESTROY:
XOR ECX,ECX
RET
BREAK
ENDSWITCH
RET
ENDF

However, I am not sure if the BREAK is needed since RET could do the same thing, making this:-

Code Select Expand


WndProc FRAME hWnd, uMsg, wParam, lParam
SWITCH uMsg
CASE PAINT:
XOR EAX,EAX
RET
CASE CREATE:
XOR EBX,EBX
RET
CASE DESTROY:
XOR ECX,ECX
RET
ENDSWITCH
RET
ENDF


[donkey]

I agree about BREAK, I had originally had it in my post and edited it out since it seems to be a do-nothing command simply replacing the functionality of RET, For IF/ENDIF etc.. I can only see an advantage to run time conditionals for large blocks so SWITCH/CASE fits the bill much better anyway, it is no great loss not to have IF/ENDIF.

Edgar

[mitchi]

Or else invent a true macro system and let the users create their own macros.
Is that hard to do ?

[donkey]

Or else invent a true macro system and let the users create their own macros.
Is that hard to do ?

The macro system is adequate in my opinion, macros are not something I am generally in favor of and I would hate to see GoAsm go the route of MASM and be polluted with hundreds of useless, poorly documented macros. For many snippets of MASM code I have seen there is not a single assembly mnemonic with the exception of MOV. I have replied to people who downloaded some older piece of code that was infested with macros and were in search of the macro include file just to be able to assemble it, in the end many are required to reverse engineer the macro just to use the code. Also they introduce bugs and the variety of the same macro introduces ambiguity into the code base

I have nothing against creating a more powerful macro engine for GoAsm, however I think that development should concentrate on intrinsic functionality and not follow the path of MASM which has become so winding that its hard to tell if your moving forward or not. The very few macros that I find useful in MASM are already part of GoAsm, in-line quoted strings and unicode to name 2.

Edgar

[GregL]

I would like to see IF/ELSEIF/ENDIF and SWITCH/CASE run-time conditionals made available to those that want to use them. I don't understand why IF/ELSEIF/ENDIF could not be considered because it is implemented in the resource compiler. How would that conflict with the assembler?

[jorgon]

Hi Greg

I don't understand why IF/ELSEIF/ENDIF could not be considered because it is implemented in the resource compiler. How would that conflict with the assembler?

Sorry if I did not make this clear.
Conditional assembly using #IF,#ELSIF,#ENDIF etc. is in GoAsm and GoRC.
To have runtime conditionals using IF,ELSIF,ENDIF etc in GoAsm is potentially confusing because it is so like #IF,#ELSIF,#ENDIF etc.
Or are you saying that this is not potentially confusing?

[Vortex]

Hi Jeremy,

In my modest opinion, adding the runtime conditionals IF,ELSIF and ENDIF would not lead to a confusion.

[GregL]

Jeremy,

I don't think it would be too confusing either.  In MASM there is IF (conditional assembly) and .IF (conditional control flow) and it's not too confusing.

[donkey]

A lack of syntactical ambiguity is a feature I like about GoAsm, though in this case I don't see much problem with separating run-time and assemble-time conditionals. However, if it is an issue there are other keywords, IF is not the only conditional keyword that can be used in this case, WHERE from SQL comes to mind...

Code Select Expand

WHERE eax = 5

ELSEWHERE eax = 6

ENDWHERE

Very clear, readable and no ambiguity.

[Mark Jones]

It would seem ideal, regardless of any chosen format, to clearly delineate which is which, and/or avoid doing what MASM did in terms of .if and if. Where some may see this as a fine delineation, I see this in terms of _ArgV and __Argv -- one tiny and easily-missed character difference. (Us programmers aren't getting any younger ya know... squint squint.)

Or better yet, would it be possible to just use one syntax for all conditionals? #if,#switch,#where, etc.

I'm not suggesting anything be "dumbed-down." Only that GoASM in particular, as Donkey says, has little syntaxical ambiguity as it is, and this is a great feature IMO.

[mitchi]

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

[mitchi]

Or else invent a true macro system and let the users create their own macros.
Is that hard to do ?

The macro system is adequate in my opinion, macros are not something I am generally in favor of and I would hate to see GoAsm go the route of MASM and be polluted with hundreds of useless, poorly documented macros. For many snippets of MASM code I have seen there is not a single assembly mnemonic with the exception of MOV. I have replied to people who downloaded some older piece of code that was infested with macros and were in search of the macro include file just to be able to assemble it, in the end many are required to reverse engineer the macro just to use the code. Also they introduce bugs and the variety of the same macro introduces ambiguity into the code base

I have nothing against creating a more powerful macro engine for GoAsm, however I think that development should concentrate on intrinsic functionality and not follow the path of MASM which has become so winding that its hard to tell if your moving forward or not. The very few macros that I find useful in MASM are already part of GoAsm, in-line quoted strings and unicode to name 2.

Edgar

A proper macro set to do serious work is the following :

Code Select Expand


Invoke
CCall (adds esp + Numparam*4). Very useful if you work with _cdecl a lot

if /else /elseif  /endif.

Proc macros
with LOCAL, arguments and stuff.

Structure macros

switch(number)

case number:
break
case
case
case