The start-up script has created the directory smd137/lab3 and placed the files "mips_pipe.xml" and "mips_pipe_extended.xml" there. The mips_pipe.xml defines a simple pipelined MIPS architecture, while the mips_pipe_extended.xml further adds exception/interrupt handling in the coprocessor 0 (CP0). You should copy the file lab1.s to this directory
cd smd137/lab3 cp ../lab1/lab1.s ./lab3.sand modify your code to run on the pipelined mips (mips_pipe.xml). Compile using:
sde-as -mcpu=r3k -O0 lab3.s -o test.o sde-ld -T linker_script test.o -o a.out sde-objdump -h -z -s -d -t a.out > mips_pipe_program.objdump rm a.out test.oor simply by using make:
When exposing your code to interrupts (using mips_pipe_extended.xml) you should compile your modified code (lab3.s) together with the files "init.s" and "int_handler.s" that have been placed in this directory by the start-up script.
sde-as -mcpu=r3k -O0 init.s lab3.s int_handler.s -o test.o sde-ld -T linker_script test.o -o a.out sde-objdump -h -z -s -d -t a.out > mips_pipe_extended_program.objdump rm a.out test.oor
make pipe_extGroup specific information which you will need later is found under lab3underlag.
DT_LABNUMMER 3 DT_LABDEL 1will be MIPS assembler code based on the file you submitted for Lab One, Part One.
DT_LABNUMMER 3 DT_LABDEL 2will be based on the group-specific underlag part A in which you will answer some questions and provide some summary information, to be described later. The third part,
DT_LABNUMMER 3 DT_LABDEL 3is your "Mips Pipe" code, based on group-specific underlag part B. You MAY use MIPS pseudo-ops in Part Three.
One of the "side" issues of the lab is to demonstrate that there is a trade-off and interaction between hardware and software when one wants to make a hardware/software codesign run faster. In this case we consider a pipelined the MIPS model. Our pipelined variant is called "mips_pipe.xml". It is not exactly like the one discussed in the book. In fact the SyncSim "Mips Pipe" model is much closer to the true MIPS processor. Your job is to understand this new model, how and why it works, and what changes become visible to the programmer. In particular are the problems of delayed branch, and delayed memory loads. In this lab you will see "delay slots". You must understand (by studying the executing SyncSim model) why these occur. Then, you must alter your code from Lab One to run in the Mips Pipe model, in such a way that you avoid "wasting" the delay slots. This involves moving your instructions around, possibly changing their order, and adding "nop" instructions as a last resort. You will have to understand which reorderings are safe, and which are not. Obviously the compiler has to know how to cooperate with the hardware. In this lab, you are making the reordering instead of the compiler.
The second "side" thing will be to take the very first steps toward
working with interrupts and exceptions. For this you should use the
"Mips Pipe Extended" model (mips_pipe_extended.xml) that have a
CoProcessor (used to handle interrupts), MMU
(Memory Management Unit), IO (Input/Output) and Timer (generates timer
interrupts). You will modify your Lab One program and compile it
together with a init program and a small "interrupt handler", and you will run your program at
the same time that interrupts are being allowed to "hit" at unpredictable
times. If you have written your program properly, it will not be affected
by these "hits." But if you have been sloppy working with the stack for
example, you may find that your program no longer works, or fails at random
times. Now you have to go back and try to make your code robust for working
in an interrupt environment.
LAB THREE WILL BE RETURNED AUTOMATICALLY IF THE MEMBER(S) OF THE PRESENT GROUP STILL HAVE A PENDING LAB ONE.Use your code for Lab One as the starting point. If you have joined a (different) group since then, then use the code which was turned in having the same "group number" as the one you have now.
You may not use any pseudo-instructions in your Lab Three program, that is, in your modified-for-pipeline Lab One program. That means you will have to expand all your Lab One pseudo-instructions out. First test that your program still works properly under mips.xml. Make sure that you correclty treat "seed" as a global variable before continuing! Note how many cycles your program now takes to finish under mips.xml. (Think about it, did the number of cycles change to Lab One, if so, why?)
Now, first of all in order to run in pipelined mode you should add some code to the main function from your Lab One so that it looks like this:
.text .set noreorder main: li $s0, ... ... bal decode # outer call to recursive "decode" nop end: b end # infinite loop; plaintext now in "plain". nopIt is only the bold text that should be added.
Now compile your Lab Three program for mips_pipe.xml.
Now try to execute the program in "Mips Pipe" (mips_pipe.xml), and compare the results against those of the "No Pipe" (mips.xml) execution. Does the unmodified program work? Does it reach the infinite loop in the end of the main function? How many characters are successfully decrypted? Try to locate where things first "go wrong".
Now modify your program to run under "Mips Pipe" (don't worry about interrupts yet, we will do that afterwards, below...) The changes MUST BE small, "local" transformations, not a big sweeping rewrite! There are only two special types of instructions that cause "trouble." The "name of the game" is to AVOID USING "NOP" instructions (or any other instruction that does no useful work). Instead, "reschedule" (re-order) your instructions a little bit, wherever possible, to make best use of the pipeline.
Once it looks like you've got it working for "Mips Pipe", and without pseudo-instructions, then run your program under "Mips Pipe" and record the number of cycles it takes to complete (put a breakpoint at the infinite loop in the main function), it must properly decode your string.
Now recompile the code for "mips_pipe_extended.xml". Take this new modified program, and load it into SyncSim "Mips Pipe Extended" (mips_pipe_extended.xml). Put a breakpoint in the interrupt routine in the code view. Press "Play" and your program should break at the interrupt routine (for each timer interrupt, approaximately every 1000 cycles). If your code does not work, check your stack management. (How many cycles did your program take to finish?....)
Open a New Input Window by right-clicking the IO component. Now, while your program is free-running, click in the input window with the mouse and strike a key on the keyboard which will print the key in the input window if it can be represented. If your program is working correctly, nothing strange should happen, i.e it should branch to the interrupt routine and stop at your breakpoint, when you press play it should finish the interrupt routine, jump back to your program and continue executing. Keep testing keystrikes like this for about a minute.
Now reset the program and set a breakpoint in the infinite loop in
the main function. Start the program and try to run the
keystrike interrupt test on it. When your program reaches the breakpoint, record how many cycles were required total. You should also verify
that your program has decoded its string properly.
Your program still
has to work correctly !
Part Two is the group-specific
underlag, part A file for your group, which you have modified according
to the instructions found there, answering all questions please.
What you are coding is called a software floating point package, that is, software which implements basic floating-point operations. Once you can perform the basic arithmetic operations, then it is possible to build other subroutines which call them, to perform other complex floating-point calculations. For eample, we have provided you with a primitive routine which can take the natural logarithm of small positive floating-point values.
You should debug each subroutine carefully before moving to the next subroutine. When all are complete, you should then execute the main program which is provided in the underlag. It will test floating addition, subtraction, multiplication and division, in that order, and repeat that sequence a total of five times. After this it will call the logarithm subroutine once. To execute your program,
00 + 5.19644e-11 1.24881e-11 6.44525e-11 6.44525e-11 10 - 0.026717674 0.000641741 0.026075933 0.026075933 20 * 2.410685e13 2118202496. 5.106319e22 5.106319e22 30 / 3.90302e-15 0.002211778 1.76465e-12 1.76465e-12 40 + 0.000676339 1.73150146 1.732177854 1.732177734 ** 50 - 3.12215e-12 8.61221e-09 -8.6091e-09 -8.6091e-09 60 * 1.29128e10 0.00065208 8420175. 8420175. 70 / 1.37244e-14 1.07808e-13 0.127304226 0.127304211 ** 80 + 3.298334e13 5.594143e10 3.303928e13 3.303928e13 90 - 7.21709919 102.1479416 -94.9308395 -94.9308395 A0 * 0.029066296 1.667559e27 4.846976e25 4.846976e25 B0 / 0.026228737 4.73909e-09 5534551.5 5534550.5 **Not too bad. The first six significant digits are the same.