Unicode in-line string literals sometimes produce error?

Started by Mark Jones, July 13, 2008, 01:15:03 AM

Previous topic - Next topic

Mark Jones

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? :-)
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

jorgon

Hi Mark

Definitely a bug!  Now fixed in the attached version of GoAsm.

Many thanks for reporting this.



[attachment deleted by admin]
Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

Mark Jones

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
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

jorgon

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.

Many thanks for finding these bugs!

Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

Mark Jones

#4
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
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

Mark Jones

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 !
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

jorgon

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]
Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)