Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly

"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:g8an22$v6v$1@xxxxxxxxxxx
Interesting. What would be the "meaning" of a (16-bit!) selector in a
32-bit reg?

Is this a trick question?

If the upper bits are "garbage", it won't work?

Are you implying that 16-bit selectors in 32-bit mode as implemented
currently don't actually work?

This looks
like a change from m32 to m16 somewhere between 2003 and 2006.

Little endian with 16-bit selectors. Basically, irrelevant if the cpu
ignores retrieving the upper 16-bits of a 32-bit value from memory...

Did the
behavior of the processor change,

According to the manual for memory source operands, yes.

or did they fix an error in the manual?

No, I don't believe so.

I would "expect" the source operand to be 16-bits,

ABSOLUTELY NOT! If the cpu is in 32-bit mode and the source operand is a
register, the register size is either 32-bits or 8-bits.

regardless of the
processor mode or size of the destination register, a selector being 16
bits.

In 16-bit mode, you have two register sizes: 8-bit and 16-bit. In 32-bit
mode, you have two register sizes: 8-bit and 32-bit.

As Phil suggests, we could conduct the experiment. I have done so,
both loading upper bits of ebx with garbage, and putting a 16-bit
variable in the last two bytes of valid memory. I conclude that the
source operand is 16 bits...

I think that's a wrong conclusion. You can conclude that only 16-bits of
the source operand are used as a selector. But, you can't determine what
size 32-bits or 16-bits was read in order to obtain the 16-bit selector.

My whole point is how do you get "bx", a 16-bit register, instead of "ebx"
for an instruction decode which can only return an 8-bit or 32-bit register?


Rod Pemberton

.

Relevant Pages