$34
This is the introductory project. Everyone should work independently and turn in their own work.
Do not work in groups yet.
The purpose of this project is to get started with DLXOS, the mini-OS used in course projects. You will learn how system calls are implemented, the understanding of which is essential for the remaining projects. The following topics are covered by this project:
The base for all projects in this course is a very simple, but functional, operating system called DLXOS. The system was written at the University of Maryland Baltimore County and the Univer-sity of California, Santa Cruz, and is based on the DLX instruction set architecture described by the Hennessy and Patterson textbook. Over the course of the semester, your job will be to improve the functionality and performance of DLXOS.
As much as possible, the assignments are structured so that you will be able to finish the project even if not all of the pieces you have built are working.
It’s important to realize that while you run DLXOS on top of this simulation as a user program on UNIX, all of the code you write is exactly the same as if DLXOS were running on bare hardware. The simulator runs as a user program for convenience: multiple students can run DLXOS at the same time on the same physical machine. These same reasons apply in industry, since it’s usually a good idea to test out system code in a simulated environment before running it on potentially flaky hardware. You do not typically have the option of throwing out a running machine to be replaced with a CPU with different features before your code will work.
2.1 Useful DLXOS pages
The DLX simulator homepage contains changes to the basic DLX architecture that are related to operating system support. For more information on DLX instruction set, please refer to the following DLX instruction set.
Do as shown in your home directory (do this on os.cs.siue.edu)
mkdir -p ~/cs314/
cp ~/Public/cs314/project1.tgz ~/cs314
cd ~/cs314/
tar xvzf project1.tgz
Depending on which shell you are running (echo $SHELL to find out), you need to set your path variable accordingly. If done correctly, this will be the only time you’ll have to do this. Below are instructions for csh, tcsh, and bash (bash is preferred).
3.1 bash
If using bash, add the line below at the end of your ~/.bashrc file to permanently add the path to the DLX compiler and assembler:
PATH=${PATH}:/home/<your username>/Public/cs314/dlxtools/bin export PATH
Execute the following to have the shell re-read your ~/.bashrc config file (you only have to do this here since you changed .bashrc, which will automatically be read each time you login, i.e. start a new shell instance):
source ~/.bashrc
3.2 csh
set path=(/home/<your username>/Public/cs314/dlxtools/bin $path)
Execute the following to have the shell re-read your ~/.cshrc config file:
source ~/.cshrc
3.3 tcsh
If using tcsh, add the line below at the end of your ~/.tcshrc to add the path to the DLX compiler and assembler:
setenv PATH ".:/home/<your username>/Public/cs314/dlxtools/bin:${PATH}"
Execute the following to have the shell re-read your ~/.cshrc config file:
source ~/.tcshrc
To compile, type make in your ~/cs314/src directory.
To compile the user program, type make userprog in your ~/cs314/src directory. The Makefile is set up to build both the OS and user program userprog by default.
To run the user program in DLXOS, assuming you’re in the src directory, you’ll run:
cd ../execs
dlxsim -x os.dlx.obj -a -u userprog.dlx.obj
You should see “Hello there” printed somewhere.
Note: DLXOS seems to leave your terminal in an abnormal state after the above program executes (you don’t see what you’re typing, but it’s there). If this happens, execute reset. You will not see it as you type in, but things should be back to normal after it executes.
Look at the Makefile to see how userprog.dlx.obj is made.
Unfortunately, using the debugger is nigh useless here, because of the simulation environment nestling DLXOS. You will have to rely on printed statements. To print stuff from the user programs use the Printf procedure, as in the provided userprog.c, you will not be able to use standard libraries in DLXOS user programs.
To print from the kernel, you may use printf as usual, BUT there is a lovely dbprintf macro defined in dlxos.h that you should take a look at. Find usage examples just about anywhere.
From dlxos.h
Specifying
// a ’+’ in the debugging string will turn on all debugging printfs.
#define dbprintf(flag, format, args...) \
if ((dindex(debugstr,flag)!=(char *)0) || \
(dindex(debugstr,’+’)!=(char *)0)) { \
printf (format, ## args); \
}
Got that? Basically, use dbprintf to write debugging printfs that display conditional upon being specified as a parameter when you start DLXOS. So... from the execs directory, assuming everything compiled correctly:
dlxsim -x os.dlx.obj -a -D p -u userprog.dlx.obj
This invocation will run userprog.dlx.obj as usual, but will also cause all dbprintfs containing the ’p’ flag (used in process-related kernel functions) to be printed.
dlxsim -x os.dlx.obj -a -D mp -u userprog.dlx.obj
This invocation will run userprog.dlx.obj as usual, but will also cause all dbprintfs containing either the ’p’ or ’m’ flag (used in process- and memory-related kernel functions, respectively) to be printed.
This invocation will run userprog.dlx.obj as usual, but will also cause all encountered dbprintf statements to print. This is fairly voluminous, so I suggest you consider an unused flag for use with any changes related to the project, so that you only see the dbprintf output you’re actually interested in. Try it and save yourself some headaches down the road.
In your ~/cs314/src directory, you will find the following important files:
To understand how traps work in DLXOS, you must familiarize yourself with the following files:
process.h dlxos.s usertraps.s process.c.
If you are unfamiliar with the DLX instruction set architecture, find an online tutorial. Google is very helpful here. Search for “DLX ISA” or “DLX ISA tutorial”. Or, you can simply look at the code that is provided. We won’t be digging into the instruction set.
The procedure for adding a new trap to DLXOS is as follows (fork() is only used as an example, read the assignment carefully because you’re not implementing fork();
.endproc _fork
Note that this is not what you’re implementing, because GetPID() does something completely different.
Modify usertraps.s to provide a user trap interface for GetPID.
For example, GetPID should look something like this:
.proc _Getpid
.global _Getpid
_Getpid:
trap select_some_unused_value
jr r31
nop
.endproc _Getpid
Implement GetPID support in the kernel.
Finally, make sure that this works as your userprog.c:
main()
{
int pid;
pid = GetPID();
Printf("The process pid is %d\n", pid);
}
Hint: Besides usertraps.s, You may end up modifying process.c, process.h, traps.c, traps.h, and of course userprog.c. However, if you write much more than 20 lines of code, you may be overthinking it...
Second hint: Look at the end of process.c:ProcessFork for a “clue” about how you might com-pute the PID. Keep in mind that DLXOS keeps track of the currently executing process with the currentPCB pointer.
Third hint: Look at ProcessSchedule in process.c, and specifically consider how often this function will be invoked.
Last hint: To return a value from the kernel to the user program, see process.c:ProcessSetResult,
which ends up getting used extensively by traps.c:dointerrupt.
10 What to Turn In
In design.txt write up how you arrived at a solution. Describe the sequence of events from the time the getpid system call is made by the user program, until the user program returns the correct value. If you were not successful in producing the solution, write what should have happened. For completeness, you should describe the control flow of your solution (i.e., the functions called and their respective input/output). No points will be awarded without a completed design.txt!!!
Turn in your entire project directory, including the design.txt, as a single archive. If you followed the instructions above, you should have the following directories:
~/cs314/execs
~/cs314/src
So, if you were me, you might tar and compress it as follows:
cd ~
tar cvzf project1_icrk.tgz ~/cs314
But, you’re not me, so you wouldn’t put icrk in that filename. Use your own username to name your file.
Now, if you were me and you had to upload this file and you didn’t have a copy on your local machine, you might scp the thing to your local machine first:
scp icrk@os.cs.siue.edu:~/project1_icrk.tgz .
Which would put the remote file in the directory that you were in when you ran the command.
If you’re running Linux or cygwin that might work. Otherwise, if you’re stuck in Windows-land,
PuTTY includes PSCP (an scp client) that I’m sure you can use somehow to get your file.