Re: disassembler prefix-byte check -- wanting comments good and bad

From: Bx.C (invalid-email-address_at_invalid.shiragajin)
Date: 03/28/04 

Date: Sun, 28 Mar 2004 04:04:55 +0000 (UTC)

(snip)

> <snip>
> > in this way, the only subset i would've had to restore AL before checking,
> > is the four normal segment registers ES/CS/SS/DS... of course, i would've
> > had to place a mov al,cl at the beginning of each of these sections, or
> > handled the data in CL without moving it again...
>
> I really have no idea of what you're talking about. I don't know what cl
> holds. You did not say how you allocated the registers. It was fairly
> obvious that al was the byte you were processing, but beyond that...
>

look back at the original code... immediately before prefix cases are tested, i have this...

 mov al,[bx+si]
 mov cl,al

i needed to save a copy of the byte, because i didn't want to keep reloading from memory
everytime i masked out some of the bits for a grouped test like prefix bytes 26/2E/36/3E... this
is done by AND AL,0E7h and CMP AL,026h

(snip)

> > in any case, the task is NOT complex... and even decoding MOD-REG-R/M and
> > SCL-IDX-BAS isn't very much ASM code at all... it's all done in the same
> > manner... test for exceptions (like Mod-R/M=006h in 16-bit)... if that
> falls
> > through, then go with the rules... AND-Mask the byte, and follow the
> > groupings...
>
> If you plan only to disassemble 16-bit code.
>

if that were the case, why would i bother with the scale-index-base byte? *smiles*

> > i see it as a very simple task...
>
> You have given no mention of the second opcode map. Supporting that and
> 3DNow is the complex part. Supporting the basic Intel stuff through 486 is
> easy. Even supporting though MMX is reasonably easy. After that it gets very
> complex--there are conflicts between Cyrix and Intel opcodes, 3DNow is a
> pain to decode, and SSE is also a pain to decode. With a code-based
> approach, it will be less of a pain for you; however, it will be a lot of
> work with a lot of cases, and it will be a pain to maintain.
>
> I said before that I prefer tables. The reason is because you can resolve
> some of these conflicts in an interesting way--decide which CPU you want to
> disassemble for. If you disassemble for a Cyrix CPU, then you use the Cyrix
> opcodes instead of the Intel ones. It also resolves the loadall/syscall
> conflict. It also simplifies the handling of things like ModR/M and SIB
> decoding and decoding 3DNow.
>

target CPU: AMD x86-64 architecture

phase 1 goal: disassembler library for 16-bit & 32-bit code
phase 2 goal: disassembler library for 64-bit code
phase 3 goal: assembler library for 16-bit & 32-bit code
phase 4 goal: assembler library for 64-bit code

both the 16-bit and 32-bit disassembler portions are being developed right now... the 64-bit
portion will take a bit longer

Relevant Pages

  • Re: Contracting Diabetes
    ... Now learn to snip even more ... Can greater VAT cause visceral pain? ... The reason for excessive intake is the irrational fear of hunger within ... Whether neurological system has some role in persisting hyperglycemia? ...
    (alt.support.diabetes)
  • Re: discouraged
    ... At the same time you can say MOV, ... in front of an operand, ... I'd like to understand how you disassemble with MOV though; ... opcode ' mov-pre ' mov-post operand MOV ...
    (comp.lang.forth)
  • Re: Cognitive Behavioural Therapy
    ... I think the one constant in the phenomenon of POCD is anesthesia. ... Some patients emerge from surgery in pain. ...
    (alt.support.chronic-pain)
  • Re: Polygamy: Solution To Fornication
    ... and laws were made to hedge it in as much as possible - until the final ... though that polygamy had infighting built in, because one was a wife, ... Pain to the woman would be pain to the man. ...
    (soc.culture.jewish.moderated)
  • Re: A new OS war? A possibility according to Architosh
    ... But your beliefs aren't reality. ... > Laughter is a good way to deal with the pain Alan. ...
    (comp.sys.mac.advocacy)