CSE 378 Homework #5: Memory Mapped Devices, Exceptions, the OS, and Address Translation
Due: Friday, 5/15/2009, 11:00PM
Assignment Goals
You'll do four new things in this assignment:
- Introduce IO to your machine using "memory mapped" device
controllers.
- Implement address translation hardware.
- Implement exception/trap handling to the hardware.
- Implement a plug-in, in C++, using Visual Studio. (It's so simple it counts as only one new thing.)
Plus, there's a bonus, optional piece:
- Modify the operating system software.
When you're done, you'll have a processor capable of running an
operating system. (Fortunately, we've already written the operating system.)
Getting Started
The starting point for this assignment is the single-cycle
machine control you built in Assignment 4.
We're supplying a SMOK container that implements most of the memory mapped
architecture required for all three steps. While there is more implementation work to do in this assignment than the last,
the majority of your time will probably be spent learning about what is needed,
and trying to make sure you understand why.
It's best to approach both the learning and the implementing in stages.
To emphasize the advice to work on this assignment piece-by-piece, the
bulk of writeup is given on separate pages.
Prologue to Working on the Assignment
We'll present more information about each step in this assignment
shortly, but first a repetition of this important message:
you can (and should) understand each piece, in the order presented,
before moving on to the next. Additionally, you can and should
implement each piece and verify that it is working before moving on to
the next. What this means is that the assignment is designed so
that even if after reading the entire thing now it is confusing, you
can safely proceed by ignoring all of it except the piece you need to
do next and nothing will go wrong. That is still a challenging
prospect, as it's hard to know you understand something without (yet)
knowing how it's going to be used.
That said, what follows is a sequence of tasks, including suggested
target completion dates, that lead to completion of the entire
assignment.
Note: Part 3 (exceptions) is the hardest part of this assignment,
and the part that has the most new things in it (making it most difficult
to accurately predict how long it will take).
Milestone 0: Understand the Assignment
| Goal: | Understand all of the assignment, at least roughly.
Understand the first piece enough to begin implementing it.
|
| Details: | This page gives an overview.
|
| See also: | All other pages related to the assignment.
|
| Target completion: | 11:59PM, Wednesday, May 6
|
Milestone 1: Memory Mapped IO
| Goal: | Implement the Cebollita memory mapped IO architecture,
enabling programs to read keyboard input, to write character output,
and to do disk IO.
|
| Details: | This
page has the assignment description for this step.
|
| Building applications: | Consult the assignment details.
|
| RUNNING APPLICATIONS: | See the assignment details.
|
| See also: |
This description of the memory mapped architecture.
This page on the SMOK memory map
container.
iolib.c, a library
that knows how to use the memory mapped IO devices. |
| Target
completion: | 11:59PM, Thursday, May 7
|
Milestone 2: Address Translation
| Goal: | Implement address translation, using the Cebollita memory mapped architecture
components.
|
| Details: | This page has the assignment description for this step.
|
| Building applications: | Consult the assignment details.
|
| See also: | This description of the memory mapped architecture.
|
| Target completion: | 11:59PM, Saturday, May 9
|
Milestone 3: Exception Handling
| Goal: | Implement exception handling, and the syscall and rfe
instructions.
|
| Details: | This page has the assignment description for this step.
|
| Building applications: | Consult the assignment details.
|
| See also: | This description of the memory mapped architecture.
|
| Target completion: | 11:59PM, Monday, May 11
|
Milestone 4: Running the OS and Shell
| Goal: | Demonstrate that everything is working by running the Cebollita OS and shell.
|
| Details: | This page has the assignment description for this step.
|
| Building applications: | Consult the assignment details.
|
| Target completion: | Wednesday, May 13
|
OPTIONAL What to Do: OPTIONAL Part E
In this part you'll modify both the hardware and the software (OS) to provide interrupt-driven
buffering of keyboard input.
In the hardware you should connect up the Character Controller in the memory
mapping container to your exception control logic,
so that an interrupt is raised when a new keyboard character becomes ready.
In the software, you should implement a new function to handle this interrupt.
The interrupt routine should read the character from the Character Controller and store it in some
buffer it owns. It should also echo the character back to the console, so that the user sees
s/he has typed something. Then the interrupt routine returns to the running program.
(If the buffer overflows, well, too bad, now input data has been lost.)
You also need to modify the function that services the readString system call.
It must fetch characters out of the buffer your interrupt handler has been filling.
If it manages to find an entire string in there, it's done -- it returns the result to the application.
If not, it has to go into a busy loop waiting for more user input.
Files
- hw5.tar.gz contains everything you need
(except for your PLA files from hw4).
Download it and put it in the directory where you want to work, then issue
the Unix/cygwin command:
tar xzf hw5.tar.gz
from a shell, after cd'ing to that directory.
- If your HW4 didn't run correctly, get in touch with me for PLA files
to start from.
Turnin