ivop Posted February 1, 2021 Share Posted February 1, 2021 (edited) Hi all, Another one of my brainfarts. I'm in the mood For years, I have been thinking how nice it would be to have a virtual machine running on the Atari 8-bit that treats the whole U1MB banked RAM as a continuous address space. Virtual machine can be read as something from a BASIC interpreter with 1MB of tokenized source code, up to a full blown CPU emulation with a 1MB address space. In any case, it'll be a lot slower than native code, but I think the speed of compiled BASIC for example, could be reached. Now there are two options I thought about. 1. Design a new VM/CPU that is specifically designed to run as fast as possible on a 6502. Pro: it'll be fast, Con: you need to create a new compiler backend that targets this VM/CPU. 2. Find a current compiler backend (gcc, llvm, ...) that has an easy enough instruction set to emulate. Pro: the backend is already there, Con: even as a bare bones compiler without library support, you are stuck with a predefined calling convention which is probably not optimal for a 6502 implementation. In both cases, one could implement INT like interrupt instructions that delegate slow parts to a dedicated routine in 6502 assembly outside the VM's address space. This way, a decently fast standard library could be created. Whadd'ya think? Edited February 1, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted February 1, 2021 Share Posted February 1, 2021 68000 might be nice target, but higher level stuff such as a JVM or .NET (Core) might be a problem without an MMU assisting with memory allocation Quote Link to comment Share on other sites More sharing options...
ivop Posted February 1, 2021 Author Share Posted February 1, 2021 3 hours ago, Wrathchild said: 68000 might be nice target, but higher level stuff such as a JVM or .NET (Core) might be a problem without an MMU assisting with memory allocation Agree on the higher level stuff. Those VMs have all sorts of curly braces languages and OO support that goes way beyond what we (might) need. About the M68K, if I'm not mistaken, all opcodes are 32-bits. That's quite a lot to handle for an 8-bit emulator. I was thinking more along the lines of the lowest supported ARM Thumb instruction set with 16-bit opcodes. But hoping for a possible candidate that would require even less loads from memory for the common opcodes Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.