Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Frank Kotler <fbkotler@xxxxxxxxxxx>
- Date: Sun, 17 Aug 2008 22:32:54 -0400
Rod Pemberton wrote:
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:g880aj$l43$1@xxxxxxxxxxx
Rod Pemberton wrote:"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in messageYeah...? Are you saying this is wrong?
news:g84aq7$vr3$1@xxxxxxxxxxx
Rod Pemberton wrote:Ndisasm 0.98.39
...
I also noticed that 'lfs' and 'lgs' disassembled correctly, butThis is one that's been discovered and fixed.
not 'lds' and 'les'...(?)
00000481 660F02C3 lar eax,ebx
000004F1 660F03C3 lsl eax,ebx
Ndisasm 2.03.01
00000481 660F02C3 lar eax,bx
000004F1 660F03C3 lsl eax,bx
Yeah...? Are you saying this isn't wrong?
I think so, yeah...
If I grant you the interpretation of the fourth, 3 out of 4 in my favor...
;-)
1) Intel 386 Programmers Reference, 1986.
0F 02 /r LAR r16,r/m16
0F 02 /r LAR r32,r/m32
0F 03 /r LSL r16,r/m16
0F 03 /r LSL r32,r/m32
2) IA-32 Intel(R) Architecture Software Developer's Manual, Volume
2:Instruction Set Reference, 2003
0F 02 /r LAR r16,r/m16
0F 02 /r LAR r32,r/m32
0F 03 /r LSL r16,r/m16
0F 03 /r LSL r32,r/m32
3) IA-32 Intel(R) Architecture Software Developer's Manual, Volume
2A:Instruction Set Reference, A-M, 2006
0F 02 /r LAR r16, r16/m16
0F 02 /r LAR r32, r32/m16
0F 03 /r LSL r16, r16/m16
0F 03 /r LSL r32, r32/m16
4) AMD64 Architecture Programmer's Manual Volume 3:General-Purpose and
System Instructions, 2007
LAR reg16, reg/mem16 0F 02 /r
LAR reg32, reg/mem16 0F 02 /r
LSL reg16, reg/mem16 0F 03 /r
LSL reg32, reg/mem16 0F 03 /r
Interesting. What would be the "meaning" of a (16-bit!) selector in a 32-bit reg? If the upper bits are "garbage", it won't work? This looks like a change from m32 to m16 somewhere between 2003 and 2006. Did the behavior of the processor change, or did they fix an error in the manual?
I would "expect" the source operand to be 16-bits, regardless of the processor mode or size of the destination register, a selector being 16 bits. 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... (Only tried lsl, P4, Linux... which could be fuckin' with me...)
Yeah, I realize I'm saying the manual's wrong... but that's what it seems to do...
Best,
Frank
.
- Follow-Ups:
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Rod Pemberton
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Rod Pemberton
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- References:
- NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Rod Pemberton
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Frank Kotler
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Rod Pemberton
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Frank Kotler
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Rod Pemberton
- NASM 0.98.39 vs. NASM 2.03.01 disassembly
- Prev by Date: Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- Next by Date: Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- Previous by thread: Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- Next by thread: Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- Index(es):