Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: "Rod Pemberton" <do_not_have@xxxxxxxxxxxxx>
- Date: Thu, 21 Aug 2008 06:27:36 -0400
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:g8ij7k$ddr$1@xxxxxxxxxxx
Rod Pemberton wrote:but
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:g8epv7$82s$1@xxxxxxxxxxx
I think we're miscommunicating here, Rod. I know you know your ***,
is...I'm quite certain Ndisasm is "fixed" not "broken" between 0.98.39 and
2.03.01...
I'm still not sure what the justification for that tenacious belief
The source is 16 bits...
Where's your proof? Nasm64developer said so?
Viktor: "Lucian is dead."
Singe: "According to whom?"
AFAICT, you haven't presented any. You ran a test against memory which
wasn't even mentioned as a problem... Why? Because, Phil said run some
unrelated test. I presented proof of the problem and posted the
descriptions confirming that the source as a register isn't 16-bits only.
1) all opcode maps/tables indicate either "Gw,Ew" or "Gv,Ew" for LAR/LSL
I.e., if we go by 386 manual, the destination is 16-bits only too for one of
them... Are you going to claim the destination is only "Gv"? One could
claim "Gw" is correct...
2) all instruction descriptions until recently effectively indicate "Gv,Ev"
for both memory and register
3) very recent instruction descriptions effectively indicate "Gv,Ew" for
memory and "Gv,Ev" for register
4) recent AMD instruction descriptions effectively indicate "Gv,Ew" for both
5) tests on what, two (?), modern cpus indicate effectively "Ew" for memory
6) no tests performed on older cpus
7) there is no method able to determine if the source register is actually
"Ew" or actually "Ev" which can and may be cpu dependent
8) current Intel manuals descriptions indicate "Ew" for memory and "Ev" for
register and have a note clarifying that "Ev" for register is correct
despite the fact that "Ew" in the opcode map
9) to provide a consistent cpu register model and to match the instruction
descriptions, "Ev" is needed for register
10) using "Ew" for the register, breaks macro's being passed 32-bit
registers, violates the cpu register model, and doesn't match the
instruction descriptions which have just as much historical precedent as the
opcode tables
11) feel free to encourage Nasm64developer provide _proof_ of his claims
other than his baseless statement: "Gv,Ew" is in the opcode map and
therefore we should fix the register to "w"...
RP
.
- Follow-Ups:
- Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly
- From: Herbert Kleebauer
- 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
- 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
- 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
- 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):