how to handle conflicting/overlapping ISA encodings with custom instruction extensions

348 views
Skip to first unread message

Guy Lemieux

unread,
Apr 11, 2018, 8:37:46 AM4/11/18
to RISC-V ISA Dev
This question may seem a bit out there.... but given the flexibility
of RISC-V, should we prepare for the eventuality where there are
multiple *custom* instruction set extensions that have conflicting ISA
encodings?

Will this ever happen in practise? Well, I can imagine two scenarios...

Scenario1: As a CPU designer, I may have developed two different
custom instruction set extensions, possibly version 1 and version 2,
or possibly just type A and type B (different application domains),
and I want them both to co-exist on my future RISC-V cores. However, I
know they won't ever be used at the same time, and so to keep my ISA
encoding as compact as possible, I want a way to "switch" between
using these two extensions.

Scenario2: Extending this a bit further, perhaps a CPU vendor wants to
create as general of a piece of silicon as possible, and support
multiple different custom instruction extensions by different third
parties. These may come from multiple/conflicting/different proposals
for bit manipulation, for example, such as one which comes from
BigCompanyA, while another that comes from CommunityProposalB, and a
third that comes from MedCompanyC.

It *is probably* reasonable to assume that once a process is launched,
it cannot switch between these. Or, if it does switch, the cost of
switching may be very high (complete pipeline+cache flush+more).

If someone can make a case that *rapid* change is necessary, where we
switch ISA subsets on the fly (possibly followed by a FENCE), then
this should also be considered.

Should we consider an official generic way to select among these
possibilities? or is it already part of the CSSRs? (sorry but I
haven't studied CSSRs at all)

Thanks,
Guy

Liviu Ionescu

unread,
Apr 11, 2018, 8:55:18 AM4/11/18
to Guy Lemieux, RISC-V ISA Dev
On 11 April 2018 at 15:37:46, Guy Lemieux (glem...@vectorblox.com) wrote:

> or is it already part of the CSSRs? (sorry but I
> haven't studied CSSRs at all)

Do you mean custom CSRs? Please note that support for CSRs in existing
development tools is already problematic, and the more you abuse them
with custom usage, the more problems you'll have.


Regards,

Liviu

Guy Lemieux

unread,
Apr 11, 2018, 8:58:13 AM4/11/18
to Liviu Ionescu, RISC-V ISA Dev
> Do you mean custom CSRs? Please note that support for CSRs in existing
> development tools is already problematic, and the more you abuse them
> with custom usage, the more problems you'll have.

I'm sure it can be done with custom CSRs. However, I was wondering if
we should standardize the approach taken so this becomes the
non-custom part, and thereby allows things like OSs to do a proper
context switch even if it isn't aware of the actual purpose of the CSR
in use.

I haven't thought this idea through too much... but wanted to ask
opinions before I totally forgot about it...

Guy

kr...@berkeley.edu

unread,
Apr 11, 2018, 10:34:21 AM4/11/18
to Guy Lemieux, RISC-V ISA Dev

>>>>> On Wed, 11 Apr 2018 05:37:03 -0700, Guy Lemieux <glem...@vectorblox.com> said:
| This question may seem a bit out there.... but given the flexibility
| of RISC-V, should we prepare for the eventuality where there are
| multiple *custom* instruction set extensions that have conflicting ISA
| encodings?

| Will this ever happen in practise? Well, I can imagine two scenarios...

This could certainly happen, as the custom space is expressly designed
not to be regulated.

| Scenario1: As a CPU designer, I may have developed two different
| custom instruction set extensions, possibly version 1 and version 2,
| or possibly just type A and type B (different application domains),
| and I want them both to co-exist on my future RISC-V cores. However, I
| know they won't ever be used at the same time, and so to keep my ISA
| encoding as compact as possible, I want a way to "switch" between
| using these two extensions.

| Scenario2: Extending this a bit further, perhaps a CPU vendor wants to
| create as general of a piece of silicon as possible, and support
| multiple different custom instruction extensions by different third
| parties. These may come from multiple/conflicting/different proposals
| for bit manipulation, for example, such as one which comes from
| BigCompanyA, while another that comes from CommunityProposalB, and a
| third that comes from MedCompanyC.

| It *is probably* reasonable to assume that once a process is launched,
| it cannot switch between these. Or, if it does switch, the cost of
| switching may be very high (complete pipeline+cache flush+more).

| If someone can make a case that *rapid* change is necessary, where we
| switch ISA subsets on the fly (possibly followed by a FENCE), then
| this should also be considered.

| Should we consider an official generic way to select among these
| possibilities? or is it already part of the CSSRs? (sorry but I
| haven't studied CSSRs at all)

It is certainly possible to add a CSR that changes instruction
encoding on the fly. We already have the possibilty of a writable
misa to enable/disable extensions on the fly or to change base ISA.

But you'd want to make sure most common use cases don't need this.
Moving the custom extensions into the standard ISA encoding space,
even if it means 48-bit or longer encodings, is probably preferable to
any kind of dynamic switching in practice. For many custom
extensions, code size is probably not the primary concern, as overall
application's code size will be dominated by all the standard code.

Krste




| Thanks,
| Guy

| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZxocJKFVrF9vaMObm_XV%3D2jdHv97sh8R_yuGOfwP7e94g%40mail.gmail.com.

Guy Lemieux

unread,
Apr 11, 2018, 10:51:08 AM4/11/18
to kr...@berkeley.edu, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 7:34 AM <kr...@berkeley.edu> wrote:


This could certainly happen, as the custom space is expressly designed
not to be regulated.

It is certainly possible to add a CSR that changes instruction
encoding on the fly.  We already have the possibilty of a writable
misa to enable/disable extensions on the fly or to change base ISA.

But you'd want to make sure most common use cases don't need this.
Moving the custom extensions into the standard ISA encoding space,
even if it means 48-bit or longer encodings, is probably preferable to
any kind of dynamic switching in practice.  For many custom
extensions, code size is probably not the primary concern, as overall
application's code size will be dominated by all the standard code.

but if it is unregulated, then collisions can occur, even if using 48b or 64b encodings.

not to mention there may be a deliberate reason for overlap, eg between a vendors own version 1 and 2 of custom extensions, where there may be a mutex incompatibility or a provable non-need to access V1 if V2 is enabled.

plus, embedded systems will want compact code size, so things like dsp/simd/vector encodings should be compact.

(topic change: if we want very compact embedded systems, we also need multi-register save/restore instructions — these will be multicycle in most implementations, but it saves a lot of space in function calls)

Guy

kr...@berkeley.edu

unread,
Apr 11, 2018, 11:16:37 AM4/11/18
to Guy Lemieux, kr...@berkeley.edu, RISC-V ISA Dev

>>>>> On Wed, 11 Apr 2018 14:50:56 +0000, Guy Lemieux <glem...@vectorblox.com> said:
| On Wed, Apr 11, 2018 at 7:34 AM <kr...@berkeley.edu> wrote:
| This could certainly happen, as the custom space is expressly designed
| not to be regulated.

| It is certainly possible to add a CSR that changes instruction
| encoding on the fly.  We already have the possibilty of a writable
| misa to enable/disable extensions on the fly or to change base ISA.

| But you'd want to make sure most common use cases don't need this.
| Moving the custom extensions into the standard ISA encoding space,
| even if it means 48-bit or longer encodings, is probably preferable to
| any kind of dynamic switching in practice.  For many custom
| extensions, code size is probably not the primary concern, as overall
| application's code size will be dominated by all the standard code.

| but if it is unregulated, then collisions can occur, even if using 48b or 64b
| encodings.

standard = regulated

| not to mention there may be a deliberate reason for overlap, eg between a
| vendors own version 1 and 2 of custom extensions, where there may be a mutex
| incompatibility or a provable non-need to access V1 if V2 is enabled.

| plus, embedded systems will want compact code size, so things like dsp/simd/
| vector encodings should be compact.

If you want switchable ISA modes, there is a path through CSRs. But
making this a standard technique will involve regulating the ISA mode
encoding space.

To avoid having two spaces to regulate, probably makes more sense to
have a standard technique for compressing longer instruction encodings
into shorter encodings+ISA mode, i.e., regulate the 48/64bit encoding
space and define a standard way for ISA mode CSRs to map portions of this
encoding space into 32/16-bit encoding spaces (yes, could include
scheme to map 32-bit too into 16-bit space).

Obviously, software stack gets much harder with having to interpret
ISA mode registers.

| (topic change: if we want very compact embedded systems, we also need
| multi-register save/restore instructions — these will be multicycle in most
| implementations, but it saves a lot of space in function calls)

This is a very different topic - please start a new thread.

Krste

| Guy

Guy Lemieux

unread,
Apr 11, 2018, 11:36:22 AM4/11/18
to Krste Asanovic, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 8:16 AM, <kr...@berkeley.edu> wrote:
>
>>>>>> On Wed, 11 Apr 2018 14:50:56 +0000, Guy Lemieux <glem...@vectorblox.com> said:
> | On Wed, Apr 11, 2018 at 7:34 AM <kr...@berkeley.edu> wrote:
> | This could certainly happen, as the custom space is expressly designed
> | not to be regulated.
> | but if it is unregulated, then collisions can occur, even if using 48b or 64b
> | encodings.
>
> standard = regulated

sorry I wasn't clear.

I was saying custom extensions are unregulated, so the likelihood of
collisions is high.

the standard part is regulated by R-V F, so it won't have collisions.

> If you want switchable ISA modes, there is a path through CSRs. But
> making this a standard technique will involve regulating the ISA mode
> encoding space.

yes, this is what I was imagining/proposing.

I'm not sure it's the only method, or the best method, but at least
the mechanism
for switching modes needs to be standardized.

> To avoid having two spaces to regulate, probably makes more sense to
> have a standard technique for compressing longer instruction encodings
> into shorter encodings+ISA mode, i.e., regulate the 48/64bit encoding
> space and define a standard way for ISA mode CSRs to map portions of this
> encoding space into 32/16-bit encoding spaces (yes, could include
> scheme to map 32-bit too into 16-bit space).

I was thinking something like this as well.

Generalizing, we could also make the whole ISA, including "standard"
extensions, swappable.

Thus, you could even upgrade from compressed version C.1 to version
C.2 if you want 20% tighter code savings..... e.g., C.1 may be for
general-purpose code, but C.2 may be an application-specific version
that achieves better results. letting users develop their own 16b -->
32b mappings for optimal code compaction would also be interesting
(designing a compact/feasible 16b-->32b decoder would be subject of
further research, but might look like a RAM or PLA or FPGA).

Guy

Albert Cahalan

unread,
Apr 11, 2018, 2:21:30 PM4/11/18
to Guy Lemieux, RISC-V ISA Dev
> This question may seem a bit out there.... but given the flexibility
> of RISC-V, should we prepare for the eventuality where there are
> multiple *custom* instruction set extensions that have conflicting ISA
> encodings?

Yes. Well, it should be blocked via legal means. Incompatibility is
a disaster for an architecture.

The viability of PowerPC was badly damaged when SPE was
introduced. This was a vector instruction set that was incompatible
with the AltiVec instruction set. Software vendors had to choose,
and typically the choice was "neither". Nobody wants to put in the
effort when there is uncertainty and a market fragmented into
small bits.

Note how Intel did not screw up. When SSE was added, MMX remained.
Software vendors could trust that instructions would be supported.
Both MMX and SSE remain today, in all shipping processors. With very
few exceptions, Intel does not ship chips with missing functionality.
There is a unified software ecosystem.

This goes beyond the instruction set. MMU functionality also matters.
You can add stuff, but then it must be implemented in every future CPU.
You can not take stuff away without harming the architecture.

Guy Lemieux

unread,
Apr 11, 2018, 4:37:23 PM4/11/18
to Albert Cahalan, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 11:21 AM, Albert Cahalan <acah...@gmail.com> wrote:
>> This question may seem a bit out there.... but given the flexibility
>> of RISC-V, should we prepare for the eventuality where there are
>> multiple *custom* instruction set extensions that have conflicting ISA
>> encodings?
>
> Yes. Well, it should be blocked via legal means. Incompatibility is
> a disaster for an architecture.

This isn't about incompatibility -- this is about two different CUSTOM
instruction set extensions being added into the same silicon. There
are blocks of opcode space for these instructions, but inevitably
there will be overlap due to conflict/scarcity.

We can't expect the RISC-V Foundation to allocate these custom blocks
out like radio spectrum... we can expect some degree of
overlap/collisions between independent groups. We can also expect
that, to maximize affordability, silicon should be able to be used in
many different use cases, eg support these independent groups by
having an ISA-select capability.

> The viability of PowerPC was badly damaged when SPE was
> introduced. This was a vector instruction set that was incompatible
> with the AltiVec instruction set. Software vendors had to choose,
> and typically the choice was "neither". Nobody wants to put in the
> effort when there is uncertainty and a market fragmented into
> small bits.

I don't know the full story between SPE and AltiVec... but did any
silicon do both?

> Note how Intel did not screw up. When SSE was added, MMX remained.

Intel also has incredibly complex variable-length instruction set
encoding, and they are a single entity that determines what encoding
will be.

> Software vendors could trust that instructions would be supported.

For general purpose workstations, yes I agree.

For application-specific embedded systems, or dedicated supercomputing
centers, I disagree.

> Both MMX and SSE remain today, in all shipping processors. With very
> few exceptions, Intel does not ship chips with missing functionality.
> There is a unified software ecosystem.

MMX and SSE should die.

AVX is sort of ok, only because vector lengths are getting
interesting, but even in their 3rd generation Intel still got it wrong
-- fixed-length vectors are wrong because they don't scale.

An ISA with variable-length vectors is the only way to go, because
then you don't need to define a whole new ISA every time you want
higher performance.

> This goes beyond the instruction set. MMU functionality also matters.
> You can add stuff, but then it must be implemented in every future CPU.
> You can not take stuff away without harming the architecture.

Sure, but who is still using legacy protected mode or segment
registers with Intel CPUs? Didn't they get rid of those yet? I'm sure
nobody would miss that ....

Guy

Albert Cahalan

unread,
Apr 12, 2018, 12:10:45 AM4/12/18
to Guy Lemieux, RISC-V ISA Dev
On 4/11/18, Guy Lemieux <glem...@vectorblox.com> wrote:
> On Wed, Apr 11, 2018 at 11:21 AM, Albert Cahalan <acah...@gmail.com>
> wrote:

>>> This question may seem a bit out there.... but given the flexibility
>>> of RISC-V, should we prepare for the eventuality where there are
>>> multiple *custom* instruction set extensions that have conflicting ISA
>>> encodings?
>>
>> Yes. Well, it should be blocked via legal means. Incompatibility is
>> a disaster for an architecture.
>
> This isn't about incompatibility -- this is about two different CUSTOM
> instruction set extensions being added into the same silicon. There
> are blocks of opcode space for these instructions, but inevitably
> there will be overlap due to conflict/scarcity.

That sure is incompatibility. That opcode space is asking for disaster.

> We can't expect the RISC-V Foundation to allocate these custom blocks
> out like radio spectrum...

That would partially mitigate the disaster.

>> The viability of PowerPC was badly damaged when SPE was
>> introduced. This was a vector instruction set that was incompatible
>> with the AltiVec instruction set. Software vendors had to choose,
>> and typically the choice was "neither". Nobody wants to put in the
>> effort when there is uncertainty and a market fragmented into
>> small bits.
>
> I don't know the full story between SPE and AltiVec... but did any
> silicon do both?

Due to conflicting opcodes, no silicon did both. Perhaps it would have
been possible to enable one at a time, but that wasn't implemented.

You can't even write a generic PowerPC disassembler. The user
has to specify the variant of the instruction set.

>> This goes beyond the instruction set. MMU functionality also matters.
>> You can add stuff, but then it must be implemented in every future CPU.
>> You can not take stuff away without harming the architecture.
>
> Sure, but who is still using legacy protected mode or segment
> registers with Intel CPUs? Didn't they get rid of those yet? I'm sure
> nobody would miss that ....

I've recently seen three different embedded OSes use segmentation
all over the place. (16-bit segment with 32-bit offset, making a 48-bit
pointer, and thus pushing 5 times for a call to memcpy) These OSes
even use the hardware-based task switching.

So no, Intel can't get rid of all that. Compatibility really matters.

Getting back to PowerPC, the embedded OS developers have not
enjoyed writing piles of low-level MMU code again and again. There
are several completely different MMU designs. The architecture is
hurt by this because OS vendors will not bother to support everything.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 12:29:07 AM4/12/18
to Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Apr 11, 2018 at 3:34 PM, <kr...@berkeley.edu> wrote:

> | Should we consider an official generic way to select among these
> | possibilities? or is it already part of the CSSRs? (sorry but I
> | haven't studied CSSRs at all)
>
> It is certainly possible to add a CSR that changes instruction
> encoding on the fly. We already have the possibilty of a writable
> misa to enable/disable extensions on the fly or to change base ISA.

Ok so that's good to know, that there is precedent for that: I am
presently studying the feasibility of abstracting out the parallelism
from both RVV and RVP, such that (apart from anything) RVV may even
utilise Compressed (16-bit) opcodes as opposed to its present 64-bit
encoding.

The trade-off - which has to be thought through exxxtreeeeeemely
carefully - is to do exactly this: change base ISA depending on bits
in certain CSRs.

l.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 12:55:55 AM4/12/18
to Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 4:16 PM, <kr...@berkeley.edu> wrote:

>>>>>> On Wed, 11 Apr 2018 14:50:56 +0000, Guy Lemieux <glem...@vectorblox.com> said:

> | but if it is unregulated, then collisions can occur, even if using 48b or 64b
> | encodings.
> [...]

> If you want switchable ISA modes, there is a path through CSRs. But
> making this a standard technique will involve regulating the ISA mode
> encoding space.

That's right. This need not be burdensome. Here is the "nightmare scenario":

* custom extremely good ISA 1 uses encoding A
* custom extremely good ISA 2 uses encoding A
* vendor lays down both in the same ASIC
* binary code is encountered with A and the engine has no idea what to do.

iiiif howeverrrrr, the situation was as follows:

* custom vendor 1 registers intent to develop custom extension with
the RISC-V Foundation
* custom vendor 1 receives "IANA-style unique number" from RISC-V Foundation
* custom extremely good ISA 1 uses encoding A HOWEVER....
* AS PART OF THE BASE (not the custom) ISA, it is made ABSOLUTELY
CLEAR that BEFORE this ISA is used, a special (*REGULATED* repeat
*REGULATED*) instruction *MUST* be called:

set-csr-iana-style-custom-unique-isa-number {insert custom vendor 1
unique number here}

compilers may now confidently generate any number of repeated
encodings A, because each usage *must* have had a call to that
iana-style mode-setting instruction with the unique CSR-mode-setting
that unambiguously defines the meaning of the instruction.

in particular it's worth noting that it is *not* necessary to call
that mode-setting instruction prior to *every* use of a custom
instruction. It would be perfectly reasonable to do this (and for
compilers to track it):

set-csr-iana-style {insert custom vendor 1 unique number here}
instruction A # custom vendor 1's "meaning"
standard RV32 instruction
standard RV32 instruction
instruction A' # from the same custom vendor 1
set-csr-iana-style {insert custom vendor 2 unique number here}
instruction A # custom vendor *2*'s "meaning"
instruction A' # from the same custom vendor *2*
standard RV32 instruction
....

The nice thing about this would be that the compiler writers would
know what to expect when it comes to upcoming custom instructions.
Right now, hmmm this hadn't occurred to me until now: vendors that
create custom instructions will be FORCED into the position of
maintaining their own fork of gcc. Without the above *STANDARD*
formal method that is part of the *BASE* RV, the first vendor that
submits patches to gcc basically becomes the de-facto "dominator" of
that encoding. Total chaos and much pain ensues.

l.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 1:00:54 AM4/12/18
to Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Apr 11, 2018 at 4:16 PM, <kr...@berkeley.edu> wrote:

> Obviously, software stack gets much harder with having to interpret
> ISA mode registers.

yyup. more than that: Jacob pointed out that an implementation
without a particular extension will not have the CSR space in which to
store even "emulating" CSRs. thus it becomes necessary to have
some... "blank CSR space" in which to do exactly that. and B-Ext with
which to manipulate it. putting the "blank CSR space" into J-Ext
might not be enough.

l.

Andrew Waterman

unread,
Apr 12, 2018, 1:03:01 AM4/12/18
to Luke Kenneth Casson Leighton, Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
It might've just occurred to you, but it occurred to us a long time ago.  As one of the maintainers of the RISC-V GCC and Binutils ports, I can assert quite confidently that we'll never accept a patch that contributes support for a nonstandard extension.  Not from anyone.  Standardization is a gateway to incorporation into the GNU tools.


l.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 1:16:27 AM4/12/18
to Andrew Waterman, Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
On Thu, Apr 12, 2018 at 6:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:

>> Right now, hmmm this hadn't occurred to me until now: vendors that
>> create custom instructions will be FORCED into the position of
>> maintaining their own fork of gcc. Without the above *STANDARD*
>> formal method that is part of the *BASE* RV, the first vendor that
>> submits patches to gcc basically becomes the de-facto "dominator" of
>> that encoding. Total chaos and much pain ensues.

> It might've just occurred to you, but it occurred to us a long time ago.

*gently*, Andrew. Someone coming in new can't know everything. That
I quickly and independently derived "what you already knew" is a good
sign, as it increases the probability that the decision / analysis
that you did was good, yeah?

Plus, what in effect you're saying is: this really *does* have to be
fixed (by introducing some form of registration of custom extensions),
because it is *guaranteed* that custom extension maintainers will have
to maintain their own separate fork of gcc. We know where that goes:
hell on earth for the organisation that now has to spend more time
forward-porting gcc patches than it does on actually supporting its
customers.

I once did a 1000-line patch to samba in a separate branch (this was
before git). I decided to pull in mainline patches using dirdiff
(developed by paulus). It took a WEEK. I added a few more lines....
couple hours work there. next day tried pulling in more mainline code
patches... another WEEK later...

Bottom line: it is absolutely hopelessly unrealistic to expect custom
vendors to maintain forks of gcc. Linaro was set up *specifically* by
David Rusling, who kindly spent about an hour on the phone with me to
explain why Linaro was established: to stop the situation where
vendors were forced to fork gcc and entire BSPs.

Therefore, logically, this has to be dealt with at the hardware level.

l.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 1:30:24 AM4/12/18
to Guy Lemieux, Krste Asanovic, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 4:35 PM, Guy Lemieux <glem...@vectorblox.com> wrote:
> On Wed, Apr 11, 2018 at 8:16 AM, <kr...@berkeley.edu> wrote:

>> To avoid having two spaces to regulate, probably makes more sense to
>> have a standard technique for compressing longer instruction encodings
>> into shorter encodings+ISA mode, i.e., regulate the 48/64bit encoding
>> space and define a standard way for ISA mode CSRs to map portions of this
>> encoding space into 32/16-bit encoding spaces (yes, could include
>> scheme to map 32-bit too into 16-bit space).
>
> I was thinking something like this as well.

Whilst it appears on the face of it to be sensible, the idea of
regulating the custom ISA space defeats the very freedom and
flexibility of having custom ISA spaces in the first place. It's a
drastic solution that's worse than the problem.

*However*: as a *separate* idea (separate from the "IANA-like custom
registration with RISC-V Foundation" concept) the idea of mapping down
to a smaller encoding space has strong merit... but should *not* be
confused or amalgamated with the "IANA-like" concept.



> Generalizing, we could also make the whole ISA, including "standard"
> extensions, swappable.
>
> Thus, you could even upgrade from compressed version C.1 to version
> C.2 if you want 20% tighter code savings..... e.g., C.1 may be for
> general-purpose code, but C.2 may be an application-specific version
> that achieves better results.

There was that research into RV16 which came up with a whopping 25%
better compression that C, wasn't there?

Sadly, bear in mind (reminder): C as part of the unix ABI standard
makes it completely pointless to consider doing any further research
into alternative Compression, and many other down-sides. This was
discussed in-depth a few months back on sw-dev.

l.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 1:38:37 AM4/12/18
to Albert Cahalan, Guy Lemieux, RISC-V ISA Dev
On Thu, Apr 12, 2018 at 5:10 AM, Albert Cahalan <acah...@gmail.com> wrote:

>> I don't know the full story between SPE and AltiVec... but did any
>> silicon do both?
>
> Due to conflicting opcodes, no silicon did both. Perhaps it would have
> been possible to enable one at a time, but that wasn't implemented.
>
> You can't even write a generic PowerPC disassembler. The user
> has to specify the variant of the instruction set.

Thank you for sharing these insights and stories, Albert, I
appreciate hearing things like this. hmmm, has anyone done a RISC-V
disassembler to make sure that it also does not have the same kinds of
flaws? I appreciate that there's qemu but a disassembler (whose
output could be passed to gcc -S and then disassembled and then passed
to gcc -S as a way to do the same triple-checks that gcc does of
itself) would have additional formal verification uses.

l.

Andrew Waterman

unread,
Apr 12, 2018, 2:24:34 AM4/12/18
to Luke Kenneth Casson Leighton, Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 10:16 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
On Thu, Apr 12, 2018 at 6:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:

>> Right now, hmmm this hadn't occurred to me until now: vendors that
>> create custom instructions will be FORCED into the position of
>> maintaining their own fork of gcc.  Without the above *STANDARD*
>> formal method that is part of the *BASE* RV, the first vendor that
>> submits patches to gcc basically becomes the de-facto "dominator" of
>> that encoding.  Total chaos and much pain ensues.

> It might've just occurred to you, but it occurred to us a long time ago.

 *gently*, Andrew.  Someone coming in new can't know everything.  That
I quickly and independently derived "what you already knew" is a good
sign, as it increases the probability that the decision / analysis
that you did was good, yeah?

The disconnect here is that this mailing list typically has a sober tone, whereas my observation is that when you see a hole (actual or perceived), you jump on it, assume the worst, and editorialize an extrapolation.  Of course I can't expect you to know everything that's happened over the last several years.  But I can also ask that you operate under the assumption that the other participants on this list weren't born yesterday, and perhaps some more subtlety might be appropriate.

kr...@berkeley.edu

unread,
Apr 12, 2018, 2:55:38 AM4/12/18
to Albert Cahalan, Guy Lemieux, RISC-V ISA Dev

By definition, RISC-V won't have incompatible standard extensions.

The whole point of the custom instruction encoding space is that we
don't have to talk about it. All standard tools and OSs should ignore
it.

Krste
| --
| You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
| To post to this group, send email to isa...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CABfYdSqTaedUk-2C%3D-aRSrQDEXAfE%2Boh%3D9DQzZQE%3DjW3wyV8zg%40mail.gmail.com.

Richard Herveille

unread,
Apr 12, 2018, 3:16:26 AM4/12/18
to kr...@berkeley.edu, Albert Cahalan, Guy Lemieux, RISC-V ISA Dev, Richard Herveille

 

 

On 12/04/2018, 08:55, "kr...@berkeley.edu" <kr...@berkeley.edu> wrote:

 

By definition, RISC-V won't have incompatible standard extensions.

 

The whole point of the custom instruction encoding space is that we

don't have to talk about it.  All standard tools and OSs should ignore

it.

 

Agreed. Custom extensions are just that … custom for a particular vendor/device/project/implementation.

Think an FFT or AES engine that gets hooked to the CPU and can be called via a single instruction.

The actual instruction may vary from project/device to project/device.

If someone comes up with a great (set of) instruction(s) that benefits a whole community, it should be proposed as a foundation supported extension.

 

Richard

 

 

Jim Wilson

unread,
Apr 12, 2018, 10:48:51 AM4/12/18
to Luke Kenneth Casson Leighton, Albert Cahalan, Guy Lemieux, RISC-V ISA Dev
On Wed, Apr 11, 2018 at 10:38 PM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> Thank you for sharing these insights and stories, Albert, I
> appreciate hearing things like this. hmmm, has anyone done a RISC-V
> disassembler to make sure that it also does not have the same kinds of
> flaws? I appreciate that there's qemu but a disassembler (whose
> output could be passed to gcc -S and then disassembled and then passed
> to gcc -S as a way to do the same triple-checks that gcc does of
> itself) would have additional formal verification uses.

Objdump can disassemble of course. The objdump testsuite has
testcases to verify that assembling code and disassembling it gives
the right result.

The disassembler needs to know the base architecture, rv32e, rv32i,
rv64i, rv128i, as there are some conflicting encodings between the
base architectures. This info can be obtained from the elf class and
elf header flags. Otherwise, there are no conflicts, but we don't
support any custom extensions currently.

Jim

lk...@lkcl.net

unread,
Apr 12, 2018, 1:36:05 PM4/12/18
to RISC-V ISA Dev, lk...@lkcl.net, acah...@gmail.com, glem...@vectorblox.com


On Thursday, April 12, 2018 at 3:48:51 PM UTC+1, Jim Wilson wrote:
On Wed, Apr 11, 2018 at 10:38 PM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
>  Thank you for sharing these insights and stories, Albert, I
> appreciate hearing things like this.  hmmm, has anyone done a RISC-V
> disassembler to make sure that it also does not have the same kinds of
> flaws?  
Objdump can disassemble of course.

oh duh :) that's a huge relief to know it's covered.

lk...@lkcl.net

unread,
Apr 12, 2018, 1:52:50 PM4/12/18
to RISC-V ISA Dev, lk...@lkcl.net, kr...@berkeley.edu, glem...@vectorblox.com


On Thursday, April 12, 2018 at 7:24:34 AM UTC+1, waterman wrote:


On Wed, Apr 11, 2018 at 10:16 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
On Thu, Apr 12, 2018 at 6:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
 
The disconnect here is that this mailing list typically has a sober tone, whereas my observation is that when you see a hole (actual or perceived), you jump on it, assume the worst, and editorialize an extrapolation.  Of course I can't expect you to know everything that's happened over the last several years.  But I can also ask that you operate under the assumption that the other participants on this list weren't born yesterday, and perhaps some more subtlety might be appropriate.


 Appreciated the feedback, Andrew.  *sigh* mindful of the wise quote "certainty is a pathological state of mind", subtlety is something I find extremely challenging.  Honesty and integrity, no problem.  Formerly and historically, prior efforts on my part to be "subtle" have been clearly so painful to witness by the recipients that people mistake them for disingenuity, sarcasm and more.  So I'm now slightly nervous and don't really know what to do (and would like to be a useful long-term contributor here so have to fix it)  Off-list feedback (from anyone) much appreciated.

l.

lk...@lkcl.net

unread,
Apr 12, 2018, 2:25:09 PM4/12/18
to RISC-V ISA Dev, kr...@berkeley.edu, acah...@gmail.com, glem...@vectorblox.com, richard....@roalogic.com


On Thursday, April 12, 2018 at 8:16:26 AM UTC+1, Richard Herveille wrote:

 

 

On 12/04/2018, 08:55, "kr...@berkeley.edu" <kr...@berkeley.edu> wrote:

 

By definition, RISC-V won't have incompatible standard extensions.

 

The whole point of the custom instruction encoding space is that we

don't have to talk about it.  All standard tools and OSs should ignore

it.

 

Agreed. Custom extensions are just that … custom for a particular vendor/device/project/implementation.

Think an FFT or AES engine that gets hooked to the CPU and can be called via a single instruction.

The actual instruction may vary from project/device to project/device.

If someone comes up with a great (set of) instruction(s) that benefits a whole community, it should be proposed as a foundation supported extension.


 Ok, so the crypto engine is a good example to run with as it may end up being extremely common (insert any other appropriate engine if there is a belief that it is not).  Let's imagine that there's some unregulated china clone of RISC-V, where they go "oo I like that custom crypto extension I found on the internet, it's BSD-licensed, I can do what I like with it, let's drop that in and make a mint!!!"

That then ends up with a *hundred million* units being sold world-wide in various smartphones and tablets as part of the SoC (the story then follows from the example of how Allwinner-based products made it from China across the world).

 After various reverse-engineering efforts someone goes "hang on a minute, that's an unregulated custom extension to RISC_V straight off of github!!" and at *that* point, due to the sheer overwhelming demand for the product, which is now so ubiquitous that the gcc maintainers, u-boot maintainers, linux kernel maintainers and so on receive *overwhelming* numbers of requests to support the custom extension by default that they get absolutely fed up and decide to include it.

 Bear in mind that those people in the software libre community are *not* under the control of the RISC-V Foundation, so that factor has to be catered for as a "likely scenario".

 Repeat this at least twice and the probability of the nightmare PowerPC scenario coming true for RISC-V increases alarmingly.


 So tracing back the chain, the *cause* of the clash can be traced back to the lack of control and clarity in the RISC-V ISA Speciffication regarding custom extensions.

 Standards MUST nail EVERYTHING down if they are to BE Standards, and there must be no wavering.  ALL possibility of ambiguity, conflict and confusion MUST be nailed in a backwards-compatible, forwards-compatible, extensible way.  No exceptions.  This is one thing that, as Albert points out, Intel gets right.

 So I can tell you, *right now*, that the lesson that Albert warns about *will* hit RISC-V - RISC-V will be a FAILURE - if it is not made mandatory that custom extensions be "registered" and given an IANA-like CSR, with an associated instruction to be called to put the processor into that "mode".

 Note that I did not say that the custom extension has to tell the RISC-V what they intend to *do* with that custom extension: they just have to *register* it (and have gcc emit appropriate CSR mode-setting instructions prior to use)

 I do understand that there is a desire for a "hands-off" approach to custom extensions, Krste.  An alternative approach would be to request that the creators of custom extensions be required, by the RISC-V Foundation, *NEVER*, under *ANY* circumstances, to publish their designs or ANY aspect of the custom extension.  not the source code, not the RTL, not the tools, nothing.  However I believe you would agree that that would be unworkable and impractical, and very much against the spirit of RISC-V.  Not least it would have implementors view RISC-V as not to be taken seriously.

 So in comparison to the alternatives, I think you'll find that an IANA-like arrangement would be warmly accepted and welcomed, once it was explained  Precedents include IANA itself, USB IDs, PCIe IDs, and linux kernel MACHINE_IDs.  It's an extremely well-known solution.  The RISC-V Foundation becomes the "atomic transactor" for unambiguity of the ISA under its wing :)

 Writing unambiguous standards is damn hard.  Being *responsible* for them is... an awful lot of work.

 l.

Jacob Bachmeyer

unread,
Apr 12, 2018, 5:33:15 PM4/12/18
to lk...@lkcl.net, RISC-V ISA Dev, kr...@berkeley.edu, acah...@gmail.com, glem...@vectorblox.com, richard....@roalogic.com
lk...@lkcl.net wrote:
> [...]
>
> [... snip nightmare scenario of Chinese vendors appropriating
> CUSTOM-0/CUSTOM-1 opcodes ...]
>
> [... snip plea for "custom extension" registry ...]
>
> So in comparison to the alternatives, I think you'll find that an
> IANA-like arrangement would be warmly accepted and welcomed, once it
> was explained Precedents include IANA itself, USB IDs, PCIe IDs, and
> linux kernel MACHINE_IDs. It's an extremely well-known solution. The
> RISC-V Foundation becomes the "atomic transactor" for unambiguity of
> the ISA under its wing :)

We have this: the mvendorid and marchid CSRs. If we require that any
given implementation can have at most one set of custom opcodes,
determining the custom opcodes available requires merely examining
{mvendorid, marchid} and looking that tuple up in a table.

This could also allow for a database-driven extensible assembler, using
a --targetid=<VENDOR-ID>/<ARCH-ID> parameter to select which custom
mnemonics should be recognized. GCC support is unlikely to be needed
for custom extensions; wrapper functions or inline assembler should be
sufficient.

I do agree, however, that RISC-V binutils should not accept patches for
proprietary exclusive extensions -- if you want the standard tools to
support your extension, even as a custom extension, you *must* permit
anyone to implement compatible support. No claim of exclusivity will be
tolerated.


-- Jacob

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 5:52:18 PM4/12/18
to Jacob Bachmeyer, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Guy Lemieux, Richard Herveille
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Thu, Apr 12, 2018 at 10:33 PM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
> lk...@lkcl.net wrote:
>>
>> [...]
>>
>> [... snip nightmare scenario of Chinese vendors appropriating
>> CUSTOM-0/CUSTOM-1 opcodes ...]
>>
>> [... snip plea for "custom extension" registry ...]
>>
>> So in comparison to the alternatives, I think you'll find that an
>> IANA-like arrangement would be warmly accepted and welcomed, once it was
>> explained Precedents include IANA itself, USB IDs, PCIe IDs, and linux
>> kernel MACHINE_IDs. It's an extremely well-known solution. The RISC-V
>> Foundation becomes the "atomic transactor" for unambiguity of the ISA under
>> its wing :)
>
>
> We have this: the mvendorid and marchid CSRs.

oh superb!

> If we require that any given
> implementation can have at most one set of custom opcodes, determining the
> custom opcodes available requires merely examining {mvendorid, marchid} and
> looking that tuple up in a table.

It's not precisely what I had in mind however as long as the
implementors ensure that if a particular marchid is *absolutely*
guaranteed to be unambiguous with respect to the custom extensions in
it (mapping is "one to one and onto" i think the phrase is), then
whilst it's not precisely what I proposed it's functionally
equivalent...

... for *identifying the custom extensions*... which just leaves one
other bit missing...

> This could also allow for a database-driven extensible assembler, using a
> --targetid=<VENDOR-ID>/<ARCH-ID> parameter to select which custom mnemonics
> should be recognized. GCC support is unlikely to be needed for custom
> extensions; wrapper functions or inline assembler should be sufficient.

indeed it could.

Ok so there is one bit that is missing, here: making sure that gcc
knows that, when two particular custom extensions contain overlapping
extensions are used on the same {VENDORID/ARCHID} machine, they.... oh
damn it doesn't work, does it?

So the issue is: {VENDORID/ARCHID} identifies the *machine*, it
doesn't identify the *custom extension*. As in: one vendor may
license *another company's custom extension*.

So unfortunately it really does have to be that the *custom
extension* needs [atomic, RISC-V-Foundation-controlled] registration,
such that gcc may issue "custom extension NNN instructions about to be
used, please interpret all upcoming binary code A instructions as
being of custom extension type NNN".

Sorry I can't think of an appropriate more compact phrase to describe that.


> I do agree, however, that RISC-V binutils should not accept patches for
> proprietary exclusive extensions -- if you want the standard tools to
> support your extension, even as a custom extension, you *must* permit anyone
> to implement compatible support. No claim of exclusivity will be tolerated.

This is a slightly different issue from the (show-stopping) initial
issue that Guy identified.

l.

Guy Lemieux

unread,
Apr 12, 2018, 6:07:14 PM4/12/18
to Jacob Bachmeyer, lk...@lkcl.net, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Richard Herveille
> We have this: the mvendorid and marchid CSRs. If we require that any given
> implementation can have at most one set of custom opcodes,

Please try to keep an open mind. This is a very strong requirement.
The cost of producing silicon is very high. Hence, it is very likely
that a silicon vendor will produce a multi-capable CPU for different
fabless customers, where each fabless customer has one or more custom
extensions.

I believe we need a way to prevent conflicts among custom extensions.

In this situation, the silicon vendor must produce the mendorid and
marched. The question is whether these values depend upon the silicon
instance itself (single value), or whether they can take on multiple
values (depending upon which custom extension is activated).

So far, Luke's IANA-style numbering is the best way. I'm pretty sure
we can elaborate on that to make it very flexible and still keep it
simple. This will not affect vendors that do not attempt to support
conflicting extensions, so it has zero cost to them (except perhaps
returning 0s for a CSR that might control this switching of
extensions).

> This could also allow for a database-driven extensible assembler, using a
> --targetid=<VENDOR-ID>/<ARCH-ID> parameter to select which custom mnemonics
> should be recognized. GCC support is unlikely to be needed for custom
> extensions; wrapper functions or inline assembler should be sufficient.

I think you're right here. As a single datapoint: VectorBlox has only
modified the assembler.

> I do agree, however, that RISC-V binutils should not accept patches for
> proprietary exclusive extensions -- if you want the standard tools to
> support your extension, even as a custom extension, you *must* permit anyone
> to implement compatible support. No claim of exclusivity will be tolerated.

This is very GPL-like in intensity.

There is a lot of merit to keep the baseline as streamlined and
non-proprietary as possible.

However, there is also a point where even proprietary extensions might
get adopted, if they become popular enough. Still, I think this issue
is a bit off-topic -- the question is whether the ISA needs to support
a *standard* way of switching between conflicting custom instruction
sets.

Guy

Cesar Eduardo Barros

unread,
Apr 12, 2018, 6:48:37 PM4/12/18
to Guy Lemieux, RISC-V ISA Dev
Em 11-04-2018 09:37, Guy Lemieux escreveu:
> This question may seem a bit out there.... but given the flexibility
> of RISC-V, should we prepare for the eventuality where there are
> multiple *custom* instruction set extensions that have conflicting ISA
> encodings?

It will happen. There are four major opcodes reserved for custom
instructions, once the fifth group creates a custom extension using a
major opcode, the pigeonhole principle says there will be a conflicting
encoding.

> Will this ever happen in practise? Well, I can imagine two scenarios...
>
> Scenario1: As a CPU designer, I may have developed two different
> custom instruction set extensions, possibly version 1 and version 2,
> or possibly just type A and type B (different application domains),
> and I want them both to co-exist on my future RISC-V cores. However, I
> know they won't ever be used at the same time, and so to keep my ISA
> encoding as compact as possible, I want a way to "switch" between
> using these two extensions.

Unless these extensions need either a lot of encoding space, or a
restricted encoding space (like filling the gaps within one of the
already allocated major opcodes), it should be simple to keep them
separate. For instance, type A uses the custom-0 major opcode, while
type B uses the custom-1 major opcode.

> Scenario2: Extending this a bit further, perhaps a CPU vendor wants to
> create as general of a piece of silicon as possible, and support
> multiple different custom instruction extensions by different third
> parties. These may come from multiple/conflicting/different proposals
> for bit manipulation, for example, such as one which comes from
> BigCompanyA, while another that comes from CommunityProposalB, and a
> third that comes from MedCompanyC.

The simplest way (and one which is very likely to already be present)
would be to allow enabling and disabling each extension individually,
unless their encoding conflicts (in that case, it should allow chosing
between the alternatives).

> It *is probably* reasonable to assume that once a process is launched,
> it cannot switch between these. Or, if it does switch, the cost of
> switching may be very high (complete pipeline+cache flush+more).

If the switching affects only the decoder, the cost is not that high.
The CSR instructions have the CSR number hardcoded within the
instruction, so the instruction decoder can see it early; when decoding
an instruction which touches a decoder-switching CSR, the decoder can
insert a bubble in the pipeline (through the same mechanism it uses for
an instruction cache miss) until the instruction is retired. The cost
ends up being equivalent to only a pipeline flush.

Of course, if the core caches pre-decoded instructions, it might have to
discard that cache, unless it's tagged with the instruction "mode". And
if the switch turns on/off power/clock to parts of the core, it will
obviously be much more expensive.

> If someone can make a case that *rapid* change is necessary, where we
> switch ISA subsets on the fly (possibly followed by a FENCE), then
> this should also be considered.
>
> Should we consider an official generic way to select among these
> possibilities? or is it already part of the CSSRs? (sorry but I
> haven't studied CSSRs at all)

We already have one for the standard extensions (the MISA CSR). Custom
extensions will probably use a similar mechanism. If you want a generic
way, it could be described in the device tree ("to toggle extension
'riscvfans-bitmanip', use CSR 1234 bit 12").

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 6:50:32 PM4/12/18
to Guy Lemieux, Jacob Bachmeyer, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Richard Herveille
On Thu, Apr 12, 2018 at 11:06 PM, Guy Lemieux <glem...@vectorblox.com> wrote:
>> We have this: the mvendorid and marchid CSRs. If we require that any given
>> implementation can have at most one set of custom opcodes,
>
> Please try to keep an open mind. This is a very strong requirement.

(I hear you. I didn't want to go overboard with the urgency, though.
Relieved you picked up on it).

> The cost of producing silicon is very high. Hence, it is very likely
> that a silicon vendor will produce a multi-capable CPU for different
> fabless customers, where each fabless customer has one or more custom
> extensions.

... and cross-license the same, due to the high development and
testing costs. They're certainly not going to make modifications to
third party RTLs just because there happens to be a conflict. I can't
possibly imagine any third party vendor reacting particularly well to
a request, "hey guys we need you to move those instructions out of
binary encoding space AAAA, because some uncontrollable China vendor
dumped a hundred million units onto the market which uses that
already.... but we're only going to pay you the same $50k as anyone
else does: take it or leave it".

Given that they probably spent upwards of $2m in VC Funding to develop
the extension (*way* more if they also tested it in silicon), they'll
quite reasonably tell such a difficult potential new customer to take
a running jump. nicely, of course.


> I believe we need a way to prevent conflicts among custom extensions.
>
> In this situation, the silicon vendor must produce the mendorid and
> marched. The question is whether these values depend upon the silicon
> instance itself (single value), or whether they can take on multiple
> values (depending upon which custom extension is activated).
>
> So far, Luke's IANA-style numbering is the best way. I'm pretty sure
> we can elaborate on that to make it very flexible and still keep it
> simple.

I thought.. moments after hitting send of course, as you do... that
perhaps allowing vendors to create their own custom extensions
*without* needing to actually register with the RISC-V Foundation, by
utilising the same trick of USB:IDs. once they'd registered the
(unique) VENDOR_ID, of course it then becomes entirely their own
prerogative to use that as a prefix for custom extensions.

Form: {VENDORID}{CUSTOMEXTENSIONID}

Thus the administrative burden on the RISC-V Foundation that I
previously thought was necessary now becomes zero (delegating the
burden of responsibility onto implementors, where it belongs).

The Devil Will Be In The Details.

In the "Parallelism Extension" I raised the same conceptual idea that
you and Krste also raised: conditional decoding of instructions based
on CSRs. It sounds like a really really good solution, and, in light
of the direction that I wanted to explore with the Parallelism
Extension, a huge relief that the same conceptual paradigm was raised.

HOWEVER

It has to be said that several people pointed out their concern as to
the potential impact on the decode phase of instructions for
CSR-dependent decoding. As in: it now becomes necessary to consult
the CSRs on *EVERY* occurrence of binary-encoding AAAA. In the case
of the Parallelism Extension, the idea under discussion was to have a
bit-per-register "hey this register is actually a vector please direct
all enquiries to the *vector* instruction decode engine and pipelines"
which gets *really* interesting and needs a heck of a lot of careful
thought.

So with the cost (increased latency) being potentially quite high at
such a critical part of any implementation, it certainly would not be
practical or desirable to compare against large numbers of bits
{VENDORID}{CUSTOMEXTENSIONID}, consequently it might be necessary to
devise some level of indirection (implementation-specific not
Standards-mandated) that results in a greatly-reduced number of bits
being needed to carry out the required disambiguation.

Anyway. At that point, my knowledge runs out (latency impact on
pipelined architectures). I've asked a source if they could give an
opinion, but if anyone else knows more that would be fantastic to get
a consensus.

Or if anyone else can think of an alternative? My feeling is though
that some sort of globally-unique CSR-derived injection of bits into
the instruction decode phase is inherently unavoidable.

l.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 7:09:36 PM4/12/18
to Cesar Eduardo Barros, Guy Lemieux, RISC-V ISA Dev
On Thu, Apr 12, 2018 at 11:48 PM, Cesar Eduardo Barros
<ces...@cesarb.eti.br> wrote:
> Em 11-04-2018 09:37, Guy Lemieux escreveu:
>>
>> This question may seem a bit out there.... but given the flexibility
>> of RISC-V, should we prepare for the eventuality where there are
>> multiple *custom* instruction set extensions that have conflicting ISA
>> encodings?
>
>
> It will happen. There are four major opcodes reserved for custom
> instructions, once the fifth group creates a custom extension using a major
> opcode, the pigeonhole principle says there will be a conflicting encoding.

Off the top of my head I can think of several: video (lots), crypto
(several vendors will make their own), audio (several), dsps (several
of those), tensors, vectors, 3D GPUs - those are all *categories*
meaning that multiple vendors will at some point want to create their
own custom extension.

One I'd like to look at is a "local memory" extension which puts,
right next to every core, a *small* block of SRAM (64x32 bits) or even
Content-Addressable Memory (really REALLY useful for speech / phoneme
decoding as well as TCP/UDP routing).

Bottom line: it's *gonna* run out of space :)

> Unless these extensions need either a lot of encoding space,

vectorblox is an entire VPU, Guy can probably give some idea, it's
likely of the order of.... fifty? a hundred opcodes?

> The simplest way (and one which is very likely to already be present) would
> be to allow enabling and disabling each extension individually, unless their
> encoding conflicts (in that case, it should allow chosing between the
> alternatives).

the "nightmare scenario" is where there's conflicts, yes. AAAA has
two (or more) meanings.

>> It *is probably* reasonable to assume that once a process is launched,
>> it cannot switch between these. Or, if it does switch, the cost of
>> switching may be very high (complete pipeline+cache flush+more).
>
>
> If the switching affects only the decoder, the cost is not that high. The
> CSR instructions have the CSR number hardcoded within the instruction, so
> the instruction decoder can see it early; when decoding an instruction which
> touches a decoder-switching CSR, the decoder can insert a bubble in the
> pipeline (through the same mechanism it uses for an instruction cache miss)
> until the instruction is retired. The cost ends up being equivalent to only
> a pipeline flush.

Ok, this seems inordinately better than the idea I came up with on
the "Parallelism Extension" exploration, where an entirely new
pipeline phase was conditionally dropped in to the mix.

> Of course, if the core caches pre-decoded instructions, it might have to
> discard that cache, unless it's tagged with the instruction "mode". And if
> the switch turns on/off power/clock to parts of the core, it will obviously
> be much more expensive.

whoops :)

>> If someone can make a case that *rapid* change is necessary, where we
>> switch ISA subsets on the fly (possibly followed by a FENCE), then
>> this should also be considered.
>>
>> Should we consider an official generic way to select among these
>> possibilities? or is it already part of the CSSRs? (sorry but I
>> haven't studied CSSRs at all)
>
>
> We already have one for the standard extensions (the MISA CSR).

ah ha! very cool! precedent [and another area I need to investigate].

thx Cesar.

l.

Cesar Eduardo Barros

unread,
Apr 12, 2018, 7:16:49 PM4/12/18
to Luke Kenneth Casson Leighton, Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
There's a weak precedent for this in Intel's MMX, where the EMMS/FEMMS
instruction should be used when switching between floating point and
SIMD, and in Intel's VZEROUPPER instruction, which should be used when
switching between different kinds of SIMD instructions.

There's also precedent for this in the x86's EFLAGS.DF bit, which shows
the pitfalls of this approach:

- It's state which must be saved and restored when entering the kernel
on an interrupt, and/or switching context to another process;
- It's state which must be saved, initialized, and restored on a Unix
signal handler (see https://lwn.net/Articles/272048/ for what happens
when you get this wrong).

> in particular it's worth noting that it is *not* necessary to call
> that mode-setting instruction prior to *every* use of a custom
> instruction. It would be perfectly reasonable to do this (and for
> compilers to track it):
>
> set-csr-iana-style {insert custom vendor 1 unique number here}
> instruction A # custom vendor 1's "meaning"
> standard RV32 instruction
> standard RV32 instruction
> instruction A' # from the same custom vendor 1
> set-csr-iana-style {insert custom vendor 2 unique number here}
> instruction A # custom vendor *2*'s "meaning"
> instruction A' # from the same custom vendor *2*
> standard RV32 instruction
> ....

In practice, the compiler would insert a call to the mode-setting
instruction at the top of every function which needs the non-default mode.

> The nice thing about this would be that the compiler writers would
> know what to expect when it comes to upcoming custom instructions.
> Right now, hmmm this hadn't occurred to me until now: vendors that
> create custom instructions will be FORCED into the position of
> maintaining their own fork of gcc. Without the above *STANDARD*
> formal method that is part of the *BASE* RV, the first vendor that
> submits patches to gcc basically becomes the de-facto "dominator" of
> that encoding. Total chaos and much pain ensues.

There seems to be some confusion here. First of all, gcc doesn't know
anything about the instruction encodings; that's the job of the
assembler, which comes from a different project (the binutils project).
Besides that, the compiler will not use these instructions by default,
only when directed to do so through its command line flags or function
attributes. Mutually incompatible instruction set extensions can be
added to gcc without any problem, as long as it knows they can't be
enabled at the same time. I see no reason why the first one to be
submitted would win.

Also, there are ways to use custom instructions without gcc knowing
about them. The gcc "inline assembly" syntax was designed for that use
case; it allows one to describe precisely which registers and/or memory
are used by the custom instruction, such that the compiler can use it as
if it were an instruction it knows (in fact, the gcc inline assembly
operand constraint syntax is directly based on gcc's internal machine
description syntax).

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 7:39:22 PM4/12/18
to Cesar Eduardo Barros, Krste Asanovic, Guy Lemieux, RISC-V ISA Dev
On Fri, Apr 13, 2018 at 12:16 AM, Cesar Eduardo Barros
<ces...@cesarb.eti.br> wrote:

> There's also precedent for this in the x86's EFLAGS.DF bit, which shows the
> pitfalls of this approach:

wheww, nice to know that new problems are actually old ones with
history and clear understanding.

>> [...]
>> set-csr-iana-style {insert custom vendor 1 unique number here}
>> instruction A # custom vendor 1's "meaning"
>> standard RV32 instruction
>
> In practice, the compiler would insert a call to the mode-setting
> instruction at the top of every function which needs the non-default mode.

i'm very relieved to learn that there's someone who knows the precise
and relevant details of what I cannot possibly hope to cover in full,
due to the extreme broad and general nature of my expertise. so...
thank you... and also for clarifying about gcc / assembly. i'm
reminded that gcc stands for "gnu compiler *collection*".

l.

Cesar Eduardo Barros

unread,
Apr 12, 2018, 8:01:27 PM4/12/18
to lk...@lkcl.net, RISC-V ISA Dev, kr...@berkeley.edu, acah...@gmail.com, glem...@vectorblox.com, richard....@roalogic.com
Em 12-04-2018 15:25, lk...@lkcl.net escreveu:
>
>
> On Thursday, April 12, 2018 at 8:16:26 AM UTC+1, Richard Herveille wrote:
>
> On 12/04/2018, 08:55, "kr...@berkeley.edu <javascript:>"
Once you postulate a rogue manufacturer, all bets are off. But I fail to
see the issue here; gcc would add it behind a command line option,
u-boot and the kernel would add it behind a kernel config option. The
problematic scenario is on the hardware side: other manufacturers
feeling pressured to include the extension with a compatible encoding.

A crypto engine instruction, by the way, is a bad example, since it's
easy to contain it within a few well-defined and easily-replaced
software subroutines. A good example would be a pervasive instruction
set extension, like SIMD (with auto-vectorising compilers) or bit
manipulation; these tend to be used everywhere.

>  So tracing back the chain, the *cause* of the clash can be traced back
> to the lack of control and clarity in the RISC-V ISA Speciffication
> regarding custom extensions.
>
>  Standards MUST nail EVERYTHING down if they are to BE Standards, and
> there must be no wavering.  ALL possibility of ambiguity, conflict and
> confusion MUST be nailed in a backwards-compatible, forwards-compatible,
> extensible way.  No exceptions.  This is one thing that, as Albert
> points out, Intel gets right.

There's a contradiction here; if a standard nails absolutely everything
down, there's no possibility of forward compatibility of extensibility.
There's a balance between making a standard too rigid or too soft.

>  So I can tell you, *right now*, that the lesson that Albert warns
> about *will* hit RISC-V - RISC-V will be a FAILURE - if it is not made
> mandatory that custom extensions be "registered" and given an IANA-like
> CSR, with an associated instruction to be called to put the processor
> into that "mode".

There are many scenarios where it makes no sense to be able to disable
any extension, be it standard or custom. For instance, a deeply embedded
control processor with a few special-purpose instructions. Disabling and
enabling extensions is more useful for general-purpose CPUs.

>  Note that I did not say that the custom extension has to tell the
> RISC-V what they intend to *do* with that custom extension: they just
> have to *register* it (and have gcc emit appropriate CSR mode-setting
> instructions prior to use)

For many scenarios, forcing the compiler to emit a CSR write on every
function is pointless. Systems where the extension can't be disabled,
systems where the extension is enabled on boot and left enabled,
programs where an initialization routine sets up the extensions, ...

>  I do understand that there is a desire for a "hands-off" approach to
> custom extensions, Krste.  An alternative approach would be to request
> that the creators of custom extensions be required, by the RISC-V
> Foundation, *NEVER*, under *ANY* circumstances, to publish their designs
> or ANY aspect of the custom extension.  not the source code, not the
> RTL, not the tools, nothing.  However I believe you would agree that
> that would be unworkable and impractical, and very much against the
> spirit of RISC-V.  Not least it would have implementors view RISC-V as
> not to be taken seriously.
>
>  So in comparison to the alternatives, I think you'll find that an
> IANA-like arrangement would be warmly accepted and welcomed, once it was
> explained  Precedents include IANA itself, USB IDs, PCIe IDs, and linux
> kernel MACHINE_IDs.  It's an extremely well-known solution.  The RISC-V
> Foundation becomes the "atomic transactor" for unambiguity of the ISA
> under its wing :)
>
>  Writing unambiguous standards is damn hard.  Being *responsible* for
> them is... an awful lot of work.

I see nothing ambiguous about "these opcodes are reserved for your
custom extensions". And requiring registration for custom extensions is
not a good thing. The Debian project (whose Free Software Guidelines
were later adopted as a standard definition for Open Source) has the
"Desert Island Test": if your software cannot be shared by a group of
people on a desert island who have no way of contacting the outside,
it's not free software.

In the same way, if one could not add extensions to RISC-V without
registering them with the foundation, an important part of RISC-V's
freedom would have been lost. And it's that freedom which is RISC-V's
main differential.

Luke Kenneth Casson Leighton

unread,
Apr 12, 2018, 8:51:37 PM4/12/18
to Cesar Eduardo Barros, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Guy Lemieux, Richard Herveille
On Fri, Apr 13, 2018 at 1:01 AM, Cesar Eduardo Barros
<ces...@cesarb.eti.br> wrote:

> Once you postulate a rogue manufacturer, all bets are off.

precisely. one that, due to overwhelming volumes, has to be taken
into consideration. earlier in the thread Krste stated that it would
not be necessary *at all* to take into account custom extensions, on
the basis that gcc (and other tools) would not incorporate custom
extensions. i felt compelled to point out a realistic scenario that
indicated that the RISC-V Foundation is *knowingly* not in control
decisions made by Software Libre developers, and, thus, logically, the
RISC-V Foundation really does have to take that into account, take it
very seriously and mitigate the "threat" to the RISC-V eco-system
accordingly.

> But I fail to see
> the issue here; gcc would add it behind a command line option, u-boot and
> the kernel would add it behind a kernel config option. The problematic
> scenario is on the hardware side: other manufacturers feeling pressured to
> include the extension with a compatible encoding.

and so on. there are many scenarios that lead to the same ambiguous
hell. the litmus test being: can objdump successfully decompile all
and *any* arbitrarily found-somewhere-on-the-internet binaries? if
the answer's "no" then the RISC-V Foundation has unfortunately failed
in its duty and responsibility towards the RISC-V ecosystem (in the
manner outlined by Albert in the POWERPC example that he gave).

> A crypto engine instruction, by the way, is a bad example,

oh :)

> since it's easy
> to contain it within a few well-defined and easily-replaced software
> subroutines. A good example would be a pervasive instruction set extension,
> like SIMD (with auto-vectorising compilers) or bit manipulation; these tend
> to be used everywhere.

ok. very cool. thank you for coming up with a better example.

>> So tracing back the chain, the *cause* of the clash can be traced back
>> to the lack of control and clarity in the RISC-V ISA Speciffication
>> regarding custom extensions.
>>
>> Standards MUST nail EVERYTHING down if they are to BE Standards, and
>> there must be no wavering. ALL possibility of ambiguity, conflict and
>> confusion MUST be nailed in a backwards-compatible, forwards-compatible,
>> extensible way. No exceptions. This is one thing that, as Albert points
>> out, Intel gets right.
>
>
> There's a contradiction here; if a standard nails absolutely everything
> down, there's no possibility of forward compatibility of extensibility.
> There's a balance between making a standard too rigid or too soft.

sorry there was a misunderstanding: the
*backwards/forwards-compatibility* needs to be absolutely nailed to
the floor. successful standards that achieve this include SMB (with
some hilarious screw-ups by various vendors over the years), SATA
(hardware-level and firmware-level speed negotiation), PCIe
(multi-lane negotiation, firmware-level speed negotiation), USB3
(*several* levels of hardware and firmware negotiation).

SD/MMC is a counter-example where they *didn't* get it right, by
trying to remove support for SPI (1-bit) mode in MMC 4... everybody
ignores that because it's harder to rip out the functionality that's
already there, than it is to leave it in. *apart* from that, SD/MMC
is an awesome example of how backwards/forwards-compatibility is
absolutely nailed to the floor. there's even voltage-switching (3.3v
down to 1.8v) and flipping over to DDR, as well as to
differential-pairs *and* backwards-compatibility right down to
25mbit/sec single-lane SPI.

> [...]

>> Writing unambiguous standards is damn hard. Being *responsible* for
>> them is... an awful lot of work.
>
>
> I see nothing ambiguous about "these opcodes are reserved for your custom
> extensions". And requiring registration for custom extensions is not a good
> thing.

in a later message (i notice you're going through the thread....)
you'll see that this was addressed. i hope.

> The Debian project (whose Free Software Guidelines were later adopted
> as a standard definition for Open Source) has the "Desert Island Test": if
> your software cannot be shared by a group of people on a desert island who
> have no way of contacting the outside, it's not free software.
>
> In the same way, if one could not add extensions to RISC-V without
> registering them with the foundation, an important part of RISC-V's freedom
> would have been lost. And it's that freedom which is RISC-V's main
> differential.

Jacob kindly pointed out that RISC-V has a similar Vendor-Mach ID to
USB and PCIe. Also, the linux kernel maintainers similarly have
"MACHINE_ID" registration, all of which *must* be done in an atomic
fashion by some "central authority".

By the "Desert Island Test" in its strictest definition, neither
RISC-V *nor the linux kernel* are software libre, due to the need for
the atomic global registration. However I do get your point.

l.

Cesar Eduardo Barros

unread,
Apr 12, 2018, 10:38:50 PM4/12/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Guy Lemieux, Richard Herveille
Em 12-04-2018 21:51, Luke Kenneth Casson Leighton escreveu:
> On Fri, Apr 13, 2018 at 1:01 AM, Cesar Eduardo Barros
> <ces...@cesarb.eti.br> wrote:
>
>> Once you postulate a rogue manufacturer, all bets are off.
>
> precisely. one that, due to overwhelming volumes, has to be taken
> into consideration. earlier in the thread Krste stated that it would
> not be necessary *at all* to take into account custom extensions, on
> the basis that gcc (and other tools) would not incorporate custom
> extensions. i felt compelled to point out a realistic scenario that
> indicated that the RISC-V Foundation is *knowingly* not in control
> decisions made by Software Libre developers, and, thus, logically, the
> RISC-V Foundation really does have to take that into account, take it
> very seriously and mitigate the "threat" to the RISC-V eco-system
> accordingly.

Here's where we disagree: I don't see it as a threat, but as an
opportunity. You're worried that manufacturers might be "forced" to
implement specific custom extensions, and moreover that these very
popular custom extensions will unavoidably conflict in their encoding.
But for it to reach that point, RISC-V must already be very popular. And
these custom extensions can be used as a prototype for a standard
extension covering the same domain.

If the toolchain developers add support for these custom extensions, so
what? They'll do so even for obscure extensions, and it'll be behind an
option in any case. Support for a custom extension does not hinder
support for another custom extension, or for a future standard extension.

>> But I fail to see
>> the issue here; gcc would add it behind a command line option, u-boot and
>> the kernel would add it behind a kernel config option. The problematic
>> scenario is on the hardware side: other manufacturers feeling pressured to
>> include the extension with a compatible encoding.
>
> and so on. there are many scenarios that lead to the same ambiguous
> hell. the litmus test being: can objdump successfully decompile all
> and *any* arbitrarily found-somewhere-on-the-internet binaries? if
> the answer's "no" then the RISC-V Foundation has unfortunately failed
> in its duty and responsibility towards the RISC-V ecosystem (in the
> manner outlined by Albert in the POWERPC example that he gave).

No, it can't, not even for x86 binaries. That's too high of a bar to clear.

Let's reduce the scope a bit: can it successfuly decompile once you tell
it which subarchitecture it is (x86-32, x86-64, etc)? It still can't, it
gets lost too easily in the instruction boundaries.

So, let's reduce the scope even more: can it successfuly decompile when
the instruction boundary is correct? Not necessarily, the instruction
might be newer than the objdump.

So we see here the limits of objdump: it has to know the instruction,
and it has to know which subarchitecture it's looking at. In RISC-V's
case, the "subarchitecture" includes which custom instructions it has.

(And that's before considering the cases where the documentation doesn't
match the hardware, like the recent issues with UD0/UD1 in the Linux
kernel. These should hopefully be less common with RISC-V.)

>>> So tracing back the chain, the *cause* of the clash can be traced back
>>> to the lack of control and clarity in the RISC-V ISA Speciffication
>>> regarding custom extensions.
>>>
>>> Standards MUST nail EVERYTHING down if they are to BE Standards, and
>>> there must be no wavering. ALL possibility of ambiguity, conflict and
>>> confusion MUST be nailed in a backwards-compatible, forwards-compatible,
>>> extensible way. No exceptions. This is one thing that, as Albert points
>>> out, Intel gets right.
>>
>>
>> There's a contradiction here; if a standard nails absolutely everything
>> down, there's no possibility of forward compatibility of extensibility.
>> There's a balance between making a standard too rigid or too soft.
>
> sorry there was a misunderstanding: the
> *backwards/forwards-compatibility* needs to be absolutely nailed to
> the floor. successful standards that achieve this include SMB (with
> some hilarious screw-ups by various vendors over the years), SATA
> (hardware-level and firmware-level speed negotiation), PCIe
> (multi-lane negotiation, firmware-level speed negotiation), USB3
> (*several* levels of hardware and firmware negotiation).

The backwards/forwards compatibility with custom instructions has been
addressed, by reserving a few of the major opcodes for custom
instruction extensions only. That is: future versions of the RISC-V
standard will not use these major opcodes, so they will not conflict
with custom extensions which used them.

The backwards/forwards compatibility within a custom extension is the
responsibility of the custom extension author.

What you're concerned with is something completely different: conflicts
between different, separately authored, custom extensions. There's no
easy answer for that. The encoding space is unavoidably limited (though
RISC-V has more free encoding space than most), hardware considerations
like the placement of fields within an instruction are important, and
every solution or workaround has a cost, which might not be acceptable
for some applications.

>> [...]
>
>>> Writing unambiguous standards is damn hard. Being *responsible* for
>>> them is... an awful lot of work.
>>
>>
>> I see nothing ambiguous about "these opcodes are reserved for your custom
>> extensions". And requiring registration for custom extensions is not a good
>> thing.
>
> in a later message (i notice you're going through the thread....)
> you'll see that this was addressed. i hope.

Personally, I'd put that information in the device tree: which
extensions are available, with their name (in device tree style, which
combines the vendor within the name) and how to enable/disable each of
them (which CSR and which bit within the CSR, if it's not permanently
enabled). This has the distinct advantage that the operating system does
not need to have a table mapping the architecture ID to the extensions
and their control registers, and therefore an old operating system can
be used with a new processor without losing access to the custom
extensions it already knows.

>> The Debian project (whose Free Software Guidelines were later adopted
>> as a standard definition for Open Source) has the "Desert Island Test": if
>> your software cannot be shared by a group of people on a desert island who
>> have no way of contacting the outside, it's not free software.
>>
>> In the same way, if one could not add extensions to RISC-V without
>> registering them with the foundation, an important part of RISC-V's freedom
>> would have been lost. And it's that freedom which is RISC-V's main
>> differential.
>
> Jacob kindly pointed out that RISC-V has a similar Vendor-Mach ID to
> USB and PCIe. Also, the linux kernel maintainers similarly have
> "MACHINE_ID" registration, all of which *must* be done in an atomic
> fashion by some "central authority".
>
> By the "Desert Island Test" in its strictest definition, neither
> RISC-V *nor the linux kernel* are software libre, due to the need for
> the atomic global registration. However I do get your point.

The difference is that it's not legally mandated. If I'm stuck in a
desert island, I can use any machine ID I want, and won't face any legal
repercussion for doing so when I get back to civilization.

Also, AFAIK the machine ID is much less important nowadays, since the
configuration is no longer done using board files (keyed by the machine
ID), instead it's done through the device tree. The ARM machine ID is a
relic from the old days.

Jacob Bachmeyer

unread,
Apr 12, 2018, 11:01:59 PM4/12/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Guy Lemieux, Richard Herveille
Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Thu, Apr 12, 2018 at 10:33 PM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> [...]
>>
>> This could also allow for a database-driven extensible assembler, using a
>> --targetid=<VENDOR-ID>/<ARCH-ID> parameter to select which custom mnemonics
>> should be recognized. GCC support is unlikely to be needed for custom
>> extensions; wrapper functions or inline assembler should be sufficient.
>>
>
> indeed it could.
>
> Ok so there is one bit that is missing, here: making sure that gcc
> knows that, when two particular custom extensions contain overlapping
> extensions are used on the same {VENDORID/ARCHID} machine, they.... oh
> damn it doesn't work, does it?
>
> So the issue is: {VENDORID/ARCHID} identifies the *machine*, it
> doesn't identify the *custom extension*. As in: one vendor may
> license *another company's custom extension*.
>

The database can store aliases? Or some form of "this instruction is
available on this list of {vendor-id, arch-id} tuples"? It still holds,
as long as any particular {vendor-id, arch-id} identifies an
implementation with a non-overlapping set of custom instructions. The
"same" instruction could even have different encodings on different
target machines.

>> I do agree, however, that RISC-V binutils should not accept patches for
>> proprietary exclusive extensions -- if you want the standard tools to
>> support your extension, even as a custom extension, you *must* permit anyone
>> to implement compatible support. No claim of exclusivity will be tolerated.
>>
>
> This is a slightly different issue from the (show-stopping) initial
> issue that Guy identified.

It is still an important policy and the Foundation, as maintainers of
the official binutils port and the hypothetical custom opcode database,
is in a position to enforce it. I highly doubt that the GNU project
would object to such a policy.


-- Jacob

Jacob Bachmeyer

unread,
Apr 12, 2018, 11:20:49 PM4/12/18
to Guy Lemieux, lk...@lkcl.net, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Richard Herveille
Guy Lemieux wrote:
>> We have this: the mvendorid and marchid CSRs. If we require that any given
>> implementation can have at most one set of custom opcodes,
>>
>
> Please try to keep an open mind. This is a very strong requirement.
> The cost of producing silicon is very high. Hence, it is very likely
> that a silicon vendor will produce a multi-capable CPU for different
> fabless customers, where each fabless customer has one or more custom
> extensions.
>
> I believe we need a way to prevent conflicts among custom extensions.
>

Such a vendor could ensure that the various extensions do not conflict,
or could arrange for each customer to get only their own extensions.

> In this situation, the silicon vendor must produce the mendorid and
> marched. The question is whether these values depend upon the silicon
> instance itself (single value), or whether they can take on multiple
> values (depending upon which custom extension is activated).
>

Having different "strappings" for the same nearly-identical silicon,
that activate different extensions (or different encodings ...) and are
set at fabrication-time would solve this problem, while also isolating
the extension sets (and customers) from each other.

> So far, Luke's IANA-style numbering is the best way. I'm pretty sure
> we can elaborate on that to make it very flexible and still keep it
> simple. This will not affect vendors that do not attempt to support
> conflicting extensions, so it has zero cost to them (except perhaps
> returning 0s for a CSR that might control this switching of
> extensions).
>

We already have IANA-style numbering for vendor and arch IDs.

>> This could also allow for a database-driven extensible assembler, using a
>> --targetid=<VENDOR-ID>/<ARCH-ID> parameter to select which custom mnemonics
>> should be recognized. GCC support is unlikely to be needed for custom
>> extensions; wrapper functions or inline assembler should be sufficient.
>>
>
> I think you're right here. As a single datapoint: VectorBlox has only
> modified the assembler.
>

Thank you.

>> I do agree, however, that RISC-V binutils should not accept patches for
>> proprietary exclusive extensions -- if you want the standard tools to
>> support your extension, even as a custom extension, you *must* permit anyone
>> to implement compatible support. No claim of exclusivity will be tolerated.
>>
>
> This is very GPL-like in intensity.
>
> There is a lot of merit to keep the baseline as streamlined and
> non-proprietary as possible.
>

An instruction, fundamentally, is a mathematical operation "named" by a
number (the encoding). Permitting exclusive claims to *math* is
outrageous. I suggest no requirement to publish an implementation, only
that the official RISC-V binutils adopt a policy of never supporting any
extension for which anyone claims a right to prevent someone else from
producing an independent implementation that also understands those
instructions. This is also a "ring fence" around potential bad actors
who might try to claim exclusive ownership of the CUSTOM-0/CUSTOM-1
opcodes, which are specifically intended as a sort of "RFC1918" space
for implementation-defined instructions, or any other part of the RISC-V
encoding space.

> However, there is also a point where even proprietary extensions might
> get adopted, if they become popular enough. Still, I think this issue
> is a bit off-topic -- the question is whether the ISA needs to support
> a *standard* way of switching between conflicting custom instruction
> sets.
>

For the nuance, I believe that proprietary instructions should be
allowed, but will receive no support whatsoever from the official RISC-V
binutils. (Since the current policy is no support at all for custom
instructions, I am actually advocating a more-permissive policy.) I
would suggest that waiving any claims to exclusive ownership of any part
of the RISC-V encoding space be a requirement for using the RISC-V
trademark, however.

A bad actor might be able to make such a claim under some bizarre
theory, but would then be prohibited from calling their product
"RISC-V", thus protecting RISC-V from such claims.


-- Jacob

Jacob Bachmeyer

unread,
Apr 12, 2018, 11:28:48 PM4/12/18
to Luke Kenneth Casson Leighton, Cesar Eduardo Barros, RISC-V ISA Dev, Krste Asanovic, Albert Cahalan, Guy Lemieux, Richard Herveille
Luke Kenneth Casson Leighton wrote:
> On Fri, Apr 13, 2018 at 1:01 AM, Cesar Eduardo Barros
> <ces...@cesarb.eti.br> wrote:
>
> [...]
>
>
>> The Debian project (whose Free Software Guidelines were later adopted
>> as a standard definition for Open Source) has the "Desert Island Test": if
>> your software cannot be shared by a group of people on a desert island who
>> have no way of contacting the outside, it's not free software.
>>
>> In the same way, if one could not add extensions to RISC-V without
>> registering them with the foundation, an important part of RISC-V's freedom
>> would have been lost. And it's that freedom which is RISC-V's main
>> differential.
>>
>
> Jacob kindly pointed out that RISC-V has a similar Vendor-Mach ID to
> USB and PCIe. Also, the linux kernel maintainers similarly have
> "MACHINE_ID" registration, all of which *must* be done in an atomic
> fashion by some "central authority".
>
> By the "Desert Island Test" in its strictest definition, neither
> RISC-V *nor the linux kernel* are software libre, due to the need for
> the atomic global registration. However I do get your point.
>

Assuming our intrepid band has somehow constructed a fab on their desert
island, they do have an option fully conformant to the spec: hardwire
mvendorid and marchid to zero. No communication with the outside world
is needed. (Although if they can build a fab, they can probably build
radios...)


-- Jacob

lk...@lkcl.net

unread,
Apr 12, 2018, 11:44:26 PM4/12/18
to RISC-V ISA Dev, lk...@lkcl.net, kr...@berkeley.edu, acah...@gmail.com, glem...@vectorblox.com, richard....@roalogic.com, ces...@cesarb.eti.br
 so how would gcc support two custom extensions where the exact same encoding is required *in the same executable* because the vendor has licensed two custom RTLs that require the exact same encoding to represent their instructions? (it's not as non-sensical a question as it sounds).
 
So we see here the limits of objdump: it has to know the instruction,
and it has to know which subarchitecture it's looking at. In RISC-V's
case, the "subarchitecture" includes which custom instructions it has.

  ok so there are subtleties of objdump that I wasn't aware of which cloud the point I was making.  Then the question perhaps should be rephrased, "can qemu be programmed to be capable of supporting all and any custom extensions" and if not ....
 
The backwards/forwards compatibility with custom instructions has been
addressed, by reserving a few of the major opcodes for custom
instruction extensions only.

 it *hasn't* been addressed, in the specific case of where a vendor wishes to license two (or more) RTLs from two (or more) different vendors, each of which utilises the exact same encoding AAAA to mean totally different things.

would you agree that it is hopelessly unrealistic to expect the providers of those custom extensions to *rewrite* them, given the cost of developing and testing them?

how is this *specific* scenario to be handled?


What you're concerned with is something completely different: conflicts
between different, separately authored, custom extensions.

yes.
 
There's no easy answer for that.

that's the purpose of the discussion that guy raised: to creatively explore such options.  various branches of the discussion ruled out several misunderstandings along the way (and raised some interesting creative possibilities), but yes, agreed: it's not easy.
 
The encoding space is unavoidably limited (though
RISC-V has more free encoding space than most), hardware considerations
like the placement of fields within an instruction are important, and
every solution or workaround has a cost, which might not be acceptable
for some applications.

plus, due to the very nature of custom extensions, the complete lack of coordination and centralisation is touted as a *strength* of the freedom... but with no "prefix" - no "scoping" if we are to use c++ or other software language - we end up with the kind of chaos that you get with OpenSCAD, javascript, and other brain-dead languages that fail to provide clear and clean scoping rules.
 
>> I see nothing ambiguous about "these opcodes are reserved for your custom
>> extensions". And requiring registration for custom extensions is not a good
>> thing.
>
>   in a later message (i notice you're going through the thread....)
> you'll see that this was addressed.  i hope.

Personally, I'd put that information in the device tree: which
extensions are available, with their name (in device tree style, which
combines the vendor within the name) and how to enable/disable each of
them (which CSR and which bit within the CSR, if it's not permanently
enabled).

which doesn't work in the case above (vendor licenses two RTLs that utilise the exact same encoding).   wait... yes it might!  ok!  awesome!
 
This has the distinct advantage that the operating system does
not need to have a table mapping the architecture ID to the extensions
and their control registers, and therefore an old operating system can
be used with a new processor without losing access to the custom
extensions it already knows.

yehyeh, no i totally get it.

ok so let's think it through.  topologically it's equivalent to the idea that i suggested:

MISA |= extension1 # sets context "extension 1 encoding enabled"
AAAA # extension 1 meaning of AAAA
ADD r1, r2, r3
MISA &= ~extension1 # disable extension 1
MISA |= extension 2 # sets context "extension 2 encoding enabled"
BBBB # extension 2 meaning of AAAA

yeah that would work!  so, again, the assembler (see, i'm paying attention...) would generate (at the top of each function... _still_ paying attention i hope) the required enable-extension MISA codes.  the *implementation* of that would switch out hardware in the "instruction decode" phase (precedent for that practice has now been set... and implemented... so that's good to know).

my only main concern would be: does enabling or disabling of the extension result in any kind of unpredictable resetting or alteration of the CSRs associated with that extension?  because if so that's going to be Bad.

also: beyond the actual clock-cycles is there a performance penalty for doing the switching?

also... and i saw the discussions about MISA.C... "if the PC is not aligned the unsetting of MISA.C is silently suppressed", that now becomes a problem that's potentially massively exacerbated given that some extensions may *also* be on unaligned boundaries.

so that section of the spec needs to be generalised and clarified.
</