hi
i need some help on how to start writing a step method for MIPS, where the step method executes a single MIPS instruction using the current program counter, or up to n instructions if a count is given and also prints a disassembled version of each instruction executed and displays the contents of non-zero registers once all instructions have been executed.
could anyone give me some help
thanks
> i need some help on how to start writing a step method for MIPS
void step() {
/* implementation goes here */
}
If you have a more specific question, let us know.
~
> i need an idea on how to actually step the
> instructions!
Just take things one small step (haha) at a time. Break your program down into very small chunks. Example:void step() {
displayCurrentInstruction();
executeCurrentInstruction();
}
void step(int numberOfSteps) {
setStepCount(numberOfSteps);
startStepping();
}
void startStepping() {
while (moreSteps()) {
step();
}
displayNonZeroRegisters();
}
void displayCurrentInstruction() {
// implementation goes here...
}
void executeCurrentInstruction() {
// implementation goes here...
}
void displayNonZeroRegisters() {
// implementation goes here...
}
void setStepCount(int numberOfSteps) {
// implementation goes here...
}
boolean moreSteps() {
return false; // TODO revise and test
}
~
> how do i get the current instruction that is running?
However you wish, depending on the implementation. There's no universal way to "get the current instruction". If you wish a more specific answer, you'll want to provide some more detail. If you're confused about the assignment, your best bet would be to confer with your instructor.
~
i have to load a file "filename.mips " which will contain instructions, depending on what it does, i have to write the step method, where the user could enter a number to step instructions.
this is part of the code below:
public static void main (String args[]) {
// Set up to read from standard input
BufferedReader inReader = new BufferedReader(new InputStreamReader(System.in));
// Process commands from standard input
String inLine;
String[] toks;
try {
// Read lines of commands from standard input until end of file
while ((inLine = inReader.readLine()) != null) {
// Remove unnecessary spaces and split into tokens at spaces
inLine = inLine.trim();
toks = inLine.split("\\s+",2);
if (toks.length == 0) {
// Ignore blank command lines
} else if (toks[0].startsWith("ex")) {
// exit : Exit program
break;
} else if (toks[0].startsWith("lo")) {
// load : load a MIPS program
if (toks.length != 2) {
System.out.println( "Filename expected" );
} else {
// Filename is forst argument
filename = toks[1];
if (filename.startsWith("\"")) {
filename = filename.substring(1);
if (filename.endsWith("\"")) {
filename = filename.substring(0, filename.length()-1);
// Load memory from MIPS file
loadMIPSFile (filename);
} else {
System.out.println( "Filename must be enclosed in quotes" );
}
} else {
System.out.println( "Filename must be enclosed in quotes" );
}
}
} else if (toks[0].startsWith("du")) {
// dump : dump progarm in MIPS memory
dumpMIPSProgram ();
} else {
// Unknown command encountered
System.out.println( "Unknown command: " + inLine );
}
}
} catch (IOException e) {
System.out.println("IO exception occurred");
}
}
You might want to consider the Command pattern. http://en.wikipedia.org/wiki/Command_pattern (beware some US universities don't allow you to list Wikipedia as your source of information) Create a MIPSCommandInterface with a method "void execute()". For each type of instruction implement this interface in a separate class. If you have parameters to your instructions, pass them to the constructor. Parse your MIPS file and for each instruction create an Instruction object and add it to a list of instructions. When you need to step through the code start iterating through the list.
MIPSen and ARMs. I like them both. I guess the OP needs to write a
MIPS simulator which can run zero or more instructions given some
simulated memory (int[] mem comes to mind).
From my head: every MIPS instruction is 32 bits wide (hence the int[])
and contains a 6 bit opcode in the bits 31 ... 26. Then either three
registers are specified, a shift count and function designator are defined
or two registers and a 16 bit immediate value or a 26 bit jump value.
This format is extremely easy to decode. (only 64 different instructions).
Basically a 'step' takes the following actions:
1) fetch an instruction
2) decode it
3) increment PC
4) execute it
I don't think the OP needs to implement a simulated deep pipeline.
This is a very nice assignment, my compliments to the instructor.
kind regards,
Jos
> > I guess the OP needs to write a MIPS simulator
> which can run zero or more instructions given some
> simulated memory
>
> That's what it sounds like to me. It also sounds a
> lot like a Z-machine emulator I've been working on in
> my nonexistent spare time. :o)
You mean: [url=http://en.wikipedia.org/wiki/Z_machine]this Z machine[/url]?
I did that one on my hp50g calculator lately (it has an ARM processor
and it's programmable in C)
kind regards,
Jos ;-)
> > You mean: this Z machine?
>
> Haha, no! I mean [url=http://en.wikipedia.org/wiki/Z-machine]this one[/url].
Hey, that's cute; I like those text adventure games but never knew there
existed a special VM for them. Maybe I can code that machine up for my
new hp50g calculator too ;-)
> Yawmark (<- it's all about the height of that little horizontal bar)
and the amount of gravity, don't forget gravity ;-)
kind regards,
Jos
> That all depends on how you implemented your MIPS' memory.
Jos,
I may be wrong, but after a second look at all the tokenizing and whatnot in this thread, I think the OP is dealing with a list of assembly instructions rather than the actual binary. That's a bit different than my earlier position, of course.
~
> I may be wrong, but after a second look at all the
> tokenizing and whatnot in this thread, I think the
> OP is dealing with a list of assembly instructions
> rather than the actual binary. That's a bit different
> than my earlier position, of course.
Looking at the commands, it would seam that they are commands to the machine, rather than the instruction codes (Load program, dump memory and the like rather than fiddle_with_memory_at, branch_if etc)
> > That all depends on how you implemented your
> MIPS' memory.
>
> Jos,
>
> I may be wrong, but after a second look at all the tokenizing and
> whatnot in this thread, I think the OP is dealing with a list of assembly
> instructions rather than the actual binary. That's a bit different than my
> earlier position, of course.
Dunno; the OP has to be more clear; reading the OP's reply #6 s/he
just started implementing some simple form of JCL that can load a
MIPS image and maybe there should be a command to start the
actual simulated machine.
Maybe we should just sit and wait for the OP to elaborate ;-)
kind regards,
Jos(now where's that fridge? ;-)
> hey
> first what does op mean?
OP == Original Poster, i.e. you in this topic.
>
> second i am dealing with instructions like:
> lui $1,
> ori $2, $1, 4
Yes I know, but do you have to deal with those instructions in text form?
If so you have to write an assembler too. If not, you just have to write the
simulator.
kind regards,
Jos
hi
i already have an assembler, the code i have got is here:
http://www.filesend.net/download.php?f=120431a37ef7ffad620a68d32359135d
the file that i have to read are here:
http://www.filesend.net/download.php?f=2f2b4cf8697972e39c1758819596f45b
to give u a better view
> > If so you have to write an assembler too.
>
> Could he not just interpret the instructions directly
> rather than, say, encoding/decoding the instructions?
Sure, but parsing that text makes up for most of an assembler. The
actual encoding of those bits is just a minimal additional effort.
IMHO interpreting thos instructions over and over again is not the way
to go.
kind regards,
Jos
> IMHO interpreting thos instructions over and over
> again is not the way to go.
I don't think so either, from a practical standpoint. But creating an assembler may well exceed the scope of the assignment and instruction. Of course, it may not as well. Heck, it may even be worth extra credit. I just draw up short on the phrase "have to".
~
> > IMHO interpreting thos instructions over and
> over
> > again is not the way to go.
>
> I don't think so either, from a practical standpoint.
> But creating an assembler may well exceed the scope
> of the assignment and instruction. Of course, it may
> not as well. Heck, it may even be worth extra credit.
> I just draw up short on the phrase "have to".
IMHO from what the OP (incompletely) sketched I find it a fun assignment.
But then again, the OP hasn't even decided yet about the memory model,
i.e. int[] or byte[] or whatever.
MIPSen and ARMs are fun ;-)
kind regards,
Jos
> hey dat wasnt me who posted on da other forum it was my m8, can
> you suggest ne code tho, to help wid the step method?
Can you elaborate then on the format of those simulated instructions first?
Are they just binary numbers (bits) or do you have to interpret
text representations of them? I'm afraid noone can help you any further
before you've clarified a few technical details first.
kind regards,
Jos (m8?)
> they are methods to change the registers e.g. add $2,
> 2 means put 2 into register 2
Once again: what is that file all about? Does it contain just bits as in
an image of a MIPS memory piece? Is it a Serialized file containing
Commands that execute those single instructions? You have to be a
bit more accurate if you want us to be able to help you. Can you show
a bit of such a file?
kind regards,
Jos
> it contains instructions that the MIPS simulator
> program will execute.
Yes, that we already knew but what is the *format* of those instructions
in your ".mips" file? Is it text representing the assembly code of those
instructions or is it a binary file containing an image of your mips memory?
kind regards,
Jos
> it's text representing the assembly code of the instructions.
Well, prepare for a lot of work then: as I wrote in a previous reply you
have to write at least the parser part of an assembler. Whether or not
you generate actual machine code (and IMHO that would be the way
to go) is up to you.
Next you have to interpreted that generated machine code or the
parsed instructions on the fly so you must implement a mips processor
model (32 registers, its behaviour etc).
Maybe there are some free mips assemblers available; if so you can
have a jump start because all you have to do then is implement the
mips processor model, i.e. the actual simulator.
good luck and
kind regards,
Jos
ps. nice but complicated assignment.
