Hwk 1

Problem I is due Tuesday, January 28, and Problem II on Monday,
February 3.

IMPORTANT NOTE:  We do not have a Reader, so the TA will be grading
the work (lal@cs).  Our department has experienced tremendous growth
in enrollment during the last couple of years, and as a result we
have a shortage of TAs.  To minimize the TA's workload, please
make sure to FOLLOW HOMEWORK DIRECTIONS TO THE LETTER, NO DEVIATIONS
WHATSOEVER.

I.  In this problem you will extend the Mac-1 instruction set,
    by adding a MULL instruction, which does multiplication.
    We will be using the DePaul University MicMac simulator, in
    the directory

       ~matloff/Pub/A*/Micro*/S*/D*

    You will add a MULL ("multiply local") instruction to the Mac-1
    instruction set, having the format 11111111zzzzzzzz.  Its action
    will be ac:=ac*m[sp+z].  In other words, the contents of the ac will
    be multiplied by the contents of the z-th element in the runtime
    stack.

    The multiplier and multiplicand are to be interpreted as
    2s-complement signed integers, while z is to be interpreted as a
    nonnegative number.  Don't worry about overflow; just assume (for
    simplicity, not for practicality) that the users will never input
    numbers whose product is wider than 16 bits.

    It is completely up to you how you implement MULL, other than
    the technical restrictions set here.

    Your design must allow the correct execution of any existing 
    MAC-1 machine-language (not just assembly-langauge) program.

    Submit your homework in the following form:  You will send files
    named mul_mac.def and mul_mac.mal for the extended Mac-1 machine,
    and only one more file, named README.  The latter will list the
    members of your group; do NOT include any other information in
    this file

    Your e-mail packaging operations must include tar, gzip and
    uuencode.  In applying the latter, you must arrange things so that
    when the TA applies uudecode to your e-mail message, the result is a
    file named hwk_1_I.tar.gz.

    The TA will have written a shell or Perl script which automatically
    runs ma, assem and sim on your files.  The TA will use his own
    (secret) .asm file, which will include a loop containing a MUL
    instruction.  The loop will have three iterations, in which MUL will
    be tested on three different pairs of numbers.  In this manner, the
    TA's .asm file will:
       
       (a) check for correct execution of the MULL instruction,

       (b) check for correction execution of whatever other instructions
           the TA has in the .asm file, and

       (c) report the number of cycles needed to execute the entire
           program.

    The reason for part (c) is that EXTRA CREDIT will be given for
    whichever homework team (a pair of students, or an individual
    working without a partner) submits the fastest implementation
    of MULL, as measured in (c).

    By the way, this "contest" is in keeping with microcoding in
    general.  In high-level programming, we usually don't care about
    small increases in speed; usually the clarity of the code is more
    important.  But microcode directly affects the overall speed of the
    machine itself, so optimal code is of great value.


II.  Use Chipmunk to implement the ALU portion of Mic-1:  There will
     be 16-bit inputs from the a and b buses, a 2-bit input from the
     alu field in mir, a 16-bit output and 1-bit n and z outputs.

     Your e-mail to the TA will consist of a SINGLE .lgf file, and a
     README file, the latter listing the members of your group (and
     NO other information), but NO other files.  The package must be
     the result of tar, gzip and uuencode, with the latter operation
     arranging things so that upon using uudecode, the output file
     will be named hwk_1_II.tar.gz.

     Since we are just implmenting the ALU rather than all of Mic-1,
     simulate the inputs with Hex Keypads (four each for the 16-bit
     inputs) and Digital Switches (two for the alu input), and display
     the outputs using Hex Displays (four for the ALU output) and LEDs
     (one each for n and z).  Put Chipmunk labels on each of these,
     showing CLEARLY which roles the Hex Keypads etc. are playing, AND
     which ones are most and least significant; e.g. for a set of four
     Hex Keypads, use a Chipmunk label to state which of the four is
     most significant, etc.

     Again, so as to minimize the TA's grading time, turn only ONE .lgf
     file (which will probably be big enough that it must be scrolled),
     no modules.  However, during your development and debugging time, I
     encourage you to use top-down design, with several modules.