Monday, Sept. 10 System Calls, SAPC Programming Environment

From last time:

We looked at the nice large (multi-GB) flat user address spaces for 32-bit UNIX/Linux/Windows and huge flat address spaces for 64-bit systems.

This user address space is part of the “virtual machine” that the OS provides for a running program.

What about Android?

Android runs Linux on 32-bit processors (ARM or x86), so at the OS level it has 3GB of user address space. But smart phones don’t have much physical memory, so this is just in theory.

However, most Android apps run in the Java environment, built on top of the Linux. Within this environment (Dalvik), user address space is artificially restricted to (say, for Android 4) 48MB to force app developers to use memory stingily. You can run C on the Linux environment (native code), however, to avoid this limit.

Each app execution runs in its own virtual machine, on Android and on UNIX/Windows, so one app program can’t look into another app’s memory.

Note that in general, the Java “virtual machine” is built on top of the OS virtual machine. So when you use println, the Java runtime has to do a system call to do the output. The Java environment uses the flat address space. Each object ref is an address, and by the flatness, this is unique, so when you compare refs and see them the same, you know you have two refs to the same object. Of course it would be possible to support Java on a non-flat address space, but it would be more difficult. The object ref would have to have more than an address in it.

Finding UNIX system calls

Example: simple UNIX program, handout on debugging session linux1.cs.umb.edu (64-bit Intel-compatible AMD processor)  to see how a program uses a system call.

Demo: followed script pretty closely.

What the handout shows:

• You can use a system call from an ordinary C program.
• The code for main contains a call instruction, “call write”.  This is an ordinary call instruction.
• After startup (when execution reaches main), write is at a very high address, in the C library DLL.  This is the little routine that contains the system call instruction.
• We followed the code inside write and saw the system call instruction, syscall. (called TRAP in Tanenbaum)
• An “si” in gdb (si = step instruction) executes the whole write system call in the kernel—it all appears as a single instruction execution at user level.
• After the system call executes, the rest of the write function executes, then it returns to main
• There is a startup module, where execution starts, the C library and DLLs are initialized
• The startup module calls main with an ordinary call instruction (not actually shown), because main is just an ordinary C function with a special name.
• After main finishes, it returns to the startup code (with an ordinary function return instruction.)
• Then the startup code calls back into the C library, and eventually executes the exit system call, collapsing the whole user virtual machine 

Each system call has a little envelope routine in the C library. We saw the one for write, and another one for exit. These are written in assembler. This allows us to make a normal function call to write to do a system call from C. It’s not possible to execute the “syscall” instruction directly from C code (except with embedded assembler code.)

SAPC Programming Environment

Ref: SAPC Programming Environment

4M flat memory, addresses 0 to 0x400000 – 1 = 0x3fffff.

(from SAPC Programming Environment:)

--increasing memory addresses--->

|-------------|---------------------------------|---- ... ---------------|

0           0x00100000 = 1M                  0x00400000 = 4M         0xffffffff

<----------4M RAM=read/write memory-------------><----No usable memory--->

<--sys area-->|<-----------3M user memory------>|------------

The first 1M is the “system area”.  We could use parts of it, but it is cluttered with reserved areas—BIOS, video memory, Tutor, etc.

So we just use the upper 3M from 0x100000 to 0x3fffff for downloaded programs.  Code is downloaded to start at 0x100100, a convenient address above 0x100000.  The data follows it immediately.  There is a startup module that calls main.  The startup code sets the stack pointer to the top-of-memory address to locate the stack there.

What’s in that first megabyte of SAPC memory labeled “sys area” above?

            --ordinary memory from 0 to 0x9ffff, with Tutor residing in 0x50000-0x60000 or so.

            --video memory in a0000-b0000 or so.

            --BIOS in f0000-fffff, the upper end of the sys area.

This means that we can use the ordinary memory between 0 and 0x50000 for experiments if we want to.  It is used temporarily during bootup by the “bootstrap”, but this use is long over when the system is booted up.

User program layout on the PC:

                  code  data                <--stack

|----------------|----------------------------------|---- ... ----------|

0                0x100000      user memory           0x400000        0xffffffff

There is no C library DLL here.  Instead, code for the C library functions in use by the program is part of the code area shown here.  The i/o functions call into Tutor to do the i/o.  This saves some downloading time and allows remote gdb to know about the i/o.  However, this doesn’t qualify Tutor as an OS, it’s just serving as an i/o library, like the system you’ll write for hw1.

SAPC hardware:

• Pentium CPU (or 486, even 386 would be compatible, “x86” for short)
• 4M usable memory
• (no hard disk, floppy is for booting only)
• (no keyboard or monitor or mouse)
• COM2 serial port: used for console i/o
• COM1 serial port: used for remote gdb protocol
• (LPT1 parallel port: but nothing is connected to it, so not much use)
• timer device: PIT, for programmable interval timer, used for periodic interrupts, “ticks”
• reset circuitry: used to reboot via ~r in mtip

SAPC software:

• BIOS: at reboot (or “reset”) this code initializes the hardware, loads and starts the Tutor bootstrap.  It is in ROM, “burned in”, thus always available at power-up.
• Tutor (and its bootstrap) – this debugger is loaded from floppy disk into RAM, i.e., ordinary read/write memory.  It does more hardware initialization and switches from 16-bit real mode to 32-bit protected mode, while staying in kernel mode.  This code derives from Linux, remote gdb, plus some local code.

Thus after boot-up, the SAPC’s x86 CPU is running in 32-bit protected mode and in kernel mode.  32-bit protected mode means that we can use 32-bit addresses, addressing up to 4G locations.  16-bit mode would only allow 64K different addresses in one sequence, a terrible handicap for today’s programs.  Even our measly 3M user memory would constitute 0x30 = 48 different sequences of 64K (or 0x10000).  In 32-bit mode, an address of 0x300000 (3M) is just an ordinary address, in fact seen to be on the small side if you write all 32 bits out like this: 0x00300000.

Warning: many texts on Pentium architecture treat only the real mode architecture.  To tell, look at the register names in use.  AX = 16-bit register, whereas EAX = 32-bit register.  Similarly SP vs. ESP.  We can use AX in 32-bit mode, but we wouldn’t use it a lot (it’s just the lower 16 bits of EAX.)

Building and downloading programs for the SAPC

See www.cs.umb.edu/ulab for first steps--get the ulab module load into your .cshrc and build and run test.c.  Note that the ulab module adds environment variables to your UNIX process to make SAPC work easier.  $pcex is the examples directory path.  Try “echo $pcex” to check, “env | grep pc” to see more.

Note that we use a cross-compiler i386-gcc and other cross-tools—they run on Sparc but generate or work with x86 machine code.  The makefile in $pcex can build from any single C source xyz.c by “make C=xyc”.  This will make xyz.lnx, an SAPC executable stored in a UNIX file.

We can download a .lnx file by using mtip, a Sparc UNIX program usable on ulab.cs.umb.edu.  The reason it has to be ulab is that the serial lines to the 14 SAPCs are connected to ulab.  mtip finds a SAPC not in use already and assigns it to you, and then provides a conduit between your keyboard and monitor and the console of your SAPC.  It watches the characters as they go by, and if you type “~r”, it springs into action and arranges a reboot for you, or if you type “~d”, a download.

If you are logged in to ulab using ssh, the ~ character is used as a command escape for ssh, so you need to double up tildas to get them through, that is, type ~~r to reset the SAPC and ~~d to download. Alternatively, use the <esc> character (new feature).

With the help of mtip, you will see the Tutor prompt “Tutor>” coming from your SAPC.  Tutor was listed above as SAPC software—it is running on the SAPC.