CS644 hw3 Below the OS: Hardware Programming 
25 pts.

Note we are not using Xinu here at all, just the basic SAPC support.
The hardware headers are in $pcinc, the examples in $pcex, and
the SAPC library sources in $pclibsrc.  Put all files in the
hw2 subdirectory of your provided cs644 directory.

Warmup, due Mon, Mar. 22
Do the steps described in warmup.txt. 

Rest due Sun., Mar 28--

1. A PC Sampler.  "PC sampling" means recording the PC value on a
regular basis during a particular program run, so that the record
can later be studied to determine where the program is spending its time.
For example, if 90% of its PCs fall in a certain function, that
function should be examined to see why it's using so much time.
(See "man pcsample" for the Solaris PC sampling facility.)

Write a PC sampler for a SAPC program like the provided pctest.c.
We can use timer interrupts to get PC values for the program,
and save them in an array.  After the program finishes, the
PC sampler will output a report, as detailed below.

For this program, use the makefile in $pcex, the SAPC C examples
directory.  Look at timer.c, typewr.c and timetest.c to get started.

The tick handler.  The clock ticks at a regular interval, and
at each tick, the sampler saves a record of the machine state of the
interrupted program execution, at least the PC, in a ring buffer.
This facility is turned on by calling PCsamp_on and off by PCsamp_off.
Another routine, PCsamp_histogram, prints out the recorded PCs,
in address-space order, with the frequency of each.  Note that qsort
is avail in the SA library--try out qsort_ex.c.

Assume the sampled program will run about 2 seconds.  Arrange to collect
at least 10000 points in this time, but be sure to allow the collection
to run much longer if necessary, wrapping around to recycle the memory
area allotted, and at the end, deliver the last 10000 points recorded.
This is what is meant by a "ring buffer", a very simple data structure.
Note that .bss (uninitialized memory) does not get downloaded, so
it doesn't slow you down to have a big empty array in your program.

It would appear that you need to write an assembler subroutine to pick
up the PC (or EIP in Intel jargon), but in fact it can all be done in C:  
the relevant PC and EFLAGS are on the stack just under the 5 regs pushed 
by irq0inthand.  PC and EFLAGS are separated by 32 bits containing the 
interrupt code and old CS.  We can bundle them all together in one struct,
as follows:

#define NREGS 5
typedef struct  {
    unsigned int regs[NREGS];  /* 5 regs pushed by irq0inthand */
    unsigned int pc;          /* the old PC we want */
    unsigned short code;      /* the interrupt code */
    unsigned short cs;        /* the old CS (code seg reg) */
    unsigned int eflags;      /* the old EFLAGS we want */
} StackLayout;

Now if we use this struct in the function definition:

void irq0inthandc(StackLayout sm)

The argument sm provides access to all the above-listed information
on the stack under the return address.  In particular,
sm.pc is desired pc.  We are of course depending on implementation
details of gcc, that is, how it passes parameters on the x86's stack,
so appropriate comments are in order.  In particular, this kind
of trick fails on many RISC processors, so don't put it in your general-
purpose bag of tricks!  

Look at timetest1.c to see the StackLayout struct trick in use.
Study timetest1.script to see remote gdb in use to further
investigate its behavior.  Note the use of system 6 (not 11-14) here:
in this assignment, the programs are small, and thus will download
quickly on any mtip system.  Only systems 5 and up have a remote
gdb connection (COM1) however, so use any system 5-14.

pctest.c is a tiny program to profile using your package.

Put the pc sampler code in pcsampler.c. Put calls to this code
in pctest.c, at its start and end, to initialize pc sampling
and at the end, to output the report.

Set up a makefile (based on $pcex/makefile) that builds your PC sampler 
around pctest, so that "make" builds the program. 

Use your PC sampler plus the symbol table to determine where pctest
spends most of its time.  Write up your results in pcsamp.txt--
a. summary of the implementation of the pc sampler
b. results on pctest, interpreted by symbolic values for at least
   the top three locations/regions, incl. library locations
c. discussion of accuracy and relevance of results.

Files to be collected:

See warmup.txt for warmup files.

pcsampler.[ch], pctest.c, makefile, pcsamp.txt

As always, please note any late days or special instructions
for running your program in a README.