[PATCH 1/2] RISC-V: Add ARC-V APEX assembler support

[Silva, Luis]

>> --- a/gas/doc/c-riscv.texi
>> +++ b/gas/doc/c-riscv.texi
>> @@ -265,6 +265,59 @@ Floating point constructors for the bfloat16 type, example usage:
>>       .bfloat16 0b:ffc1
>>  @end smallexample
>>
>> +@cindex @code{.extInstruction} directive, RISC-V

> To me this directive is too long. .extinsn perhaps, or even one of .einsn or
> .xinsn? Otoh ...

>> +@cindex ARC-V APEX instructions
>> +@item .extInstruction @var{name}, @var{opcode}, @var{attrs}@dots{}
>> +Define a dynamic APEX instruction that uses the Custom-0 encoding space.

> ... the ARC-V / APEX aspect isn't encoded at all in the directive name. Some
> other vendor could come up with some different scheme. So maybe .apexinsn?
> Or one of the earlier suggested names, but with a first operand required to
> be "apex" for this variant?

The existing ARC support in binutils already has a comparable mechanism in place
that serves the same purpose, so this directive name isn’t new.

>> +The @var{name} is the mnemonic used in subsequent assembly.  The
>> +@var{opcode} is the function code (sub-opcode) whose valid range depends
>> +on the format.  The @var{attrs} are a comma-separated list drawn from:
>> +
>> +@table @code
>> +@item XD
>> +XD format (3 register operands, 8-bit sub-opcode, range 0--255).
>> +@item XS
>> +XS format (2 registers + 8-bit signed immediate, 6-bit sub-opcode,
>> +range 0--63).
>> +@item XI
>> +XI format (1 register + 12-bit signed immediate, 5-bit sub-opcode,
>> +range 0--31).
>> +@item XC
>> +XC format (1 register acting as both destination and source +
>> +12-bit signed immediate, 5-bit sub-opcode, range 0--31).

> What's the difference between XI and XC? The description says "compressed"
> for the latter, but the encoding space needed (without the major opcode)
> is 5 + 12 + 5 = 22, i.e. way beyond 16 bits. That's really no different
> from XI. What am I missing?

Indeed, "compressed" was the wrong term here; XC is not a 16-bit compressed
instruction.

The difference is that XI has no source register, while XC uses the destination
register as an implicit source register.  Therefore XI has 2 operands
(`rd`, `imm`), whereas XC behaves as 3 operands (`rd/rs1`, `imm`).

>> +@item void
>> +Omit the destination register from the operand list.
>> +@item no_src0
>> +Omit the first source register from the operand list.
>> +@item no_src1
>> +Omit the second source register (or immediate) from the operand list.
>> +@end table
>> +
>> +Exactly one of @code{XD}, @code{XS}, @code{XI}, or @code{XC} must be
>> +specified.  @code{XS} and @code{XC} may be combined;

> This contradicts the first sentence. That earlier sentence would better be
> written to avoid such a contradiction, e.g. "With one exception, eaxctly
> one ...".

Good point. The current wording is contradictory: "Exactly one" conflicts with
the later statement that XS and XC may be combined.  I'll rephrase it to make the
exception explicit.

>> in that case the
>> +assembler uses the XS encoding when the destination and source registers
>> +differ (and the immediate fits in 8 bits), and the XC encoding when the
>> +registers are the same or the immediate requires 12 bits.

> This can't be correct: XC, as per what's said elsewhere, requires RD == RS1,
> and hence the form can't be used when the immediate requires 12 bits but the
> two registers don't match.

You're right, my wording is incorrect.

XC is only valid when RD == RS1.  The intention was to describe selection between
XS and XC based on both register equality and immediate range, but the current
sentence incorrectly suggests XC could be chosen based solely on immediate size.

I'll rephrase this to make the register constraint explicit and ensure XC is
only used when RD == RS1.

>> +Examples:
>> +
>> +@smallexample
>> +     .extInstruction myalu, 1, XD
>> +     myalu a0, a1, a2
>> +
>> +     .extInstruction myimm, 5, XS
>> +     myimm a0, a1, 42
>> +
>> +     .extInstruction myflex, 3, XS, XC
>> +     myflex a0, a1, 10
>> +     myflex a0, a0, 1000
>> +@end smallexample
>> +
>> +The assembler emits metadata about each @code{.extInstruction} into
>> +ELF sections named @code{.riscvapex.@var{fmt}.@var{custom0}.@var{opcode}},
>> +which the disassembler reads to reconstruct instruction names and
>> +operand formats.

> So these sections exist solely for the disassembler's convenience? I.e.
> them getting stripped (or them not being understood) isn't a functional
> issue?

Yes, the metadata is for disassembler/debugger use.  Without it,
execution is unaffected; only recognition of the dynamically defined
instructions is lost.

Regards,
Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260605/f48f554d/attachment-0001.htm>