用Java / C / C ++创建MIPS机器

Question

Hey everyone I'm in an Assembly Language and Computer Organization class. Recently I got an assignment that requires that I create a program that emulates a MIPS machine in Java, C, or C++.

The program reads hex from a ASM file and stores the lines in an array. Then it is supposed to emulate the MIPS machine.

I've been searching all around but have no idea how to even start. Does anyone have some ideas or even pseudo-code to get me on the right path?

An example of the file to be read:

24080019
2409001e
240a0023
01094020
010a4020
00082021

If anyone can just get me started down the right path that would be fantastic, thanks!

Answer 1

The first thing you need to do is to learn to decypher those instructions.

It appears they're 8 hex digits. This is nice, because MIPS instructions are 32 bits long. (a hex digit is 4 bits, of course.)

So each line in the file cooresponds to one instruction.

Look at the format of instructions here: http://www.d.umn.edu/~gshute/spimsal/talref.html

You need to keep track of a few registers inside the machine. (You know what the MIPS registers are, right?)

Then you need to determine what the operations do, and what registers they effect.

Answer 2

SPIM might be a good place to start looking at how such a program might be constructed. It's a MIPS32 simulator.

Answer 3

So basically your program will be a loop that reads one instruction (one line in the input file)*, and alters its variables in the same fashion the instruction would alter its registers.

This would be a big "switch case" on the opcode, and for each case you handle the particular instruction.

The variables of your program would basically be your registers, and you will also have to simulate a memory somehow (you should be able to allocate your whole memory once and for all as a big chunk of memory that you will handle) and to handle the translation from the MIPS addresses to addresses in your chunk of memory.

Then dealing with the opcodes is basically a question of altering your registers and your memory. You might be able to benefit from your language to do some operations (like sum, product, ...) but you'll most certainly have to handle a bit more than this: set the flags in your status register for instance.

I'm not familiar with MIPS instruction set, but you might also have to do some address translation depending on the available addressing modes.

*: Actually, it should be more clever than just reading the input file line by line: you should load your program in that "memory" array first, and handle a program counter that will start at the first instruction and be incremented after handling the current instruction. Sometimes, the flow might move the PC back. Ideally you'd also want to make this part of the "memory" unmodifiable, but it's not what you want to focus on first.

I hope I didn't say anything irrelevant to MIPS.

So in terms of structure, this pseudo-code gives an idea:

set all your register variables to their default value
allocate memory for the "memory"
load your program in the "memory"
for (initialize PC ; ??? ; PC"++")
{
    read the "memory" at the address in PC -> opcode
    switch (opcode)
    {
        case op1:
            handle_op1(); // modify registers and/or "memory", set status register
        break;
        [...]
    }
}

Answer 4

I did something like this many years ago as a coursework. Unfortunately, sources didn't survive, so I'll try to put together some general ideas which I remember. I hope it will help you with your project.

First and most simple - register block. I did it as a plain structure. For flag register(s) I created few set/clear functions for the sake of convenience.

Second and probably requiring most effort - instruction decoding. I had a handbook on my target CPU instruction set which explained meaning of different bits in the binary code. There are normally few basic classes of the instructions: arithmetic/boolean operations, control flow instructions, memory/register copying/exchange and probably a couple of others. Another aspect is how the operands are addressed by an instruction. In general there are 2 operands and addressing of each of them is encoded in the binary command. So to interpret them you need two things:

• a set of handler functions covering all variations of all instruction classes which will do the actual job (ie - modify your machine state);
• and some instruction selector function which will take next binary command at Program Counter (PC) or Instruction Pointer (IP), prepare it for execution on your "machine" (for example, decide that it's an addition operation, extract argument value(s) from memory), call a corresponding handler function and adjust PC/IP after the call. Here you can also print a nice human-readable assembly instruction along with command's bytecode and its address.

Third - memory. This depends on the target architecture. In my case there were no segments/selectors and the max memory amount was small, so I've just allocated a corresponding block. To access concrete memory cells I added a set/get functions. Some areas of the memory were supposed to be taken by ROM, so this thin layer was helpful to implement it.

Forth - I/O and interrupts. And this is where it can get really complicated, depending on the requirements and the platform. The the simplest terminal output can be achieved by dedicating a memory block for some sort of screen buffer. When your mem-setter function sees a write to that block, it updates your console emulation (you need a GUI in your app, right?). A simplest console input will also resemble a 8086 architecture - when user presses a key you emulate an interrupt, pass key code into it etc. If you need something more complex that that, ie real BIOS support with loadable interrupt handlers and/or emulation of some I/O controllers then it will take the same amount of time that you have spent on the previous parts of the machine. So don't delay it to the last week.

Answer 5

You need to think about two issues: mapping the internal state of the emulated machine to variables in your emulator, and executing the code. The first is normally handled by an array for the registers, probably in a struct with various other information: a program counter, a bit map with condition codes (supposing the processor has these---I don't know the MIPS architecture), etc. The second will be either a switch or a table of pointers to functions or functional objects. If the architecture uses different machine instruction formats, this could be a multilevel table. The emulator then reads the "instruction" at the current instruction pointer, then "executes" it by switching on it or using it to index into the table. Over and over, in an endless loop.

Answer 6

This should get you started:

http://www.oberle.org/procsimu-index.html

You would have to customize it for MIPS instruction set.