This Week in Iridium - #3
Summary of what happened in the third week
Summary of what happened in the third week
Summary of what happened in the fourth week
Adds in a symbol table to our VM
Welcome back! When we last left our intrepid readers, we were about to write an assembler struct.
But why? What does it do?
What does it all mean?! Why don’t more people love interrobangs?! Ahem.
Adds in labels to our VM
Adds in strings to our VM
Adds in strings to our VM
This may shock you, but they are a bit more complicated than they might seem. Since a computer cares about bytes, it has no concept of the letter s
, !
or any other letter. These having meaning to us humans. But we want our users to be able to give input and read output without having to do it all in hex. The solution is to use some sort of character encoding. This maps a particular character to a number.
You’ll hear two common encodings mentioned these days: ASCII and UTF. I’m not going to go into an exhaustive history of them; for that, check out this article for ASCII and this article for UTF-8. I will cover enough for us to put in support for strings, though.
Adds in heap memory to our VM
Teaches our assembler to recognize more instruction forms
Our assembler right now can recognize one opcode, load
. We need to teach it to recognize all the rest. There’s a couple ways we can do that:
We can write a parser for each opcode
We can write a parser that recognizes the letters a-z
and then check if they are a valid Opcode.
Let’s go with option #2, since it will require much less copy-paste. It also gives us an excuse to implement From<CompleteStr<_>>
for our opcodes!
== The From<&str>
Trait
In instruction.rs
, below the block where we implemented From<u8>
, put this:
Goes back and adds docs, tests and other improvements
You know how I’ve written several times we’ll come back and fix/change stuff later?
Summary of what happened with Iridium in the second week.