Closed mumbel closed 5 years ago
We are interested in new language definitions and would welcome pull requests for them.
Most of the processor modules we've included are fairly clean and tested in a variety of situations, although they all have their issues and shortcomings. All processor modules go through a review process just as code does. I'm not sure the stage it would be ready for a pull request.
There is a bit more pcode needed. It should work on large programs with the all instructions used by a compiler spec'ed in pcode. There may also need to be refactoring of operands into shared sub-constructors for shared operations like addressing modes. Then concentrating on instructions that are found in the binary under investigation. Pseudo-ops for the instructions like SIN() that are too complicated. It is at a basic state of completion (disassembly with flow) where someone will find it useful and carry on the work. Including it as a useful prototype is a possibility as long as it doesn't cause issues with the core system. Processor modules don't tend to on their own. If I were reviewing it, then it needs more work as you mention. Being a bit new to pull requests, there would need to be a balance of readiness versus an initial prototype. If a pull request is meant for an initial review starting very early, then yes we could accept it as a pull request. We'll need to discuss a bit what stage something should be in to start the pull request. IMHO it will likely depend on each individual pull request.
Your method of extracting some portion of the spec from binutils or any other source that can provide at least some automation in creating some portion of them is a good methodology when creating a new processor spec. It looks like you have many of the basics down.
@emteere Thanks for a taking a look.
ld.dd E2 [A4]
loads 16 bytes into into the 8 byte registers E2 and E4 (or also the 4 byte registers D2,D3,D4,D5)
edit: added 2 more tokens for even/odd and then attached the even to evens and odd to odds<pentry>
looks like, so hopefully I can sort that out too (for now I've removed e/p which might be the correct thing here anyways).I'm going to go ahead and close out this question. The conversation is continuing in #567.
I have been working on a TriCore processor and have at least decent disassembly and semi-working decompiler. Thought I would push the effort so far to github. (Ghidra devs if you don't want this sort of thing here, I can understand and please close)
I basically took the tricore headers and source from binutils (similar approach to r2) and scripted out the generation of most of the sleigh. This provided the majority of all the disassembly, though I have found I am missing some instructions still from the manuals. Then went through and added the logic for a lot of the instructions (though i did TODO a lot if I wasn't sure on if I could macro large portions).
movh.a
and other intructions likeld.hu
to get a 32-bit addressdefine space
for ram and registers loads and stores can reference ram or registers. Should I set high address space registers in spec or only define a single shared space?Some issues I just have not looked into yet and I'm sure there are other things I'm forgetting to mention here, but any comments or suggestions welcome. (To Ghidra devs, at what stage of development would pull requests for something like this be appropriate? or is that a big TBD at this point)
src link pdf 1.3 & 1.3.1 pdf 1.6 test binaries