CS444 hw1 25pts, due Sun, Sept. 26, midnight
(#0 is due Fri., Sept. 16)

Note: for each hw in this class, make a subdir of the same name, e.g. hw1,
and put everything there you want the grader to look at.
Supply a README file for the grader to read first, and include in it
your authorship statement and any special notes such as late days.

0. Warmup for 2. Running the provided testio.lnx.
First study testio-orig.script and reproduce it as testio-orig1.script,
noting the behavior that needs to be fixed by your work for problem 2.  
Then reproduce remgdb-testio.script, that is, run
the provided testio.lnx under control of remote gdb with several
breakpoints and "next" commands, and successfully enter input
in the console window.  Additionally, print out the contents of
buf after it has been filled in with "AABB...".  Leave this output
in remgdb-testio1.script.  This part is due a week earlier than the rest.

NOTE: don't let the SAPC sit idle for more than 30 seconds at a time
while you are debugging.  Sometimes the network communications system
that sits between the SAPCs and the ulab system drops idle connections
that carry SAPC output to you.  If you stop seeing SAPC output in your
mtip window, you can start over or carry on without the output, since
gdb itself will continue to work (apparently because your input restarts
output if necessary.)

1.  Study the script handed out in class showing the system call "write"
just before trap-execution.  Similarly examine a process executing the
seemingly-trivial program:
int main()
{
   printf("Hello world!\n");
   return 0;
}

Catch it just before its first "write" system call, and display the 
registers, and identify the 3 args to write.  Is the whole string being
printed in one write?  Find the string being printed in _write by following
the string pointer in o1 and using x/s <addr>  to show it.  Is it the same 
string passed from main to printf?  (Find main's string address in o0
at the call to printf to answer this.)
Do a backtrace using "where" or "bt" from the _write routine to see
printf calling write--any intermediate functions?  Can you figure out
what's going on here with the two copies of the string?
Make a script of your run and leave it in file hello.script.

Added note: don't set a breakpoint on write, as it won't help, because
write won't be reached from printf.  Set the breakpoint on _write.

2. Just short of an opsys--a standalone i/o package for the SAPC.
By "standalone" we mean there is one and only one program running
on the machine, so the whole machine is owned by that program.

We start from an almost-complete but imperfectly coded device-independent
standalone i/o package provided in $cs444/hw1.  Fix it up as follows:

a. Given a character queue package that allows multiple queues, in 
subdir queue:

init_queue(Queue *q, int max_chars);  make a new empty queue, filling in *q
int enqueue(Queue *q,char ch);     enqueue char ch on q, or return -1 if can't
int dequeue(Queue *q);     dequeue a char and return it, or return -1 if can't
int queuecount(Queue *q);  return # chars currently in queue q

Use it to replace all the ring-buffer code in this i/o package with proper
queues, one Queue for the readqueue, another for the echoqueue, etc.
Use just 6-char Queues so you are sure to test it fully.  Don't edit
or replace queue.c, just *use* it.

The code should now be easier to understand.
Note: we don't have malloc in the SAPC library.  Therefore you
will need to use "Queue" type variables to hold the queue state,
not Queue * pointers + malloc'd space as often done in C.
Once you have a variable of type Queue, it's easy to get a Queue
pointer by using &.

b. The read function does type-ahead, but only that.  Normal "reads"
pick up typeahead, but if that does not satisfy the nchar of the
read call, the read function waits around for the rest to show up.  
Make this happen here.

c. The write function only polls--let's make it interrupt driven too.
Set up an output queue for each port, again only 6 chars capacity.
Chars from a user write call are enqueued, or, if the queue is or
becomes full, the caller has to wait for space to show up.
Set up a second queue for echoes, and output preferentially
from the echo queue.

d. Consider how to add the LPT1 device (write-only) to this system.
See $pcinc/lp.h for the hardware header for this device.
What edit is needed for ioconf.c?  Invent function names to
go in devtab and a filename for the lp driver code, corresponding
to tty.c for the TTY devices.  What functions would be implemented
in this new file?  You don't need to code this up unless you want to,
just invent function names and file names and discuss, in lpdriver.txt.

Note: because this is a standalone i/o package, and not a real OS,
it is allowable and necessary for the waits to be busy loops.
Once we are writing OSs, this will be a great crime, wasting the
CPU that could be used by another program.

Testing: Testing is always an important part of any code writing.  Generally,
you need to write many tests.  Here, I've provided a comprehensive test
for you, testio.c.  Your hw1 submission should include the output of 
a test run.  Use the 'script' to capture the output of your test runs
and leave the file created (testio.script) in your hw1 directory.

For collection:  These need to be in your cs444/hw1 directory!

README: with authorship statement for sure, late days note if needed. 
testio-orig1.script
remgdb-testio1.script
hello.script
lpdriver.txt
tty.[ch]
testio.script--run after hw1 fixes