I agree. ElectricFence was also something I looked into. My C is excellent, my C++ is something that happened later after I learned much text book lingo post Ada, APL/J, and I still think Forth could be good, although linking it has never really been a DSP tool developer goal. Gigabytes came and made compact threaded code sort of obsolete by competition of not so compact but more generable code.
Adding a threading cache on the out of order fetch unit was something I’ve argued on
comp.arch as smaller code reduces instruction cache volume on the Harvard architecture, leaving more data fetch for less memory stalls.
Also I said on the RaspberryPi forum (educational) that a BWT transform of the compiled code (it makes the search more time linear) could be easily factored into small subroutines (common instruction sequences), and code reduced for size to try for some of this effect even from monolith code. I’m not sure the processors yet do some caching priority of future on stack instruction sequences.
The Mill processor was excellent, based on an initial idea of shrinking program code by making the target register implicit. What started the conversation. It wasn’t Intel code level compatible though, so a assembler to assembler code translator seemed a little too far. Less heat in processors by double tracking the CR time constant into double wiring. It never changes the logic of processor design, but the layout uses more metal layers but consumes less power. I said I didn’t mind its use.
In the galactic terms of billions and a hotter faster centre? Module
Q might seem a little bit of a joke, but it’s not so in some sense. uncertain-geo.pdf - Google Drive kind of says it all. Mistakes but not as silly as it might first appear.