CSE 378 Homework #7: Exceptions, the OS, and Everything

Due: 3/10/2003
Work in teams of up to three

Assignment Goals

You'll do two new things in this assignment:
• Implement exception/trap handling, in the hardware.
• Use that mechanism to extend a simple operating system for your machine (i.e., software).

When you're done, you'll have a processor and a mini-OS for it that is capable of running Cebollita programs.

Starting Point

The starting point for this assignment is the single-cycle machine you built in Assignment 6, minus your implementation of memory-mapping. We are supplying a SMOK container that implements the memory mapped architecture required. More on that in a moment, after we've explained the architectural implications of the new component.

The Memory Mapped Portion of the Achitecture

You're about to see documentation on the memory mapping scheme used in this architecture. Keep in mind that (a) this is already largely built for you, and (b) you don't really require all this detail to finish the assignment. The architecture does affect the part of the hardware you're building, but only in ways much simpler than all this detail implies. The detail is here largely for completeness, but also because some of it may be useful in the code you write in the last part of this assignment, and all of it is useful if you need to read and understand the code we're providing.

So, don't despair, it's a lot easier than it probably will look.

The IO Architecture

The machine has memory mapped locations that directly expose the hardware character controller and block controller devices.

Name	Address	Use
Character Controller	0x40000000	When written, the data is fed into the character controller. When read, the result is the current output of character controller.
Block Ctrl	0x40000010	When written, writes the block controller Ctrl input. When read, reads the controller's current output (Status port).
Block Memory Address	0x40000014	Write-only. Writes the block controller's memory address input.
Block Disk Address	0x40000018	Write-only. Writes the block controller's disk address input.
Block Count	0x4000001c	Write-only. Writes the block controller's block count input.

The Trap Architecture

The machine has four memory mapped locations related to trap handling:

Name	Address	Use
Handler Address	0x40000030	Holds the address that should be loaded into the PC when an interrupt, exception, or trap occurs.
Status Register	0x40000034	Bit 0 is the privilege bit. When on, the machine operates in privileged mode. (When off, it does not.) Bit 1 is the interrupt enable bit. When 1, interrupts (and exceptions, traps, or whatever other name you might use) can occur. When 0, they are not raised.
EPC	0x40000038	PC of the instruction executing when the trap occurred.
Cause	0x4000003c	Read-only. An integer indicating the kind of trap that occurred.

(Note that "read-only" refers to what can be done by software. The hardware can of course do most anything.)

The Memory Protection Architecture

Memory protection is provided using memory base and length registers. When the machine is running in unprivileged mode, the contents of the base register is added to all addresses before actually reading from memory. (This means, for instance, that the instruction fetched is at actual memory location PC+base.) This allows a program that has been linked as if it were going to be loaded at address 0 to be loaded anywhere in memory without change.

The length register is used to constrain the portion of memory an application can touch. If the address it issues (before adding base) is greater than or equal to length, it is a memory addressing error. In this case, a fault is raised.

When the machine is operating in privileged mode, the base and length registers are ignored. (This allows the operating system full access to memory.)

Note that because all memory mapped resources are at addresses that will be larger than any application's base+length register settings, no application will be able to manipulate those resources itself. This is an aspect of enforcing security.

Name	Address	Use
Memory Base Register	0x40000020	Offset to add to all memory addresses when machine is running in unprivileged mode.
Memory Length Register	0x40000024	Largest legal address that can be requested by the program when the machine is running in unprivileged mode.
Memory Size	0x40000028	Read-only. The size of physical memory, in bytes.

What to Do: Part A

In the first part of the assignment, "all you have to do" is implement the hardware-side of trap handling. In particular, you need to:
• implement a new instruction, syscall, that forces a trap. When the trap occurs, the hardware needs to do all of the following in the current cycle:
  • EPC <- PC
  • Cause <- a unique id number indicating the event that occurred
  • Status <- 1
  • PC <- trap handler address
• implement a new instruction, rfe, that returns from an interrupt
  • PC <- EPC
  • Status <- 2
• test your implementation. Make sure syscall and rfe do the desired things by writing tiny test programs and observing that the machine jumps to the correct address and that the Status register is updated correctly.

(The formats of the new instructions are in the text on page A-78.)

The SMOK container provides a lot of support for these functions -- you should not have to understand the internals of that component to get this working. More information is provided at the end of this document.

Exception Cause ID	Meaning
1	Char device needs attention
2	Block device needs attention
4	Addressing violation
8	System call
16	Integer overflow

Note that of these you need to implement only the syscall, overflow, and the character device exceptions.

What to Do: Part B

• Implement an overflow exception. (The ALU has an output that indicates when it occurs).
• Implement the memory architecture. Use the base register to adjust addresses issued by the program (when running in unprivileged mode). Raise an exception if the machine is in user mode and a memory address greater than or equal to the Memory Length Register value is used.
• Test, test, test.

Having done Part A, these should be relatively easy.

What to Do: Part C

Up to now, you haven't needed the code for the operating system. We've just been building and testing a machine that could support an OS. This is the point at which we make the transition.

Build an OS image, including some test applications, and run them. The OS will kill any process that generates an unhandled exception. It should run processes that do not generate exceptions to completion.

Because we're getting perilously close to what a real machine and system is at this point, you do not simply use the SMOK memory component to magically read the OS disk image into itself. Instead, you use SMOK's boot capability, which requires you to attach a virtual disk (i.e., the OS image file you generated) to the Block Controller device inside the memory map container. Having done that, you can use the power on toolbar button to boot your machine. (See the documentation on SMOK's Block Controller for more information.)

When you boot your machine, the SMOK Block Controller will load the boot loader (whose source is bootloader.s) into memory at address 0. When that is done, your machine starts executing (so it should have its PC initialized to 0). The boot loader loads the rest of the OS into memory and then transfers control to it.

Once the OS has initialized itself it starts the first process, a shell. The shell is just a regular old user application. The OS transfers control to it, and it starts running.

This is a very primitive system -- it has no file system at all. (It has a disk, but it doesn't have any notion of files, just raw disk space.) All the shell can do for you is start other programs.

The shell sits in a loop. At the top of the loop it prints a prompt asking you for a disk block number. To identify the program you want to run, you have to give the disk block number at which it is located. The block number corresponding to each program on your disk is printed out when you create the disk image, so those are the numbers you need to supply.

So, what are you doing in this part? You're just making sure you can create a disk image and that the OS will run on the machine you've built. That is, you're just using tools and software that is provided, and verifying that your hardware implementation works. There is no need for you to implement any new hardware or write any software for this part.

What to Do: Part D

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 for this 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 overlows, 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.

That's It, You're Done

It looks like a lot, but almost all of it is learning what things mean. The work to complete the parts you actually build is probably much smaller than the work to understand what is going on.

The Memory Mapping SMOK Container

When you add this container to your model (right-click, then Add Component, then From File...) a copy is made and embedded in your SMOK model. From that point on you simply work with the model -- you can even delete the container file if you'd like.

The container is the hardware analogue of a subroutine in software. It has a relatively simple interface -- what it wants for input, and what it provides as output. All you need to do is attach to that interface correctly. The interface is described in a separate document. (Note that you do have to make a simple connection internally to the container - you have to connect your Memory component to the Mem input of the Block Controller. There is no way to avoid this, sorry.)

Files

• CebMemoryMap.smokcont (the memory map Container file).
• OS and related code

Debugging Utilities

• Disassembler utility: part of the Cebollita toolkit. Converts an instruction from hex to assembler. Example use:

  $ java util.Disasm
  > 34084000
  ori     $t0, $0, 16384
  > 8d090000
  lw      $t1, $t0, 0
  > [killed with ^C]
  
  
  $ java util.Disasm 34084000
  ori     $t0, $0, 16384
  

• Suppose your machine doesn't work, but you can't figure out why. You can get a trace of the PC and the instruction executed each cycle:
  1. Add a Trace component to your model. Right-click/Add Component to add exactly two input ports. Connect the first of these (port 0) to the PC. Connect the second to the IF unit that fetches instructions. Do not mix up up which is which.
  2. Double-click on the Trace component and choose Properties. Give it a file name to writ to.
  3. Now boot.
  4. Stop your machine and exit SMOK.
  5. The Trace component will have created a file that looks like this. It's not very easy to read. (See the documentation for Trace if you really want to know what it is.)
  6. Now run this perl script to make a more readable file. (Note that it took almost 4 minutes to do this conversion on my machine for a trace of only 35,000 cycles!.) This will work only if you have perl installed. I ran it like this:
     perl convertTrace converted.txt