6 ms·

Yeah, this part: " We have implemented a system taking a wholly different approach that we call “slim binaries.” The object files in our system do not really co

Yeah, this part: " We have implemented a system taking a wholly different approach that we call “slim binaries.” The object files in our system do not really contain native code for any particular processor at all, but a highly compact, architecture-neutral intermediate program representation " is basically the definition of Java byte code. Wikipedia search of the author seems to say he came up with it first, though: " His doctoral dissertation, entitled "Code Generation On-The-Fly: A Key To Portable Software"[11] proposed to make software portable among different target computer architectures by way of using on-the-fly compilation from a compressed intermediate data structure at load time. Two years later, the Java programming language and system were launched and took this idea mainstream, albeit using the term "just-in-time compilation" instead of the term "on-the-fly compilation" that Franz had used. " https://en.wikipedia.org/wiki/Michael_Franz https://en.wikipedia.org/wiki/Michael_Franz

eterps 7y ago
> is basically the definition of Java byte code Except that the slim binaries concept is not based on byte code at all, but more like a Huffman compressed abstract syntax tree. Not only are the binaries smaller, they can potentially be optimised further because no semantic information is lost. See also this blog post for more details: https://hokstad.com/semantic-dictionary-encoding https://hokstad.com/semantic-dictionary-encoding Original website on Wayback machine: https://web.archive.org/web/20020617132121/http://caesar.ics.uci.edu/oberon/research.html https://web.archive.org/web/20020617132121/http://caesar.ics...
- kragen 7y ago
  The Self bytecode was pretty close to an abstract syntax tree, though not huffman-compressed. How is it that nobody has mentioned Self yet in this thread? Self was doing JIT compiling from a platform-independent bytecode in the late 80s and getting within a factor of 2 of C performance by the early 90s.
nialldalton 7y ago
Yeah Michael's dissertation was out in '94 already, and he had native Oberon running in slim binaries (aka jit'ing from compressed AST) for quite a bit before that. Thomas did the Juice stuff (aka slim binaries on the web) around mid '96 IIRC, then did a continuously optimizing JIT for Oberon, then got sucked into binary translation at Transmeta. There were a lot of fun overlaps. Robert Griesemer did his PhD at ETH around the time Michael did, on a vector extension to Oberon for a Cray. He went on to Animorphic working on Strongtalk, and later the JVM at Sun. IIRC the assembler from Strongtalk days has been extended and used in other projects like Javascript compilers. Animorphic had Urs Hoelzle / Lars Bak / Gilad Bracha too; Urs was undergrad at ETH with Michael IIRC, then worked on Self at Stanford inventing a bunch of the optimizations that went into Strongtalk and later Hotspot for Java. Etc. Etc. Small world :-)
SilasX 7y ago
According to the lectures in the Nand2Tetris course, the concept dates to p-code from the 60s and 70s: https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine
- nialldalton 7y ago
  Absolutely bytecode was already an old idea by the time this work took place. (And Wirth, Franz's advisor, wrote compilers and books using pcode). The novelty was in using trees for the representation, and recompiling the entire Oberon system not just a single app. Later work by his students (Vivek+Chris iirc) looked at using arithmetic encoding to further compress things. Also Michael noticed that it prevented malformed programs, as his interest in security grew. Another branch of the family tree worked on more compiler optimization friendly IRs, such as typed SSA instead of bytecode, and applied it to Java. The idea being to be able to do more upfront optimization work, and still transmit a safe representation that was cheap to verify.

eterps 7y ago

> is basically the definition of Java byte code Except that the slim binaries concept is not based on byte code at all, but more like a Huffman compressed abstract syntax tree. Not only are the binaries smaller, they can potentially be optimised further because no semantic information is lost. See also this blog post for more details: https://hokstad.com/semantic-dictionary-encoding https://hokstad.com/semantic-dictionary-encoding Original website on Wayback machine: https://web.archive.org/web/20020617132121/http://caesar.ics.uci.edu/oberon/research.html https://web.archive.org/web/20020617132121/http://caesar.ics...

kragen 7y ago
The Self bytecode was pretty close to an abstract syntax tree, though not huffman-compressed. How is it that nobody has mentioned Self yet in this thread? Self was doing JIT compiling from a platform-independent bytecode in the late 80s and getting within a factor of 2 of C performance by the early 90s.

nialldalton 7y ago

Yeah Michael's dissertation was out in '94 already, and he had native Oberon running in slim binaries (aka jit'ing from compressed AST) for quite a bit before that. Thomas did the Juice stuff (aka slim binaries on the web) around mid '96 IIRC, then did a continuously optimizing JIT for Oberon, then got sucked into binary translation at Transmeta. There were a lot of fun overlaps. Robert Griesemer did his PhD at ETH around the time Michael did, on a vector extension to Oberon for a Cray. He went on to Animorphic working on Strongtalk, and later the JVM at Sun. IIRC the assembler from Strongtalk days has been extended and used in other projects like Javascript compilers. Animorphic had Urs Hoelzle / Lars Bak / Gilad Bracha too; Urs was undergrad at ETH with Michael IIRC, then worked on Self at Stanford inventing a bunch of the optimizations that went into Strongtalk and later Hotspot for Java. Etc. Etc. Small world :-)

SilasX 7y ago

According to the lectures in the Nand2Tetris course, the concept dates to p-code from the 60s and 70s: https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine

nialldalton 7y ago
Absolutely bytecode was already an old idea by the time this work took place. (And Wirth, Franz's advisor, wrote compilers and books using pcode). The novelty was in using trees for the representation, and recompiling the entire Oberon system not just a single app. Later work by his students (Vivek+Chris iirc) looked at using arithmetic encoding to further compress things. Also Michael noticed that it prevented malformed programs, as his interest in security grew. Another branch of the family tree worked on more compiler optimization friendly IRs, such as typed SSA instead of bytecode, and applied it to Java. The idea being to be able to do more upfront optimization work, and still transmit a safe representation that was cheap to verify.