> The retirement stage is some of the most difficult hardware logic to design [citation needed] There are many difficult parts to a super scalar speculative dy

> The retirement stage is some of the most difficult hardware logic to design [citation needed] There are many difficult parts to a super scalar speculative dynamically scheduled microprocessor, but retirement doesn't even make top 10. If I had to pick, it would hands-down be the load-store unit which is really hard to scale (and has a lot of gnarly corner cases). > This all may seem inefficient and crazy and it is. Program representation and execution need a major re-think along the lines of the once-investigated dataflow architecture. I actually agree with the impedance mismatch of our legacy ISAs, but "dataflow" is a bizarre pick as the original formulation was incredibly inefficient and all modern processors (A72 included) are already dataflow machines over a fixed windows of the (partially speculated) path through the program. There have been a lot of interesting paradigms published, but it's extremely rare for industry to take a risk. VLIW is still a darling (in principle very efficient iff you hit in the caches), but there are a _lot_ of other ideas. Browse through the past few decades of ISCA and MICRO proceedings to see examples. The cost of making new binaries is always the problem. At Transmeta we used binary translation as the answer for x86 and NVIDIA's Denver much improved upon the idea for Arm. Both use in-order execution which in hindsight didn't seem to have worked out. Alas, dynamic translation of binary code has huge overheads and issues with cold code. There's hope though; if the code you are translating is WASM then you are in a much better place, but still not quite as good as source as you are lacking all the alias knowledge. [updated typos and grammar]