> Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple during the transition from 68k to PowerPC architectures. OMI provided portable code based on a compressed version of the abstract syntax tree.
If you are interested in pursuing that topic, Vidar Hokstad wrote a nice blog post about it a couple of years back: https://hokstad.com/semantic-dictionary-encoding
I'm trying to navigate similar tradeoffs for a system I'm prototyping now, but motivated by code footprint and safety rather than portability.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87...
Notice that on Oberon System 3 you could decide what kind of optimizations would take place, section 7 on the PhD refers to it as further work (System 3 came later).
Also a good production ready example of AOT + JIT to dive into as inspiration, are the latest version of Android. Since version 7 they rebooted the whole AOT concept, back to a mix of interpreter written in Assembly, JIT compiler with PGO, generating AOT code when the device is idle with help from PGO data, sharing PGO metadata with similar devices via Play Story.
I had the sense that Dalvik is a much more complex design, far too complex for a single hacker, additionally handicapped by backward compatibility with earlier Dalvik versions.
So you can have modules fully native without any kind of intermediate representation, for IBM i you would need the cleverly named Metal C compiler for proper native code.
Actually there are plenty of systems that offer AOT/JIT workloads, Android, Java, .NET, Common Lisp, Visual Basic (classical)....
WebAssembly is also adopting both approaches.