Decompiler Refactor 101

[Escapingbug]

This is a requirement for decompiler refactor. Current decompiler suffers a lot from leaky abstraction and not enough abstraction.

Anti-patterns such as "using namespace std" is used everywhere.

Upstream does not currently has any idea on refactor the code. This might be on our own.
My thought is to write down notes on how the refactor could happen and people interested in this might gradually submit commits on making the code enjoyful to read.

Some of the refactors could be:

• refactor some of the code into Rust: C++ suffers from dependency management problem across platforms. Current solution is to write everything ourselves (see xml implementation). This might prevent us from moving forward to only what we care most. Jobs at a glance:
  • entrance refactor: this can be seen as a POC of combining Rust and C++ world. Rewrite the entrance and command handling part in Rust. -- EASY (But I myself may do it first to setup the overall code structure)
  • xml refactor: add xml dependency in Rust, and let the dependency handle the xml parsing -- EASY
  • Rule system rewrite: This is a heavy thing to do, only to mention it a little. My thought on this is that we might totally get rid of current rule rewriting system and rewrite that part in Rust using a new concept called "equality saturation". This would also requires tuning current block structuring algorithm (rewrite!) to follow what is required by that technique. -- EXTREMLY HARD! NOT EVEN POSSIBLE.
  • other refactors: all other refactors mentioned here might also be directly refactored into Rust instead of C++.
• better rewriting pattern implementing Rule: LLVM could give us some insights of how this could be done possibly. Current implementation of rewrite is handled manually, may be suboptimal. -- HARD
• better matching pattern implmenting block graph matching: as well, LLVM could give up some insights -- HARD
• DSL for generating Pcode: current pcode insertion is a looooooooooooooooooooooooooooong work, hard to read, boring to read. -- MEDIUM
• LSP like RPC header: this could allow us to have a totally text based RPC transmission, allowing us to inspect the connection better. -- EASY
• logically organized better actions: currently actions are orgnized by ActionGroup, it is a concept of "how they might be performed", like in a look or something. But no dependency management is actually performed aside from the comments which is an anti-pattern as well -- obviously the comments are not enough to ensure the constraints. Some sort of dependency management may solve this better. Also, this allows the reader to understand what action takes effect to what algorithm. -- UNKNOWN
• fix the "using namespace std;" problem. -- EASY, but might take some time.

[Escapingbug]

Update:

Refactor is more likely to be in Rust. Initial work has already be done in #21 .

[Escapingbug]

Update:

I'm changing my mind about some previous decisions. Especially the Rust language one.

Rewrite the whole project into Rust can be a really large work, and may not be so beneficial during such time. What's more, this could take a lot of man power to do so.

Since currently the project is already running well, and we do not have such man power to rewrite anything in fact (quite sad, but true). I'm reconsidering this, as even after rewrite, the coding style may never come to Rust-style, it will follow C++ style most of the time as the current schema of C++ is not that "modern" style that could be transferred to Rust in a elegant way.

As for the experience, the #21 does not, till now, introduce anything really useful to us. Instead, it makes the compilation process even harder. We will have to keep an eye on the building process as it is using Rust building system instead of pure C++ one.

I will shortly try to deprecate the Rust try-out. Our rewrite should, sadly speaking, be in C++. Maybe more modern style C++ and more DSL rewrites, but in C++.