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!
