The Microprocessor Lab

Supporting CS341, CS444, and CS644 with stripped-down PCs (“SAPCs”) accessible from ulab.cs.umb.edu

Please email eoneil to correct or improve this webpage!

Currently, to login to ulab from offsite, you need to ssh to linux1.cs.umb.edu, then rlogin (or ssh again) to ulab.cs.umb.edu.

For more information, see AccessToUlab

Setup

1.      Get an account for cs341, cs444, or cs644 by running apply (see the consultants in S/3/158 for more information. This account will give you access to ulab.cs.umb.edu.  Note that it may take hours or a day to take effect. Test it by logging in to linux1.cs.umb.edu, then "rlogin ulab" to reach ulab. No password is needed for the rlogin.

2.      Add module ulab to your .cshrc, so the module-load line reads, for example   “module load standard ulab”.  Don’t add this line at the end of your .cshrc, because the later part of .cshrc is not always executed.  Find the line with “module load” near the start of .cshrc and modify it.  Log out and in again to get this new module loaded and test your edit.

3.      Look at your new set of environment variables with “env”.  To see a subset with most of the interesting environment variable use “env | grep pc”. You should see “pcex”, the pathname for the PC examples directory, and “pcinc”, the pathname for the include directory, and a few others.  Try “cd $pcex” followed by “ls” to look at the examples directory.  In addition, your PATH has been edited to give you access to needed tools. These environment variables, directories, and tools will be available for your use on any of our general-purpose UNIX systems.

4.      Although the directories and tools supporting the microprocessor lab are available from all our systems, one UNIX system, ulab.cs.umb.edu, is set up for providing access to the “online SAPCs”.  Make sure you can login to ulab with “rlogin ulab” from local systems. From offsite, “ssh linux1.cs.umb.edu" followed by "rlogin ulab.cs.umb.edu”.

The mtip program for access to the online SAPCs on ulab.cs.umb.edu: uses the ~ character, also used by some ssh clients

The mtip program is available on several systems but only works on ulab.cs.umb.edu, where the SAPCs are attached by a network device. The mtip program provides ssh-like access to the Tutor commands running on the SAPC, and uses the ~ character to “escape” to its own commands, as will be clear from the example below. Note that ~ is used as an escape character in some versions of the ssh client program needed to access ulab from offsite. In such cases the ~ needs to be doubled up to get through to mtip, where it is also used as an escape character. To simplify use of mtip, we have added an alternative default escape char to mtip, the escape character, so you can use <Esc> (the single character) instead of ~ (or ~~ through some ssh clients) when using mtip.

Test to see if your ssh uses ~ as an escape character:  In ssh, type ~?, and if it responds with about 9 lines of output starting with “Supported escape sequences:” or the equivalent, it is using ~ as an escape character. If it just hangs waiting for more input, it is not using an escape character.  Whether or not it uses such an escape is configurable in a system file on the client system.

First SAPC test using mtip on ulab.cs.umb.edu

1.      Log in to ulab (a UNIX system, more exactly a Sun Solaris system.)

2.      Use “mtip” to access an available SAPC.  mtip is a UNIX program that knows how to access the SAPCs.

3.      Type a carriage return and see if the “Tutor>” prompt appears.  If so, the system assigned to you appears healthy, but you never know for sure until you reboot it.  Your carriage return was sent to your SAPC and processed there by the Tutor debugger running on the SAPC.

4.      To reboot your SAPC, type “~r” ("~~r" through ssh, or the two characters "<Esc>r").  The tilde (or <Esc>) is an “escape character” that is not sent to the SAPC.  Instead, the mtip program processes it and sends a command to a little helper system that is wired to each SAPC’s reset circuitry.

5.      Wait about 12 seconds.  After that, you should see the prompt: “Please type <CR> to confirm console setting:”  Type the carriage-return.

6.      After the public license banner appears, you should see the “Tutor> “ prompt.  Now you can be sure the system is in good condition. 

7.      Try the “h” command to see other Tutor commands. This "h" command is a Tutor command, processed by the SAPC Tutor program, and needs no escape char.

8.      Use “~q” (or "~~q" under ssh) or "<Esc>q" to quit out, or two control-C’s.

Running your first program on an SAPC

1.      Make a directory “test1” (or any other convenient name.)

2.      Copy $pcex/makefile and $pcex/test.c to that directory.

3.      Use “make” to build test.lnx, the SAPC executable, using the command
  make C=test
The suffix “.lnx” is short for Linux, since we are using a Linux-originated executable format.

4.      Log in to ulab.  (You could do this first, but don’t have to until you need to use mtip.)

5.      Use “mtip –f test.lnx” to obtain an SAPC and specify to mtip what executable you’re planning to download.

6.      When you get an SAPC, it’s safest to ~r to reboot it, but you can take your chances and save 12 seconds.  Just remember that if anything gets weird, you need to start over and reboot.

7.      Type “~d” (or "~~d" under ssh) or "<Esc>d" to download test.lnx.

8.      When you see the Tutor prompt again, type “go 100100” to execute the program.  Follow its directions, and it should finish up quickly and hand control back to Tutor, so you will see a Tutor prompt again.  You can run it again if you want with “go 100100”.

9.      Type “~q” (or ...) or two control-Cs to quit out of mtip.

Information on SAPCs

SAPC stands for standalone PC, a PC without an operating system.  Instead of an OS, it boots up with a debugger called Tutor.  Tutor runs in 32-bit protected mode on the PC, just like all forms of UNIX on the PC and Windows starting from Windows 95 and Windows NT.  32-bit protected mode is actually easier to work with than the old 16-bit real mode still covered in many textbooks on PCs.  If you have ever heard of the notorious 64K memory segments of real mode, be assured that you don’t have to worry about them in 32-bit protected mode.  Memory is “flat”, just like all UNIX systems.  This means memory appears as a simple sequence of addressed locations to your code.  Tutor also runs in kernel mode, or “ring 0”, to allow us to use all the instructions of the CPU, even the ones normally used only by the kernel of the OS.

There are 14 online SAPCs.  Of these, systems 1-10 are 400 Mhz Pentium systems (actually AMD-K2 processors, Pentium compatible), whereas systems 11-14 are older 100 Mhz i486 systems.  Thus for all timing experiments, you should make sure to use one of the first 10.

Each SAPC is connected to ulab via its COM2 serial port, and this connection provides the standard input and output for the system. For example, when you see the Tutor prompt, you are seeing output from the SAPC’s COM2 serial port. 

Systems 5-14 have their COM1 serial port also connected to ulab, enabling them to use remote gdb, a source-level debugger.  The Tutor software in the SAPC knows how to do its end of the remote gdb protocol defined for the Gnu debugger.  In particular, we use i386-gdb, the Gnu debugger built for x86 cross-platform development (gdb is the same debugger built for programs running on the local UNIX system).  i386-gdb is itself a UNIX program running on ulab, and communicates with the SAPC via its COM1 port.

To use remote gdb, first login twice to ulab.cs.umb.edu, with one window for mtip, and the other for i386-gdb.  This is easy to do from your system at home with an Internet connection, or from any system in the department.  Then follow the example below.  Also see below for a gdb “cheatsheet” listing the most useful commands.

Programming and Debugging on the SAPCs

SAPC Programming Environment: what you need to know for C programming on SAPCs

Remote gdb example. Try this on SAPC system 5 or higher: these systems have the COM1 line connected for remote gdb.

Notes on program images. Using debuggers to look at memory locations on the SAPC and under UNIX.

Notes on using C to access hardware registers.  Elementary hardware programming on SAPCs.

Slides on Interrupts.  The PC (x86) interrupt system.  (original Powerpoint)

SAPC Hardware Support Information

SAPC problems and fixes

SAPC portmap -- which line does what

SAPC Software Support Directories

·         $pcinc – headers

·         $pcex – C examples

·         $pcbook – for S&S chapters 2 and 3, assembler examples

·         $pclibsrc – sources for the SAPC support library

Help on gcc, gdb, mtip

External Resources

From www.gnu.org: GDB manual, other manuals

From linuxassembly.org:  Assembler syntax info, Manuals