Related articles |
---|
Writing a disassembler ? lightfault@gmail.com (So and so) (2008-10-10) |
Re: Writing a disassembler ? j.vimal@gmail.com (Vimal) (2008-10-11) |
Re: Writing a disassembler ? jeffrey.kenton@comcast.net (Jeff Kenton) (2008-10-11) |
Re: Writing a disassembler ? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-10-11) |
Re: Writing a disassembler ? sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-10-11) |
Re: Writing a disassembler ? ArarghMail810@Arargh.com (2008-10-11) |
Re: Writing a disassembler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-10-12) |
[3 later articles] |
From: | "So and so" <lightfault@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 10 Oct 2008 16:57:31 +0200 |
Organization: | Compilers Central |
Keywords: | disassemble, question |
Posted-Date: | 11 Oct 2008 05:55:37 EDT |
Hey,
I've set myself a goal to write a disassembler, so far I've managed to
understand most of Intel's documentation (for now it's only going to
disassemble x86 code) and I'm about to start writing the basic
skeleton.
The algorithm I had in mind was :
Read N bytes (or the whole files, I'm not sure about it yet)
if this byte is part of a prefix instruction, parse it else continue
to opcode, and so on and so on .
Though, I ran into several "problems" in mind:
1. Which data structure should store the values I read ? A hash table
or a Tree ? Or a combination of both ? (trie) Should the tree be
balanced ? If not, will it cost in efficiency or whether balancing it
will cost in efficiency ?
2. What about invalid instructions ? Should I strip them the moment I
detect they're invalid or should they be stored FFU ?
3. Which data structure should hold the final result of the
disassembled instruction ?
5. Should the disassembler itself be multi threaded or one program
which does everything step-by-step and if it will be multi threaded -
how can I handle or parse different instructions ? or handle
synchronization ?
best regards,
lightfault
Return to the
comp.compilers page.
Search the
comp.compilers archives again.