When you're done, you'll have a processor that is capable of executing some of the kinds of Cebollita programs we've built so far -- you won't be able to do I/O, because your machine has no I/O devices, but everything else will run. This means that you can use Cebollita to generate complicated test cases. (Part of this assignment (and all real-world projects) is convincing yourself that your implementation works. You'll do that through a combination of testing and reasoning.) Those test cases will be useful in this assignment, and in future ones as we expand and reimplement the machine. Some information on how to build them is given below.
(* Remember that MULT/DIV have been simplified to look like regular R-type instructions. Other changes from the Mips are noted in the Cebollita documentation.) The Cebollita instruction encodings are given in the relevant Cebollita documentation.
Is this subset enough to get anything interesting done? Yes. In fact, the Cebollita compiler limits itself to this subset as well, so you will be able to use it to build real benchmarks and test programs for your machine.
You'll notice that there are more than four containers (the large, light grey
rectangles) in the model. The others are there just to indicate why you are
using containers -- later assignments will require additional circuitry that
we intend go in those "extra" containers. You can delete the extras
for now if you want and your screen is large enough to make the connection
points available when both Containers are "collapsed",
but remember that (a) you'll need add many more components
later, and (b) there is no simple way to move components from one container to
another in SMOK (you basically have to delete them and create them anew, or
else edit the .smok
file).
Containers are not functional parts of the circuit, they're just ways of organizing the components on the screen. You can connect directly between components in different containers, if you want, or you can create input/output "passerelles" components that interface what's inside a container with everything outside. (The passerelles are simply connectable components large enough to click on when a container is not expanded, unlike the connection points on the other components within the container. When you run SMOK, you'll see what I mean.)
Double-clicking on the background within a container expands it, making it easier to work on. A picture of the expanded data path container is here. A picture of the expanded PC control container is here.
This initial model, as a SMOK input file, is linked near the end of this assignment.
Note that, if convenient to your implementation, you can edit the meanings of the ALU control lines in SMOK to alter which control line values correspond to which ALU operations.
Read the relevant section of Appendix B and C to learn more about PLAs. There is more information in the online SMOK Component documentation, and an example using PLAs (to build a "stack machine") on this page.
ori $0,$0,1
). SMOK provides a simple way
to guarantee this - the RegisterFile component can be set to enforce
this behavior. The RegisterFile in the inital model distribution
has this behavior set.
ORI/ADDI: It may seem redundant to have both of these instructions in the instruction set; however, ORI has the nice quality that it does NOT sign-extend its immediate operand. This makes it useful/convenient for generating large constant values. The upshot of its inclusion is that the ALUSrc MUX will now take 3 inputs: a register value (for R-types), a sign-extended immediate (for memory ops and ADDI), and a non-sign-extended immediate (for ORI). Again, the inclusion of this instruction will impact your control equation.
cebollita\apps\quicksort
. However, it does IO.
There is a little glitch in that plan, though. If no instructions are known to execute correctly, how can you rely on the test program working? The answer is, you can't. You'll have to start with assembler programs consisting on only a couple of instructions and verify by stepping through your program that those instructions work. The test program I described above can't be used until at least some kind of conditional branch works. Because those are among the hardest things to get right, you might start with straightline code that tests a number of instructions, putting the result of each in a different register, and then halting. Examining the registers when you halt should show where there are problems.
Remember that it's possible to debug your test program(s) (i.e., that software, which needs debugging just like any other software) while the machine is being implemented, using the Cebollita simulator. It would be good to verify that the test program doesn't itself have a bug, so that you don't misinterpret a software mistake as an error by the hardware (SMOK) implementation.
SMOK
understands the Cebollita
executable format,
and will set up $gp
and $sp
when the
memory
component (re)loads the associated contents file.
.text .global main main: add $t3, $t2, $t1 haltYou won't have
jal
implemented,
so you won't be able to use a real prologue to link with this.
However, __start
is not defined, causing the linker to complain.
One way to solve this problem is to link with
cebollita\apps\prologue-standalone.s
:
# The null prologue, which leaves the user-written code at PC=0 # but satisifies the linker by having a __start: symbol .text .global __start __start:That satisfies the linker, but doesn't create any instructions at all.
Alternatively (and equivalently, in terms of the .exe
that is produced), you can just create the symbol __start
in your .s
file and not link with any prologue:
.text .global __start __start: add $t3, $t2, $t1 halt
main
function, because that's where execution starts. And, suppose you're
pretty sure you have jal
and all the other instructions working.
You can link your C-- program with prologue-noos.s
(supplied in the files section of this writeup):
# The Cebollita ISA simulator's loader has set things up so that on entry: # $gp = size of text segment # $sp = text size + data size + heap size + stack size - 4 # $pc = entry point (presumably __start here!) .text .global __start __start: jal main haltNote that it uses the Halt instruction to stop, so doesn't need an OS.
.smokpla
files,
which must be edited externally to SMOK. You can cause a PLA component
in a running instance of SMOK to re-read its PLA file by reinitializing the
SMOK model. (The memory component will re-read whatever file you loaded
into it as well.)
We'd like your SMOK model and PLA files, as well as whatever test programs you tested your model on.
We also would like a short (under a page should do it) writeup telling us:
Please submit files in a tar file hw3.tar. To make this file, enter cygwin, navigate to the directory
with your files and use the following command:
tar cvzf
hw3.tar.gz <files to include>
for example:
tar cvzf
hw3.tar.gz *.smok *.smokpla *.c *.s mywriteup.txt