MASM 14.0 .if signed comparison bug

[jj2007]

at least in my case it would be good to have a masm alternative package ready to use, unpack and run, with examples with batch files to compile in one click. Easy to use, easy to see. With no external dependencies. I think that in such case masm would desappear and jWasm an forks would reign as real successors.

As I demonstrate every now and then, it is indeed possible to produce include files and macros that work with ML32, ML64 and the WatCom forks:

Code Select Expand

include \Masm32\MasmBasic\Res\JBasic.inc
Init
  Inkey Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format")
EndOfCode

OPT_64         1   ; put 0 for 32 bit, 1 for 64 bit assembly
OPT_Assembler  ML  ; choose your assembler

Output, depending only on the OPT_ settings:

Code Select Expand


This code was assembled with ml64 in 64-bit format
This code was assembled with ML in 32-bit format
This code was assembled with UAsm64 in 64-bit format
This code was assembled with UAsm64 in 32-bit format
This code was assembled with AsmC in 64-bit format
This code was assembled with AsmC in 32-bit format

Full project attached, with source and six executables, all at 1536 bytes. It "compiles" by hitting F6, provided that MasmBasic is installed and you use the RichMasm editor to open the *.asc source. Note that it does not require an additional "MASM64 SDK". It just needs the Masm32 and MasmBasic packages, and UAsm, nothing else.

So, with a little bit of goodwill, it is possible to use both Microsoft ML64 (requiring .if eax}=edx) and UAsm (happy with .if eax>=edx) with identical sources and include files.

The problem is that JBasic.inc is just a proof of concept; the necessary macros and includes for both ML and UAsm will not fall from heaven, and I will not write them simply because I don't believe that 64-bit code is any better than 32-bit code :P

Note there is a big and sophisticated macros and include files package that could perform this task. However, it lacks an occasional switch:

Code Select Expand

IFDEF __UASM__
   ... use syntax that is compatible with Microsoft MASM, 32-bit version, plus UAsm, JWasm and AsmC ...
ELSE
   ... use syntax that is compatible with Microsoft MASM, 64-bit version, and nothing else ...
ENDIF

Simple example for Win64.inc, line 9552:

Code Select Expand

ifdef __UASM__
   _Rip DWORD64 ? ;+0F8h
else
   Rip DWORD64 ? ;+0F8h
endif

The Rip in CONTEXT STRUCT works only with ML64, because in other assemblers it is the name of a register (i.e. a reserved keyword), used e.g. as follows:

Code Select Expand

  lea rax, [rip+2]  ; cannot work with current versions of ML64
  jmp @F
  db "Hello World", 0
@@:
  PrintLine rax

[hutch--]

 

Yeh, but why haven't you included FASM, GAS and anything else or is it the same veiled criticism of anything that does not fit your model of Microsoft's 1990 16 + 32 bit ML format to the exclusion of anything else. When it comes to 64 bit, I prefer simplicity to the unnecessary clutter of a plethora of options compromised across a range of different tools and OS bit size versions.

> and I will not write them simply because I don't believe that 64-bit code is any better than 32-bit code

Until you have to start whacking around multi-gigabytes. It can be done in 32 bit but it involves some really messy code and it is nowhere as fast on big data. Then of course with twice as many registers you can set up lower overhead procs without stack overhead of preserving and restoring registers in many cases.

I already have the tools to write 32 bit code with the MASM32 SDK and it is useful in many cases but there is no substitute for 64 bit with large data or output speed. Writing 8 bytes at a time beats writing 4 bytes at a time and you have far more memory than in 32 bit. Does 2 gig allocation limit ring a bell, try 48 gig in 64 bit, more if you have enough memory and you can start to take advantage of legacy SSE, AVX and AVX2.

What I am not committed to is looking for anything that is not Microsoft, I will happily use CL, ML, ML64, LINK, DUMPBIN, EDITBIN, LIB, RC as they all work OK, cost me nothing and are components of the world's most used tool set.

[jj2007]

is it the same veiled criticism of anything that does not fit your model of Microsoft's 1990 16 + 32 bit ML format

Sorry, but it is you who is hammering that we don't need that modern .if eax>=edx crap to hold your hot little hand if we, real men^TM, can also use only the pure mnemonics that ML64 understands

[hutch--]

You forget that I went through the assembler wars 15 to 20 years ago and I have heard it all before. You may not like Vasily's {} notation but it works fine. I personally don't like the clutter, stack twiddling and the plethora of near useless options that I see in the forks but I try and support the authors but your endless criticism supporting them will eventually bring my criticism in return and trust me, I am well practiced.

I comfortable write VC 32 bit inline assembler with no high level notation just as I write Intel notation in 32 bit basic without high level notation so I am not all that dependent on the hand holding you are dependent on. There is a simple rule, if you choose to be a critic, you have also chosen to be the target of criticism.

[jj2007]

I am not all that dependent on the hand holding you are dependent on.

If you consider .if eax>ecx or an invoke macro that checks and counts arguments "hand holding", then I plead guilty of being a n00b. Honestly, you can be really proud of the Masm32 package, it has sparked a revolution, as you write yourself occasionally. But please ask yourself if you are doing yourself a favour preventing people from using modern tools and syntax.
:icon14:

[hutch--]

You are wasting your time with the hard sell, I used ML 6.14 to its capacity but it is not subject to your attempt to re-interpret it to supporting anything else, it is what it is based of the capacity that was available. Noting that the project was started 20 years ago, I have other options which allow me to do other things and things that are different which I have not been able to do due to the architecture being set to ensure that the project did not break any other person's code.

As the shift from 16 bit DOS to 16 bit Windows and later to 32 bit Windows involved changing many things, I refuse to be locked in the past and have developed 64 bit MASM with the capacity it has and to be honest, I develop a lot faster with it than in 32 bit MASM. Back in 32 bit I had to develop a lot of macros to get around the locked in PROTO / INVOKE / PROC notation that I am completely free from in 64 bit MASM. I use the .if notation from Vasily and the .switch macro that uses it with no problems. With over 130 macros and just over 90 library modules and it just keeps getting more powerful.

> preventing people from using modern tools and syntax

I have already mentioned other assembler not on your list, FASM is an excellent assembler, GAS is a GAS and then there is Bogdan's and a host of others. 64 bit MASM is a lower level tool than the 32 bit version but it still has the old MASM pre-processor and most things can be done with it. This notion that your preferred assembler(s) are "modern" is just another open sauce sales pitch. I have put up with this chyte for years because I will not kiss the arse of open sauce and be sure of this, I never will. Its like pissing resource down a black hole and you never get anything back except their phuking licence.

When the MASM32 project was first started there were a heap of people who contributed, now its just bludgers sucking the life out of anything they can get while never contributing anything of their own. I don't write code for other assembler as I get nothing back from them except the same old chyte, its time for someone to get off their arse and write their own help file, libraries, include files and other accessories because I am not going to do it for them.

I don't know why you persist with these recurring tirades, I am simply not interested but if it keeps up I can happily retaliate as I have many years of practice in the assembler wars.

[Queue]

The version of ML64 to use in VC2017 is in the x86_amd64 directory at 402,584 bytes.

There are 4 copies of ml64.exe in VS2017 (that I've found).

The one you note is the 32-bit build for 14.0.24218, is with the Visual C files, and appears to be a slight bugfix (though I have no clue what the bug would be, there's just a slight change in code between the two that looks bugfixy) and rebuild of 14.0.24210 (which was from VS2015 Update 3 if memory serves) which was also 402,584 bytes, so file size has at least one collision among the MASM 14 builds.

With the Visual C files is also a 64-bit build for 14.0.24218 at 528,536 bytes, which I'm sure is the one you warn is slow.

With the Visual C++ "Tools" files is a newer pair of ml64.exe files for 14.10.25017 weighing in at 404,632 bytes and 530,576 bytes for the 32-bit and 64-bit builds, respectively.

Not sure how 14.10.25017 stacks up to 14.0.24218.

Queue

[aw27]

Through an update done yesterday I have more recent stuff (Version 14.10.25019.0):
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64
ML64 518 KB (530,552 bytes)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x86
ML 567 KB (580,728 bytes)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64
ML64 395 KB (404,600 bytes
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86
ML 437 KB (448,120 bytes)

[jj2007]

I don't know why you persist with these recurring tirades, I am simply not interested but if it keeps up I can happily retaliate as I have many years of practice in the assembler wars.

Glad we can agree on something

Yeah, the good ol' times when Betov and F0dder were still active. What happened to these guys?

[aw27]

did you report this discovery to Microsoft?

No, I haven't. I don't even know where I could report this sort of information to Microsoft.

You can try https://connect.microsoft.com/VisualStudio/

[hutch--]

 

> Yeah, the good ol' times when Betov and F0dder were still active. What happened to these guys?

Interesting the Japheth tried the same trick of appealing to ancient alt.lang.asm postings for what he could get out of it.

[Queue]

Through an update done yesterday I have more recent stuff (Version 14.10.25019.0):

Thanks for the heads up. I hadn't noticed there were even newer ones.

Queue