masm bugs

[ecube]

I was wondering if this list of bugs for masm is factually correct as some of them sound pretty serious :\


    7. MASM bugs fixed in JWasm

    - the infamous "invoke" bug: using invoke with variables of type BYTE
      (or WORD in 32bit code) causes bad code to be generated in MASM.
    - PROTOs contained twice in the source caused an EXTDEF entry to be
      generated in the object module.
    - PURGE actually works in JWasm.
    - MASM ignores an optional alignment parameter for STRUCTs which have
      just one field (and also for UNIONs, no matter how many fields it has).
      JWasm never ignores this parameter. So a STRUCT/UNION with alignment
      DWORD (or 4) and just one field of size 1 has size 1 in MASM and size
      4 in JWasm.
    - "TYPE xmm0" will return 10 in Masm v6 and v7, JWasm returns 16, same
      as Masm v8.
    - a nested structure might cause a GPF in Masm if the embedded STRUCT's
      starting offset has to be adjusted due to alignment.
    - defining huge arrays in Masm is very slow and might even cause a
      deadlock if COFF has been selected as output format.
    - for Masm v6 and v7, if an array > 64 kB is defined and output
      format OMF is selected, the array's size will be mod 0x10000 only.
    - Masm doesn't flag invalid numbers in struct/array initializer strings.
    - if an ALIAS is defined somewhere in the source and the symbol table
      is listed, a 'General Failure' error occurs in Masm if output format
      is OMF.
    - Type "coerces" for DWORD data items defined in a 32bit segment are
      ignored by Masm, i.e., "dd far16 ptr <symbol>" will generate a
      near32 fixup instead of a far16 one.
    - if the ALIGN directive has to add 5 bytes in 32bit code segments,
      Masm includes an "add eax,0" opcode, which isn't a no-op because
      flags are modified.

    It's slightly dangerous to fix old MASM bugs, since some code might
    work only if the bugs exists. So no, JWasm won't achieve 100% MASM
    compatibility.

[hutch--]

I think japheth has done a great job rebirthing an old pig like WASM into a masm 6.0 compatible assembler but there will always be limits to exact compatibility as masm has itself changed over time. I tend to see an assembler as a tool, not consumer software and I accept that its not exhaustive in its tolerance, error reporting and general use but then it IS an assembler, not a consumer media player so I see no real problem if you bother to use it properly.

JWASM will play a useful role, especially for people who want to write software for different OS's or open source or anything else they like but masm has a massive user base alongside the rest and that will not change in the life of 32 bit Windows. For the coming 64 bit era, FASM and POASM both are capable already and if they have a need Microsoft will probably fix ML64 when the need arises as they use it themselves where they see the need.

[Mark_Larson]

I was wondering if this list of bugs for masm is factually correct as some of them sound pretty serious :\


    7. MASM bugs fixed in JWasm

    - the infamous "invoke" bug: using invoke with variables of type BYTE
      (or WORD in 32bit code) causes bad code to be generated in MASM.
    - PROTOs contained twice in the source caused an EXTDEF entry to be
      generated in the object module.
    - PURGE actually works in JWasm.
    - MASM ignores an optional alignment parameter for STRUCTs which have
      just one field (and also for UNIONs, no matter how many fields it has).
      JWasm never ignores this parameter. So a STRUCT/UNION with alignment
      DWORD (or 4) and just one field of size 1 has size 1 in MASM and size
      4 in JWasm.
    - "TYPE xmm0" will return 10 in Masm v6 and v7, JWasm returns 16, same
      as Masm v8.
    - a nested structure might cause a GPF in Masm if the embedded STRUCT's
      starting offset has to be adjusted due to alignment.
    - defining huge arrays in Masm is very slow and might even cause a
      deadlock if COFF has been selected as output format.
    - for Masm v6 and v7, if an array > 64 kB is defined and output
      format OMF is selected, the array's size will be mod 0x10000 only.
    - Masm doesn't flag invalid numbers in struct/array initializer strings.
    - if an ALIAS is defined somewhere in the source and the symbol table
      is listed, a 'General Failure' error occurs in Masm if output format
      is OMF.
    - Type "coerces" for DWORD data items defined in a 32bit segment are
      ignored by Masm, i.e., "dd far16 ptr <symbol>" will generate a
      near32 fixup instead of a far16 one.
    - if the ALIGN directive has to add 5 bytes in 32bit code segments,
      Masm includes an "add eax,0" opcode, which isn't a no-op because
      flags are modified.

    It's slightly dangerous to fix old MASM bugs, since some code might
    work only if the bugs exists. So no, JWasm won't achieve 100% MASM
    compatibility.

good thing I don't do any of those thigs   :P

[ecube]

projects i've tried to compile with JWasm failed, i'm to lazy to change things to make it work, but perhaps he get's it alil better so compiling can be transparent, I take from the responses these bugs are indeed real which is annoying as I use atleast one of those things...sigh.

[BlackVortex]

projects i've tried to compile with JWasm failed ...

Have you tried the latest version, its masm-compatibility has skyrocketed. Or else report your bugs to japheth, he likes more work   :bdg

[FORTRANS]

    - MASM ignores an optional alignment parameter for STRUCTs which have
      just one field (and also for UNIONs, no matter how many fields it has).
      JWasm never ignores this parameter. So a STRUCT/UNION with alignment
      DWORD (or 4) and just one field of size 1 has size 1 in MASM and size
      4 in JWasm.

   I thought alignment specified the start of a data item or
piece of code?  Not size?  Curfuddeled...

Mark_Larson wrote:

good thing I don't do any of those thigs

   Indeed.  Though it might be mind blowing to try some.

Regards,

Steve N.

Edit:  Reading some posts in the Soap Box/Colosseum makes me
think that the use of slang here may not be advised.  An attempt
to be funny, may be misconstrued.
Curfuddeled = Confused + befuddled.
Mind blowing = too much effort + too confusing + icky

SRN

[Mark_Larson]

a