|
II. Programming exercises: Due by noon on Friday, October 13, 2006.
Consider the following SIC/XE source code for getting a 3 byte integer from
device F2:
.
. subroutine to input 3 bytes from DEVF2
.
GETINT LDS #3
CLEAR X
READ TD #242 . DEVF2
JEQ READ
RD #242 . DEVF2
TIXR S
JEQ RTRN
SHIFTL A,8
J READ
RTRN RSUB
Incorporate this code (as a subroutine) into the program from assignment 2 to
provide the means for bringing a table of numbers in from device F2. In other words,
use the GETINT subroutine to load TABLE.
Then, once the table is loaded process the table as before. You will need to tally the
number of integers input to establish the COUNT value.
Assume that when GETINT brings in an integer with value 0 that
there is no more input. There should be no changes to the program other than those for getting
the table read in.
- Add in-line comments to appropriate source code lines as explanations of the program
implementation and install the (commented) source code in a file named
<student-id>-3.A.src.
- Use the routine sicdtoh (in
/usr/public/cop3601/cwinton/sicstuff )
to construct a file named <student-id>-3.A.in.
Via sicdtoh
input exactly the same 24-bit (SIC) integers that you used in Assignment 2
and follow them with at least 10 whose values are determined by the rand-ints program in
/usr/public/cop3601/cwinton/sicstuff.
This is the file to be input to the SIC simulator as device F2.
- Assemble your program using the SIC/XE assembler sicasm and execute the assembled
object file on the SIC simulator. As you saw in the previous assignment, the shell script
sicsimrun assigns the specified object file to
DEVF1. If an additional parameter is
given, it is assigned DEVF2 (and if there is one more, it goes to
DEVF3). Hence, the command
structure for this assignment is
sicsimrun COP3601-3.A.src.obj COP3601-3.A.in
You should make several runs to be sure that you know what the program is doing.
Once you are satisfied, remove the sic.log file and make your final run.
Then move the sic.log file to a file named <student-id>-3.A.sic.log.
- Construct your Part A documentation in the same manner as specified for Assignment 2.
In your examination of intermediate results, be sure to examine the program result at the point
it has processed the first 10 values from Assignment 2 and highlight/comment; be sure to
note that the result is identical to that achieved in Assignment 2 (this is a verification check).
Be sure to include this subtotal in the (base 10) corroboration that is to
appear in Part A's Assessment section.
Construction of an assembler requires a table searching routine (e.g., the symbol table, the
op code table). You should already be familiar with both linear and binary search processes from
your prior coursework. Your task for Part B of the assignment is to produce (in C) a (modified)
binary search subroutine for a sorted table that follows the specifications below.
Subroutine specifications
- Structures
#ifndef SYMBSIZE
#define SYMBSIZE 10
#endif
typedef struct tabinfo
{
int val;
int type;
int info;
} tabdata;
typedef struct tablemem
{
char symbol[SYMBSIZE];
tabdata symbdata;
} tabletype;
int findlast (tabl, n, x)
tabletype tabl[];
int n;
char x[];
- Parameters
- Table characteristics
- tabl < === > table name
- n < === > number of entries in the table
- Find requirement
- x < === >
a character string to compare to the symbol part of each table entry
- Returned value
- Return the index of the last occurrence in the table
of the symbol given by parameter x (return -1 if the symbol given by x is not present).
Remember that in C, arrays are indexed from 0.
- File name
- findlast.c
Example:
/* int i */
i = findlast (symbtab, n, x)
where
- "symbtab" is the table name
- "n" is the current number of entries in the table
- "x" is a string giving the searched-for symbol.
Procedure:
- Design and construct a findlast subroutine that observes the requirements of the
above specifications.
- Produce a (throw-away) "main" program in a file named
<student-id>-3.B.c to serve as a test driver for your subroutine.
Hard code into your driver a (sorted) test table of at least 10 entries, some of which have duplicate
symbol entries, but all of which have different value entries. Your driver
should be capable of invoking its find routine against this table with various values of n.
The driver may interactively acquire n and items to search for, or may simply consist of a
collection of presets, each followed by a call to findlast and a dump of the result.
Note: under no circumstances (other than for preliminary debugging) is the findlast
subroutine to do any printing (output is a function of the calling program).
To create a log of subroutine test results analogous to the sic.log file produced
by the SIC simulator, the class directory
(/usr/public/cop3601/cwinton/) contains a library hlib
of "h" functions (hprintf, hputs,
hscanf, and hgets) that operate
exactly like their standard counterparts except that they "echo" to a log file named
hlib.log (created and time-stamped if not present,
appended to, if present). To use the h functions, copy hlib along with its
include file cop3601.h to your
own directory. Your driver program will need to have the preprocessor command line
- #include "cop3601.h"
The purpose of the h functions is to allow selective capture of the screen I/O produced by
program execution. Note: an alternative often used is the Unix "script"
command, which forks a new shell that provides a "quick and dirty" means for recording a
terminal session (everything appearing on the screen is recorded until the forked shell is exited),
but it's all encompassing nature generally renders it inadequate for producing a testing log.
Do no use "script" for generating your test log.
- Devise a makefile named <student-id>-3.B.makefile to compile
your routines using naming conventions as indicated by:
- cc -c findlast.c -o findlast.o
- cc COP3601-3.B.c hlib findlast.o -o COP3601-3.B
- Devise a test plan for your subroutine. Pay particular attention to boundary cases:
- table empty (which simply means that n=0)
- item to find is only item in table
- item to find is first in table
- item to find is last in table.
Obviously, your tests should include an item not found case and and a judicious selection of
cases where there are multiple occurrences of the item (to verify that you are actually finding
the first occurrence). Please keep in mind that one basic requirement of testing is that
every line of code in the program gets exercised by at least one of the tests conducted.
When you are satisfied that you have an effective test plan, remove hlib.log and then
run your tests for the record. When finished, move hlib.log to
COP3601-3.B.log (to appear as an annotated appendix
in your Part B documentation in a manner analogous to that for prior assignments).
- Construct your Part B documentation as per earlier instructions. Since your log file
COP3601-3.B.log is derived from
hlib.log and you designed its format, it will
annotate differently than sic.log files. Note that your source code needs to
documentated with some combination involving meaningful variable names, in-line commenting,
and annotation. If it is difficult to follow the program logic, the program submission
may be downgraded on a qualitative basis. Excessive or indiscriminant
documentation is almost as bad as insufficient documentation.
In documentating your testing plan and testing results,
it is important that the plan look like a plan, laying out case by case what is being
looked for. The discussion of the results must then lay out case by case what the
testing determined. There should be a testing summary that sums it all up.
You should annotate your log file to flag
test results (if the results are hard to spot on the log, expect to get dinged on the critique).
Construct Word documentation as specified on the assignments page.
Remember that your documentation file is to be a single file having 2 distinct parts: a write-up for Part A and
a write-up for Part B, each with its own executive summary and its own set of appendices.
A reality check on your documentation:
if the reader of an Executive Summary must look in
the appendix for information, you have an inadequate Executive Summary.
Use the submit shell script
from /usr/public/cop3601/cwinton to "shar" your
- documentation (<student-id>-3.doc)
- Part A source code (<student-id>-3.A.src)
- Part A input file (<student-id>-3.A.in)
- Part A listing code (<student-id>-3.A.src.lst)
- Part A object file (<student-id>-3.A.src.obj)
- Part B findlast source code (findlast.c)
- Part B make file (<student-id>-3.makefile)
- Part B driver source code (<student-id>-3.B.c)
- Part A log file (<student-id>-3.A.sic.log)
- Part B log file (<student-id>-3.B.log)
and "turnin" by noon on Friday, October 13 to cnw.3601.3.
Late submissions can be submitted until the due date for the next assignment via submit
to cnw.3601.3L (late points
assessed as stipulated on the assignments page).
|
