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 15 Aug 2008 19:26 On Aug 15, 12:27 pm, Frank Kotler <fbkot...(a)verizon.net> wrote: > > This is one that's been discovered and fixed. Get the very latest, hot > off the presses, version here: > > ftp://ftp.zytor.com/pub/nasm/snapshots/ > > Or watch it as it happens: > > http://repo.or.cz/w/nasm.git > > Sorry 'bout the "instability"... They complained when it was "dead", > too... :) > Hmm... you give the impression that maybe terms like "stable release", "development release", "snapshot", "unsupported" have little actual meaning. Interesting. Nathan.
From: Wolfgang Kern on 16 Aug 2008 07:25 Thanks a lot for this info Rod, I never bought nor used x386 nor any Cyrix CPU. Except for 0F 7E (MOVD r/m,MMn) these codes seem to be kept reserved by AMD and Intel for 'some reason'. It wouldn't be a huge job to add the few 'Cyrix Special' into my disass, at least as commented 'db', but will it be needed often or at all ? Experience with 286/386 Loadall, which became totally different meanings with 486, make me think that we could renounce of undocumented old codes in todays disassemblers. But perhaps it helps if the disass show them commented with a 'CPU-type' mark, or let the disassemble output switch ? I already have this type marks to to tell about the latest target-CPU, but only documented code for (80x86/186/286/386/486/+586/MMX/SSE..) yet, It would need me to add a few more possible types. But I'm not sure if there would be many demands for it. Disassembly output should be re-compileable, but impossible to produce code with equal size/checksum if even minor architecture-differences... __ wolfgang ---copy:--- > These are in described in the NASM 0.98.39 nasmdoc.txt. The complete > descriptions are too much to post (and probably copyrighted), so these are > first couple of lines from it for each instruction. (You'll notice that > IBTS and XBTS have the same opcode as CMPXCHG486.) > B.4.116 `IBTS': Insert Bit String > > IBTS r/m16,reg16 ; o16 0F A7 /r [386,UNDOC] > IBTS r/m32,reg32 ; o32 0F A7 /r [386,UNDOC] > > B.4.332 `XBTS': Extract Bit String > > XBTS reg16,r/m16 ; o16 0F A6 /r [386,UNDOC] > XBTS reg32,r/m32 ; o32 0F A6 /r [386,UNDOC] > > B.4.295 `SMINT', `SMINTOLD': Software SMM Entry (CYRIX) > > SMINT ; 0F 38 [PENT,CYRIX] > SMINTOLD ; 0F 7E [486,CYRIX] > > B.4.276 `RSDC': Restore Segment Register and Descriptor > > RSDC segreg,m80 ; 0F 79 /r [486,CYRIX,SMM] > > B.4.310 `SVDC': Save Segment Register and Descriptor > > SVDC m80,segreg ; 0F 78 /r [486,CYRIX,SMM] > > B.4.311 `SVLDT': Save LDTR and Descriptor > > SVLDT m80 ; 0F 7A /0 [486,CYRIX,SMM]
From: Rod Pemberton on 16 Aug 2008 16:50 "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 Rod Pemberton
From: Frank Kotler on 16 Aug 2008 21:52 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? Best, Frank
From: Rod Pemberton on 17 Aug 2008 02:35
"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? 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 :-) Rod Pemberton |