Suppose I'm writing my own virtual machine interpreter, and I want to target it with a 'real' language like C. I could retarget the backend of gcc, but I hear that work is horrendous. What I would rather do is abuse GCC already written for another processor. Back in school, we had a stripped-down gcc that output to a subset of MIPS, and we had to write a MIPs emulator, so it would be similar to that, just much more feature-rich.
I suppose this more of a question for those who have written a lot of assembly language: What CPU do you think is most ideally suited for writing an interpreter? Keep in mind that I don't necessarily need to run a modern style OS on the VM, and the memory architecture can be simple. I'm even considering subsets of certain processors. For instance, a 386 in real mode has 32-bit registers, floating point support (387), and there's a trick to address 4gb flat from real mode (called unreal mode.) If my interpreter only acted as a 386 in 'unreal mode', that would be fine by me. But x87 opcodes are complex... I want a simpler processor.
Why do I want to do this? For fun. Several years ago, I wrote a little VM and my own language and gave it bindings to a C library I wrote that did basic graphics. The vm would call functions like, load this image file, draw is image here, etc, and the C library did all the grunt work. I kind of want to do the same thing again, but with OpenGL 3d graphics. I could invent a new pet language again, and I might, but if I could get plain C compiling to vm bytecode that would be great. Some of the optimizations gcc does (loop unrolling, moving constants out of loops etc) would benefit bytecode programs probably quite a bit.
And before someone lists it as an x86 interpreter, I am considering just adding opengl calls to dosbox. If I reserve certain addresses for communication to the outside of the VM, there wouldn't be anything stopping me from writing 3d accelerated apps in qbasic or turbo c!
Edited by DracoLacertae, 11 January 2013 - 06:26 PM.