Hi Jeremy,
When writing an application that I want to assemble as both a 32 bit version and a 64 bit version GoAsm is very flexible when using the header type indicators as well as the RAX/EAX switching. However, there are times, especially when dealing with structures that CMP, INC, MOV etc type indicators have to be changed as well. As an example take the NMHDR structure, which is frequently used in processing the WM_NOTIFY message:
NMHDR STRUCT
hwndFrom HANDLE
idFrom UINT_PTR
code DD
ENDS
Note that the members hwndFrom and idFrom are both resized to QWORDs when WIN64 is defined. In normal use you would use them to verify which control sent the notification as follows:
cmp D[eax+NMHDR.idFrom], SOME_CTRL_ID
if you were assembling under WIN64 you have to change it to:
cmp Q[rax+NMHDR.idFrom], SOME_CTRL_ID
This presents the problem of having to manually go through all of your code to find which ones need to be expanded and which remain unchanged. With data types in the data and constant sections as well as local stack based ones, I can have them redefined by the header project, however there is no such redefinition possible with the data types above. For example this is not possible:
#DEFINE @HANDLE D
cmp @HANDLE[hInstance],0
jne >>.ERROR
I realize that you're busy with the run time conditionals however it would be nice to add this to your ever growing "to think about" list. It is as far as I can tell the last obstacle that we face in order to have the ability to write applications that can assemble for either Win32 or Win64 without modification.
Edgar
A similar situation arose with ANSI/UNICODE strings. S was reserved as a switchable string type indicator and could be defined as either B or W, or even better as 1 or 2 for possible use in other size calculations.
Perhaps P could be reserved as a switchable pointer type indicator, defined as 4 or 8 (D or Q) depending upon WIN64.
Hi Wayne,
Didn't know about the S type indicator, it seems to fit the bill quite nicely. It can be used to switch B,W,D or Q types and though not clearly readable is none the less in keeping with the general syntax of GoAsm. Because it is already reserved for a specific purpose however I hesitate to use it in my projects, as you suggest a P type indicator would work.
Hi Edgar and Wayne
I can add another switch similar to "S" quite easily.
S was introduced to switch the source code at assemble time from ANSI to Unicode.
It works because whenever GoAsm expects a type indicator like B,W,D,Q or T it also looks for S.
S would usually be set to 1 or 2 or to B,W,D,Q or T by an equate controlled by conditional assembly.
The GoAsm help file "Writing Unicode programs" contemplates that S might also be used to switch the length of character strings or buffers (like the CHAR or TCHAR constant) because it will usually be set to 1 or 2 depending on whether the source should assemble as ANSI or Unicode.
It is undocumented that S defaults to 1 if it is not specifically set by a conditional assembly switch.
I can see that it would be useful to add one or more similar switches.
In the context of switching source code at assemble time from 32-bit to 64-bit typically it might need to be a value of 4 or 8 as raised by Edgar.
P ("Pointer" type as Wayne suggests) would seem to be a convenient character to use.
However I would ask whether P ought to be switched automatically by GoAsm depending on whether the x64 switch is used in the command line.
If so it would default to 4 and become 8 when x64 is used.
The alternative would be for P to default to 4 but be controllable in size the same as S.
A further alternative would be to use "X" as the automatic x64 switch (default of 4 changing to 8 if x64 specified).
This would leave "P" free to be added as a further switch which could be controlled generally to any value. For my part I cannot think of any reason to need a further switch like P but I do know that GoAsm is used in many ways I had never thought of!
So do GoAsm users think that the new switch should be automatically switched based on the x64 command line switch, should it be "X" or "P" and should a general switchable pointer type "P" also be added?
Hi Jeremy,
I prefer a switch defined by the user rather than one automatically changed by the x64 switch, but both would be OK as well.
Edgar
Tempting to go automatic with an application being either 32-bit or 64-bit (less mixed scenarios than ANSI/Unicode), but for consistency with S, user defined may be better. I lean towards P for "pointer" type indicator switching. To me, X seems more variable-like for a further general switch if needed (the availability would reduce the potential to use S and P for purposes other than strings and pointers).