Policy on adding custom instructions/extensions and upcoming Andes RV variants

[Ruinland ChuanTzu Tsai]

Hi Palmer, Alistair and all,

As RISC-V platforms thrives, there are many custom instructions appear
like bamboo shoots.

We, the Andes Technology, has been determined to contribute our RISC-V
platform into QEMU upstream, namely our Linux-capable AE350 platform
and our A series RISC-V CPU core product line, which we have already
upstreamed our U-Boot an OpenSBI port.

Some of our efforts get ratified into standard extension, just as the
P-Extension has made its way. And there are still many other
enhancement/additions to original extensions - -
Our odyssey on optimizing code size and branch performance ends up as
our very own "Andes Extended Instructions" and "Advanced CoDense™
technology." Both of them are the bedrock which makes our customers
have delightful experience on transisting into RISC-V ecosystem. [1]

We firmly believe by making them accessible to the public could benefit
each other from many perspectives.

Somehow, as we dive deeply to the current code base, we have some
issues which we would like to inquire with the community first and
ask around if there are prior discussions.

That is, we are curious about how QEMU regards on adding new
instructions/extensions, and to be more specific, the upcoming
"-Xandes" CPU variants ?

The existing extensions/instructions are now listed in :
`target/riscv/*.decode`.

If a new extension gets ratified, then it won't be a problem for us just
to add its instructions into corresponding decode file.
Nonetheless, what if we want to add some custom instructions that are
widely adopted custom standards ?

Since we cannot disclose too much at this time being, let's take
CV32E40P, a.k.a. RIS5Y, from PULP Platform as an example, it has been
taped out by NXP as RV32M1 and they are publicly available. The
implementation has Post-Incrementing Load &Store Instruction[1],
and some of them are landed as enhancement to vanilla RV32I - -

p.lb  rD, rs2(rs1)
p.lbu rD, rs2(rs1)
......

they have the same opcode as ordinary lb,lh ... (000 0011).

What will be the most desired way for QEMU upstream to encompass such
feature ?

Will it be suitable to just add them into `insn32.decode` and use
definition guard at compile time to toggle such feature or should there
be a duplicated new decode file which end up as a new decoder for 
decode_opc() to invoke and gets setup during QEMU startup ?

And to be aggressive, if ones made modification on the existing opcode
encoding, duplicating decode file seemed to be inevitable ?

Certainly, these might be too detailed to ask before we put our code
here. Still we would like to know the policy first so we can cooperate
more smoothly.

Cordially Yours,
Ruinland ChuanTzu Tsai

[1] https://www.andestech.com/en/products-solutions/andestar-architecture/
[2] https://pulp-platform.org/docs/ri5cy_user_manual.pdf (Section 14.1.2)