On Wed, 22 Jun 2011, Gabriel Michael Black wrote:
Quoting Nilay Vaish <[email protected]>:
On Tue, 21 Jun 2011, Gabe Black wrote:
The size of the immediate pulled in by IMMEDIATE is always the same
since it's the uint64_t "immediate" field of the x86 ExtMachInst. The
predecoder decides how to fill it, and it uses the tables in
src/arch/x86/predecoder_tables.cc for that. You have to use a particular
size for all instructions with the same main opcode bytes (aka it can't
change based on opcode extensions). Thankfully x86 -almost- follows this
rule, and the one exception I'm aware of is hardcoded into the
predecoder. Assuming you're grabbing a top level opcode and not doing
anything tricky, you should be able to just adjust the ImmediateType
table and get what you want. Some of the immediate types change size
based on the effective operand size, I believe, but there are also ones
that are fixed. That's determined by the SizeTypeToSize table.
Gabe
On 06/21/11 15:10, Gabriel Michael Black wrote:
I'll have to look through the code again, but you should be able to do
that. I don't have time to look at it right now, but I'll try to
sometime soon.
Gabe
Quoting nathan binkert <[email protected]>:
You'll have to find out from Gabe :) Hopefully he's reading.
Nate
The current implementation of the pseudo instructions make use of the
immediate value to figure out which pseudo instruction to execute. This
means that I cannot make use of the same opcode. So, I have to add a
new
one. I have made the following additions to two_byte_opcodes.isa file.
+ 0x0E: decode OPCODE_OP_TOP5 {
+ 0x00: decode OPCODE_OP_BOTTOM3 {
+ format BasicOperate {
+ 0x4: newinst({{
+ PseudoInst::dosomethingnew(xc->tcBase(),
IMMEDIATE);
+ }}, IsNonSpeculative);
+ default: M5InternalError::error(
+ {{"Unexpected instruction opcode!"}});
+ }
+ }
+ }
This compiles, but I am not sure of the width of the IMMEDIATE field
in this
case. How can I ensure that the immediate field has a length, say,
32-bits.
Change in predecoder_tables.cc
//For two byte instructions
{ //LSB
// MSB 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F
+/* 0 */ 0 , 0 , 0 , 0 , WO, 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , QW,
BY ,
If I am adding a new opcode, where all do I need to make changes? Are the
changes to the decoder and to predecoder_tables.cc enough? It seems they
are not. With these changes, the simulator panics --
panic: Unrecognized/invalid instruction executed:
{
leg = 0,
rex = 0,
op = {
num = 1,
op = 0xe,
prefixA = 0,
prefixB = 0
},
modRM = 0,
sib = 0,
immediate = 0,
displacement = 0
dispSize = 0}
@ cycle 3558500
[invoke:build/X86_SE/arch/x86/faults.cc, line 278]
Memory Usage: 1151536 KBytes
They should be. The instruction it dumped is a one byte instruction, not the
two byte instruction you're attempting to add if I remember correctly. You
may have not encoded your instruction correctly, or you're changes to the
decoder aren't correct. If you end up offset in the stream of incoming
instruction memory (too few, too many immediate bytes, etc.) you'll probably
end up decoding junk after that.
Also note that the simulator is complaining that you tried to execute an
undefined instruction which could very easily be your program's fault and not
gem5's.
int main()
{
asm (".byte 0x0F\n\t.byte 0x04\n\t.long 0x5c");
asm (".byte 0x0E\n\t.byte 0x04\n\t.long 0x5c");
return 0;
}
This is the program that I am making use of. Since the first instruction
executes correctly (it does what I expect it to do), I expect that the
program is correct. So, the problem has to be with the changes I have made
to the decoder. I also noticed that the decoding of a two byte op is
actually done as a prefix + opcode and not as opcode alone. Is this
intentional?
{
leg = 0,
rex = 0,
op = {
num = 2,
op = 0x4,
prefixA = 0xf,
prefixB = 0
},
modRM = 0,
sib = 0,
immediate = 0x5c,
displacement = 0
dispSize = 0}
Thanks
Nilay
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
