Hello Gabe,
Thanks for your help, just to verify what I have understood from your
explanation is, to add new instruction which behaves like MOV
I just need to take care of using proper operands(Gb,Eb), and *REX(Prefix)
will be taken care automatically*.
>From available opcodes in two_byte.isa, I have chosen 6c, 6d, 7c, and 7d.
for example to implement
6c:New_mov(Eb,Gb)
I just add following line it in two_byte.isa file
""
0x0D: decode LEGACY_DECODEVAL {
// no prefix
0x0: decode OPCODE_OP_BOTTOM3 {
{
0x4: NEWMOV(Eb,Gb);
}
}
""
And just duplicate function by changing name in "
insts/general_purpose/data_transfer/move.py" and "microops/ldstop.isa"
So if I create binary for "41 0f 6c 03" (for NEWMOV (%r11),%al)
I do have to worry for "41" in "41 0f 6c 03" (41 is used for Extension of
r/m field, base field, or opcode reg field(reference:
http://ref.x86asm.net/coder64.html))
Is this correct?
Best regards,
Abhishek
On Thu, Nov 1, 2018 at 6:25 PM Gabe Black <gabebl...@google.com> wrote:
> Hi Abhishek. In x86, and in gem5 in general but particularly in x86,
> decoding happens in two steps. The predecoder reads in the bytes which are
> in memory and applies context to them (operating mode, various global
> settings like address sizes) and translates them into a canonical structure
> called an ExtMachInst. In x86, that step gathers up all the prefixes,
> opcode bytes, etc., and stores them in the ExtMachInst. When an instruction
> is specified in the decoder, it has some parameters which specify what
> format its operands come in. That's useful if the basic functionality of
> the instruction is the same, but in different scenarios it uses register
> indices from different parts of the encoding for instance. If that flavor
> of operand is defined to include bits from the REX prefix, then that will
> be factored in when that instruction is set up. The format of those
> specifiers is modeled after an encoding you'll find in the AMD architecture
> manuals where it serves a similar purpose, and you can look at that to get
> an idea of what a particular specifier means.
>
> If you use the same operand suffixes as regular mov does (for instance
> Ev,Gv), then your mov should get its arguments in the same way. For
> reference, E means that operand may be a register or a memory location
> based on the ModRM byte, and G means the "reg" field of modRM. The small v
> means to use the effective operand size.
>
> Gabe
>
> On Thu, Nov 1, 2018 at 9:51 AM Abhishek Singh <
> abhishek.singh199...@gmail.com> wrote:
>
>> Hello Everyone,
>>
>> I wanted to introduce a new implementation for Mov Instruction using R11
>> register, my new opcodes are placed in two_byte.isa and I have duplicated
>> 'mov' functionality present in files move.py and ldstop.isa.
>>
>> My question is: I understand how to decode opcode for example if the new
>> opcode is '0x11'
>> take top 5 bits and then 3 bits to write a case function in two_byte.isa
>>
>> I am not understanding, how should I make sure it uses REX format same as
>> MOV?
>>
>>
>> For example:
>> In the case of 8 bits:
>>
>>
>> *41* 8a 03 mov (%r11),%al
>>
>> *41* 0f xx 03 new_mov (%r11),%al
>>
>> In the case of 16*: *
>>
>> *66 41* 8b 03 mov (%r11),%ax
>>
>> *66 41* 0f xx 03 new_mov (%r11),%ax
>>
>>
>> In the case of 32*: *
>>
>> *41* 8b 03 mov (%r11),%eax
>>
>> *41* 0f xx 03 new_mov (%r11),%eax
>>
>>
>> In the case of 64*: *
>>
>> *49* 8b 03 mov (%r11),%rax
>>
>> *49* 0f xx 03 new_mov (%r11),%rax
>>
>> ***Numbers in bold are REX bits, xx are new opcodes.
>>
>> Gabe or anyone who has any information on this?
>>
>>
>> Best regards,
>>
>> Abhishek
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
