The exam will consist of short-answer questions and writing your own code. A significant portion will consist of writing code (more than half the points), so you should be prepared to do this.
The review below, in addition to Lab 1, Lab 2, and Lab 3, are all fair game for the exam. For the labs, this includes both code you've written and questions you've answered. Between this review and the first three labs, this information is intended to be comprehensive; there will be no material on the exam which isn't touched by either the labs or this review.
If you're pushed for time, my personal recommendation is to spend the majority of your time studying what you wrote for your labs, both code and questions. You'll find the review below to be largely (though not entirely) redundant with that information.
0x45
into decimal.0x1F
into decimal.1001
into decimal.1001
into decimal.0110
, showing the result in binary.0110You're not told whether or not the number is signed or unsigned. Is this information important in knowing what the value of the number is, in decimal? That is, do you need to know if it's signed or unsigned to say what the decimal value is? Why or why not?
1001You're not told whether or not the number is signed or unsigned. Is this information important in knowing what the value of the number is, in decimal? That is, do you need to know if it's signed or unsigned to say what the decimal value is? Why or why not?
add
and addu
instructions?
Consider the following C code:
signed int x = -1; // line 1 signed int y = 5; // line 2 signed int result = x + y; // line 3
In generating the assembly code for line 3, MIPS compilers will generally use the addu
instruction, which is for unsigned addition.
This is not a bug in the compiler, and result
will, in fact, end up holding the correct result.
There are two questions here:
addu
return the correct result, despite being intended for unsigned addition?addu
here instead of add
?Perform the following addition, noting whether or not the carry bit and the overflow bit get set:
01111111 +11111111
Perform the following addition, noting whether or not the carry bit and the overflow bit get set:
00100101 +10110111
Perform the following subtraction, noting whether or not the carry bit and the overflow bit get set:
01111111 -11111111
Perform the following subtraction, noting whether or not the carry bit and the overflow bit get set:
00100101 -10110111
Consider the following C code:
signed char x; for (x = 1; x > 0; x++) { printf("Hello\n"); } printf("Goodbye\n");
Assume the compiler performs a naive translation to assembly, and doesn't exploit any special features of C. Some questions follow:
"Goodbye\n"
ever get printed out?
Why or why not?
Consider the following C code:
unsigned char x; for (x = 0; x <= MAX_UNSIGNED_CHAR; x++) { printf("Hello\n"); } printf("Goodbye\n");
Assume that MAX_UNSIGNED_CHAR
holds the maximum value representable in an unsigned char
, which is defined previously in the code.
Some questions about this code follow:
"Goodbye\n"
ever get printed out?
In the following questions, &
refers to bitwise AND, |
refers to bitwise OR, ^
refers to bitwise XOR, <<
refers to shift left, and >>
refers to shift right.
00011101 &11011010
00011101 |11011010
00011101 ^11011010
Consider the following C code, which is intended to extract the lowest 7 bits of the given input i
, leaving the bits in their original position:
int unsignedBits0through6(int i) { return __________; }
Fill in __________
with a single bitwise expression which will make the code do what it is intended to do.
Consider the following C code, which is intended to extract the next 7 bits of the given input i
, leaving the bits in their original position::
int unsignedBits7through13(int i) { return __________; }
Fill in __________
with a single bitwise expression which will make the code do what it is intended to do.
Consider the following C code, which is intended to extract the lowest 7 bits of the given input i
, treating the result as a signed value, leaving the bits in their original position:
int signedBits0through6(int i) { __________; return __________; }
Fill in the blanks with valid C code which will make the function do what it is intended to do.
Consider the following C code, which is intended to extract the next 7 bits of the given input i
, treating the result as a signed value, putting the bits in the rightmost position:
int signedBits7through13(int i) { __________; return __________; }
Fill in the blanks with valid C code which will make the function do what it is intended to do.
DecodeCode.c
.
I'm not including those questions directly here because it is redundant, and because I won't post the answers to them (which would give the world the solutions to the lab!).
00001011
.
How can this be multiplied by 4, without using an instruction intented for division or multiplication?
00001011
.
How can this be divided by 4, without using an instruction intented for division or multiplication?
There is only one form of shift left, but there are two forms of shift right. Some questions follow about this fact:
Division by a power of two can be achieved via the clever use of shift right. However, this won't always get the same result as actual division would. Some questions follow about these facts:
li
pseudoinstruction do?li
an actual MIPS instruction?li
to a form that uses only actual instructions (no pseudoinstructions):
li $t0, 0xFFFFFFFF
Translate the following C code into MIPS assembly.
The variables used below should be placed in the register with the same name.
For example, variable s0
should be placed in register $s0
.
If you need additional registers than what the code below uses, use registers $t0 - $t9
.
You do not need to exit the program properly.
int s0 = 82; int s1 = s0 << 2; int s2 = s1 * 20; int s3 = s2 + 7; int s4 = s3 - 24; int s5 = s4 / 3;
Translate the following C code into MIPS assembly.
Where <<read integer from the user>>
is used, you should use special functionality provided by SPIM to read in an integer from the console.
Where <<print integer s1>>
is used, you should use special functionality provided by SPIM to print the integer stored in s1
to the console (you might not be able to do this directly, in which case you'll need to copy the value of s1
into another register first).
The variables used below should be placed in the register with the same name.
For example, variable s0
should be placed in register $s0
.
If you need additional registers than what the code below uses, use registers $t0 - $t9
.
You do not need to exit the program properly.
int s0 = <<read integer from the user>>; int s1 = 2; if (s0 < 7) { s1 = 3; } <<print integer s1>>
Translate the following C code into MIPS assembly.
Where <<read integer from the user>>
is used, you should use special functionality provided by SPIM to read in an integer from the console.
Where <<print integer s1>>
is used, you should use special functionality provided by SPIM to print the integer stored in s1
to the console (you might not be able to do this directly, in which case you'll need to copy the value of s1
into another register first).
The variables used below should be placed in the register with the same name.
For example, variable s0
should be placed in register $s0
.
If you need additional registers than what the code below uses, use registers $t0 - $t9
.
You do not need to exit the program properly.
int s0 = <<read integer from the user>>; int s1 = 2; if (s0 < 7) { s1 = 3; } else { s1 = s0 + s0; } <<print integer s1>>
Translate the following C code into MIPS assembly.
The variables used below should be placed in the register with the same name.
For example, variable s0
should be placed in register $s0
.
If you need additional registers than what the code below uses, use registers $t0 - $t9
.
You do not need to exit the program properly.
int s0; int s1 = 1; for (s0 = 0; s0 < 10; s0++) { s1 = s1 * s0; }