The MASM Forum

Our friend José inspired me to drop important other work and investigate into the behaviour of his favourite tools:

Quote from: aw27 on August 29, 2017, 06:09:04 PMGood rules dictate that developers must always use the latest versions of their tools. That's what I do. Check with release 14 of MASM then.

Here is a tiny little test routine:include \masm32\include\masm32rt.inc

.code
txEbx db " ebx", 13, 10, 0
txLE db "lesser or equal", 13, 10, 0
start:
  mov esi, offset txLE
  or ebx, -1
  useCRT=0
  .Repeat
print str$(ebx)
print offset txEbx
int 3
.if sdword ptr ebx<=0
nop
if useCRT
invoke crt_printf, esi
else
print esi
endif
.endif
int 3
.if ebx<=sdword ptr 0
nop
if useCRT
invoke crt_printf, esi
else
print esi
endif
.endif
inc  ebx
  .Until !Zero?
  pop eax
  inkey
  exit
end start

The output looks like this, of course:-1 ebx
lesser or equal
lesser or equal
0 ebx
lesser or equal
lesser or equal

This builds and runs fine with UAsm, JWasm, AsmC, and MASM, versions 6.14, 6.15, 8.0, 9.0, 10.0. For example, with useCRT=0 and the int 3's enabled, MASM 10.0 generates the following code:CC                   ³int3
83FB 00              ³cmp ebx, 0                 ; .if sdword ptr ebx<=0
7F 07                ³jg short 0040104D
90                   ³nop
56                   ³push esi                   ; ÚArg1
E8 AB000000          ³call StdOut                ; Àsdword_ptr_encodings.StdOut
CC                   ³int3
81FB 00000000        ³cmp ebx, 0                 ; .if ebx<=sdword ptr 0
7F 07                ³jg short 0040105D
90                   ³nop
56                   ³push esi                   ; ÚArg1
E8 9B000000          ³call StdOut                ; Àsdword_ptr_encodings.StdOut

Straightforward, nothing unusual in there... now try with MASM version 14.0:CC                   ³int3
83FB 00              ³cmp ebx, 0
7F 06                ³jg short 004011AC      ; *** invalid address, should be ..AD
90                   ³nop
56                   ³push esi
E8 BBFEFFCB          Àcall CC401068              ; *** invalid pointer
81FB 00000000        cmp ebx, 0
7F 06                jg short 004011BB
90                   nop
56                   push esi
E8 ACFEFF42          call 43401068              ; *** valid pointer

There are more crappy surprises, if you use useCRT=1 or switch between debug and release mode. It seems that ML 14.0 is unusable for serious work. Not as bad as CrippleWare^TM ML64 (http://masm32.com/board/index.php?topic=5662.0) perhaps, but still... crashing applications won't be popular 8)

Nice example when using the CRT:
004011B1              .  81FB 00000000        cmp ebx, 0
004011B7              . 7F 0A                jg short 004011C3
004011B9              .  90                   nop
004011BA              .  56                   push esi                    ; ³format
004011BB              .  FF15 B4304000        call near [<&msvcrt.printf> ; ÀMSVCRT.printf
004011C1              .  83C4 43              add esp, 43     ; <<<<<<<<<<<< YEAH!!
004011C4              . 74 BB                je short 00401181

Testbed and ML 14.0 executable attached (has int 3s, so it will definitely "crash")

@JJ
Is the masm32rt.inc distributed by Microsoft or are you simply happy to use it?
Should Microsoft adapt MASM to the masm32rt.inc?

I don't know what you guys are whinging about, MASM has always had "features" that you needed to be highly familiar with.  :P

Quote from: hutch-- on August 29, 2017, 08:37:22 PMMASM has always had "features" that you needed to be highly familiar with.  :P

I know, I know... but some of these features have not been officially announced or documented by M$. Here is a test with the other ML.exe included in VS 14.0 (same code as above):

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64_x86\ml.exe
\masm32\include\windows.inc(24749)size
\masm32\include\windows.inc(24749) : error A2042:statement too comMicrosoft (R) Macro Assembler Version 14.00.24210.0
Copyright (C) Microsoft Corporation

The error message looks garbled and no, that's not my fault :icon_cool:

Quote from: aw27 on August 29, 2017, 08:35:24 PM
@JJ
Is the masm32rt.inc distributed by Microsoft or are you simply happy to use it?
Should Microsoft adapt MASM to the masm32rt.inc?

So far I was happy to use masm32rt.inc, all my 5,000+ assembler sources work just fine with masm32rt.inc. But now that your "rules" dictate that one has to use the latest tools from Micros**t, I may have to look for an alternative SDK. Do you have one that you can recommend, José?

Quote from: jj2007 on August 29, 2017, 09:22:45 PM
So far I was happy to use masm32rt.inc, all my 5,000+ assembler sources work just fine with masm32rt.inc. But now that your "rules" dictate that one has to use the latest tools from Micros**t, I may have to look for an alternative SDK. Do you have one that you can recommend, José?

Normally, I don't use 3rd party include files. I don't like blind dates.

The content of the runtime include files is no mystery, its a plain text file that anyone can read. Its done as a convenience so people do not have to look up which function is in which include file, it also puts the files in the right order as far as having the equates and structures first.

Quote from: hutch-- on August 29, 2017, 11:20:02 PM
The content of the runtime include files is no mystery, its a plain text file that anyone can read. Its done as a convenience so people do not have to look up which function is in which include file, it also puts the files in the right order as far as having the equates and structures first.

I am not saying that the include directory is not valuable, it is valuable.  :t

The MASM bug in ML versions 14 and higher hit me again, therefore here a very short demo:include \masm32\include\masm32rt.inc

.code
start:
  xor ebx, ebx
  m2m esi, 9
  .While ebx<esi && sdword ptr esi>=0
print str$(ebx), " "
inc ebx
  .Endw
  inkey chr$(13, 10, "ML14+ sucks")
  exit

end start

An even shorter version without the print statement:
  int 3
  .While ebx<esi && sdword ptr esi>=0
inc ebx
  .Endw
  nop
  nop

Note there are two nops. Now the disassembly:
00401105             .  CC                   int3
00401106             . EB 01                jmp short 00401109
00401108             .  43                   inc ebx
00401109             >  3BDE                 cmp ebx, esi
0040110B             . 73 04                jae short 00401111   ; BUG ************
0040110D             .  83FE 00              cmp esi, 0
00401110             . 7D 90                jge short 004010A2   ; BUG ************
00401112             .  90                   nop
00401113             .  68 00204000          push offset 00402000          ; ÚArg1 = ASCII CR,LF,"ML14+ sucks"
One of the two nops disappeared, and the jge short 004010A2 is a jump to no man's land 8)

ML 10.00.40219.01 still behaves OK. Grateful if somebody can test it with ML 11 ... 13 or higher ML versions. Maybe they have fixed the bug. In any case, my recommendation: UAsm (http://www.terraspace.co.uk/uasm.html#p2) :t

 :biggrin:

You know how I sob silently about MASM bugz, you just call them features and get on with it.  :P

The later version have a new feature, the error messages are unintelligible where the older ones tended to make sense. You tell the men from the boys by the paper they use (large sheet of XXXX sandpaper in the loo), MASM is an industrial tool, don't expect it to hold you hand, it will bite it instead.  :badgrin:

For reporting bugs, Microsoft has a Virtual Agent with optional contact with a real person along the process at:
https://support.microsoft.com/en-us

I had not tried it yet.  ::)

But the best approach is probably from here:
https://developercommunity.visualstudio.com/spaces/8/index.html

I had not tried it as well, but this one might work.    :idea:

Later:
Yeap, I found a bug under investigation here:
https://developercommunity.visualstudio.com/search.html?f=&type=question+OR+problem+OR+idea&type=question+OR+problem+OR+idea&c=&redirect=search%2Fsearch&sort=relevance&q=MASM+14.0+.if+signed+comparison+bug

Probably someone from here can advance and report the other bugs.

makteam provides a solution, too:

QuoteOne 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.)

Quote from: jj2007 on July 20, 2018, 04:14:36 AM
makteam provides a solution, too:

Interesting, but does it work?

No. That's why I proposed the other solution: use UAsm :P

> No. That's why I proposed the other solution: use UAsm

MASM has been around for over 35 years, should we hold our breath waiting for the alternatives ?  :P

Watcom died in the arse, JWASM barely made 5 years and MASM is still going strong, should we be worried ?  :lol:

Do the newer masm also have the bug,where it takes time ala a coffee break while using big numbers in DUP?

Most probably but I doubt it will ever be fixed as its really bad code to start with. If you want big memory, allocate it, that's what its designed for.

Quote from: hutch-- on July 20, 2018, 01:08:35 PM
> No. That's why I proposed the other solution: use UAsm

MASM has been around for over 35 years, should we hold our breath waiting for the alternatives ?  :P

Watcom died in the arse, JWASM barely made 5 years and MASM is still going strong, should we be worried ?  :lol:

Quote from: hutch-- on July 21, 2018, 11:44:32 AM
Most probably but I doubt it will ever be fixed as its really bad code to start with. If you want big memory, allocate it, that's what its designed for.

A man made a suit in a studio. He returns home, put it on. The wife says in anger:
"What did you sew?" Look: one sleeve is longer, the other is shorter.
The floors at the jacket are different, the legs are different. Bring it back!
The husband went back:
"What did you sew me?" Look! Pants of different lengths!
- You can bend one leg in the knee, because you do not go on straight
feet. Then everything will be fine.
- Look, the sleeves are different in length!
- So what? You do not hold your hands on the sides. Bend them in the elbows.
Now everything is fine.
"And the floors?" What to do with them?
- You can lean a little on one side. Now everything is fine.
The man came out in a new suit. People at the bus stop:
"Look at that freak!" How he suffers! But what a cool suit!

  :biggrin:

Quote from: daydreamer on July 20, 2018, 03:23:57 PM
Do the newer masm also have the bug,where it takes time ala a coffee break while using big numbers in DUP?

Hi daydreamer,

is there any example with this bug?

i don't know if there is an example, per se
just try assembling a test program with this in the .DATA? section

buffer db 65536 dup(?)

the code works fine - a buffer is created
but, it takes a long time to assemble
it's a well-known masm bug
usually fixed by breaking the buffer into a few smaller DB's

Quote from: hutch-- on July 21, 2018, 11:44:32 AM
Most probably but I doubt it will ever be fixed as its really bad code to start with. If you want big memory, allocate it, that's what its designed for.

I am not sure if it's both. Data and. Data? Section or just one of them
I don't think it's bad code,I think the masm coder who wrote that part was thinking the same as you: big memory is allocated, dup should be used for create very small buffers ,so nobody tested dup for high numbers before release?
But if every byte needed = one alloc call * some milliseconds no wonder it takes time with high dup numbers
Anyone tested if dup 6554 real10's or bigger data sizes would make it 10 times faster than a 65536 dup with db?

Yeah, Microsoft sent me an email saying that they fixed it  :t (Fixed - Pending Release)
https://developercommunity.visualstudio.com/content/problem/231914/masm-140-if-signed-comparison-bug.html

54.9% of problems solved :P

Not only masm has bugs ,Cl or other too
The biggest bug is the new OS it end with 10  :icon_redface:

MASM has always had interesting "features", whats new ?

https://github.com/UnlimitedChild/x86-x64-Microsoft-Macro-Assembler-bugs/releases

I think M$ has no more quality management ,bugtest?*tester=user ::)
Your can see it  the update problematic on win10 the last and this year.

A new comment on a MASM 14.0 .if signed comparison bug was posted by Blair Wang [MSFT] on Developer Community:

A fix for this issue is now available in the latest preview, Visual Studio 2019 Preview: https://visualstudio.microsoft.com/vs/preview/ (https://visualstudio.microsoft.com/vs/preview/) , which can be installed side-by-side with your existing instance of Visual Studio 2017.  To learn more on how the Visual Studio 2019 preview can help you to be more productive, please visit https://blogs.msdn.microsoft.com/visualstudio/2018/12/04/making-every-developer-more-productive-with-visual-studio-2019/ (https://blogs.msdn.microsoft.com/visualstudio/2018/12/04/making-every-developer-more-productive-with-visual-studio-2019/)

I had not tested VS 2019 Preview yet, but will do it soon.