Intertect Journal Day 11 (Evening)
Today I went off on my own an implemented a little utility for pretty-printing binary instructions. I was planning to make some headway on the testing infrastructure, but I realized that in order to really get going, I’ll have to be able to quickly look at what the compiler (either ours or the reference compiler) is outputting. Here’s what the output looks like from the program. In instruction in question is add $t2, $t0, $t1.
+--------+-------------------------------------------------+
| | opcode | rs | rt | rd | shamt | funct |
+--------+--------+-------+-------+-------+-------+--------+
| binary | 000000 | 01000 | 01001 | 01010 | 00000 | 100000 |
+--------+--------+-------+-------+-------+-------+--------+
| hex | 0 | 8 | 9 | A | 0 | 20 |
+--------+--------+-------+-------+-------+-------+--------+It can also print out I and J format instructions, of course. If you look at the hex dump output of a compiled program, it’s really difficult to know which bits are doing what. For example, running hexdump against the program gave me 01 09 50 20 as he hexidecimal bytes for that instruction. That means pretty much nothing to me since the arguments aren’t on byte boundaries. I’m hoping this tool will make diagnosing compiler bugs significantly faster. Once the testing infrastructure is set up, I’ll integrate this so that whenever there’s a difference between the two programs, it’ll output a table like this showing exactly what is different between the expected and actual output.
It was a surprisingly quick utility to throw together which was fantastic. Rust, man. It’s the best. Anyway, tomorrow I’ll do more setting up of the testing infrastructure and if I have time I’ll write a post about endianness in computer architecture. It’s a surprisingly complex topic and it’s also one that tends to confuse novice programmers. You won’t have to care care about it 99.99% of the time, but this is that .01%. This’ll be fun!
-Peter