Hi, sometimes the code snippet below (in red) will cause a "Must have new label after uninitialised data" error:
Quote
STRINGS UNICODE
#include "C:\GoAsm\IncludeW\WINDOWS.inc"
#include "C:\GoAsm\IncludeW\all_api.inc"
...
.data
hCout dd ?
OptionC db ?
OptionD db ?
OptionE db ?
.code
invoke GetStdHandle,STD_OUTPUT_HANDLE
mov [hCout],eax
...
ot:
...
: cmp al,"C" ; option C
jne >
mov b[OptionC],1
invoke coutt,[hCout],<"Option C selected",13,0,10,0,0,0>
jmp <ot
: cmp al,"D" ; option D
jne >
mov b[OptionD],1
invoke coutt,[hCout],<"Option D selected",13,0,10,0,0,0>
jmp <ot
: cmp al,"E" ; option E
jne >
mov b[OptionE],1
invoke coutt,[hCout],<"Option E selected",13,0,10,0,0,0>
jmp <ot
...
coutt frame hConsole,lpTextW ; console-out (threaded)
local n ; threading code omitted
xor eax,eax ; get length of text arg
mov ecx,[lpTextW]
: cmp w[ecx+eax],0
jz >
add eax,2
jmp <
: shr eax,1 ; eax = n unicode chars
invoke WriteConsole,[hConsole],[lpTextW],eax,[n],0
ret
endf
However, if the offending line is replaced by
invoke coutt,[hCout],"Option C selected"
...then it will complile and run normally -- with no errors on any of the remaining string immediates. Any ideas? :-)
Hi Mark
Definitely a bug! Now fixed in the attached version of GoAsm.
Many thanks for reporting this.
[attachment deleted by admin]
Many thanks for the quick reply and fix Jeremy. :bg
I have another code question involving string literals. Is it by design that __debug9 is not being recognized in this "debug echo" macro?
STRINGS UNICODE
...
; uncomment to make build debug (tons of extra data echoed to console)
#define __debug9
; debug echo macros - echo inline text to hCout (only if a debug build)
#define decho(%lpTextW) = \ ;
#ifdef __debug9 \ ;
invoke coutt,[hCout],addr %lpTextW \ ;
#endif
#define decho2(%lpTextW) = invoke coutt,[hCout],addr %lpTextW
decho3(%lpTextW) macro
#ifdef __debug9
invoke coutt,[hCout],addr %lpTextW
#endif
endm
decho4(%lpTextW) macro
invoke coutt,[hCout],addr %lpTextW
endm
...
CODE SECTION
start:
nop
decho(<"*** DEBUG Build ***",13,0,10,0,0,0>) ; seems to do nothing
decho("*** DEBUG Build ***") ; seems to do nothing
;decho2(<"*** DEBUG Build ***",13,0,10,0,0,0>) ; "data not closed with > operator"
decho2("*** DEBUG Build ***") ; <-- works
;decho3(<"*** DEBUG Build ***",13,0,10,0,0,0>) ; "More material expected .."
;decho3("*** DEBUG Build ***") ; "More material expected .."
;decho4(<"*** DEBUG Build ***",13,0,10,0,0,0>) ; "data not closed with > operator"
decho4("*** DEBUG Build ***") ; <-- works
nop
I'm trying to let one global #DEFINE toggle subsequent macro expansion. Thanks for all your hard work. :U
QuoteIs it by design that __debug9 is not being recognized in this "debug echo" macro?
Definitely not! See fix for this and other issues you raise (http://www.masm32.com/board/index.php?topic=9572.0).
Many thanks for finding these bugs!
Thanks Jeremy, workin' great! :U
[Edit]: Actually, I might have found something else, sorry! :red
STRINGS UNICODE
#define ccBlack EQU 0
#define ccDarkBlue EQU 1
#define ccDarkGreen EQU 2
#define ccSoftBlue EQU 3
#define ccDarkRed EQU 4
#define ccDarkPurple EQU 5
...
; uncomment to make build debug (tons of extra data echoed to console)
#define debug
; debug echo macros - echo inline text to hCout (only if a debug build)
#define decho(%lpTextW) = \ ;
#ifdef debug \ ;
invoke coutt,[hCout],addr %lpTextW \ ;
#endif
dechoc(%lpTextW,%CCode) macro
#ifdef debug
invoke couttc,[hCout],addr %lpTextW,%CCode
#endif
endm
start:
...
decho(<"*** DEBUG Build ***",13,0,10,0,0,0>) ; works :-)
dechoc("*** DEBUG Build ***",ccDarkRed) ; works...
dechoc(<"*** DEBUG Build ***",13,0,10,0,0,0>,ccDarkRed) ; error
The first "debug echo colored" macro expands properly, but the second one (using the <> string literal) stops with "Use square brackets to address memory, ADDR or OFFSET to get address:- %CCode." :toothy
Edit: the issue was only occuring on certain text, and with further testing it appears to only occur in a <> string which contains any of the following: "-+*/&|;".
Changing the line above to read:
dechoc(<"!!! DEBUG Build !!!",13,0,10,0,0,0>,ccDarkRed) ; <-- works now, * changed to !
Hi Mark!
Thanks for spotting this and reporting it.
This was happening because when inserting arguments in macros, GoAsm has to be careful to ensure correct arithmetic priority
eg:-
event(x,y) = (x+y)
a = event(30,b & c)
needs to become (30+(b & c)) instead of (30+b & c)
So GoAsm was adding the bracket when it thought appropriate. However there was no allowance for the use of <.....> type data in an argument which meant that the comma separating the two arguments in your code was being written over by a bracket added by GoAsm. I have now ensured that <.....> type data in an argument is now being jumped over by the parser dealing with arithmetic priority, hence the problem is solved in the attached version of GoAsm.
[attachment deleted by admin]