Quoting Nilay Vaish <[email protected]>:
On Wed, 22 Jun 2011, Gabriel Michael Black wrote:
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.
Does that mean it is not possible to define a new two byte opcode
with the first byte being something other than 0x0F? As I scanned
through the file two_byte_opcodes.isa, I felt all the opcodes are in
use, though the AMD's manual shows that many combinations are invalid.
--
Nilay
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Yes, that's correct. If it doesn't start with a 0x0F, there isn't any
way to tell if it's the start of a two byte opcode or just a one byte
opcode by itself. You might want to reconsider using an immediate, but
I wouldn't be -that- surprised if there was somewhere you could fit a
single opcode and get away with having an immediate. If I get a chance
I'll look for a spot, although I can't promise anything.
Gabe
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
