Hi Richard > Why would you be maintaining another description? Your approach below > with the simple recursive algorithm appears to be no different.
We initially considered to drop our tables completely replacing it by decodetree. > >> Also that decodetree alone would not allow us to properly disassembly >> code, still requiring to keep the initial structure. > > Why is that? By disassembly I am referring to the pretty-print of the instructions when using "-d in_asm". Our tables contain information for printing as they are the ones used by bintutils assembler. > > 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. There where no problems from the perspective of understanding what it did or how to use it. It was just that auto generating of the decodetree seemed more then a simple task but a rather elaborated one, since we needed to identify common operand style instructions, group similar instruction conflicting encodings, etc. And when comparing to the ease of automating the creation of the decoding trees, seemed much more complex. > > 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? I do have. Please allow me a few days to properly clean it. Considering, I wanted to get your opinion before of a greater commitment to the solution, it is still in a prototype stage. Cupertino _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
