Clarifications and FAQ

• 1. Final Deliverable
• 2. Garbage Collection / Reclaiming Resources
• 3. Types for Process Starting Point Functions
• 4. Process Starting Point Functions Returning

1. Final Deliverable

The details on what the final deliverable should contain can now be found on the final deliverable page which has been added to the specification (2004-Dec-06).

2. Garbage Collection / Reclaiming Resources

In the specification, there is a requirement to reclaim all memory used by a certain process when it ends. What this means is that if you use statically allocated arrays for the process control blocks and process stacks and message queues, you should make sure that all used items are put back on the list of free items when the process ends. Ideally, you should also make sure that you have sufficient stack and message space for the maximum number of processes that your operating system supports (2004-Nov-08).

3. Types for Process Starting Point Functions

All functions that form the starting point of a process should take the same parameters, since you will want to have arrays of function pointers with starting points of your processes. This requires that all starting point functions take the same parameters (if nothing else, the C type system requires this). Parameters from the process spawning a new process is easier to send as messages to the new process than to try to pass as arguments to the actual spawning (2004-Nov-08).

4. Process Starting Point Functions Returning

If a process designated as the starting point of a process returns, your OS should interpret and handle this as if the process exited. Logically, this can be accomplished by wrapping the starting of function like in the following C-like pseudo-code (this code is called as the actual starting point of the new process, so it is run in the context of the new process):

StartProcess( function-pointer function_to_start )
{
  function_to_start()
  quit_this_process()  // kernel call to terminate this process
  // if we get here, we are in trouble
}

(2004-Nov-08)

---

• 1. Interrupt Setup of Machine Updated
• 2. Updated Description of Interrupt Handling
• 3. Updated Description of Example Files
• 4. Updated Explanation of Virtual Memmory System

1. Interrupt Setup of Machine Updated

It turned out that the current setup of the serial port and its interrupt handling in the MIPS machine was too complicated and led to many problems with interrupts coming in all the time or not at all. To solve this problem, we have made a simple change to the machine: the NS16550 serial port is now directly connected to the CPU, and the GT64120 and i8259 devices can simply be ignored. With this change, the example_uart.c program works reliably and does not generate lots of spurious interrupts.

The new version of the machine is described at machine setup, and can be copied from the course directory by getting a fresh compsys.tar file.

For those that want to edit the machine setup themselves rather than copy the entire machine, the relevant file is called compsys.conf. In this file, change the following lines (at line 47):

OBJECT tty0 TYPE NS16550 {
	irq-dev: pic0
	irq-level: 4

to

OBJECT tty0 TYPE NS16550 {
	irq-dev: cpu0
	irq-level: 2

(Update 2004-Nov-28)

2. Updated Description of Interrupt Handling

The description of the machine setup has been updated with details on the pic0 device, and how the serial port tty0 is mapped to it. Note that you simply should use the provided example code (i8259.c) as-is to initialize the pic0; it is nothing that you want to figure out from scratch, it is just a routine job that is always done in the same way.
(2004-Nov-12)

3. Updated Description of Example Files

The example files page now describes the header files in the include directory in more detail. What should be noted is especially the use of C structures to map hardware. In effect, we have the following:

• A struct can be used to put names to offsets in memory, as each element in the struct has a fixed offset from the start of the struct.
• By creating a pointer to a structure, and then assigning a specific address to this pointer, a structure can be used to access any part of memory in a "structured" manner.
• The file devices.h creates pointers to the devices in the current MIPS system, using the structures defined in the device-specific files.
• See the example code for how these structures are used.

(2004-Nov-09)

4. Updated Explanation of Virtual Memmory System

The description of the machine setup has been updated to explain the effects of the virtual memory system in more detail (2004-Nov-09).

---

• 1. Cannot start Simics (2.0.23) due to missing license file
• 2. Problems running the Linux part of the Simics introduction lab

1. Cannot start Simics (2.0.23) due to missing license file

There was a bug in the Simics 2.0.23 installation that made Simics complain about a missing license file when started (after doing the installation as detailed by the installation instructions). This has now been fixed. If you are hit by this problem, simply copy the file /it/kurs/compsys/simics-2.0.23/licenses/uppsala-x2005-01-01-v5.lic into your SIMICS/licenses directory. Note that any installation done after 14.00 on Oct 26th, 2004, should be correct.

2. Problems running the Linux part of the Simics introduction lab

You might encounter the following problem when running the introduction lab:

Argument error: argument 1 (vmlinux-4kc) given to 
'<processor>.load-binary' has the wrong type; an existing 
file (in the Simics search path) expected.
SYNOPSIS: <processor>.load-binary filename [offset] [-v] 
[-pa] [linux.simics:7] the command did not complete properly; 
interrupting script

This indicates that the file SIMICS/import/mips/vmlinux-4kc is missing. This file was accidentally not part of the installation of Simics-2.0.23 for a brief time on October 25th, 2004. It is also not present when installing Simics on your own machines. In the case that it is missing, copy it from /it/kurs/compsys/simics-2.0.23/import/mips.