The purpose of this homework is to explore what needs to be done to add support in CalOS for programs being written using logical addresses instead of hard-coded physical addresses.
Download the files from here. You should have 5 python files: main.py, cpu.py, calos.py, ram.py, and devices.py; and 2 assumbly language files: mult.asm and fib.asm.
CalOS has changed a bit since homework05:
current_procis now a list of PCBs for the currently running processes, indexed by the CPU number.
The MMU, as you recall from class, is a device that sits between the CPU and RAM. It is responsible for checking if address accesses are legal, and can be used to translate addresses. Using the MMU we can begin to treat addresses in code as logical addresses instead of physical addresses and we can thus load a program in to any memory location in RAM.
Step 1: Add the MMU class, but don't have it do any address translation
Create an MMU class in the file ram.py
Now, update cpu.py to use the MMU and not use RAM directly.
Step 2: "Fix" mult.asm to use contiguous memory
One problem with our assembly language programs is that they are written with hard-coded physical addresses in them, not only for places to jump to in the code, but also addresses which data is read from and written to.
mult.asm to use contiguous memory.
mult.asmassumes the data is found in locations 10, 11, and 12, whereas the code is assumed to be at locations 20 - 31.
mult.asmto read the two values to multiply together from locations 32 and 33, and put the result of multiplication at location 34. Thus, the code will be from locations 20 to 31, and the data will immediately follow in locations 32 - 34.
Step 3: Update
main.py and asm files to note the area
in a file for data storage
Our assembly language files now store data in the locations following the text of the code. But, the files do not indicate the location or size of the data.
To solve this problem, we are going to make one assumption: code always uses the area right after the text as a data area. That solves the problem of where the data will be stored in memory. However, we still need to indicate to the operating system how large the data area is. If we don't do this, the operating system cannot properly check if memory accesses go out of range. To fix this, we'll introduce another special label in the assembly language, __data: value, which will indicate to the OS how much space must be reserved for the program to store data.
main.py, inspect the code in
_handle_main_label.Note how the code reads the address of the entry point of the code and stores it in the PCB.
_handle_data_labelthat will take the same parameters as
_handle_main_label. This code reads the number of bytes from
pcb.set_high_mem()to store the high memory location in the PCB. You will have to write a tiny bit of code to compute that high memory location.
__dataline to the
mult.asmfile with the value 3 to indicate to CalOS that
mult.asmrequires that 3 bytes of data space be reserved after the code. Note: this
__dataline goes at the end of the file -- after the last line of the program.
fib.asmas well. Note that the program currently generates output starting at location 500 but is not limited in how many values it can output. You may assume a limit of 100 bytes.
_load_program()to do two things:
for line in f:to call
set_low_mem()and store the
elifto recognize the __data: line and call
__str__method in PCB to print out the low and high memory limits for the process.)
We are still not doing any address translation or address checking yet. In fact, our MMU object doesn't do anything yet, except pass memory accesses on through to the RAM object. It is time to take care of that. We are going to have our MMU object implement figure 7.6 from the book, where low and high addresses are checked and addresses are translated from logical to physical.
Step 4: Implement Address Translation and Checking
Add registers to the MMU
mult.asmto use 0-based addresses. Do that now. (Sorry.) Make sure the value after
__main:is 0, indicating that the code is written assuming logical addresses starting at 0. Honors students: do it for
set_mmu_registers(). Note that the values passed to
set_mmu_registers()aren't a direct mapping of PCB values to MMU registers -- you have to do a little math to set the correct values in the mmu.
mult.asminto a location that is not 20 -- like 30 or 200. You'll have to enter the operands to be multiplied into the locations that are 12 and 13 bytes after where you load your code.
mult.asmtwice, into two different locations in RAM, setting the operands for both processes, and then starting the OS. Both instances of
mult.asmshould run concurrently and produce correct results.
mult.asmto try to access values outside of the legal range. Make sure the error messages are printed on the console. After doing this, undo your changes to that
mult.asmruns correctly again.
Submit all the code and supporting files for this homework to
We will grade this exercise according to the following criteria: (15 pts total)