Just documenting an .if statement bug in MASM 14.0.23026 and newer. Conditional jumps besides jz/jnz generated from signed comparisons are short by one and end up trashing the resulting code if not accommodated.
COMMENT ~ ASM EXE
#
# ERRATA.ASM
#
# MASM Source - MASM Errata - version 1.0.0.0
#
# Noted differences between MASM versions, some causing problems.
#
# [WH]
#
# (C) All Rights Reserved
#~========================================================================================
include \masm32\include\masm32rt.inc
; int 3 align
align_int3 macro _:REQ
local $$, $$$
$$ equ $
align _
$$$ equ $ - $$
if $$$
org $$
db $$$ dup(0CCh)
endif
endm
; else align
align_else macro _:REQ
local $$, $$$
$$ equ $
align 16
$$$ equ $ - $$
if $$$
org $$
db -($$$ mod 16 lt _) * (16 + $$$ - _) dup(0CCh)
db (($$$ mod 16 lt _) + 1) * ($$$ - _) dup(0CCh)
endif
endm
; nop align
align_code macro _:REQ
local $$, $$$
$$ equ $
align _
$$$ equ $ - $$
if $$$
org $$
db -($$$ mod 4 ge 3) dup(66h)
db -($$$ mod 4 ge 2) dup(66h)
db -($$$ mod 4 ge 1) dup(90h)
dd $$$ / 4 dup(90666666h)
endif
endm
;~========================================================================================
.code
align_int3 16
db @CatStr(<!">,%@Version,<!">),0
align_else 5
EntryPoint textequ @CatStr(<EntryPoint>,%@Version)
call EntryPoint
;~........................................................................................
align_int3 16
EntryPoint proc <forceframe> uses ebx esi edi
local wRegisterLocal:WORD
int 3
align_code 16
; MASM ge 1400 jumps 1 byte short on signed comparisons (jz and jnz work)
.if sbyte ptr al >= "`"
sub al, 20h
.endif
.if sword ptr ax < "``"
sub al, 20h
.endif
.if sdword ptr eax <= "````"
sub al, 20h
.endif
align_code 16
; MASM ge 800 encoding change
cmp al, ah
align_code 16
; MASM lt 800 add unnecessary data size prefix to register mov
push ecx
mov [esp], ss
mov word ptr [esp], ss
mov wRegisterLocal, ss
pop ecx
align_code 16
ret
EntryPoint endp
;~........................................................................................
align_int3 16
end EntryPoint;*/
One potential workaround is to insert a nop before the .endif:
.if sbyte ptr al >= "a"
sub al, 20h
if @Version ge 1400
nop
endif;compat
.endif
(The nop gets consumed by the bug leaving only intended code.)
Note that the following works correctly:
.if sbyte ptr al & "a"
sub al, 20h
.endif
.if !(sbyte ptr al & "a")
sub al, 20h
.endif
.if sbyte ptr al == "a"
sub al, 20h
.endif
.if sbyte ptr al != "a"
sub al, 20h
.endif
This issue affects:
14.0.23026
14.0.23506
14.0.23918
14.0.24210
14.0.24218
14.10.25017
It doesn't affect:
12.0.40629 or older
Those are what I've checked personally, not sure if other builds in the 14.0 or 14.10 versions exist.
Queue
I have noticed that M$ have phuked up ML.EXE with the error messages which are now as buggy as ML64. Looks like the M$ script kiddies have got at it at last. :icon13:
Is there such a thing as Masm 14.0 :icon_exclaim:
MASM 12.0 is part of Visual Studio 2013.
MASM 14.0 is part of Visual Studio 2015.
MASM 14.10 is part of Visual Studio 2017 (though one of those version numbers for 14.0 I listed I also got out of Visual Studio 2017, and I think I recall seeing other executables with a version number of 15, so not sure why 14.10 for MASM).
Personally, I usually just use MASM 6.15, but I keep a large set of different MASM versions to double check for code compatibility issues and it helps me spot bugs like this one. If I was stuck on a desert island I'd probably opt for MASM 7.1 since it doesn't need an external err file but still only has kernel32 as a dependency. Considering how often I use SEH I should probably migrate to it and start using SafeSEH anyway.
hutch, in what way is it effing up error messages? I've only used 14 on already known assemble-able code so haven't seen error messages. 14's certainly looking screwed up enough that I'll probably just write it off as a waste of space, like all the basically broken 64-bit builds of ml.exe.
Queue
Here is a little overview what is available. UAsm64 is my favourite, it's twice as fast as ML* and reliable.
I have always been amused by these comparisons, since the last boxed version, MASM has been industrial software to screw mnemonics together into object modules, any pretence of it being soft friendly consumer software went out the door with ML 6.14 onwards. The ideology of the 1990s was to make everything soft, friendly, easy and usable by morons but MASM escaped this because Microsoft needed it for components of their operating system.
Without having to hold the hot little hand of the timid, MASM in both 32 and 64 bit does the job for people who actually know how to write assembler code but it has never been compromised as soft consumer software. While I have been pleased to see habran/John and nidud developing working assemblers, trying for a backdoor C compiler is simply a mistake that is wasting their work and delaying the output of a finished assembler. I eventually went to 64 bit MASM because it could be used in my lifetime. Both Watcom based assemblers need to get their core assembler up and working as release versions instead of wasting their working time on stray high level ideas.
What are my views on the flood of criticism of MASM, who cares when MASM is finished, made by Microsoft, reliable and working application ready. I have heard all of this bullsh*t before, first the TASM brigade, then years of Betov and a pile of arse kissing cronies and while all of the opposition have bit the dust, MASM is still with us, 2017 versions in both 32 and 64 bit so we know who has the runs on the board and both are at least as unfriendly as they have ever been. :P
I should add to this, the only other stayer is the GNU AS (GAS) which is a very good tool as long as you avoid that disgusting AT&T notation. GAS is so low level you can hear the pushes and pop happening below it but it is capable of producing very good code if the programmer know how to write it. FASM deserves a mention as well, Tomas has produce a very good assembler that is highly reliable and capable of producing very high quality code, my only problem with it is it uses old style TASM notation that drives me nutz.
I'm slightly confused, when did the topic shift to assembler comparisons? On the suggestion of uasm64? I just wanted to document some MASM bugs (and ideally workarounds) and changes in generated machine code between versions. I badmouthed MASM 14 because the type of bug is pretty bad, but it's not like they can't fix it someday (and it's not like I can't either avoid the bug, workaround it, or use a different version of MASM).
Queue
Quote from: hutch-- on August 05, 2017, 12:36:24 PMI have been pleased to see habran/John and nidud developing working assemblers
Me too, they are doing an excellent job :t
Quoteit uses old style TASM notation that drives me nutz.
That's harmless! The latest 64-bit "assemblers" by M$ (http://masm32.com/board/index.php?topic=5956.0) force you to use...
.if wParam == 1
.if lParam {} 3 || pMsg {} WM_COMMAND
.if wParam } 1 || wParam { 4
conout " ----------------------------------------",lf
conout " Ain't Vasily's runtime comparisons great",lf
conout " ----------------------------------------",lf
.endif
.endif
.endif...if you want modern-style
runtime comparison (back on topic :bgrin:).
Shudder :dazzled:
Quote from: Queue on August 05, 2017, 12:58:14 PM
I'm slightly confused, when did the topic shift to assembler comparisons? On the suggestion of uasm64? I just wanted to document some MASM bugs (and ideally workarounds) and changes in generated machine code between versions. I badmouthed MASM 14 because the type of bug is pretty bad, but it's not like they can't fix it someday (and it's not like I can't either avoid the bug, workaround it, or use a different version of MASM).
Queue
Hi Queue,
did you report this discovery to Microsoft?
Reporting won't help. As Hutch correctly wrote, Microsoft does not want it to be user-friendly, so they ignore all user requests. Btw keep away also from this version (which I renamed, of course):
*** Assemble using \masm32\bin\ml64_14_slow /c /Zp8 tmp_file.asm ***
Assembling: tmp_file.asm
** 64-bit assembly **
...
Microsoft (R) Macro Assembler (x64) Version 14.00.24210.0
...
*** build all took 15479 ms ***
The source is this:include \Masm32\MasmBasic\Res\JBasic.inc
Init
MsgBox 0, "Wow, it works!!!!", "Hi", MB_OK
EndOfCode
UAsm64 needs 300 milliseconds to do the job. The good news is YES, it does assemble correctly with ML64 - kudos to Microsoft :eusa_clap:
The bad news is if you insert, for example, a line like bug somewhere, the error messages are garbled:
\Masm32\MasmBasic\Res\JBasic.inc(47)d size
\Masm32\MasmBasic\Res\JBasic.inc(47) : error A2008:syntax \Masm32\MasmBasic\Res\JBasic.inc(48)d size
You can have more fun with Macro Assembler (x64) Version 14.10.24930.0 of 21 Feb 2017. Test it, it's great! Not compatible with anything (work in progress), but it's the latest greatest Microsoft Macro Assembler :t
P.S.: Don't miss the unofficial change list (http://bytepointer.com/masm/index.htm)
Error message from x86 version of Microsoft (R) Macro Assembler (x64) Version 14.10.25017.0 was not trashed.
Avoid Hostx64 version.
So it just take time to fix bugs at MS, they have to learn that ml64 first :P
Their focus is to change the CRT in every version.
:biggrin:
> conout " Ain't Vasily's runtime comparisons great",lf
But sad to say for the whiners, it works just fine and even sadder, MASM has been going strong since 1982. If I wanted a C compiler I would use CL.EXE, when I want an assembler, I want something that screws mnemonics together and if its a MACRO assembler, all the better.
If you are trying to be a purist in assembler, why are the rest trying to ape MASM notation with built in .IF, INVOKE etc ...., when Microsoft only put it there in the first place for a consumer boxed version. I own the last boxed version complete and it was a 16 bit version. That is how old the design is. Like it or lump it, MASM is by far the most widely used Windows assembler and for good reason, it been around for 35 years, what about the rest.
With a MACRO assembler, simple notation for hacky API code is reasonably straight forward to write, it does not need to be a pseudo C compiler to do crap like,
invoke MessageBox,hWin,"How D, Awl","Grittings",MB_OK
If you need someone to hold your hot little hand, try something else, MASM already can produce minimal 64 bit code size, with /LARGEADDRESSAWARE can manage all of the memory in a 64 bit Windows box, AVX2, code as fast as you can write it, full include file and library files and can routinely handle as much memory as the box has available and it is here now today.
None the less I have heard all of this crap before. Japheth started JWASM back in about 2008, never finished it, dumped it and a number of forks have gushed forth out of it. I hope habran/John and nidud get their versions running as release versions in my lifetime but it is not looking like its going to happen any time soon and MASM is here now and works just fine. :badgrin:
Quote from: LiaoMi on August 05, 2017, 06:03:40 PM
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.
Quote from: jj2007 on August 05, 2017, 06:21:25 PM
*** build all took 15479 ms ***
P.S.: Don't miss the unofficial change list (http://bytepointer.com/masm/index.htm)
Like TWell said, that's most likely due to using a 64-bit build. The 64-bit builds of ml.exe also take 10+ seconds and choke on a define in MASM32's windows.inc.
There have been 64-bit builds of ml64.exe since MASM 8.0 and 64-bit builds of ml.exe since MASM 12.0 (at least), and none of the 64-bit builds of ml.exe are any good (they all take 10+ seconds to assemble something that takes less than a second with the 32-bit build, and some versions just crash). I don't know of the state of the 64-bit builds of ml64.exe, but the 32-bit builds should all be good.
That bytepointer site is what prompted me to keep a collection of MASM versions to begin with. :t
Queue
Queue,
The version of ML64 to use in VC2017 is in the x86_amd64 directory at 402,584 bytes. The other works but is really slow to get going.
JWasm is said not for beginners, as it were a characteristic more. Personally, I don't have time to fight against a compiler, I'd expect that the compiler would make my life easier, not the opposite.
I respect the hard work and disinterested around the world, but 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. Alink would be an open source linker to take in account for that, for example. Nevertheless, as I said before, I respect the work that is very good, and everyone can focus their life to where they want, so, nothing to say :t.
In the other hand nasmx and fasm are very good and ready to use. The main difference with masm is that they don't use "offset" or "addr". If you want to get an addres you use "mov eax, var", if you want to take its value you use "mov eax, [var]".
goasm is a very good ready to use packet too. Maybe I miss some more examples in 64 bits.
Quote from: caballero on August 05, 2017, 08:54:47 PMat 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:
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 assemblerOutput, depending only on the OPT_ settings:
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 formatFull 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 (http://masm32.com/board/index.php?topic=94.0) 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 (http://masm32.com/board/index.php?topic=5631.0) that
could perform this task. However, it lacks an occasional switch:
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 ...
ENDIFSimple example for Win64.inc, line 9552:
ifdef __UASM__
_Rip DWORD64 ? ;+0F8h
else
Rip DWORD64 ? ;+0F8h
endifThe
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:
lea rax, [rip+2] ; cannot work with current versions of ML64
jmp @F
db "Hello World", 0
@@:
PrintLine rax
:biggrin:
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.
Quote from: hutch-- on August 05, 2017, 10:58:49 PMis 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 :badgrin:
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.
Quote from: hutch-- on August 05, 2017, 11:40:06 PMI 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:
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.
Quote from: hutch-- on August 05, 2017, 08:46:52 PM
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
Through an update done yesterday I have more recent stuff (Version 14.10.25019.0): :badgrin:
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)
Quote from: hutch-- on August 06, 2017, 01:40:58 AMI 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 :badgrin:
Yeah, the good ol' times when Betov and F0dder were still active. What happened to these guys? (https://www.google.com/search?num=20&newwindow=1&safe=off&site=&source=hp&q="Betov"+"F0dder"+"hutch"&oq="Betov"+"F0dder"+"hutch")
Quote from: Queue on August 05, 2017, 08:19:07 PM
Quote from: LiaoMi on August 05, 2017, 06:03:40 PM
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/
:biggrin:
> 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.
Quote from: aw27 on August 06, 2017, 06:06:56 AM
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