Menu
▾
▴
#17 Specifying opcode variants
I'm currently reverse-engineering an old DOS
driver. Because I'm a perfectionist, I want the
recompiled driver to be byte-for-byte identical to
the original.
I noticed that NASM assembles "mov bp,sp" to
89h e5h. The same instruction is encoded as
8bh 0ech in the original driver.
This is not really a problem, because both
variants have the same length.
Still, it would be great if you could explicitly
specify the opcode variant in cases like this.
Logged In: NO
From an implementation standpoint this could be achieved
by collecting all matching instruction database entries
in an array, and then selecting one entry. The selection
would have to be based on the user's input. For example
we could introduce a set of prefixes that allow the user
to specify that the Nth entry is to be used, if available.
Another possibility would be a preprocessor directive --
though that would make the feature unavailable whenever
the preprocessor is disabled. Yet another possibility is
a new pseudo-instruction, which would affect the choice
for the subsequent line or instruction. There probably
are a few other possibilities out there, when it comes to
letting the user make that choice within the constrains
of the existing NASM syntax.
One area I haven't looked at yet are the potential side-
effects on multiple passes and optimizations. IIRC then
NASM can select a more optimal encoding on a later pass.
The new feature would have to cope with that.
Another interesting area would be the reporting of mis-
match errors, because multiple entries may have different
reasons for not matching the current instruction. It may
be difficult to report this wealth of information in a
way that is easily comprehensible by the user.
Logged In: YES
user_id=804543
In my local version I have implemented support
for ALT.n prefixes, where n=0...31. (With n=0
you get the first match, while n=1...31 select
the alternatives, if available. The last ALT.n
prefix takes precedence.)