Quoting Nilay Vaish <[email protected]>:
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
The program is not correct. 0x0F means the instruction has a two byte
opcode, and 0x0E is a one byte opcode by itself. It encodes the push
%es instruction which is invalid in 64 bit mode which is why gem5 is
(correctly) making it fault.
When decoding a two byte opcode, the first byte is just a boring
prefix (0x0F) and doesn't need to be decoded. Most of the things the
decoder is doing are intentional. If it couldn't decode two byte
opcodes correctly it would be very, very broken.
Gabe
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
