SIB byte generation is reversed from MASM when no scaling factor is specified unless -Zg is used. I'm curious as to what is the reason for not always matching the behavior of MASM and requiring -Zg to do so ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's explained somewhere already, but I cannot find it anymore.
In short: the Masm documentation clearly states that, if no scaling factor is used in the expression, the first register ( counting from left to right ) is to become the base, and the second will be index ( unless the second is ESP, because this register cannot be an index register ).
Hence the documentation and Masm v6+ behavior don't match - and I prefer to assume that the buggy part is Masm's behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not assume the MASM documentation is wrong especially considering that the behavior of MASM has been the same since MASM 6.0 ? Also it is a SIB (scale-index-base) byte which suggests that the index is first and the base is second (unless a scale is specified or ESP is used).
I no longer have the MASM 6.0 manual but I would guess that perhaps it worked this way in MASM 5 but was changed in MASM 6 which was a major update and the documentation wasn't updated to reflect this. Anyway JWASM really should follow the behavior of MASM without the need for option -Zg particularly considering this behavior has remained constant since MASM 6.0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dug up MASM 5.10 and checked, the SIB byte generation was indeed reversed. This was changed in MASM 6.0 and has remained the same ever since (at least through MASM 10.0). What is gained by having JWasm copy MASM 5.x behavior by default ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just the code generation differences wouldn't have made me change it, but there are also parsing issues:
1. if both indexing registers are "assuming" something, it matters what's base and what's index.
2. if a memory expression is an operand of OPATTR, it also matters what's base and what's index
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SIB byte generation is reversed from MASM when no scaling factor is specified unless -Zg is used. I'm curious as to what is the reason for not always matching the behavior of MASM and requiring -Zg to do so ?
It's explained somewhere already, but I cannot find it anymore.
In short: the Masm documentation clearly states that, if no scaling factor is used in the expression, the first register ( counting from left to right ) is to become the base, and the second will be index ( unless the second is ESP, because this register cannot be an index register ).
Hence the documentation and Masm v6+ behavior don't match - and I prefer to assume that the buggy part is Masm's behavior.
Why not assume the MASM documentation is wrong especially considering that the behavior of MASM has been the same since MASM 6.0 ? Also it is a SIB (scale-index-base) byte which suggests that the index is first and the base is second (unless a scale is specified or ESP is used).
I no longer have the MASM 6.0 manual but I would guess that perhaps it worked this way in MASM 5 but was changed in MASM 6 which was a major update and the documentation wasn't updated to reflect this. Anyway JWASM really should follow the behavior of MASM without the need for option -Zg particularly considering this behavior has remained constant since MASM 6.0.
> Anyway JWASM really should follow the behavior of MASM
No - it's not supposed to be a Masm-clone.
Dug up MASM 5.10 and checked, the SIB byte generation was indeed reversed. This was changed in MASM 6.0 and has remained the same ever since (at least through MASM 10.0). What is gained by having JWasm copy MASM 5.x behavior by default ?
jwasm v2.10 will copy masm v6 behavior.
Just the code generation differences wouldn't have made me change it, but there are also parsing issues:
1. if both indexing registers are "assuming" something, it matters what's base and what's index.
2. if a memory expression is an operand of OPATTR, it also matters what's base and what's index
Verified fixed in JWasm 2.10rc8