On Higher-Order Opcodes: Machine Code is a Functional Stack Based Language
I’ve started a few threads on higher-order opcodes for intermediate languages.
It seems thought that many people overlook the fact that most machine code is already a functional stack-based language. You can pass instructions as data, and execute data as instructions.
April 11th, 2007 at 5:41 pm
The von Neumann architecture, where both code and data are stored in the same memory, can pass instructions as data and execute data as instructions. However, JVM and CLR are not modeled around von Neumann architectures; in both, code and data have different address spaces.
JVM and CLR are stack machines, but JIT compilers can view them as serialization formats for expression DAGs. Something I feel you haven’t explained (please enlighten me! :) ) is how you expect your proposed extensions to be compiled.
What kind of machine code would they compile to? Can you write a series of C instructions you expect each opcode to translate into, whether the JVM/CLR is viewed as a serialization format for expression DAGs (in other words, very similar to a normal compiler’s code generator), or in order to implement a slightly faster interpreter (e.g. ‘push 42′ might translate to ‘(stackPtr++)->intValue = 42;’)?
April 11th, 2007 at 8:00 pm
Hi Barry,
I haven’t really thought about the problem of translating to expression DAGs, and to be honest I don’t understand the reason why I would want to do so, apart from reasons of compatibility with existing JIT compilers. Can’t we simply ignore JITs and expression DAGs for now and look at what the translation to assembly code would be for higher-level opcodes?
I’ve written a short post which roughly outlines my ideas on how to generate assembly for higher-level opcodes: http://cdiggins.com/2007/04/11/cat-higher-order-instructions-to-assembly/
I’d be curious to hear your thoughts on that post.
Thanks!