U1MB / Antonia 4MB Virtual Machine

[ivop]

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

[Wrathchild]

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

[ivop]

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