3 ms·
The article mentions: > Slim binaries were invented by Michael Franz in the early 1990s. They were motivated and opposed to the fat binaries invented by Apple
by eterps 4y ago
The article mentions:
> 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 https://hokstad.com/semantic-dictionary-encoding
- pjmlp 4y agoBy Oberon System 3 timeframe we had both distribution formats, either fully AOT compiled, or slim binaries.
- rbanffy 4y agoIIRC, it’s similar to how AS/400 binaries were distributed. Not sure they were compiled to native code on install or on first run.
- pjmlp 4y agoTIMI isn't exactly like Oberon, because with Oberon you could chose, either fully native code, or in this source coded form, that is JITed at load time. 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.
- kragen 4y agoWhat was the runtime performance cost of load-time JIT for slim binaries? What fraction of inner-loop bounds checks could be hoisted? What was the cost of dynamic dispatch? I'm trying to navigate similar tradeoffs for a system I'm prototyping now, but motivated by code footprint and safety rather than portability.
- pjmlp 4y agoNot really sure, you can read the PhD thesis about it, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.4977&rep=rep1&type=pdf 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. https://source.android.com/docs/core/dalvik/jit-compiler https://source.android.com/docs/core/dalvik/jit-compiler
- kragen 4y agoThank you! 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.
- pjmlp 4y agoThe only thing that ART has left from Dalvik are the DEX bytecodes, but from complexity level it is yet another JVM implementation (whithout being technically one).
- eterps 4y agoIf I remember correctly this article describes some considerations and metrics: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.1711&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.10... (it has been a while since I read it though)
- kragen 4y agoThank you!
- Torwald 4y agoThere was also Oberon for the Amiga.
- eterps 4y agoSome additional info+links can be found here: https://wiki.tcl-lang.org/page/Slim+Binaries https://wiki.tcl-lang.org/page/Slim+Binaries