[llvm-dev] New x86 instruction with opcode 0x0F 0x7A

Tue Dec 12 08:12:06 PST 2017

Hi Craig,
I'm assuming much or all of this information isn't written up in documentation anywhere, or you would have provided a link.
Would you be willing to write some kind of how-to-write-instruction-definitions overview?  Or even if it's specific to X86, I suspect that would still be helpful to people writing private targets (seems to happen a lot).
Just a thought… thanks,
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Craig Topper via llvm-dev
Sent: Monday, December 11, 2017 4:18 PM
To: Barbora Murinová
Cc: llvm-dev
Subject: Re: [llvm-dev] New x86 instruction with opcode 0x0F 0x7A

Adding these to X86InstrInfo.td or any other X86Instr*.td should pretty much do it.

def MYINSTRrr : I<0x7A, MRMSrcReg, (outs VR64:$dst), (ins VR128:$src), "myinstrmnemonic\t{$src, $dst|$dst, $src}", []> PS;
def MYINSTRrm : I<0x7A, MRMSrcMem, (outs VR64:$dst), (ins f64mem:$src), "myinstrmnemonic\t{$src, $dst|$dst, $src}", []> PS;

Replace MYINSTR and myinstrmnemonic with the name of your instruction.

Since CVTPS2PI has a form that reads memory and a form that reads a register you need to do define two instructions for LLVM. The MRMSrcReg and MRMSrcMem distinguish the difference for the assembler and disassembler to know how to map the operands to the ModRM byte. There are also MRMDestReg and MRMDestMem for instructions that have store behavior instead of load.

The 0x7A is from your chosen opcode of 0x0F 0x7A. The 0x0F is specificed implicitly as part of the PS at the end of the line. PS means its on the "two byte opcode map"where the first byte is 0x0F. The PS further implies that there is no 0xF2/0xF3/0x66 prefix emitted with this instruction. But if you had one of those prefixes in front of 0x0F 0x7A it should not decode to this instruction. This is probably used by most SSE instruction that has a packed single precision floating point type. And most MMX instructions.

The "ins" and "outs" list specify the inputs and outputs of the instructions and their types. VR64 means 64-bit Vector Register (aka. MM0-MM7), VR128 is a 128-bit Vector Register (XMM0-XMM15). f64mem means it reads a 64-bit floating point location. There are also f128mem, i128mem, f256mem, i256mem, etc.

The string with "myisntrmnemonic" is the string for the assembler to match. The names prefixed with dollar sign correspond to the names in ins and outs. So that they can me matched correctly and allow arbitrary orders. The curly braces indicate alternatives for at&t and intel syntax. at&t put destination on the right of the operand list. Intel syntax puts destination first. The | character in the middle separates the two orders.

The empty square brackets normally define an instruction selection pattern, but since you only mentioned inline assembly you can leave it empty.

let me know if you have any questions.

~Craig

On Mon, Dec 11, 2017 at 9:14 AM, Barbora Murinová via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi all,

I'm trying to simulate an extended x86 architecture on gem5 with several new instructions. My hardware setup is done and now I'd like llvm to accept the existence of the new instruction passed in inline assembly and output the correct opcode and registers. I chose the two-byte opcode 0x0F 0x7A and I would like the instruction to have the same operands and return values as CVTPS2PI instruction.

I have found this link (https://llvm.org/docs/ExtendingLLVM.html) which claims "Before you invest a significant amount of effort into a non-trivial extension, ask on the list" so that's what I'm doing. I would like to know which of the solutions would work in my case and what's the easiest way to achieve my goal.

Thank you very much!

--
----------------
Barbora Murinová
The University of Edinburgh
SK: +421905718390<tel:+421%20905%20718%20390>
UK: +447477833795<tel:+44%207477%20833795>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/2ab096bd/attachment-0001.html>