Quick play with UASM

[aw27]

I understand both parts arguments, however it appears that once we select OPTION LITERALS:ON anything enclosed between quotes will be considered a string, even if we don't have a PTR parameter, until we use OPTION LITERALS:OFF, as we do in the code below.
proc2 expects a qword but if we don't deactivate OPTION LITERALS:ON with OPTION LITERALS:OFF    it will not even build.

Code Select Expand


option win64 : 11

includelib \masm32\lib64\kernel32.lib
includelib \masm32\lib64\user32.lib

MessageBoxA PROTO :QWORD,:PTR,:PTR,:DWORD
MessageBox equ <MessageBoxA>
ExitProcess PROTO :DWORD
proc2 proto :qword

.code

proc2 proc myValue : qword
ret
proc2 endp

main proc

OPTION LITERALS:ON
invoke MessageBox, 0, "Hello World", "Title", 0
OPTION LITERALS:OFF
invoke proc2, "abcd"
invoke ExitProcess,0
main endp

end

COMMENT ?
0007ff7`48d31006 33c9            xor     ecx,ecx
00007ff7`48d31008 488d15f11f0000  lea     rdx,[test6+0x3000 (00007ff7`48d33000)]
00007ff7`48d3100f 4c8d05f61f0000  lea     r8,[test6+0x300c (00007ff7`48d3300c)]
00007ff7`48d31016 4533c9          xor     r9d,r9d
00007ff7`48d31019 e819000000      call    test6+0x1037 (00007ff7`48d31037)
00007ff7`48d3101e 48c7c164636261  mov     rcx,61626364h
00007ff7`48d31025 e8d6ffffff      call    test6+0x1000 (00007ff7`48d31000)
00007ff7`48d3102a 33c9            xor     ecx,ecx
00007ff7`48d3102c e800000000      call    test6+0x1031 (00007ff7`48d31031)

?


[hutch--]

This is what has me tossed, in MASM 64 bit with macros, I either get quoted text OR you put a number there, that can be an immediate or a variable and it is easy enough to parse, if the argument starts with a double quote, its a string, if its a number, its an immediate. If it can be done in the pre-processor in MASM it should not be a big deal when you are writing an assembler.

Now I have a work around, make all of the prototypes PTR and the string literals work and everything else is passed as a PTR in 64 bit Windows is 64 bit. Its just that its very untidy and misleading. If someone types "abcd" then it should generate an error.

[johnsa]

Personally.. I would agree that using "abcd" as a numeric expectation/value isn't great in the first place.. but that's how MASM works and there is code out there expecting it to be that way.

I guess it has "a" place (pardon the quoted pun) :)

for example,

CompareDwordAsASCII PROC bufferPtr:PTR, dwordStringValue:DWORD
mov rdi,bufferPtr
mov eax,dwordStringValue
cmp [rdi],eax
....

and you'd call it with:
CompareDwordAsASCII ADDR myBuffer, "heap"

I imagine that most legacy uses are of this sort of style for 1/2/4 char strings.

[johnsa]

AW that sounds like a bug to me in that case, the string should work as a literal string for message box and as a qword with value "abcd" after that.. i'll check that one.

[hutch--]

I think I get what the problem John addressed happens to be. It is common to write mnemonics where you use quoted text for characters.

    cmp eax, "x"    ; and all other data sizes. "xx","xxxx","xxxxxxxx"

This is normal mnemonic coding practice but use it in a function call and it is ambiguous. It can be either quoted text "My Text" or a number "abcd". Rather than inflicting a form of strong typing to stop people from making an error, test if its a valid number "abcde" and generate an error if its not. It is just that quote text is just about universal across programming languages where quoted numbers "1234" are not.

If someone wants to put "abcd" in a function call, they are writing text "abcd". I would suggest that a data type "PTR" should only ever be an equate to the actual pointer size.

    PTR equ <QWORD>  ; in 64 bit

[aw27]

In Visual Studio C/C++, GCC, and others, we can pass multi-character constants within single-quotes. These are called multi-character literals and have type int (i,e 4 bytes). This behavior is considered implementation-defined, i.e, not part of the C/C++ standards.
For example, what C++14 (C is similar) says is:
"
An ordinary character literal that contains more than one c-char is a multicharacter literal. A multicharacter literal, or an ordinary character literal containing a single c-char not representable in the execution character set, is conditionally-supported, has type int, and has an implementation-defined value.
"
One conclusion we can take now is that the standards do not consider qword size (8 bytes) multi-character constants, they are limited to int (4 bytes).
Although is not absurd in Assembly Language to consider qword size multi-character constants, they are not a current practice. However, even if UASM restricts multi-character constants to dword size this will not make happy people that do not use prototypes, or consider them a girly thing - so, is a no-solution. In addition, for ASM is also a no solution to use single quotes specifically for that, since single quotes are an alternative to double quotes. I don't think the grave accent is an excellent solution, but is not bad at all, because not all keyboards have it (but people can always type ALT 96).

An example C implementation:

Code Select Expand


#include <stdlib.h>
#include <stdio.h>

void myFunction1(char *str)
{
printf("%s\n", str);
return;
}

void myFunction2(unsigned int myValue)
{
printf("0x%x\n", myValue);
return;
}

int main()
{
myFunction1("abcd");
myFunction2('abcd');
return 0;
}


Output:
abcd
0x61626364

[hutch--]

I can do this in MASM easily.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    mov rax, "abcdefgh"                 ; load immediate into register

    conout "abcdefgh = ",str$(rax),lf   ; display immediate src string + numeric result

    waitkey
    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end


Screen output,
abcdefgh = 7017280452245743464
Press any key to continue...

[aw27]

I know it required, and still requires, a lot of effort to produce brilliant macros to compensate for the MASM lack of features and shortcomings.
Macros will always have a significant place in all assemblers, whether they are called macro assemblers or not. Actually I never met an assembler that does not do macros and some have a much larger macro grammar than MASM.

This does not mean that we need to make a holy war against more advanced assemblers than MASM is, simply because they prefer to use internal code to replace some hand crafted macros. In my opinion - the perspective of a single user - the code becomes more clean when we don't abuse macros.