I haven't tested it yet, but the x86 disassembly source code looks very well written, in my opinion, as a programmer that understands Pascal/Delphi...
https://github.com/cheat-engine/cheat-engine/blob/master/Che...
That one unit has more than 16000 LOC, its basically one huge case statement where each opcode is handled separately... super simple but certainly not DRY (don't repeat yourself). But I guess its one of those cases where you should avoid writing DRY code.
In the same manner is the fpdebug-disassembler from the free pascal team, I found that disassembler one of the most elegant one.
https://github.com/alrieckert/lazarus/blob/master/components...
It has some minor errors in the Rex decoding though, if I remember correctly....
Yes, fpdebug definitely looks like it is the better written code of the two...
I will definitely have to grab myself a copy of its source code and play around with it...
>It has some minor errors in the Rex decoding though, if I remember correctly....
By Rex, you mean Regex, right? Well, it having issues there wouldn't surprise me one bit... If I used it, fpdebug, I probably wouldn't use it with all of the bells and whistles turned on -- I'd probably pare it down to only the most essential source code...
But that being said, I think that having that source code to refer to -- could be highly beneficial...
See, there's this problem in Software Engineering, which looks something like this:
Let's say I want an open source library (and in Pascal no less!) whose purpose is twofold, on the one hand to translate raw binary x86 machine code sequences into readable text, and on the other, to translate the text of an x86 assembler instruction, into binary.
OK, so now, the $64,000 question is:
Who (or what) -- is the absolute source of truth for that library?"
See, even if that library were written by Intel themselves, I guarantee that there will be mistakes...
The mistakes are not due to documentor and/or programmer negligence (Intel or otherwise) -- so much as they are due to instruction set complexity...
You see, I'll bet, pound for pound, line of code for line of code, that any assembler/disassembler routines for say a RISC instruction set (RISC-V for example) -- should be much, much shorter (and more elegant to boot!) than Intel's "everything but the kitchen sink, we keep expanding it because it gives us the competitive edge via patent and other legal protections" constantly-expanding-the-instruction-set approach...
So the issue, at least in x86-land is,
"Who (or what) -- is the absolute source of truth with respect to the x86 instruction set?"
Also, remember that Christopher Domas (Google him, you'll find a whole lot of interesting stuff) -- discovered that x86 processors typically can and do implement all sorts of undocumented instructions:
https://github.com/xoreaxeaxeax/sandsifter
>"Typically,
several million undocumented instructions on your processor will be found
, but these generally fall into a small number of different groups. After binning the anomalies, the summarize tool attempts to assign each instruction to an issue category:
o Software bug (for example, a bug in your hypervisor or disassembler),
o Hardware bug (a bug in your CPU), or
o Undocumented instruction (an instruction that exists in the processor, but is not acknowledged by the manufacturer)"
Anyway, thanks for the link! (The second one! )