The MASM Forum Archive 2004 to 2012

Project Support Forums => GoAsm Assembler and Tools => Topic started by: Mark Jones on July 13, 2008, 01:15:03 AM

Title: Unicode in-line string literals sometimes produce error?
Post by: Mark Jones on July 13, 2008, 01:15:03 AM
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? :-)
Title: Re: Unicode in-line string literals sometimes produce error?
Post by: jorgon on July 16, 2008, 06:00:18 PM
Hi Mark

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

Many thanks for reporting this.



[attachment deleted by admin]
Title: Re: Unicode in-line string literals sometimes produce error?
Post by: Mark Jones on July 18, 2008, 01:23:02 AM
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
Title: Re: Unicode in-line string literals sometimes produce error?
Post by: jorgon on July 26, 2008, 03:34:32 PM
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!

Title: Re: Unicode in-line string literals?
Post by: Mark Jones on July 29, 2008, 06:38:35 AM
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
Title: Re: Unicode in-line string literals sometimes produce error?
Post by: Mark Jones on July 31, 2008, 03:27:48 AM
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 !
Title: Re: Unicode in-line string literals sometimes produce error?
Post by: jorgon on August 02, 2008, 10:44:27 AM
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]