NASM 0.98.39 vs. NASM 2.03.01 disassembly
in [ASM]
|
Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Wolfgang Kern on 17 Aug 2008 07:14 Rod anwered Frank: .... >> Yeah...? Are you saying this is wrong? > Yeah...? Are you saying this isn't wrong? > If I grant you the interpretation of the fourth, 3 out of 4 in my favor... > ;-) Yes Rod, only AMD seem to got an idea how it works into the manuals :) I just checked on this rare to never used codes: PM16: 0f 02 C0 LSL ax,ax ;...the info will be incomplete 66 0f 02 C0 LSL eax,ax ;ok and usable PM32: 0f 02 C0 LSL eax,ax ;ok and usable 66 0f 02 C0 LSL ax,ax ;...the highword wont be seen here too RM16: (real&unreal) any of exc06 ;ok and the same story is valid for LAR, the returned 32 bits seem to contain byte 4..7 of the segment descriptor here. The source operand is always 16-bit regardless of mode/override. __ wolfgang __________________________________________ > 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 > > :-) > > > Rod Pemberton >
From: Wolfgang Kern on 17 Aug 2008 08:03 I wrote: .... > PM16: > 0f 02 C0 LSL ax,ax ;...the info will be incomplete .... please replace all 02 with 03 in my last post ;) __ wolfgang
From: Phil Carmody on 17 Aug 2008 08:55 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> writes: > LSL reg32, reg/mem16 0F 03 /r I guess someone could align a mem16 2 bytes away from unmapped memory, and see if it traps? If it does, it was really a mem32 not a mem16. Phil -- The fact that a believer is happier than a sceptic is no more to the point than the fact that a drunken man is happier than a sober one. The happiness of credulity is a cheap and dangerous quality. -- George Bernard Shaw (1856-1950), Preface to Androcles and the Lion
From: Frank Kotler on 17 Aug 2008 22:32 Rod Pemberton wrote: > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:g880aj$l43$1(a)aioe.org... >> Rod Pemberton wrote: >>> "Frank Kotler" <fbkotler(a)verizon.net> wrote in message >>> news:g84aq7$vr3$1(a)aioe.org... >>>> Rod Pemberton wrote: >>>> ... >>>>> I also noticed that 'lfs' and 'lgs' disassembled correctly, but >>>>> not 'lds' and 'les'...(?) >>>> This is one that's been discovered and fixed. >>> Ndisasm 0.98.39 >>> 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 is wrong? >> > > 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
From: Rod Pemberton on 18 Aug 2008 02:40
"Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:g8an22$v6v$1(a)aioe.org... > > Yeah, I realize I'm saying the manual's wrong... but that's what it > seems to do... Does "what it seems to do" affect how it should be disassembled? If an old cpu uses reg32 in the instruction operation and a new cpu uses reg16, how should you represent the disassembly of the instruction? Or, should instructions be disassembled to match the manuals? If to match the manuals, which manual when there is a discrepancy or operational change? Rod Pemberton |