Apr-18: I have fixed a few bugs in the MMU's implementation of paged virtual-to-physical translation. It seems to work correctly now. However, in doing so, I discovered that I had been inconsistent, within the simulator, about endianness. To make it consistent, I needed to change how the mode register (MD) behaves. Previously, the meaningful bits of this register were in the most significant positions; I have changed that now to use the least significant bits. Specifically, if we number the bits from 0 to 31, right to left, least significant to most, the flags controlled through MD are:
With apologies for your kernel code, please update accordingly.
Apr-05: Important correction: I said something stupid yesterday while presenting Project 2 (details to be posted soon). Specifically, the PT register, as well as the pointers in the upper-level page table, cannot contain virtual addresses. Doing so creates a fundamental circularity problem: To translate the virtual address in the PTR, one needs to use the page table to which the PTR points.
What is the correct thing to do? The PTR and the upper-level page tables must contain physical address. Therefore, the kernel must know the physical locations of the page tables (upper and lower) that it allocates, and place those physical addresses into the PTR and page table.
Mar-14: Allen has noted an important property of the assembler about which you all should know: The code, numeric, and text (string) values written into your assembly code are emitted, by the assembler, as three, contiguous segments, no matter the order in which you interleaved them in the code. That is, the assembler will reorder the lines you wrote such that all machine code comes first, followed by all numerics, followed by all strings.
For most circumstances, this reordering is irrelevant, since you should be using labels to determine addressing for jumping, loading, and storing among these regions. However, you may wish to use a label to mark the end of the statics region. To do so correctly, you must take into account the reordering. That is, if you add, to the end of your code, the following...
.Numeric
end_of_statics: 0
...then you will find that this label will correspond to the last numeric value, but preceed the strings (if you have any). If you have at least one string, then you must use a label on a string to mark the end of the statics:
.Text
...
end_of_statics: "The end."
First, note that overwriting this meaningless string should be fine; the string itself can be anything, since all meaningful strings preceed this last one. Second, note that strings may not begin or end on word-aligned address boundaries. Therefore, this label tells you the end of the statics, but any new region (say, the beginning of a heap) should start at the next word boundary. That is, you may need to round this label up to the next address that ends with the bits 00.
Mar-04: Because I will be attending a conference, there will be no class meetings on Monday and Tuesday. You do, however, know that your project partners are available from 11:00 to 11:50 am on those days, so perhaps you should all get together in 007 and work on Project 1. Hint hint.
Detail update: Assume, as we have in Project 1, single-segment virtual addressing. When an interrupt occurs, the kernel's interrupt handler does not exist within the user-process's virtual address space. Therefore, the CPU cannot remain in that addressing mode while vectoring into the kernel. I will update the simulator, later today, such that an interrupt will automatically switch the mode from single-segment virtual addressing to physical addressing. Thus, your existing trap table configuration should continue to work. (Later, when we employ paged virtual addressing, this situation will change; worry about that later.)
Mar-01: I've finally posted Project 1. It's big, and I fear that few groups have made any significant progress. You have two weeks, so get cracking. Ask lots of questions, divide the project into discrete, testable parts, and get moving.
Feb-12: I goofed. If you look in your home directory, you will likely notice that there is a directory named submissions that contains what you submitted as your Project 0 work. It wasn't supposed to go there. I have fixed (I think!) the problem with the submission code, and it should properly put your submission into my directory now. So please, ASAP, re-submit your work with cs261-submit for Project 0.
Jan-28: Although we have not yet met in the lab, start reading Project 0. Only a small part of the text is the assignment itself; most of the document describes the k-system instruction set, assembly, device interface, and simulator. These are the tools and environment that you will use for all of the projects, so begin to absorb the details.
Note that I have not quite yet installed some of the files and tools; that will happen over the next day. If you try to copy the sample assembly file and it isn't there, don't panic; just try again later. In the meantime, keep reading. Send questions so that I can address the most critical ones in class on Monday.
Jan-21: Welcome to Computer Systems II! If you are enrolled in this class, or even if you are considering this class, please begin, before our first class on Monday, Jan-23, by reading the Course Information. This document makes clear what material we will cover, what is expected of you as a student, how I will evaluate your work, etc. It may also help you to determine whether this course is one that interests you.