This is the second of two assignments in which you will write binary code for the simple machine you created a simulator for in lab. It is more involved than the first one, and will take more time. Both assume that you have understood that lab’s content well.
icode |
Behavior | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
0 | rA = rB |
||||||||||
1 | rA += rB |
||||||||||
2 | rA &= rB |
||||||||||
3 | rA = read from memory at address rB |
||||||||||
4 | write rA to memory at address rB |
||||||||||
5 | do different things for different values of
|
||||||||||
6 | do different things for different values of
In all 4 cases, increase |
||||||||||
7 | Compare rA (as an 8-bit 2’s-complement number) to 0 ; if rA <= 0 , set pc = rB otherwise, increment pc like normal. |
You should create two files
One you work with, that has comments and notes to keep you sane. Call this anything you like.
One you run and submit, which contains nothing by hex bytes separated by white space. You’ll submit this as a file named fib.binary
To test your code, do one of
python3 sim_base.py fib.binary
or
java SimBase fib.binary
or going to our online simulator and click the file upload button at the top of the page to load your fib.binary
into the simulator’s memory.
Create a binary program (i.e., a file containing hex bytes) that runs in this language; name the file fib.binary
.
When run in a simulator (yours or ours), fib.binary
should change the contents of memory for all addresses i
≥ C016, placing in address i
the i-0xC0
th Fibonacci number (modulo 256, since these are bytes).
Once 0xC0
through 0xFF
are set, halt by running an instruction with the reserved
bit set.
The file fib.binary
itself must not contain more than C016 (19210) hexadecimal bytes.
It should be the case that running your simulator on fib.binary
for many cycles should result in output ending with the following:
0xc0-cf: 01 01 02 03 05 08 0d 15 22 37 59 90 e9 79 62 db
0xd0-df: 3d 18 55 6d c2 2f f1 20 11 31 42 73 b5 28 dd 05
0xe0-ef: e2 e7 c9 b0 79 29 a2 cb 6d 38 a5 dd 82 5f e1 40
0xf0-ff: 21 61 82 e3 65 48 ad f5 a2 97 39 d0 09 d9 e2 bb
Your code should not change the byte stored in address 0 during its run.
You definitely want to make sure you can write working code for this in some language you know well before trying to convert that code into binary.
We suggest following these steps, carefully, saving the result of each in a file so you can go back and fix them if they were wrong:
for
loops to while
loops with explicit countersif
or while
guards to the form something <= 0
a <= b
becomes a-b <= 0
a < b
becomes a+1 <= b
becomes a+1-b <= 0
a >= b
becomes 0 >= b-a
becomes b-a <= 0
a > b
becomes 0 > b-a
becomes b+1-a <= 0
a == b
becomes a-b == 0
becomes !(a-b) == 1
becomes !!(a-b) <= 0
a != b
becomes a-b != 0
becomes !(a-b) == 0
becomes !(a-b) <= 0
and closing withspot1
=pc
if …, goto spot1
0x80
though 0x80
+ number of variablesicode
, a
, b
) triples, possibly followed by a M[pc+1]
immediate valueicode
, a
, b
) into hexmult.binary
Debugging binary is hard. That’s part of why we don’t generally write code in binary. If you get stuck, you should probably try pulling just the part you are stuck on separate from the rest and test it until it works, then put it back in the main solution.