On 6/9/21 2:58 AM, Cupertino Miranda wrote:
We started to do that and in the process we realize that the approach
would bring us yet another encoding language description to maintain.
Why would you be maintaining another description? Your approach below with the
simple recursive algorithm appears to be no different.
Also that decodetree alone would not allow us to properly disassembly
code, still requiring to keep the initial structure.
Why is that?
The current uses of decodetree are quite complex, so I sincerely doubt that it
cannot do the job. You've asked no questions, nor have you described any
problems you have encountered.
That said, decodetree was merely a suggestion based on what appeared to me to
be a trivial automated textual rewrite of your current data set. If you want
to use something else that performs equally well, fine.
So far, we did the following:
- converted opcodes.def to macros instead of table entries.
Sure.
- created a script that reads those entries and outputs macros that
directly translate to a switch/case decision tree (example below), just
like the ones produced by decodetree. The difference is that the switch
will return the enum entry for the proper decoder structure instead of
calling a translation function.
An enum result is fine, sure.
The example is not especially enlightening because you don't show the macro
definitions, or the expansion. Have you a link to a git repo that you can share?
- the script can either be contributed in C or python language as it
is based on a simple recursive algorithm.
Either is fine. We currently use both as build-time generators.
r~
