Journal entries from July 2022¶
Parsing the source¶
So far we have read an assembly source file into a string, and we got to know some new data structures. It is time we use the one to fill the other. Let us start parsing.
Assemble!¶
We introduce an API for assembly to our lovem library.
Last time, we built the frame of a command line program, that will become our new assembler, lovas. It is time that we give that program the power to assemble.
Don't byte me!¶
I have had it with these motherloving bytes in this motherloving bytecode!
By now you should have come to a realisation: writing bytecode sucks! It wasn't fun to begin with, but now that we introduce jumps in our code, we need to count how many bytes the jump takes – and that with instructions that have different numbers of bytes as opargs. Encoding negative numbers in bytes is also no fun. And just think about it: if you change your program (e.g. add a few instructions), you have to adjust those relative jumps! How horrible is that? Can't someone else do it? Well, yeah, of course. We invented a machine that can do annoying and monotone tasks that require accuracy and that must be done over and over again. That machine is, of course, the computer.
Go ahead and jump!¶
All our programs have been linear so far. Let's build the base for jumping around.
In every program we have written so far, each instruction just advances the PC[^pc], until we reach the end. That is very linear. We will now introduce a new opcode, that jumps to a different position in the program.
Reverse polish notation¶
We are using the design of a stack machine to efficiently execute some calculations.
The way stack machines work can be used in programs that execute calculations. We will look at it by implementing an example from the Wikipedia page about stack machines.
More operations¶
The basic operation of the VM is working. Let us add a few more opcodes, so that we can do calculations.
We have created a rust library that holds our virtual register machine. We can now add multiple executables to it, so that makes it easier, to write different programs and keep them (to mess around with the VM). We will add a few more opcodes to our repertoire, because only adding numbers is just plain boring.
Early VM decisions¶
Many design decisions must be made for lovem. Here I talk about some of those in the current state.
I have shared and discussed source code in the recent posts. Now it is time again, to write about design decisions. I made a few of them for the code you saw. So far I have not been reasoning about those here, and some of you might have wondered already. Let's talk about them.
To the library!¶
We turn our project from a binary project into a library project.
So far, our lovem cargo project holds a single binary. That is not very useful for something that should be integrated into other projects. What we need is a library. How is that done? Simple: we rename our main.rs to lib.rs.
Becoming social¶
A new way for you to participate in my journey.
After a few days of progress on the project itself, I spent a bit of time on the site again. We have the fancy link to our GitHub repo in the upper right corner now. But more important, I added support for comments on my entries. You can now react and ask questions or share your thought.
Turn "fragile" into "rusty"¶
After we got our Proof of Concept running, we clean up our code and make it look like a respectable Rust program.
Did you play around with the program from the previous post? If you are new to Rust, you really should! At least mess around with our bytecode. You should find, that our VM does not react well to errors, yet. It simply panics! That is no behaviour for a respectable rust program.
Running our first program¶
Now, that we have a VM, we will run a program on it.
So we built our very first VM and studied the code in detail. It is time to execute a program on it and look at it's output. We will look at every single step the program takes. Aren't we lucky, that our VM is so talkative during execution?
A VM¶
The first draft of source code, that will be our VM, explained.
I dumped some source code in front of you, and then I started to talk about programming languages. Time now, to explain what I did and why. We only have 132 lines, including comments. We will go through all parts of it. And I will talk a little about how Rust's basic syntax works, while I use it. Not too much, since it is not good Rust code, yet, but to help you start. This will be a longer entry.
It looks so weird¶
Now, that you have seen some code, I might have to explain a bit again. Depends, on where you are coming from, I guess.
So, did you take a look at the code, yet? In case you've forgotten, this is my "initial commit":
Let there be source code¶
Finally, I will be showing some source code. Not directly in the journal, but I will link you to GitHub, for a start.
I have written code. And this time, I (re-)started lovem in a public git repository, so you can see what I do, if you are interested. And I hope it puts enough pressure on me, to keep on the project for a while.
Making virtual a reality¶
So I have been talking a lot about VMs without doing anything concrete. Well that is not true, I have done quite a bit already, but I am still describing earlier steps. We will get there.
Registers?¶
When I was looking around for a scripting language to use inside our embedded devices, I came across an article I mentioned in an earlier post: [Creating a Virtual Machine/Register VM in C][register-book].
What is a Virtual Machine anyway?¶
So, how do you build a Virtual Machine. There are actually two quite different approaches:
All new once more¶
Reality strikes again, and code will be written from scratch once more. And the reason is this site.
You want me to get to the code. And I really should. I have written so much already, and I want to show it, but there is so much around it. And after I had written up a long text on how I started, I realised that I had no commits during the early state. So I had to write it all again, slower, and with code to be presentable in this journal.
State of the Journal¶
Since I am always focused on my work on lovem, I will never get sidetracked. Unrelated: I spent a few days on reworking the journal on this site.
So, no update on the core project today, sorry. I was very unhappy with my first solution, on how the Journal entries where created. Way too much to do by hand – that is not what I learned programming for. But mkdocs is python, and python I can do. So did. And now I can write my Journal entries (like this one) as plain Markdown files with very few metadata entries. And I get entries in the navigation and pages listing the whole month. I even included a whole month in single page version of the journal. I feel it is quite fancy. I will need to do a bit of work on the static content of the site, but one step at a time.