3 ms·
It will be interesting to see if this complexity affects closed-source software more than open-source software, or if AS/400-style bytecode-compilation schemes
by derleth 15y ago
It will be interesting to see if this complexity affects closed-source software more than open-source software, or if AS/400-style bytecode-compilation schemes catch on again.
(The AS/400 (now iSeries) world compiles COBOL and RPG source to a very stable bytecode that has been the same for the lifetime of the system, AIUI. When the program is first run, the bytecode is automatically compiled to machine code and the machine code is stored alongside the bytecode; all subsequent runs either just use the machine code, or regenerate the machine code if the bytecode is newer and then run the machine code. When moving software to a new system, the machine code is left and only the bytecode (and, possibly, sources) gets moved. This works well enough IBM has been able to migrate AS/400 people from CISC to RISC hardware without any more pain than using OS/400 stuff usually entails.)
- axman6 15y agoI may be wrong, but I think that this is theoretically possible using LLVM. If you just translate the source into LLVM IR without any optimisation, then all of that can be left until runtime if necessary, which is pretty neat. Though I'm not sure if languages impose restrictions on the IR that may hinder this, I know that GHC had to implement its own calling convention for LLVM to make it run efficiently. There's also the fact that you need all of the program to be translated into the IR; using GHC as an example again, this is a problem because the runtime system is written in C. I shall have to do more reading about AS/400 I think, sounds interesting, especially the easy CISC -> RISC transition.