So You Want to Build a Language VM - Part 26 - Adding Floating Point Support

These are also known as whole numbers. 1, 2, 3, 4 etc. It also includes negative numbers: -1, -2, -3, etc. 0 is also an integer. If we look at those numbers in terms of money, we can see a problem…​how do you represent $1.50? You can’t, you have either $1 or $2.

These have decimal points in them and are used when greater precision is needed. We can represent fractions like $1.50.

So why don’t we use floats everywhere? Well, we could. In fact, a few languages do. So why do most languages distinguish between them? Let’s take a look at how an integer is represented inside a computer.

In binary, every bit is 1 or 0. We group 8 bits into something called a byte. We can express integers using this without issue:

[0, 0, 0, 0, 0, 0, 0, 0]

The integer 1 is represented as [0, 0, 0, 0, 0, 0, 0, 1], and so on. This is how our decimal system works.

If we want to represent floating point numbers in binary, we have to do more work. I am not going to go into detail on it here, as excellent explanations abound online. The summary is that it takes more work for the CPU to work with floating point numbers compared to integers.

This has the advantage of simplicity, but it also causes a lot of code duplication. Now we need separate instructions for the 64-bit registers. And what happens if someone tries to add a 32-bit register to a 64-bit register? Do we allow casting between them?

This has the advantage of being a more generic solution, but it also would require us to write a lot of code to manage u8s.

One of our primary goals is to not use unsafe rust unless we cannot avoid it.

Option 1! It is easiest to code and understand. It will make some things a bit more annoying for the user, but we can do some things in the parser to help with that.

This is an easy one. In src/vm.rs, add a field called float_registers.

Then in the VM constructor, we need to initialize it:

Note the fact that we are defaulting them to 0.0. This is because they are f64s.

We need to a bunch of new instructions:

In src/instructions.rs, add each of those to the list of Opcodes, the From<u8> impl, and the From<CompleteStr<'a>> for Opcode trait.

But wait, there’s more!

We also have to add a match arm for each of the new instructions in src/vm.rs. The implementation of the ADDF64 looks like:

Opcode::ADDF64 => {
    let register1 = self.float_registers[self.next_8_bits() as usize];
    let register2 = self.float_registers[self.next_8_bits() as usize];
    self.float_registers[self.next_8_bits() as usize] = register1 + register2;
},

Let’s take a look at the EQ opcode for the 32-bit instruction:

Opcode::EQ => {
    let register1 = self.registers[self.next_8_bits() as usize];
    let register2 = self.registers[self.next_8_bits() as usize];
    self.equal_flag = register1 == register2;
    self.next_8_bits();
}

== works fine for comparing integers, since they can be expressed exactly in binary. However, two floats may vary by a very small amount. For example, say we have 1.1003 and 1.1004. We may not care that one is one 10000th higher, and care only that they are equal within one tenth. This margin of error is often called is epsilon. Rust makes it available via use std::f64::EPSILON;.

Check out our EQ64 instruction:

Opcode::EQF64 => {
    let register1 = self.float_registers[self.next_8_bits() as usize];
    let register2 = self.float_registers[self.next_8_bits() as usize];
    self.equal_flag = (register1 - register2).abs() < EPSILON;
    self.next_8_bits();
}

Let’s try a more succinct way of writing a test:

#[test]
fn test_parse_float_operand() {
    vec!["#100.3", "#-100.3", "#1.0", "#0.0"].iter().map(|i| {
        assert_eq!(float_operand(CompleteStr(i)).is_ok(), true);
    });
}

Because we have a problem. A big (or not so big) problem, depending on how you look at it.

Let’s say we want to load a 32-bit number into a 32-bit register. What we could do is have an instruction that sets the first half of the target register to the first 16-bits of the register, then an instruction that shifted those to the right 16 places.

So we go from: [0,1,0,0,0,1,1,0,0,0,0,1,0,0,0,0 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] → [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,1,0,0,0,1,1,0,0,0,0,1,0,0,0,0]. Now we can use the same instruction to set the first 16 bits again.

Before we end this tutorial, let’s write a quick bit-shift instruction. The new instructions are:

I’m not going to go through the details of adding in opcodes, other than the implementation in src/vm.rs. You should know those already. =)

The syntax for these commands will be: * SHR $<reg_num> * SHR $<reg_num> #<number of bits>

The second form is more aspirational, but it would be nice to allow users to choose the number of bits to shift if desired.

You may be wondering why there aren’t bit shift instructions for floats. This is because of how floats are represented internally. The bits are divided into two parts, the significand and the exponent. If you shift bits around, you risk changing the actual meaning of the bits by moving them to different sections.