If you build a virtual machine right you should be able to run your programs to any platform you want (Windows, Mac, Linux, SmileBASIC, etc) without needing to rewrite a single line of code. This is essentially how Java works.
I've created my own awhile ago, although I've not worked out all the bugs so I never released it (and frankly stopped caring about SmileBASIC since it's stuck in Japan), but you can see the benefits of a virtual machine pretty clearly from the screenshots. It allowed me to write programs in an assembler that would then compile to a program that could run on my PC, my Raspberry Pi, in SmileBASIC, and I even was working on TI-84+CE support.
I'll just write up some information what I learned from this to see if any of it will help you.
Assembler
It will be hard to code anything for your virtual machine if you lack an assembler to go with it. An assembler compiles assembly code written in ASCII text into the numerical machine code that the machine can understand. Basically to make an assembler you need three things:
1. A table that matches instructions as ASCII text to their numerical machine code equivalent. This is called an "opcode reference chart". For example, see the
Z80 opcode reference chart.
2. Your assembler will pass through your code twice. On the "first pass" it builds what's called a "symbol table". Unless you're building an incredibly primitive assembler like from the 80s, most modern assemblers don't require the user to know anything about RAM addresses when coding. If you store data in RAM, you should be able to put a symbol tag before that data and simply refer to the symbol tag when you need its address, and the assembler will fill it in for you.
For example, in my virtual machine when I wanted to change the Window's title, I'd do something like this:
;Set title
MVU $0
MOV $5
EXP B
GET appTitle
MVU $0
MOV $8
SYSCALL
Notice how I reference "GET appTitle" on its own. If I were to scroll down to the very bottom of the code, I'd find:
appTitle:
$"Snake"
"appTitle" here is called a "symbol". It is tagging the memory address of the string "Snake". When you pass through your code the first time, you don't compile anything, you just keep track of how far down in the code you are and then when you hit a symbol tag such as "appTitle", you know exactly where that symbol will exist in memory when the program is ran. What you then do is add both the symbol and its memory address to your "symbol table". You pass through the entire code building a symbol table from every symbol tag.
3. The second pass actually compiles your code. Just run through the code and for every line, you can directly compile it based on the structure of your opcode reference chart. Whenever you see a symbol, such as the line "GET appTitle", you can simply replace "appTitle" with its actual value based on your symbol table you built in the first pass.
There are other things you may consider including in your assembler, such as macros.
Virtual Machine
Building the actual virtual machine should be a bit easier. Essentially this is all you need for any virtual machine...
;Pseudocode
var RAM = load("program.bin")
var pc = 0
var register1, register2, register3, etc
var flag1, flag2, flag3, etc
var halted = false;
while (!halted) {
switch (RAM[pc]) {
case RAM[pc] == 0:
...
break;
case RAM[pc] == 1:
...
break;
...
etc
}
pc++;
}
So first you need to load your program into the virtual machine's RAM somehow. Your RAM's size can either be static (either the user defines how much RAM the program has explicitly or implicitly based on the program's size) or it can be dynamic (resizes itself if the program needs more RAM during runtime).
"Registers" are piece of hardware inside the CPU that computers use to temporarily keep track of data. They can usually store between 8 bits to 64 bits, but that's completely your choice. Intel 4004 was a 4-bit CPU and fully functional. Z80 had 16-bit registers, and eZ80 had 24-bit registers. Modern x86_64 computers by Intel and AMD go up to 64-bits.
Your "pc" is your Program Counter, it's the most crucial register for any computer. It tells the computer which memory address to read the next instruction from. Hence why every loop we increment it by 1, because we are incrementing through our code.
The "switch" statement just says to do something specific depending on what the instruction is.
Typically CPUs also have "flags", which are a special type of 1 bit register. For example, if register1 is holding the value "2" and I call an instruction to compare it to register2 which holds the value "3", they are not equal. But where is the result of the comparison stored? Typically in a flag. So you might have a flag called "equal" and it will be set to 1 if they are equal and 0 if they're not. Then later, you might have a jump instruction that changes the program counter but only if the equal flag is true, that way you can have sub routines only happen under certain conditions.
That's basically all a CPU is. It looks at a number (your instruction), manipulates some memory based on the number, and then goes to the next number.
Virtual Kernel
Notice in my virtual machine I use an instruction called "SYSCALL". All modern operating systems have something called a "system call". For example, in Linux operating systems on x86_64 machines, if you want to exit a program, you'd use this system call:
mov rax, 60
mov rdi, 0
syscall
In this case, "rax" and "rdi" are registers and "mov" is an instruction to move data from the second operand into the first. In this case, "syscall" takes two inputs: the ID of the system call (60 being the "end program" syscall) and the error code (0 being "no error").
This system call is sent to a piece of software called the "kernel" which handles the call. All modern operating systems have some sort of kernel. The kernel handles most everything at a hardware level. For example, if I want to save a file to the hard drive, that is a physical process. Something has to tell the hard drive to spin up, something has to tell the actual write head what to do.
Given there's thousands of different pieces of hardware out there, nobody wants to write code for a
specific device. No one wants to write a program that can only save files for a very specific hard drive, for example. So instead, the kernel handles all file operations, and the programmer just has to send messages to the kernel. This way, the programmer doesn't need to know how the hard drive works, they just need to know how to control the kernel, and this kernel contains the information of thousands of different pieces of hardware and how to use them. The programmer only needs to know how to code for 1 kernel which then can control thousands of unique pieces of hardware.
For my assembler I built something very similar I called the "virtual kernel". It is not a true kernel as it does not directly interact with the hardware, but from the programmer's perspective inside the virtual machine it's the same exact thing.
Imagine if I want to save a file in my virtual machine, but the virtual machine is running on a Windows computer. The Windows kernel expects completely different code for file operations than, let's say, the Mac or Linux kernel. Or, let's say I'm in SmileBASIC. SmileBASIC also expects very different code for file operations.
So what the "virtual kernel" does is abstract all that out. I build a "virtual kernel" for each platform, and what this does is allows the assembly language to make a system call to the virtual kernel, and the virtual kernel handles the actual operation depending on the platform. This way, the code for saving a file will be exactly the same on the programmer's end whether or not I'm running on Windows, Mac, Linux, SmileBASIC, etc.
The goal of the virtual kernel should be to abstract out all of your hardware specific stuff. It should have things built-in like saving and loading data to a virtual disk, getting input from the mouse/keyboard/touch screen, playing audio, and outputting graphics to the screen.
You should never directly do any hardware-specific operations within the virtual machine's assembly code itself. That will not only make coding more difficult and convoluted but it will make porting your virtual machine to other platforms insanely difficult.
Stack
It's not required but
highly recommended to implement a stack inside of your virtual machine. All modern computers have one.
What's a stack? It's a type of data structure called LIFO (last-in, first-out). Both names describe how it works in different ways.
Imagine you have a box that can only fit the width and length of a single book, but you can fit 20 books if you stack them on top of each other.
I place the first book in, then the second, then the third, then the fourth, then the fifth.
Now, let's say I want to read the first book. Well, I can't, it's at the bottom of the stack. So I have to remove the fifth book first, then the fourth, then the third, etc, until I get to the bottom.
This is why a stack is also called LIFO, because the last book I put on the stack (the fifth one) is the first one to come off the stack.
With a stack, you can only look at the books on the top, and you can only remove books from the top. You can't remove anything that is not on the top of the stack.
Looking at the book at the top is called "peeking". Removing that book from the stack is called "popping". Adding another book onto the stack is called "pushing".
So, you might be wondering, what do stacks have to do with computers?
Imagine if I'm writing an RPG, and in my RPG I have some code to save your game.
Most RPGs have multiple save points, so there are dozens of different places I could save my game.
Should I copy and paste the save code to all those dozens of places?
No, that's a waste of memory. Instead, I could only write the code one time, and
call it when I need it.
Calling code stored somewhere else is known as a "subroutine".
How does a subroutine work? Basically, when I call the subroutine with some sort of "call" instruction in assembly code, the CPU changes the program counter to the address of the subroutine, so then it will started executing instructions at the subroutine. Then, when it hits the "return" instruction at the end of the subroutine, the CPU will change the program counter back to the value it was before I called the subroutinee (plus one in order to not get stuck in an infinite loop of calling and returning).
But how does the CPU remember the address from which it was called?
It remembers it using a stack. When you "call" a subroutine, it pushes your current program counter onto the stack. It then changes the program counter to the address of the subroutine, and when it's done executing, it pops the program counter back off the stack which returns it to where it was originally called.
Stacks are also useful since CPUs always have a limited number of registers, so all code shares the same registers. So if I am using register2 for example, and I call a subroutine that also uses register2, my data in register2 will be destroyed. This can be avoided by pushing register2 onto the stack before I call the subroutine and then popping it off the stack when I'm done.
So yeah I probably wrote way too much but maybe some of these tips will be helpful.
