Ulrik_Lindblad
asked on
Instruction decoder
Hi all,
I am planning to do some generic processor simulator, and one of the tasks that always
will occur is an instruction decoder. Now, if creating a processor simulator for a fairly
complexed processor I want ALL parts of it to be quite fast (sometimes we are talking
hours for a single simulation). So - to start with - lets talk about the decoder.
Lets say that we have a processor with 2 registers that is supporting only 2 (!) instructions
(dont care about the details, it is the principle that is important):
Registers:
==========
REG1
REG2
Instructions:
=============
ADD S,D with opcode "0sd"
SUB S,D with opcode "1sd"
Register decoding:
==================
s = 0 -> S = REG1
s = 1 -> S = REG2
d = 0 -> D = REG2
d = 1 -> D = REG1
So in this case the possible instructions encountered in a program would be:
Opcode 000: ADD REG1,REG2
Opcode 001: ADD REG1,REG1 (2*REG1)
Opcode 010: ...
.
.
Opcode 100: SUB REG1,REG2
.
.
And so on...
And now to the discussion. How would this be implemented in a fast way? (consider an instruction
set with up to 80 instructions, opcodes 24 bits (or even more for VLIW architectures)). One should
be able to gain something because of the fact that every opcode corresponds to an unique instruction
(and it's arguments).
Even though quite memory consuming, I (or rather - a program that I will write in that case)
am thinking about doing an explicit enumeration, so that - at run-time - decoding of an intruction will
only be a simple (and therefore fast?) table lookup (that will be indexed using the opcode,
and that will return a function pointer to the "instruction" (that in C++ of course will
be implemented as a function) to be run. Is this a good idea do you think? And in that case, which
container should I use?
std::map <int, InstrExecFunc*> ? (The mapping of an opcode (represented in some datatype) to an "int" need
in that case only to be done once, before the actual execution (simulation) starts, so it will add no overhead
(or even, I create it once and then store it - in some way - as a part of the program)).
Thoughts, ideas suggestions?
Another question, anyone has experience of simulating fixed point arithmetics? I am having problems choosing
representation that allows me to simulate, for example, a ripple carry adder that will set condition codes
and stuff like that. I was in a project where we did this in C, and then we represented data as arrays of
chars, but there should be faster and better ways I think. Ideas? URL's?
Cheers,
/Ulrik
I am planning to do some generic processor simulator, and one of the tasks that always
will occur is an instruction decoder. Now, if creating a processor simulator for a fairly
complexed processor I want ALL parts of it to be quite fast (sometimes we are talking
hours for a single simulation). So - to start with - lets talk about the decoder.
Lets say that we have a processor with 2 registers that is supporting only 2 (!) instructions
(dont care about the details, it is the principle that is important):
Registers:
==========
REG1
REG2
Instructions:
=============
ADD S,D with opcode "0sd"
SUB S,D with opcode "1sd"
Register decoding:
==================
s = 0 -> S = REG1
s = 1 -> S = REG2
d = 0 -> D = REG2
d = 1 -> D = REG1
So in this case the possible instructions encountered in a program would be:
Opcode 000: ADD REG1,REG2
Opcode 001: ADD REG1,REG1 (2*REG1)
Opcode 010: ...
.
.
Opcode 100: SUB REG1,REG2
.
.
And so on...
And now to the discussion. How would this be implemented in a fast way? (consider an instruction
set with up to 80 instructions, opcodes 24 bits (or even more for VLIW architectures)). One should
be able to gain something because of the fact that every opcode corresponds to an unique instruction
(and it's arguments).
Even though quite memory consuming, I (or rather - a program that I will write in that case)
am thinking about doing an explicit enumeration, so that - at run-time - decoding of an intruction will
only be a simple (and therefore fast?) table lookup (that will be indexed using the opcode,
and that will return a function pointer to the "instruction" (that in C++ of course will
be implemented as a function) to be run. Is this a good idea do you think? And in that case, which
container should I use?
std::map <int, InstrExecFunc*> ? (The mapping of an opcode (represented in some datatype) to an "int" need
in that case only to be done once, before the actual execution (simulation) starts, so it will add no overhead
(or even, I create it once and then store it - in some way - as a part of the program)).
Thoughts, ideas suggestions?
Another question, anyone has experience of simulating fixed point arithmetics? I am having problems choosing
representation that allows me to simulate, for example, a ripple carry adder that will set condition codes
and stuff like that. I was in a project where we did this in C, and then we represented data as arrays of
chars, but there should be faster and better ways I think. Ideas? URL's?
Cheers,
/Ulrik
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: Salte
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Tinchos
EE Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: Salte
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Tinchos
EE Cleanup Volunteer
ASKER
Thanks for the comments Alf! I am realizing, though, that I have not been clear enough when explaining what I want
(or maybe it s like aways: "I don't really know WHAT I want" =) ). I will get back to you with a better explanation on what I mean with "generic" (I am going
for a dinner tonight (as if you were interested... =) ))later, and I think you (and others) really can give me some
really good feedback and good ideas. As for now: thanks again, "talk" to you later!
/Ulrik