OPTION LITERALS in 32 bits

[habran]

Good thinking, Nidud
I can see that PURGE directive can be quite useful, however, I am not familiar with PURGE directive, I never used it. Can you give me one example of its usage.
I am sure that DEFINE can be implemented in C source to be more useful. I did it with macro to see if it can find a purpose in ASM programming. If so, we can than extend its usage. I'd like to have it built in as assembly directive.

[nidud]

deleted

[habran]

I have implemented it  and works well. :t
The advantage is that it reports an error if the variable is not defined, while macro doesn't
DEFINE macro is fine in that regard and it can stay as macro.

[johnsa]

Hey,

Right so we've put in some other changes to 2.39 and fixes apart from the really cool DEFINE/UNDEF directives which now means BOTH of these styles work simultaneously with option literals:on

Code: [Select]


.386

.model Flat, C
option Casemap :None
OPTION LITERALS:ON ; Allow string literals use in INVOKE

TRUE equ 1

includelib c:\masm32\lib\ntdll.lib
RtlCompareString PROTO STDCALL :ptr,:ptr,:BYTE
RtlInitAnsiString PROTO STDCALL :ptr, :ptr

includelib c:\masm32\lib\msvcrt.lib
printf PROTO :PTR, :vararg

includelib c:\masm32\lib\kernel32.lib
ExitProcess proto STDCALL :dword

_STRING struct
_Length word ?
_Maximumlength word ?
_Buffer dword ?
_STRING ends

.data
format db "result: %d",13,10,"%s",13,10,0
s1 db "someStr",0 ;
s2 db "anotherStr",0 ;

.code

main proc
LOCAL str1 : _STRING
LOCAL str2 : _STRING

INVOKE RtlInitAnsiString, addr str1, "someStr"
INVOKE RtlInitAnsiString, addr str2, "anotherStr"
INVOKE RtlCompareString, addr str1, addr str2, TRUE
INVOKE printf, "result: %d\n%s\n", eax, "test"

INVOKE RtlInitAnsiString, addr str1, addr s1
INVOKE RtlInitAnsiString, addr str2, addr s2
INVOKE RtlCompareString, addr str1, addr str2, TRUE
INVOKE printf, addr format, eax, addr s1


INVOKE ExitProcess,0

main endp

end main



[hutch--]

Good modification John.  :t

[jj2007]

Code: [Select]

include \masm32\include\masm32rt.inc

OPTION LITERALS:ON

.code
start:

  invoke WriteConsole, rv(GetStdHandle, STD_OUTPUT_HANDLE), "this is a string", 16, 0, 0
  invoke WriteConsole, rv(GetStdHandle, STD_OUTPUT_HANDLE), cfm$("this\nis a\nstring\n"), 20, 0, 0

  inkey "ok?"
  exit

end start
The first WriteConsole line chokes with

Code: [Select]

Error A2145: INVOKE argument type mismatch: argument 2
Tmp_File.asm(8) : Error A2274: Constant value too large: 74686973206973206120737472696E67h
Which syntax would work correctly?

The second line works fine with version 2.39, not surprisingly - after all, cfm$() is a well-tested Masm32 macro. Besides, it remains compatible with MASM, in contrast to the first line.

However, with version 2.38 of 2 August, it produces

Code: [Select]

siht
a si
gnirts
?ko ;)

[aw27]

@JJ,
The team has said that it is necessary the argument to be a pointer to use a literal.
The prototypes in the include directory are not made for type checking, which is a pity.

[hutch--]

My comment on some of the development is that it seems to be going in the wrong direction, you have three aspects of code production in a MACRO assembler.

1. The mnemonic cruncher, IE, the assembler.
2. The MACRO engine and its capacity to write perfect assembler.
3. The dedicated libraries that can be used with the assembler.

If you maintain this set of distinctions, you can concentrate on the main work which is the assembler where if you start to blur this set of distinctions, you are starting to write a compiler. There is value in providing .IF blocks, .SWITCH blocks, call automation and the like as it improves the throughput of shovelling through high level API and similar styles of code which in turn leaves you with more time to write the stuff that matters, genuinely high speed pure mnemonic code.

Running as open an architecture as possible is the best option for an assembler where restricting the format to produce high level code is a mistake that goes in the direction of a compiler. I see that John and Habran have done some very good work in the development of UASM and I would hate to see it go into the direction of a pseudo compiler, the drift of my comments is make it into a grunty pure "can do" assembler and leave algorithm design to the libraries and macro engine.

[jj2007]

Agreed :t

UAsm is an extremely valuable project, as it offers the full functionality of MASM at much higher speed (3x), at a time when Microsoft cripples ML64 to something that can be used by a compiler but sucks from a programmer's point of view.

OPTION LITERALS may be useful for some people, but if my code gets incompatible with assemblers that are still widely used by others, then I may have a problem; if the libraries need to be rewritten (:DWORDs to pointers...), I have a big problem. And there is absolutely no need for this fight: In the rare occasions when I have to pass a literal string to an API, I can use

Code: [Select]

invoke someapi, chr$("Hello World")  ; Masm32
invoke someapi, cfm$("Hello World\x")
invoke someapi, chr$("Hello World")  ; MasmBasic
What makes me reluctant at this moment to recommend UAsm (but I still do recommend it!) is this juggling with wild options, and the implicit accusation "why, didn't you read point 3.5.6, options xyz, of that nice manual that I wrote for you?".  It is a tool, it is supposed to be compatible with everything I've coded so far with MASM. It should do its job, nothing else. And I fully agree with Hutch: I really don't need yet another C compiler.

[hutch--]

 

> invoke someapi, chr$("Hello World")


Or write a decent MACRO that allows,
invoke someapi, "Hello World"

[johnsa]

It's always a challenge to come up with new features while maintaining the compatibility. That is the main reason for all the extra option settings.
For general use where you may want to be fully masm compatible I'd leave option literals off and use macros instead, we could/should even bundle these into the built-in macro library?

Where I personally saw the literals being useful is when you're writing a lot of custom code that deals with string processing, in which case you can easily switch literals on and then back off again.

OPTION LITERALS:ON

invoke catStr, "result is: ", ADDR resultmsg
invoke replaceItem, ADDR curString, "rd",  "road"
invoke replaceItem, ADDR curString, "rod",  "road"
invoke replaceItem, ADDR curString, "roads",  "road"

and so on.. while it's possible to use the macro method, this a) looks slightly neater and b) re-uses existing string data to reduce data bloat.. so there'd only be a single instance of "road" in this example.

Everything we do we will always try to make work in a way which is either compatible, or extended via an option of some sort.. The problem is at some point, if you start using features it will become incompatible with masm.. like switch, floating point hll comparison, conditional flags, improved union initialization and so on.. I can't see any way around this apart from being knowledgeable enough to know that if you may require that level of compatibility with other assemblers use the features sparingly or not at all.

To say that we shouldn't add these features as it breaks masm compatibility is sort of a bit defeatist, if we do that we cannot add most of the nice to have or useful stuff at all.
We also mustn't forget that we're building up a lot of use on the Linux front where compatibility with masm is non-issue, there we have users who may want us to make it nasm or gas compatible!

You cannot please everyone all of the time :)

[jj2007]

To say that we shouldn't add these features as it breaks masm compatibility is sort of a bit defeatist, if we do that we cannot add most of the nice to have or useful stuff at all.

John,

You and Habran are doing an excellent job, no doubt. And I am not against new features, but one must be careful not to break existing code. For example, a dedicated new macro library is a good thing, but it can be a nightmare if it intrudes into the namespace of an existing library. Imagine, for example, that UAsm supplies a macro library that understands

Code: [Select]

print str$("The number is %i\n", eax)
This is Masm32 SDK syntax...

This is why the default option should remain "fully compatible, no extra macros".

[johnsa]

In terms of the macro library that is ok. The macro library is evaluated before any actual source code, so if you include macros which overlap with stuff in the library it simply replaces the library with your version of the said macro. So as long as the intention and use of the macro is equivalent then it shouldn't affect the outcome. The ones we've included so far are compatible with the implementations from MASM32, granted there are only a few so far but I agree with you 100% if we add a built-in one it should conform so that code written for assembly under ML using MASM32 macros should be identical under UASM with the built-in library. :)

[jj2007]

if you include macros which overlap with stuff in the library it simply replaces the library with your version of the said macro.

Sounds ok. How do you handle the case when UAsm has a built-in foo macro, and Masm32 sdk uses

Code: [Select]

Ifndef foo
  foo macro ...
Endif?

Testcode:

Code: [Select]

include \masm32\include\masm32rt.inc
.686p
.xmm
ifdef ASDOUBLExxxx
.err <already defined> ; without the xxxx, this error will be triggered
else
  ASDOUBLE macro xmmreg
EXITM FP8(1111.1111)         ; triggers "not equal"
  ENDM
endif
.code
start:
  movlps xmm0, FP8(123.456)
  movaps xmm3, xmm0
  .if (xmm0 == ASDOUBLE(xmm3))
inkey "equal, built-in mlib macro is active"
  .else
inkey "user's macro is active"
  .endif
  exit
end start

[hutch--]

This may be virtuous if you are trying to remain compatible with 32 bit MASM but for 64 bit code, either for Windows or Linux you really need a completely different set of macros and here I would be inclined to tweak the macro engine for 64 bit code without having to remain MASM compatible. The old MASM macro engine can be coaxed to do most things with enough dedication but I would imagine that you can do a lot better in a brave new world of 64 bit code.