Appendix A
                                                  A1.    Execution, memory address computation, or branch completion
                                                  A2.    Preprogrammed MIPS Instructions
                                                  A3.    Layout of Datapath
                                                  A4.    Layout of the project
                                                  A5.    The Complete finite state machine control for the datapath
                                             Appendix B
                                                  B1.    Instruction Sequencing
                                                  B2.    Program Organization:

                                             Appendix C
                                                  C1.    Source Code

                                             Bibliography

1.0   OBJECTIVE

        The objective of the project is to simulate the operation of MIPS processor, and develop  a  graphical
        representation of it in Microsoft JAVA 6.0 language.  In this project, the datapath with all the modules
        for  different implementations of the MIPS instruction set was constructed, and an implementation  that
        includes a subset of the core MIPS instruction set was also simulated.  And of course  after  doing  the
        project, the following main points would be clearly understood.

1. The main modules of the MIPS processor.
2. The function of each modules.
3. The three types of MIPS:
1. I-type
2. R-type
3. J-type
4. The four classes of MIPS:
1. The memory-reference instructions load word (lw) and store word (sw)
2. The arithmetic-logical instruction add, sub, and, or, and slt
3. The branch instructions beq, bne.
4. The jump (j) instruction
5. Modules required when running a particular instruction of each type of MIPS

2.0   INTRODUCTION

        MIPS is an instruction set developed by Sony, Nintendo, and NEC. MIPS, which stands  for  Million
        Instructions  Per  Second,  is a  rating  of  a  Central Processi ng Unit (CPU), that refers to how many
        low-level machine code instructions a processor can execute in one second.

        The core MIPS instruction set architecture determines  many  aspects  of  the  implementation,  which
        includes an  integer arithmetic-logic  instruction,  the  memory-reference  instructions, and  the  branch
        instructions.  Much of what needs to be done to implement these instructions is the same, independent
        of the exact class of instruction.

        In this project, a series of Java programs that simulate  a  MIPS  Multicycle  Processor  was  created.
        Following the architecture and design  in  reference [1],  a  working  multi-cycle  MIPS  processor  in
        Microsoft JAVA was created.  In order to accomplish such a difficult task,  a  brief  overview  of  the
        implementation of a multi-cycle MIPS processor, a description of the data path and  instruction  cycle
        will be discussed.  Following this, a more detailed description of the code used in the simulation of the
        MIPS will be presented.  Before reading on, the user is assumed to have a basic knowledge of  some
        programming, computers and Java programming.
 

3.0 INSTRUCTION EXECUTION CYCLES

        The main difference between a multi-cycle and  single  cycle  MIPS  processor  is  the  fact  that  the
        multi-cycle implementation takes more than one clock cycle to execute an instruction, but  the  exact
        number of cycles needed to execute one instruction can vary depending  on  the  type  of  instruction.
        Although the single cycle implementation may appear on the surface to be a faster,more efficient data
        path, the multi-cycle data path actually has many more advantages.  The  multi-cycle  implementation
        allows a functional unit (such as an Arithmetical Logic Unit or ALU) to be used more than  once  per
        instruction provided it's used on different clock cycles. This in turn reduces the amount  of  hardware
        required.

        Allowing the processor to take multiple cycles to execute an instruction is actually an advantage.  For
        a single cycle processor,it would take a fixed amount of time to execute an instruction, no matter how
        simple it is. So a simple addition instruction will take as long as a more  complicated  memory  access
        or memory write instruction. This is not the case in the multi-cycle processor.  If  the  instruction  is  a
        relatively simple instruction, then  it  takes  the  processor  fewer  cycles  and  therefore  less  time  to
        execute.  If the instruction is relatively more complicated, it can use  more  cycles,  requiring  a  small
        amount of time as the single cycle processor to  execute.  The  ability  to  allow  instructions  to  have
        varying numbers of clock cycles to execute and the reuse of functional units are the major advantages
        of the multi-cycle processor.

        All instructions implemented and their corresponding clock cycles in processor can be  found  in  this
        simulation.  In a multi-cycle MIPS processor, there are  five  basic  stages  that  the  processor  goes
        through.  A very brief overview of each stage is presented in the following.

3.1   Instruction Fetch

                In this step, the instruction in memory pointed to by the Program Counter (PC) is loaded  from
                memory.  The instruction is read and stored  in  the  Instruction  Register  (IR)  and  the  PC  is
                incremented by four. In this step the processor does not know what the instruction  is  or  does.
                The operation of incrementing the PC by 4 requires setting the ALUSrcA signal to  0  (to  send
                the PC to the ALU), and ALUOp to 00 (to set the ALU to perform addition).   The  operation
                of sending the PC to the memory requires asserting the control signals MemRead and  IRWrite,
                and setting IorD to 0 to select the PC as the source of the  address.  Finally,  the  operation  of
                storing  the  incremented   instruction  address into  the  PC  requires  asserting  PCWrite.  The
                increment of the PC and the instruction memory access can occur in parallel.  The new value of
                the PC is not visible until the next clock cycle.

3.2    Instructions Decode and Register Fetch

                In this step, several different actions are performed. First of all,  the  branch  target  address  is
                calculated using the ALU before the instruction type  is  known. This  does  not  interfere  with
                anything because if the instruction is not a branch, the result can be ignored. The registers used
                in R-type instructions will also be read, which are stored in A and B.  Reading the  registers  at
                the early stage helps to speed up the execution time of the current instruction. The operation of
                computing the branch target requires setting ALUSrcA to 0(so that the PC is send to the ALU),
                ALUSrcB to the value 11 (so that the sign-extended and shifted offset field is send to the ALU),
                and ALUOp to 00 (so the ALU adds).  The  register file accesses and computation  of  branch
                target occur in parallel.

3.3    Execution, Memory Address Computation, or Branch Completion

                This stage is the first in which  the datapath operation  is  determined  by  the  instruction  class.
                There are  four different instruction  classes: Memory  Reference,  Arithmetic-logical  (R-type),
                Branch, and Jump.  A more detailed description and a breakdown of each class  of  instruction
                will be attached as Appendix A of this report.Depending on the instruction,it is either completed
                at this cycle or data is prepared for use in the next cycle. Of all the instructions, only the branch
                instructions, which are Branch-class, finish at this stage.

3.4    Memory Access or R-type Instruction Completion

                In this cycle, the R-type instructions are completed and the results are stored  in  the  appropriate
                registers.  I-type instructions are also completed here,  except  for  those that deal  with  memory
                reading or writing. For memory access instructions, the data is stored in the memory data register
                where it is used in the next cycle.  A more detailed description and a breakdown of each class of
                instruction are attached as Appendix A of this report.

3.5    Memory Read Completion
                In the final stage, the data stored in the memory data register is either written to memory  (in  the
                case of a store word instruction), or is written to a specified register (in the case of a load  word
                instruction).  The operation of writing the data into the register file requires setting MemtoReg=1
                (to write the result from memory), asserting RegWrite (to cause a write), and setting RegDst = 0
                to choose the rt (bits 20-16) field as the register number.
 

4.0    IMPLEMENTATION

        In this section, the implementation of the simulation of the MIPS processor  is  described.  Since  this
        project is to develop a graphical representation of MIPS processor, all modules written in JAVA are
        represented graphically throughout this project.  The source code for this graphical simulation is quite
        complicated, and the 57 source codes in total are attached as Appendix C.

4.1   User Interface

                In this applet a user should see five  buttons (Star  Simulation,  Step,  Reset,  Clear  TextArea,
                About), an instruction window, a single pipeline consisting of  all  five  stages (IF,  ID/EF,  EX,
                MEM, WB), register values, and asserted values, a datapath of MIPS processor. With the five
                buttons, a user will be able control the simulation steps of the datapath. A user will then be able
                to clear, reset instruction window, or will be able to fill, cut, or paste  in  a  instruction  window
                using MIPS instructions(or use the ready-made program already in the instruction window)and
                run those instructions through the datapath of MIPS.Register file and asserted value updates are
                displayed corresponding to the result of the different stages. A graphical layout of the project is
                attached as Appendix A in the project.

4.1.1    Start Simulation Button

                            When this button is hit, the simulation begins to run through  five  stages until  a  user  hit
                            this button again, or hit Step button.  Meanwhile, this button  will  be  renamed  as  Stop
                            Simulation in  order  for  a  user  to  stop  the  simulation.  The  instruction  is  displayed
                            accordingly beside the single pipeline.  At the same time the modules in datapath for the
                            instruction are highlighted in yellow color, the control lines are highlighted in blue at each
                            stage.  Values are updated and displayed in the value panel, which is located at the right
                            upper  applet.   At   each   stage,   there  is  a  delay  of  2000  microsecond,  which   is
                            approximately equal to 2 seconds in real time.

4.1.2    Step Button

                            The operation of the applet after hitting this button  is  same  as  hitting  Start  Simulation
                            Button, except there is no delay. Instead of the 2 seconds delay, a user is required to hit
                            this button again, or hit Start Simulation button to further tracing an instruction.

4.1.3    Reset Button

                            The Reset button is just to perform an initialization.  When this button is  hit,  values  are
                            set to 0, modules are  un-highlighted,   and  instructions  beside  the  single  pipeline  are
                            cleared. In the instruction window, the pre-programmed instructions  will  be  displayed
                            again. Instruction buffer is cleared.

  4.1.4    Clear TextArea Button

                            What is accomplished when hitting this button is just to clear the instruction  window  in
                            order for a user to punch in or paste new instructions.  Meanwhile a user will  find  that
                            this button is renamed to  Reset TextArea  after  hitting  this  button.  When  hitting  this
                            button again, the cleared instruction will be displayed  again in  the  instruction  window.
                            This will help if a user make a wrong hit before.

4.1.5    About Botton

                            This button is simply displaying information about the programmer.  But a user should
                            note that when the applet is running,  pressing  this  button  make  no  changes  and  a
                            warning sentence is shown in the status bar. The button works only if the applet is not
                            running, and instead of displaying the datapath, the information about the programmer
                            will be displayed.   Meanwhile, a user should note that the button is renamed to View
                            Datapath in order for a user to view the datapath at whatever stage the applet was.
 

4.2 Datapath

                The datapath of a MIPS processor can be described as logical layout of the  processor.  Before
                doing this project,  the major components required to execute  each  class  of  MIPS  instruction
                was carefully examined. Knowing clearly what the datapath  looks  like,  the  datapath  model  in
                Java would be successfully created.  The layout of the datapath is attached in the Appendix  A  in
                the report.  The datapath of the MIPS multicycle has a regular structure.  Basically, there are  ten
                main modules: Program Counter, Memory, Memory Data Register, Instruction Register, General
                Registers,  Control,  ALU,  ALU  Control,  Target,  and  the  Multiplexors.  These  modules  are
                interconnected by a number of data lines controlled by the Control module. The Memory module
                is a storage element, which houses the instructions to be run as well as the data.

                A MIPS instruction, which is always 32 bits wide,  can be broken down into two sections -- the
                opcode and operators/addresses.  In this structure, the  Instruction  Register  stores  the  current
                instruction to be executed.   It holds the instruction  in its  registers  to  be  viewed  by  the  other
                modules.  The Opcode describes the operation to be performed, such as  (addition,  subtraction,
                multiplication, etc).  The general Registers hold data that are either the results of other instructions
                or loaded directly from the Memory. The ALU module performs all  the  operations (+, -, *, etc)
                on the data. The Program Counter stores the current position in the instruction stack.The Control
                module has signal lines that connect to the other modules to control their function. The task of the
                Control module can be thought of as a conductor in a symphony. As  an  instruction  is  executed,
                the Control module directs each module to function in a certain way.Using the symphony analogy,
                each module can be considered as an  instrumental  section,  the  Memory  module  is  the  brass,
                Registers are the strings, etc. Each section needs to play in unison and in key. By the same token,
                each module needs key data from the other modules at certain instances. The Control  module  is
                the conductor, which fits the requirement.

4.3    Unpipelined Execution

                In this project, the instructions are executed in an unpipelined technique.  However, the processor
                can be viewed as a pipe made up of several instruction stages. The instructions enter the pipe and
                proceed through the stages. At the given stage, the appropriate work is done.When an instruction
                exits the pipe, a new instruction enters.Notice,  however,  that  not  all  instructions  need  to  pass
                through all the stages.  For the unpipelined  technique,  instructions  are  executed  based  on  their
                different classes.  There are a total of four classes, memory reference, R-type  instruction,  Branch
                instruction, and J-type instruction. Before reading on, we have to know the format of each type of
                instruction. The length of bits of each parameter in the particular instruction is shown as below:

                                                 R-Type:

                                                 I-Type:

                                                 J-Type:

                After knowing the format of each type of instruction and the  bit  length  of  each  parameter,  the
                stages and clock cycles required by each instruction type to exit  the  pipe  were  described. The
                detail of the stages used by each type is discussed as follow.

4.3.1    Memory reference:
                            a) Load Word (lw) -- for a lw instruction, the instruction is required to  pass  through  all
                                five stages shown.
 

                            b) Store Word (sw) -- for a sw instruction, the instruction is required to pass through only
                                four stages as shown below.
 

4.3.2    R-type instruction:
                            An R-type instruction is an ALU instruction, and all ALU instructions do not use the MEM
                            stage. So, all  R-type  instructions  are  required to pass through only four stages as shown
                            below.
 

4.3.3    Branch instruction:
                            A Branch instruction is simpler than a Memory reference instruction and an R-type
                            instruction. It is required to pass through on three stages as shown below.
 

4.3.4    J-type instruction:
                            A J-type instruction is similar to a Branch instruction and also requires passing  through  only
                            three stages as shown below.
 

4.4    Shortcomings

            Some shortcomings of my project include
            1) In this project, only 10 of the 32 registers used by the simulator are visible in the applet due to lack
                of space.  It is a good idea to keep the number of registers used under 10 in order to  see  what  is
                happening in the datapath.

            2) For simplicity, the entire memory was not created.  Addresses 1-100 are available, but again, only
                1-10 memories are visible.

            3) Not all the instructions implemented; however, most of  the  integer  ones  was  implemented.  (40
                instructions in total)

            4) In branch and jump instructions,  line numbers were used instead of labels (names)

            5) This program is particular to the format of the typed MIPS  Instructions.  Any  misspelled  word  or
                a wrong register or file name will cause either a NullPointerException or a NumberFormatException
                that will stop the simulation of the applet.  The error should  display  on  the  status  bar,  and  it  will
                propagate throughout the program unless fixed.  All a user would  need  to  do  then  is  to  find  the
                typographical error and correct it, then it should run smoothly again.
 

4.5    Available Instructions:

            These are the instructions available that a user may add to the pipeline through the text area:
            LB, LBU, LH, LHU, LW,  LHI
            SB, SH, SW
            ADD, ADDI, ADDU, ADDUI
            SUB, SUBI, SUBU, SUBUI
            AND, ANDI OR, ORI, XOR, XORI
            SGT, SGTI, SLT, SLTI, SEQ, SEQI
            SNE, SNEI, SGE, SGEI, SLE, SLEI
             J
            BEQZ, BNEZ

4.6    Program Organization:
            This section will discuss the detail of source code files. Each file accomplishes particular tasks.
            Basically the project is broken down into 57 separate files (Java classes).

            a) DataPath.java --  This  is  a  complicated  class that  handles  the  layout  of  the  Datapath  of
                   MIPS Processor, the layout contains ten main modules as described  in Part  4.2.  An  integer
                   parameter  is called from MIPSProcessor.class  to display the complete a complete  datapath
                   or just the modules required  by  a  specific instruction. Parameter 888 is called to display  the
                   the complete datapath; parameter 96  is  called  to  display  the  modules  required  by  step 1
                   described in 3.1.  Detail  information is required to have a look at this file.Also, this class  also
                   displays the information about the programmer.

            b) MIPSProcessor.java --  This is the applet that the HTML file  will  look  at.   It's  basically  the
                   control unit and the graphical interface between the  program and  the  user.  This class  file  set
                   the  layout  for the whole applet.  Each stage of the pipeline is represented by the  methods: if(),
                   id(),  ex(),  mem(), and wb().  It is the job  of  the  MIPSProcessor.java  to call  each  of  these
                   methods  on  particular instructions at the right time.

            c) Mux -- This is a class contains 20 arrays that hold the asserted value  signaled  by  the  control
                   module. The file set the layout of the asserted-value table.  A user can  easily  trace  the  values
                   asserted  by control module, since all arrays are labeled and displayed.

            d) MuxFile -- This is basically a "manager" for the Mux class. It is a container that keeps track of
                   all 20 asserted values (signaled by the control module). At  each  stage,  there  will  be  several
                   values asserted, and displayed in the corresponding label. But at next stage, all asserted will be
                   reset to 0 again.  This is because we can clearly know what values are asserted at that stage.

            e) Pipeline.java  -- This is a simple class  that  set  the  layout  of  the  pipeline  stages,  which  are
                   labeled  IF, ID/RF, Exe,  Mem,  Wb.  Also,  it  will  handle  the  formatting  and  displaying of
                   Instructions.  Since this is a unpipelined simulation, only one instruction will be displayed before
                   the instruction leaves the pipe.

            f) Buffer.java -- This is a simple class that only handles the formatting and displaying of Instructions.
                  Since only one instruction will be  displayed  before  the  instruction  leaves  the  pipe, uses   lose
                  trace  when instruction leaves the pipe. But when instruction  leaves  the  pipe,  the  instruction  is
                  written into the buffer.  With this buffer, uses can easily trace  the  instruction  before  the  current
                  instruction.

            g) Register.java -- This is a class that simulates a single 32-bit register. It is able to store integer data
                   and return this data if needed.The file also handles the layout of the register table.A user can easily
                   trace the values changed at every stage.

            h) RegisterFile.java -- basically a "manager" for the register class. It is a container that keeps track
                   of all 32 registers (in the register file) or 50 memory cells (in the main memory).

            i) Parser.java -- contains the text area where instructions can be  added.   This  class  will  take  the
                  assembly code from the user and parse it to an Instruction format that the pipeline can understand
                  (from text to a Program object).

            j) ParserException.java-- thrown when the Parser detects an error while parsing the program.  This
                  allows the main DLXPipeline applet to handle the error.

            k) Program.java -- it is basically a container for Instructions.

            l) Instruction.java -- the base class for all instructions.  It contains the methods: if, id, ex, mem, and
                  wb, which can be overloaded in the derived classes if extra functionality is needed.

            m) I_Instruction.java --  see J_instruction.java.

            n) R_Instruction.java -- see J_instruction.java.

            o) J_Instruction.java --  These are the class that is derived from Instruction .java.  These  are  self-
                   explanatory; they are based on the three different instruction format types.The rest of the classes
                   are the individual instructions, each with its own if, id,  ex,  mem,  and  wb  methods.  These  are
                   derived from one of the three instruction formats mentioned above.
 
 

5.0    Conclusion:
 
                     A graphical representation of the operation of a MIPS processor implementation has been created.
              A multicycle processor model was chosen for the implementation. Although this is not the most efficient
              design, it was chosen because it is more straightforward to implement and easier to verify the design. The
              layout of the graphical representation has been carefully designed to meet the requirement of being able to
              run in a Web browser. Since this project will be displayed on monitor through the Web site, the size of the
              layout had to be carefully selected; otherwise a portion of the screen could be cut off.  This project can
              now be viewed through any computer, but the best results are obtained if the user sets the resolution of the
              monitor at 1024x786 pix.

                    Once this layout was chosen, the project was then implemented in three phases. Phase I was to draw
              and display the complete datapath first; Phase II was to draw and display those buttons, TextArea, and
              Pipeline; and Phase III was to draw and display Register table, Memory Table, Asserted-value table.
              Many skills and techniques were used throughout the graphical representation.  Most of my time was
              spent on figuring out these skills and techniques.  For example, it took me almost one month to just finish
              the complete datapath.  Although most of my time was spent writing and simulation JAVA code using the
              Microsoft JAVA 6.0, the complete processor was finished during the semester.
 
 
 

Appendix A

A1.    Execution, memory address computation, or branch completion (ABSTRACT from [1])

Memory reference:

Target = A + sign extend (IR [15-0]);

Operation: The ALU is adding the operands to form the memory address. This requires setting ALUSrcA to I (so that the first ALU input is register A) and setting ALUSrcB to 10 (so that the output of the sign extension unit is used for the second ALU input). The ALUOp signals will need to be set to 00 (causing the ALU to add).

Arithmetic-logical instruction (R-type):

Target = A op B;

Operation: The ALU is performing the operation specified by the function code on the two values read from the register file in the previous cycle. This requires setting ALUSrcA = I and setting ALUSrcB = 00 (together causing the registers A and B to be used as the ALU inputs). The ALUOp signals will need to be set to 10 (so that the function field is used to determine the ALU control signal settings).

Branch:

If (A == B) PC = Target;

Operation: The ALU is used to do the equal comparison between the two registers read in the previous step. The Zero signal out of the ALU is used to determine whether or not to branch. This requires setting ALUSrcA = 1 and setting ALUSrcB = 00 (so that the register file outputs are the ALU inputs). The ALUOp signals will need to be set to 01 (causing the ALU to subtract) for equality testing. The PCCondWrite signal will need to be asserted to update the PC if the Zero output of the ALU is asserted. By setting PCSource to 01, the value written into the PC will come from Target, which holds the branch target address computed in the previous cycle. For conditional branches that are taken, we actually write the PC twice: once from the output of the ALU (during the Instruction decode/register fetch) and once from Target (during the Branch completion step). The value written into the PC last is the one used for the next instruction fetch.

Jump:

PC = PC [31-28] || (IR [25-0]<<2)

Operation: The PC is replaced by the jump address. PCSource is set to direct the jump address to the PC, and PCWrite is asserted to write the jump address into the PC.
Memory access or R-type instruction completion step

During this step, a load or store instruction accesses memory and an arithmetic-logical instruction writes its result. When a value is retrieved from memory it is stored into the memory data register (MDR), where it must be used on the next clock cycle.

Memory reference:

MDR = Memory [Target];
Or
 Memory [Target] = B;

Operation: If the instruction is a load, a data word is retrieved from memory and is written into the MDR. If the instruction is a store, then the data is writ, ten into memory. In either case, the address used is the one computed during the previous step and stored in Target. For a store, the source operand is saved in B. (B is actually read twice, once in step 2 and once in step 3. Luckily, the same value is read both times, since the register number--which is stored in IR and used to read from the register file -- does not change.) The signal MemRead (for a load) or MemWrite (for store) will need to be asserted. In addition, for loads, the signal lord is set to 1 to force the memory address to come from the ALU, rather than the PC. Since MDR is written cycle, no explicit control signal need be asserted.

Arithmetic-logical instruction (R-type):

 Reg [IR [15-11]] = Target;

Operation: Place the contents of Target, which corresponds to the output of the ALU operation in the previous cycle, into the Result register. The signal RegDst must be set to 1 (to force the rd (bits 15-11) field to be used to select the register file entry to write). RegWrite must be asserted, and MemtoReg must be set to 0 (so that the output of the ALU is written, as opposed to memory data output).
 

A2.    Preprogrammed MIPS Instructions:

ADDI R1,R0,#20
ADDI R2,R0,#30
ADD R3,R1,R2
AND R4,R1,R2
SW R3,1(R0)
LW R5,1(R0)
SUB R1,R5,R2
SLT R6,R3,R5
SEQ R7,R3,R5
SGT R8,R3,R5
BEQZ R6, 13
ADDI R9,R0,#911
SUBU R5,R2,R3
J 15
ADDI R9,R0,#100
LH R5, 2(R0)
SUBI R6, R9, 91
LB R9, 2(R6)
OR R2, R3, R9
SEQI R8, R0, #0
J 1
 
 

A3.    Layout of Datapath

A4. Layout of the project
 

A5.    The Complete finite state machine control for the datapath (from [1])

B1.    Instruction Sequencing

The process by which instructions are loaded from memory and executed in the CPU is referred to as instruction sequencing.

The basic required steps to execute an instruction are listed below. Not all instructions require all steps. Also, some steps can be combined or expanded depending on the implementation.

Fetch instruction. The instruction has to be loaded from memory before it can be executed. The program counter (PC) always points to the location of the next instruction to be executed. After fetching the instruction at MEM[PC}, the CPU needs to increment the PC by the appropriate offset (the length of the current instruction)

 Instruction Decode. Instructions are encoded into machine code for storage in the computer. The CPU needs to interpret the bits it fetched from memory to determine what the instruction needs to do.

 Effective Address Calculation. For operands in memory, the memory address needs to be calculated based on the addressing mode used.
 Operand Fetch. Before any operations can be performed, the data must be loaded. The data can be either in the instruction (immediate), in a register, or in memory.

 Execution. The operation specified by the opcode is performed on the operands.

 Write Back. The results of the operation must be stored. The write back stage can write either to registers or to memory.

B2.    Program Organization:

My project is broken down into 57 separate files (Java classes).

Mux.java -- a class contains 20 arrays that hold the asserted value signaled by the control module.

MuxFile.java -- basically a "manager" for the Mux class. It is a container that keeps track of all 20 asserted values (signaled by the control module).

DataPath.java -- This is a complicated class that handles the layout of the Datapath of MIPS, and updating modules for a particular instruction in different stages.

MIPSProcessor.java --  the applet that the HTML file will look at.  It's basically the control unit and the graphical interface between the program and the user.  Each stage of the pipeline is represented by the methods: if(), id(), ex(), mem(), and wb().  It is the job of the DLXPipeline to call each of these methods on particular instructions at the right time.
Pipeline.java  -- simple classes that only handles the formatting and displaying of Instructions.

Buffer.java -- simple classes that only handles the formatting and displaying of Instructions.

Register.java -- a class that simulates a single 32-bit register. It is able to store integer data and return this data if needed.

RegisterFile.java -- basically a "manager" for the register class. It is a container that keeps track of all 32 registers (in the register file) or 50 memory cells (in the main memory).

Parser.java -- contains the text area where instructions can be added.  This class will take the assembly code from the user and parse it to an Instruction format that the pipeline can understand -- from text to a Program object).
ParserException.java-- thrown when the Parser detects an error while parsing the program.  This allows the main DLXPipeline applet to handle the error.

Program.java -- it is basically a container for Instructions.

Instruction.java -- the base class for all instructions.  It contains the methods: if, id, ex, mem, and wb, which can be overloaded in the derived classes if extra functionality is needed.

I_Instruction.java --  see J_instruction.java.

R_Instruction.java -- see J_instruction.java.

J_Instruction.java --  These are the class that is derived from Instruction.java.  These are self-explanatory; they are based on the three different instruction format types.  The rest of the classes are the individual instructions, each with its own if, id, ex, mem, and wb methods.  These are derived from one of the three instruction formats mentioned above.

Appendix C.

C1. Source Code
 

File Name	Size	File Name	Size	File Name	Size	File Name	Size
ADD	863	ADDI	2k	ADDU	834	ADDUI	2k
AND	722	ANDI	2k	BEQZ	2k	BNEZ	2k
Buffer	2k	Datapath	53k	EMPTY	198	I_Instruction	742
Instruction	340	J	518	J_Instruction	560	LB	2k
LBU	2k	LH	2k	LHI	2k	LHU	2k
LW	2k	MIPSProcessor	14k	Mux	978	MuxFile	2k
NOP	306	OR	720	ORI	2k	Parser	16k
ParserException	157	Pipeline	3k	Program	854	R_Instruction	975
Register	2k	RegisterFile	2k	SB	2k	SEQ	734
SEQI	2k	SGE	776	SGEI	2k	SGT	776
SGTI	2k	SH	2k	SLE	746	SLEI	2k
SLT	744	SLTI	2k	SNE	746	SNEI	2k
SUB	725	SUBI	2k	SUBU	2k	SUBUI	725
SW	2k	XOR	720	XORI	2k

Bibliography:

1. John H. Crawford. [1993]. Computer Organization and Design: Second ed., Digital Press, Bedford, MA.

2. Kidder, T. [1981]. Soul of a New Machine, Little, Brown, and Co., New York.

3. Describes the design of the Data General Eclipse series that replaced the first DG machines such as the Nova. Kidder records the intimate interactions among architects, hardware designers, microcoders, and project management.

4. Levy H. M., and R. H. Eckhouse, Jr. [1989]. Computer Programming and Architecture: The VAX, Second ed., Digital Press, Bedford, MA.

5. Good description of the VAX architecture and several different microprogrammed implementations.

6. Patterson, D. A. [1983]. "Microprogramming," Scientific American 248:3 (March) 36-43. Overview of Microprogramming concepts.

7. Tucker, S. G. [1967]. "Microprogram control for the System/360," IBM Systems J. 6:4, 222-41. Describes the microprogrammed control for the 360, the first microprogrammed commercial machine.

8. Wilkes, M. V. [1985]. Memoirs of a Computer Pioneer, MIT Press, Cambridge, MA.