Thanks for all your replies. Yes, both x86 and 68k are CISC monsters. 6502 and Auduino are both fairly clean, but they have 16-bit addresses and data words. Access to 32-bit data types would be ideal. But still, I could probably still do a lot with a 64k address space, especially since the VM will call out to the host for things like loading images and rendering. If all the vm needs is a handle to an image or VBO that is already in the host's memory, then reading the keyboard/mouse, performing in-game logic and deciding when and what to render could be handled fairly well in such a small vm. The VM won't need direct access to the framebuffer, it's just going to call out to the host and say 'draw sprite #123 at x,y' or 'draw 3d model #99 at x,y,z'. I'll look at some classic 8-bit designs. Programming it will be a bit like a gtx560 strapped to a really fast commodore 64.
which cpu to model in VM interpreter?
[quote name='DracoLacertae' timestamp='1357950210' post='5020543']
I could retarget the backend of gcc, but I hear that work is horrendous.[/quote]
Why not retarget something simple instead, like Small-C? Writing a backend for a portable-by-design compiler like that is likely to be a lot simpler than emulating even a fairly simple real-world chip.
But I'm also a little unclear as to your goals here. Usually one writes a VM for one of two reasons: (a) to emulate a real-world piece of hardware for which no emulator exists, or (b) to provide a runtime for a new high-level programming language. Your use case doesn't seem to resemble either one of those - is this just a learning exercise?
Thanks, small-c looks almost perfect! It seems like its missing structs? A quick googling shows many variants. I'll probably learn more retargeting a simpler compiler to my own cpu than emulating something else. Thanks a lot!
