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: Alexei A. Frounze on 18 Aug 2008 03:17 On Aug 17, 11:40 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > "Frank Kotler" <fbkot...(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 This form of disassembly may do the trick if you're too cautious: DB bytes ; mnemonic Alex
From: Rod Pemberton on 18 Aug 2008 03:37 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:g8an22$v6v$1(a)aioe.org... > 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
From: Rod Pemberton on 18 Aug 2008 03:53 "Wolfgang Kern" <nowhere(a)never.at> wrote in message news:g893bb$ffj$1(a)newsreader2.utanet.at... > Yes Rod, only AMD seem to got an idea how it works into the manuals :) I think AMD got it wrong their manual. I believe this, which implies the source operand is 16-bits in all cases: > 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 Should've been this, with the register size for 32-bit mode being 32-bits: LAR reg16, reg16/mem16 0F 02 /r LAR reg32, reg32/mem16 0F 02 /r LSL reg16, reg16/mem16 0F 03 /r LSL reg32, reg32/mem16 0F 03 /r > The source operand is always 16-bit regardless of mode/override. 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. So, how can a register as the source operand be a 16-bits in 32-bit mode? Please also read my post to Frank which begins "Is this a trick question?" Rod Pemberton
From: Wolfgang Kern on 18 Aug 2008 06:05 Rod Pemberton wrote: > Frank Wrote: (...about...and in reply to my other post) >> regardless of the processor mode or size of the destination register, >> a selector being 16 bits. Right, and also memory source is only 16 bit then. > 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. .... > 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? Yes for general purpose instructions, but when segment-selectors were involved the story become 'special', similar to SMSW AX and FSTSW AX. Also PUSH/POP-seg work on 16 bit only even stack may change by 4 byte. >> 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... Me too checked it out on LSL/LAR with memory-operands at the last two bytes of a segment, no exception occured, so I may confirm (on AMD) that the source is always 16-bit for these instructions. But Rod's claim exposed: PM16: 0f 03 C0 LSL ax,ax ;...the info will be incomplete *1) 66 0f 03 C0 LSL eax,ax ;ok and usable *2) PM32: 0f 03 C0 LSL eax,ax ;ok and usable *2) 66 0f 03 C0 LSL ax,ax ;...the highword wont be seen here too *1) only usable in a rare seen strict PM16 environment. *2) this two are the only versions which make sense to me (16/32 mix). similar to useless MOVSX/ZX word..and BSWAP w/o 66h in 16 bit modes. Also for LAR, because info from this instruction is also 32-bits wide even the highword may not be of interest in most case. __ wolfgang
From: Rod Pemberton on 18 Aug 2008 17:42
"Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message news:g8b8t9$bg0$1(a)aioe.org... > 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? > For arpl, lldt, lmsw, ltr, str, verr, and verw instructions, the manuals consistently present one instruction decode line (16-bit only). One exception is that new AMD manuals presents 16-bit, 32-bit, and 64-bit decodes for str. For lar and lsl, the manuals consistently present at least two instruction decode lines (16-bit, 32-bit). Given the presentation of the instruction decode lines and the 8/16 and 8/32 etc. register separation of the cpu, I don't believe the decode for lsl, and lar should be treated the same, i.e., using a fixed 16-bit register, as those for arpl, lldt, lmsw, ltr, str, verr, and verw. AFAICT, although there are some instructions fixed to 16-bit registers only, there currently is no 32-bit instruction that uses _both_ a 32-bit register and a 16-bit register as Ndisasm is "doing to" lar and lsl... Rod Pemberton |