[llvm-dev] Encoding an X86 format with long operands

[Craig Topper via llvm-dev]

Hi Gus,

When you say "n byte destination" you mean you want to encode an n byte
address as a constant within the instruction? That would mean you couldn't
encode an address that comes from a register.

~Craig

On Tue, Mar 20, 2018 at 9:48 AM, Gus Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all.
>
> tl;dr: I would like to add a long x86 instruction which doesn't conform to
> any existing format that I know; I'm not sure where to start.
>
> I am attempting to add an instruction into X86, to be simulated in gem5.
> I've already added a simple, opcode-only instruction which I can
> successfully decode and run in gem5, so I am roughly familiar with .td
> files and how backends are built out of them.
>
> My goal now is to make a more complex instruction -- specifically, I need
> to add large operands. The format would look something like this:
>
>    - 1 byte opcode (0x06, which I hijacked from PUSHES, which isn't
>    implemented in gem5)
>    - n byte destination (memory location)
>    - n byte source (memory location)
>    - n byte source (memory location or  immediate)
>
> If n=4, then the total opcode length is 13 bytes, which is under the 15
> byte x86 limit.
>
> As far as I know, this doesn't conform to any existing x86 format. Because
> that's the case, I'm not sure how to go about encoding an instruction like
> this; presumably, I can't use the existing I<..> class, which is what I'd
> used previously.
>
> Can anyone point me in the general direction of what I will need to do to
> encode this rather arbitrary instruction format? Should I look into
> implementing a new Instruction class? Is there an easier way?
>
> Thanks,
> Gus Smith, PSU
>
> _______________________________________________
> LLVM Developers mailing list
> 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/20180320/e6e4ca80/attachment.html>