The minimal instruction set computer misc in java
1 / 80

The Minimal Instruction Set Computer (MISC) in Java - PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

The Minimal Instruction Set Computer (MISC) in Java. Note: This is the same set of overheads that is used to introduce MISC in CS 320. This version of the overheads has an additional section at the end. That section describes the programming project for CS 304 which is based on MISC.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

The Minimal Instruction Set Computer (MISC) in Java

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

The Minimal Instruction Set Computer (MISC) in Java

  • Note:

  • This is the same set of overheads that is used to introduce MISC in CS 320.

  • This version of the overheads has an additional section at the end.

  • That section describes the programming project for CS 304 which is based on MISC.

Part 1. MISC

  • MISC is a Java simulation of a simple CPU

  • The architecture makes use of 4 byte words

  • In the simulation the contents of a register as well as the contents of a byte in memory are modeled by an object containing a character array of 8 bytes

  • Each bit is then modeled by the presence of either the character ‘1’ or the character ‘0’ in a particular position in one of these 8 byte arrays.

  • The registers are packaged together in an array named “reg”.

  • The index of the array identifies the particular register.

  • Registers:

  • register namedecimal indexbinary code

  • identificationin reg arrayof index

  • unusedreg[0]"00000000"

  • general purpose

  • Areg[1]"00000001"

  • Breg[2]"00000010"

  • Creg[3]"00000011"

  • Dreg[4]"00000100"

  • Registers, cont’d.:

  • register namedecimal indexbinary code

  • identificationin reg arrayof index

  • memory offsets

  • codeoffsetreg[5]"00000101"

  • dataoffsetreg[6]"00000110"

  • unused1reg[7]"00000111"

  • unused2reg[8]"00001000"

  • unused3reg[9]"00001001"

  • flagreg[10]"00001010"

  • Registers, cont’d.:

  • register namedecimal indexbinary code

  • identificationin reg arrayof index

  • control unit registers

  • instructionreg[11]"00001011"

  • operand1reg[12]"00001100"

  • operand2reg[13]"00001101"

  • extrareg[14]"00001110"

  • ALU registers

  • aluinreg1reg[15]"00001111"

  • aluinreg2reg[16]"00010000"

  • aluoutregreg[17]"00010001"

  • The memory is also implemented in the simulation as an array

  • Each element of the array is a machine word

  • The index of the array represents the offset into the memory, counting by 4 byte words.

  • Memory:array name


General Remarks on Machine Instruction Execution

  • The general rules for both move and arithmetic instructions are these:

    • A register or a memory variable can be a destination.

    • A constant, a register, or a memory variable can be a source.

    • Memory to memory operations are not allowed.

  • After a program is loaded the machine takes control of execution

  • This is done by means of a call from the Osystem to the takeControl() method of the Machine

  • The machine steps through the contents of the code segment until it encounters an empty (“00000000”) instruction byte

  • Execution starts with the value 0 in the code offset register

  • The machine takes the contents of 4 contiguous bytes of memory starting at the address in the code offset register

  • It puts those bytes into the instruction, reg[11]; operand1, reg[12]; operand2, reg[13]; and extra register, reg[14], respectively

  • After the retrieval of each instruction and before its execution, the code offset is incremented for the next retrieval.

The Machine Instruction Set

  • The MOVE Instruction

  • assembly instructionmethod in simulationmachine instruction

  • MOVE register, registervoid moveDestRegSrcReg()“10000001”

  • MOVE memory, registervoid moveToMemFromReg()“10000010”

  • MOVE register, memoryvoid movetoregfrommem()“10000011”

  • MOVE memory, constantvoid movetomemfromconst()“10000100”

  • MOVE register, constantvoid movetoregfromconst()“10000101”

  • The ADD Instruction

  • assembly instructionmethod in simulationmachine instruction

  • ADD register, registervoid addDestRegSrcReg()“10000110”

  • ADD memory, registervoid addToMemFromReg()“10000111”

  • ADD register, memoryvoid addToRegFromMem()“10001000”

  • ADD memory, constantvoid addToMemFromConst()“10001001”

  • ADD register, constantvoid addToRegFromConst()“10001010”

  • The SUB Instruction

  • assembly instructionmethod in simulationmachine instruction

  • SUB register, registervoid subDestRegSrcReg()“10001011”

  • SUB memory, registervoid subFromMemSrcReg()“10001100”

  • SUB register, memoryvoid subFromRegSrcMem()“10001101”

  • SUB memory, constantvoid subFromMemSrcConst()“10001110”

  • SUB register, constantvoid subFromRegSrcConst()“10001111”

  • The JUMP Instruction

  • assembly instructionmethod in simulationmachine instruction

  • JMP unsigned integervoid jumpUnconditional()“10010000”

  • JPOS unsigned integervoid jumpOnPositive()“10010001”

  • JNEG unsigned integervoid jumpOnNegative()“10010010”

  • JZERO unsigned integervoid jumpOnZero()“10010011”

  • JOVER unsigned integervoid jumpOnOverflow()“10010100”

  • The unsigned integer parameter in operand1 is to be interpreted as an offset into code memory

  • It has to be treated as unsigned, and in order to work correctly it has to fall on a 4 byte instruction boundary

General Remarks on the Form of Machine Language

  • In a line of executable machine language code the instruction comes first, followed by the destination operand, followed by the source operand

  • This is followed by an extra space which does not yet have a designated use

  • If the line of code contains a data declaration rather than an instruction, the first item will be the initial value of the data item, and the remaining three spaces will be unused

  • A program can take a maximum of 32 lines.

  • The program will be loaded at offset 0, the data portion first, the program code itself second

  • Words 0-7 are reserved for data variables

  • That means that a single program can have a maximum of 8 memory variables

  • If there are not 8 variables, the unneeded words will be filled with 0’s

  • The code segment of a machine language program begins at offset 8

  • Jump instructions in the code will have to be written with operands incremented by 8.

  • The source file signals termination with a row of asterisks

  • When the source program is loaded, the asterisks aren’t loaded.

  • What is placed in memory instead is a line of 0’s.

  • Inside the machine, the takeControl() method stops if it encounters an instruction which is all zeros

  • This means that in memory, a program has to be followed by at least one word where the first byte is zeros

  • If need be, this will be the 32nd line, meaning a maximum of 31 lines for a program, or up to 8 variables and up to 23 lines of code

An Example Machine Language Program

  • The example is a machine language program that sums the first 10 integers

  • The machine language alone with artificial line breaks and segment labels follows

  • The *’s are used on input to detect the end of the program.

  • data segment

  • 00001011000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • 00000000000000000000000000000000

  • code segment

  • 10000101000001000000000100000000

  • 10000111000000010000010000000000

  • 10001010000001000000000100000000

  • 10000011000000110000000000000000

  • 10001011000000110000010000000000

  • 10010001000010010000000000000000

  • ********************************

The Example Program Data Segment with Assembly Language Guide

  • /.DATA///

  • This is a directive, not an instruction

  • 00001011 00000000 00000000 00000000

  • /LOOPLIM/X0B//

  • loop limit data variable, offset 0, value 11

  • 00000000 00000000 00000000 00000000

  • /ACCUM/X00//

  • accum data variable, offset 1, value 0

General comments on data variables

  • Registers can only contain 8 bits, so memory variables are limited to 8 bits

  • Memory variables have to occur on word boundaries in order to be addressable

  • Therefore, 3 bytes are wasted for every variable

The Example Program Code Segment with Assembly Language Guide

  • Only the live code is shown below.

  • Memory would be filled with 6 additional lines of 4 groups of 8 zeros

  • These are not shown.

  • /.CODE///

  • This is a directive, not an instruction

  • 10000101 00000100 00000001 00000000

  • /MOVE/D/X01/

  • move reg D, const 1

  • MISC method: movetoregfromconst4, 1


  • This is a directive, labeling a line in the code which can be jumped to

  • 10000111 00000001 00000100 00000000


  • add data offset 1, reg D

  • MISC method: addtomemfromreg 1, 4

  • 10001010 00000100 00000001 00000000

  • /ADD/D/X01/

  • add reg D, 1

  • MISC method: addtoregfromconst4, 1

  • 10000011 00000011 00000000 00000000


  • move reg C, data offset 0

  • MISC method: movetoregfrommem3, 0

  • 10001011 00000011 00000100 00000000

  • /SUB/C/D/

  • sub reg C, reg D

  • MISC method: subtractdestregsrcreg3, 4

  • 10010001 00001001 00000000 00000000  


  • Since space is reserved for 8 variables, the first instruction comes at word 8.

  • The label looptop designates the 9th word, or line.

  • jump on positive to “LABEL”

  • MISC method: jumponpositive 9

  • /.END///

  • This is a directive, not an instruction.

Running the Simulation and Using the Operating System Commands

  • Altogether, the simulation consists of 6 java files:

  •,,,,, and

  • Assuming all of the files are in the same directory, compiling and running will set MISC in motion

  • When it is running, it presents a simple command line prompt in a DOS window.

  • The operating system has only 3 commands, rpf, dmc, and exit


  • = run program file

  • Upon entering this command the user is prompted for the name of the program (machine language) file to run.

  • Note that machine language files have to be simple text files and that when prompted for the file the O/S expects a name with the .txt extension

  • It will seemingly “accept” files without the extension, but it will not work correctly


  • = dump memory contents

  • Upon entering this command the user is prompted for the name of the output file to create

  • In this file the system will put the contents of the memory after a program run

  • Notice that this operating system in effect has no I/O capabilities.

  • You only know what the program did by looking at the memory contents afterwards.

  • Note that the output file specified should also be a text file with a .txt extension.


  • = quit or end the simulation. (Technically this isn’t even really a command…)

  • Note that a text file named “showfile” should show up in the directory where you run the simulation.

  • This is caused by a call to the showStuff() method in the simulation code.

  • It is a debugging tool

  • Even if things are so messed up that you can’t successfully use dmc, you can still see simulation results

  • A call to showStuff() can be placed at various locations in the simulation code to capture and output the machine’s contents at that point.

A Summary of the Structure of the Java Simulation by Class, Constructor, and Method

  • Listed below are the component classes that make up the simulation

  • Complete html documentation for the simulation code is available

  • In this summary, important information is emphasized without exhaustively commenting on all aspects of the classes or mentioning all instance variables, constructors, or methods of the classes.


  • This is a container for an array of 8 characters

  • Each character is either a 1 or a 0, so this represents a byte in the machine simulation


  • This is a container for an array of 4 MachineByteobjects

  • In the machine architecture 1 addressable word equals 4 bytes


  • This is the heart of the simulation and its contents can be broken down into several categories

  • As explained in greater detail above, the hardware of the machine, its registers and memory, are simulated by elements of arrays of the necessary type

  • These are declared and constructed in Machine

  • Machine has a general purpose method that may be useful for debugging, showStuff()

  • This shows the complete contents of the machine, including the registers

  • This method exists “on the side” and can be used to figure out what is going on with the simulation

  • It is not intended for use as part of your solution to a programming assignment, except as a debugging tool

  • Machine has some special purpose methods, which do not support general machine language instructions

  • Instead, they are used by the Osystem to do I/O.

  • They are:

  • loadWordToOffset()

  • getWordFromOffset()

  • Machine has some methods which contain the logic for executing a machine language program.

  • These are:

  • totalReset()

  • resetOffsets()

  • takeControl()

  • takeControl() is the most fundamental of the execution methods

  • It is called by the Osystem after a program is loaded

  • takeControl() contains the built-in logic of

    • incrementing the codeoffset register

    • checking the contents of that location in memory

    • and executing the method that implements the machine language instruction corresponding to the binary code found there

  • Machine has methods that implement the machine language move, add, subtract, and jump instructions

  • It also has some helper methods that support arithmetic

  • One method helps with integer arithmetic when the machine contents are in binary form

  • Another method sets the flag register to agree with the outcome of an arithmetic operation


  • This has a constructor in which a copy of the Machine is constructed

  • It also contains two methods:

    • runProgramFile()

    • dumpMemoryContents()

  • runProgramFile() loads a program from an external file and turns execution over to the machine

  • dumpMemoryContents() stores the current contents of the machine’s memory into an external file


  • This is a program containing a main() method

  • It is the simulation driver

  • In it a copy of the Osystem is constructed

  • The rest of the program is basically a loop which prompts and checks to see whether the user is entering Osystem commands and file names to go with them

  • It also supports an exit command, which is not an Osystem command, but is simply the input which causes the MachineOSProgram to stop looping.


  • This is just my implementation of a simple class that supports input to a program running in a command prompt.

Part 2. Programming Project

  • With the exception of a couple of items, everything you need to know in order to work this assignment you learned in CS 202.

  • You will notice that the examples given in the later units of CS 202, registers and so on, are the basis for the project in CS 304.

  • It will not be necessary to explicitly use any design patterns when working the project.

  • So to a large extent the project is a review, requiring you to stay in practice programming while learning various things.

  • On the other hand, as you learn more about design patterns, you may find that some of the knowledge you’ve gained can be applied towards writing a good solution to the problem.

  • The project consists of 10 numbered parts which are described below.

  • There are dependencies between some of the parts, and these are explained in the bulleted items following the descriptions.

  • There is also a diagram at the end that spells out the dependencies.

  • Two parts of the project are marked with ***’s.

  • This means that their successful implementation relies on aspects of Java that have not been and will not be illustrated with example programs.

  • This will make it necessary to look in the Java API documentation in order to complete them.

  • In the interests of making sure that everyone is equal in doing the project, the following information is being announced here:

  • Most of you know by now that I have solutions or partial solutions to most assignments, and I tend to store them on the Web page for the course.

  • If you look in the folders for CS 304, you will find my solutions to the first five parts of the project.

  • My solutions are available for reference in case you get stuck or are not clear about what the assignment requires.

  • Each person will get a different layout for their version of the project.

  • This means that even if you rely on my code, you’ll have to make modifications.

  • In any case, you’ll have to become familiar with the code so that you can modify it to accomplish the second five parts.

  • Writing your own code from the beginning would mean being able to apply any insights you might have about programming rather than just relying on my cut and dried solution.

Project Part 1

  • Give the application a frame with a menu.

  • Have the options to do load, run, dump, and exit be menu items with associated listeners.

  • Use a JFileChooser to handle the information about file names that has to be passed back and forth for the load and dump commands.

  • Do this part first.

Project Part 2

  • Display the register contents of the machine in the graphics frame of the application.

  • The register representations should be capable of both input and output.

  • This will mean using JTextFields.

  • You should label the registers with JLabels .

  • Because the application runs files from beginning to end without a break, it is sufficient to show the register contents at the end of a machine language program run.

  • It is not necessary to update the representation in the frame as the program executes.

  • Do this after completing part 1.

Project Part 3

  • Add a JButton to the graphics frame and revise the application code so that the next instruction is executed only when the button is clicked.

  • In this version of the application, the contents of the registers as shown in the frame should be updated after each button click, namely after the execution of each instruction.

  • It is reasonable to assume that the next instruction is still sitting in memory, and what is displayed in the registers after a click is the previously executed instruction along with the state resulting from its execution.

  • Do this after completing part 2.

Project Part 4

  • This part has two separate components.

  • A. Add focus to the application so that when you enter something into one of the registers from the keyboard, the cursor moves to the next register.

  • B. Add a button that will clear the contents of all of the registers without changing the loaded program.

  • In general, clearing means setting to 0.

  • You will need to confirm that whatever value is put into the code offset register is the correct one so that execution will start at the beginning of the machine language program when the run button is next clicked.

  • Note that this is not a perfect situation, since memory variable values might have been changed already before the registers are cleared for restarting at the beginning.

  • You can do this after completing part 3.

  • It would also be possible to skip this part of the assignment if you wanted to and move on to later ones.

  • Since this part is included in the posted partial solution, skipping it when doing the assignment would be an unlikely option to exercise.

Project Part 5

  • Display the contents of the machine’s memory in the frame using a JTextArea.

  • Since memory contents are too large to all fit in the frame at the same time, make sure the JTextArea is contained in scroll bars.

  • Do this after completing part 3.

  • The screenshot on the next overhead gives some idea of what an implementation of parts 1-5 might look like.

Project Part 6

  • *** Once the memory is displayed in the frame, add some visual indication of which machine instruction in memory is the current one.

  • Do this by highlighting a line in the area where memory is displayed by changing the background color of that line.

  • You can check the Java API documentation for more information on things you can do in a JTextArea.

  • You might also want to look up the class JTextComponent, which has methods like selectAll(), cut(), setCaretPosition(), and moveCaretPosition().

  • These methods would be a good starting point for finding information on how to highlight a line.

  • You can do this after completing part 5.

  • It is also possible to skip this part of the assignment if you want to and move on to later ones.

Project Part 7

  • *** Make memory editable in the frame so that as execution progresses, if the machine language code in memory is altered, then it is the altered version that is run.

  • This is not supposed to cause any change in the original source file, just change the current state of the machine.

  • This opens up the possibility of using the memory area as an editor and entering programs either by writing them there from scratch, or by copying and pasting from other sources.

  • You can check the Java API documentation for more information on how to do things with a JTextArea.

  • You can do this after completing part 5.

  • It is also possible to skip this part of the assignment if you want to and move on to later ones.

Project Part 8

  • Add save and load options to the menu so that midway through a machine language program run, between button clicks, it would be possible to save the state of the machine to a file and reload it later to continue the run.

  • If the design is suitably object-oriented, serializability should support this.

  • You can do this after completing part 5.

  • It is also possible to skip this part of the assignment if you want to and move on to later ones.

Project Part 9

  • Add a new, second button, which causes a program to run from beginning to end without repeated clicking.

  • Turn this into a threaded application.

  • It should be possible to make more than one copy of the machine, each in its own frame.

  • It should be possible to load and run sumtenV1.txt in multiple frames and see the copies of MISC executing the program in their separate frames at the same time.

  • If things go by so fast that you don’t have time to start a second copy before the first one stops, add a delaying mechanism to the code.

  • You can do this after completing part 5.

Project Part 10

  • Draw a UML diagram for the final version of your code, the version you’re handing in.

  • Notice that this depends on how many of the parts you decided to do.

Project Part Dependency Diagram

  • The diagram given on the next overhead shows the dependency relationships between the different parts of the project.

  • Any given part should only be done if the parts in a direct line before it have already been done.

  • The order for accomplishing things for turning in is linear.

  • You have to turn in parts 1-3 by the first test, parts 4-6 by the second test, and parts 7-10 by the end of the semester.











Part 10 depends on however many parts you chose to implement.

The End

  • Login