There was typo in my last line
It is
I do *NOT* 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))
On Thu, Nov 1, 2018 at 9:37 PM Abhishek Singh <
abhishek.singh199...@gmail.com> wrote:
> 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
