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: NathanCBaker on 21 Aug 2008 01:13 On Aug 19, 6:24 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > "Nathan Baker" <Nat...(a)aioe.org> wrote in message > > news:g8des6$3ct$1(a)aioe.org... > > > Frank Kotler wrote: > > >> Given the presentation of the instruction decode lines and the 8/16 > > >> and 8/32 > > >> etc. register separation of the cpu, > > > > I really question this! > > > Me too. > > "Executable code segment. The flag is called the D flag and it indicates the > default length for effective addresses and operands referenced by > instructions in the segment. If the flag is set, 32-bit addresses and 32-bit > or 8-bit operands are assumed; if it is clear, 16-bit addresses and 16-bit > or 8-bit operands are assumed." > > IA-32 Intel(R) Architecture Software Developer's Manual Volume 3A:System > Programming Guide, Part 1, pg 3-14, 2006 > > Mixed mode programming (i.e., overrides) is one way to change the > operational operand and address sizes, but this doesn't change the way the > instructions are *encoded*, as 8/16 or 8/32 etc. > So, is "movzx eax, mem16" really a 16-bit instruction using a 32-bit override; or is it a 32-bit instruction which is doing two 8-bit moves simultaneously?? Nathan.
From: NathanCBaker on 21 Aug 2008 01:44 On Aug 21, 1:13 am, NathanCBa...(a)gmail.com wrote: > On Aug 19, 6:24 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > > > > "Nathan Baker" <Nat...(a)aioe.org> wrote in message > > >news:g8des6$3ct$1(a)aioe.org... > > > > Frank Kotler wrote: > > > >> Given the presentation of the instruction decode lines and the 8/16 > > > >> and 8/32 > > > >> etc. register separation of the cpu, > > > > > I really question this! > > > > Me too. > > > "Executable code segment. The flag is called the D flag and it indicates the > > default length for effective addresses and operands referenced by > > instructions in the segment. If the flag is set, 32-bit addresses and 32-bit > > or 8-bit operands are assumed; if it is clear, 16-bit addresses and 16-bit > > or 8-bit operands are assumed." > > > IA-32 Intel(R) Architecture Software Developer's Manual Volume 3A:System > > Programming Guide, Part 1, pg 3-14, 2006 > > > Mixed mode programming (i.e., overrides) is one way to change the > > operational operand and address sizes, but this doesn't change the way the > > instructions are *encoded*, as 8/16 or 8/32 etc. > > So, is "movzx eax, mem16" really a 16-bit instruction using a 32-bit > override; or is it a 32-bit instruction which is doing two 8-bit moves > simultaneously?? > Too accustomed to thinking in terms of my Masm handbook. I meant to write this in Nasmesse: "movzx eax, word address" a) If it is seen as "a 16-bit instruction using a 32-bit override" then does the assembler truncate the address to 16-bits during encoding? b) If it is seen as "a 32-bit instruction which is doing two 8-bit moves simultaneously" then does the assembler actually encode "movzx al, byte address+1" plus "movzx ah, byte address" into the object file? Randy has been "taking issue" with my bug reports of late. Wait 'til I get my hands on the stuff that Rod has been smoking. :) Nathan.
From: Rod Pemberton on 21 Aug 2008 02:50 "Chuck Crayne" <ccrayne(a)crayne.org> wrote in message news:20080820194210.0bc52145(a)thor.crayne.org... > On Wed, 20 Aug 2008 17:25:27 -0400 > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > > > Four guys who develop NASM reading a.l.a. and I have to file a bug > > report? > > Only because it would appear that you have not yet convinced any of us > that you have a valid case, and the bug report gives you access to a > larger audience. Well, I thought that what I posted originally (16-bit decode below) made it completely obvious. But, it seems I was completely wrong. I also found out later on my own (no help from anyone here... thanks...) that the opcode map and instruction descriptions for LAR and LSL for many generations of Intel and AMD manuals are slightly different. But, to me, it seems that the opcode map fails to make much sense for source register disassembly for LAR and LSL by not fitting the cpu's register model. The descriptions in the later Intel manuals seem to confirm my view. 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 > As I understand your case, (If I state something somewhere else that does or seems to contradict this, this is still the case. Thank you.) Basically, I think Ndisasm (NASM 0.98.39) decoding of LAR/LSL is correct. Ndisasm (NASM 2.03.01) using a fixed 16-bit register is "incorrect". > you have stipulated that the Intel manuals > use the Ew notation for the operand type, which means that the mode bit > is ignored, and the operand is always 16-bits. OK. > However, you then seem > to argue that Intel was correct only in respect to memory operands, No. It seems I (fortunately) didn't mention any memory operands in the "bug" report. I intentionally tried to avoid most mention of it in this thread. While it seems realistic to me that some modern processors do do a 16-bit memory read, I'm not convinced that early processors such as a 386 do a 16-bit memory read instead of a 32-bit memory read with upper 16-bit discard. I don't have logic analyzer to confirm and wanted to stick to register decode size issue instead of the memory operand size issue. What I did indicate was that the source register should be decoded/encoded appropriately for the mode (and adjustable by overrides), and not fixed to 16-bits. > and should have had a separate entry for register operands, > with an Ec notation, Ec? The manual I just looked at says this for "c": "c Byte or word, depending on operand-size attribute" For the source register, I'd think it should be Ev notation. Whether memory is Ew or Ev isn't a concern to me... > along with a footnote that the mode bit is also > ignored in this instance. What? I don't recall recommending ignoring the mode bit anywhere. Nor did Intel state that. In fact, ignoring the mode bit creates the same problem as I'd liked fixed... > You have also stated that "only 8-bit or 32-bit registers should > be displayed for 32-bit mode, and 8-bit or 32-bit registers for 16-bit > mode.", which (ignoring the obvious typo) seems to imply that one > cannot use 16-bit registers in 32-bit mode. Chuck, I hope the above clarified the issue... since my answer (below), although stated elsewhere in this thread is likely to spark extra comments. Well, IMO, that's true in general. Perhaps, my mental model is a bit different... I don't know. One can't use 16-bit GP registers in 32-bit mode except for a few noted instructions where both the opcode map and instruction descriptions match. One can use 16-bit segment registers in 32-bit mode. One can use instructions with hardcoded 16-bit registers in 32-bit mode. One can use an override to convert a 32-bit mode instruction to a mixed-mode instruction and change the effective register size to 16-bits for execution. Rod Pemberton
From: Rod Pemberton on 21 Aug 2008 06:27 "Wolfgang Kern" <nowhere(a)never.at> wrote in message news:g8i5kd$n6h$1(a)newsreader2.utanet.at... > Rod Pemberton wrote: > > I'm still not sure what the justification for that tenacious belief is... > > Yes Rod, > you have to say what you found in conflict with the manuals... > I already posted the instruction descriptions from four manuals that clearly demonstrate that LSL and LAR aren't to be encoded or decoded as 16-bit only, i.e., Ew notation, for the register source operand. That was a.l.a. 8/17/08 2:35 am in this thread. I also posted in the bug report where Intel explicitly clarifies that LSL and LAR do actually read 32-bits of register when the source operand is a register even though that same manual says "Gv, Ew" in the opcode table. > http://sourceforge.net/tracker/index.php?func=detail&atid=106208&aid=2063064 > &group_id=6208 > > but pleese just mention where you found a bug, > or shall we guess it ? I posted the "bug" in a.l.a. on 8/16/2008 4:50 pm, about 11 posts ago from me in this thread. The bug was found by comparing Ndisasm (0.98.39) output with Ndisasm (2.03.01) output using a list of instructions culled from 0.98.39 insns.dat in order to check Willow's assembler. That's where I found a bug: by visual comparison. Is that what you're asking? That post shows that the "bug" is a difference between the way the two versions of Ndisasm disassemble the LAR and LSL instructions. That's the bug I found: a difference. Is that what you're asking? I checked a few manuals for the descriptions of those instructions. Ndisasm (2.03.01) decodings didn't match the instruction descriptions. That's the bug I confirmed: by reading. Is that what you're asking? Is was clear from the instructions descriptions that Ndisasm (2.03.01) decodes a source operand register for LAR and LSL with a fixed 16-bit operand size which is incorrect according to the instruction descriptions. So, I posted. Then, Frank said it wasn't a bug... I also described the "bug" in the NASM report: "Ndisasm is not decoding LAR and LSL to a register appropriate for the mode". I also added two links to a change which I believe caused the problem. Is Nasm64developer's statement of the exact opposite problem unclear too? I believe I've reviewed almost 75% of the thread now... Rod Pemberton
From: Wolfgang Kern on 21 Aug 2008 10:02
Rod Pemberton wrote: >>> I'm still not sure what the justification for that tenacious belief >>> is... >> Yes Rod, >> you have to say what you found in conflict with the manuals... > I already posted ... .... Ok,ok Rod :) The manuals may show it different, so all we need to know is how the CPU interpretes these opcodes. And we checked it. My conclusion on this is that a 66h overide for LAR/LSL in PM32 is useless..wrong, but I'd recommend it for PM16 in mixed environment. And I may repeat myself for I see no fault in: LSL eax,bx because 'this is' what the CPU actually does, no matter how. __ wolfgang |