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

[Jan Beulich]

On 25.05.2026 15:30, Luis Silva wrote:
> --- 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 @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?

> +@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 ...".

> 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.

> +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?

Jan