Microsoft MASM bug

[hutch--]

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.

[LiaoMi]

> 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:

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!

 

[LiaoMi]

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?

[dedndave]

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

Code Select Expand

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

[daydreamer]

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?

[aw27]

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

[jj2007]

54.9% of problems solved :P

[ragdog]

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

[hutch--]

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

[ragdog]

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.

[aw27]

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/ , 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/

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