Reserved space in C.LWSP, is Spike still the golden reference or is it Rocket? was: Re: [isa-dev] RISC-V Memory Consistency Model Update

[Clifford Wolf]

Hi,

On Thu, May 3, 2018 at 3:58 AM, Daniel Lustig <dlu...@nvidia.com> wrote:

This public release also starts the Foundation's 45-day ratification
clock.  The ratification process is described at the following link:
https://workspace.riscv.org/higherlogic/ws/public/workgroup?wg_abbrev=tech

We welcome any feedback you might have, from small typo corrections to
major issues.  Feedback or questions can be sent as a reply to this
message on isa-dev, to me directly, or as a pull request or issue on
the riscv-isa-manual GitHub repo.

This new version of the document changes the behavior of C.LWSP (and some related compressed opcodes) so that now rd=0 is not reserved anymore. Is this also part of the 45-day ratification period?

This is a backwards incompatible change with v2.2 of the ISA spec (which includes v2.0 of the compressed spec).

Spike was also changed now to match the new behavior.

Rocket always implemented the previously incorrect, now correct, behavior.

When I joined RISC-V there used to be two promises:

1. No backwards incompatible changes after the 2.0 release of a spec, and

2. Spike is the executable golden reference.

But now it looks like the spec and spike are changed at will to match whatever Rocket does. I find this a *very* concerning trend.

Here is the change in spike:

https://github.com/riscv/riscv-isa-sim/commit/d336aee08ba9c5715d5d7836a39003e62ee4ada8

Here is the change in the spec:

https://github.com/riscv/riscv-isa-manual/commit/272d038abebe7f006ed7960b522f1e51890bb982

(This also effects C.LQSP and C.LDSP but I personally care more about C.LWSP because I have a processor out there, in silicon, that matches the previous behavior of spike and will now be throwing an illegal instruction exception for something that is now suddenly deemed a valid instruction.)

Is Spike still the "executable golden reference", or is it in fact Rocket and everything else may be changed at any time to match whatever Rocket happens to implement?

(This change also throws away 64 reserved code points in c.lwsp for nothing. I hope nobody ever tells me again that there is not enough compressed encoding space left for the 24 code points that XBitmanip is asking for.)

I am deeply concerned about the direction the RISC-V process seems to be going here. Are we going to build RISC-V processors, or are we building Rocket-compatible processors?

The commit messages claim that this is not a spec change but in fact just clearing up an "ambiguity" in the spec. This is incorrect because spike presumably is the golden reference and the behavior of spike was changed. The whole point of having an executable spec like spike is that it can be used to resolve ambiguities. If clearing up an ambiguity was the goal here, then spike should have change unmodified and the English language spec should have been changed to match spikes behavior. But instead the spec and spike was changed to match Rockets behavior.

regards,

 - Clifford

[Daniel Lustig]

Hi Clifford,

On 5/4/2018 5:28 AM, Clifford Wolf wrote:
> Hi,
>
> On Thu, May 3, 2018 at 3:58 AM, Daniel Lustig <dlu...@nvidia.com> wrote:
>
>> This public release also starts the Foundation's 45-day ratification
>> clock. The ratification process is described at the following link:
>> https://workspace.riscv.org/higherlogic/ws/public/workgroup?wg_abbrev=tech
>>
>> We welcome any feedback you might have, from small typo corrections to
>> major issues. Feedback or questions can be sent as a reply to this
>> message on isa-dev, to me directly, or as a pull request or issue on
>> the riscv-isa-manual GitHub repo.
>>
>
> This new version of the document changes the behavior of C.LWSP (and some
> related compressed opcodes) so that now rd=0 is not reserved anymore. Is
> this also part of the 45-day ratification period?

It is not. This 45 day ratification period is specifically in reference
to the memory consistency model.

What you're referencing is just something that already happened to have been
pushed upstream on riscv-isa-manual before we merged in our memory model
updates on top.

So, I'll let Andrew or someone else answer the rest of your question.

Dan

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[Andrew Waterman]

On Fri, May 4, 2018 at 5:28 AM, Clifford Wolf <cliffor...@gmail.com> wrote:

Hi,

On Thu, May 3, 2018 at 3:58 AM, Daniel Lustig <dlu...@nvidia.com> wrote:

This public release also starts the Foundation's 45-day ratification
clock.  The ratification process is described at the following link:
https://workspace.riscv.org/higherlogic/ws/public/workgroup?wg_abbrev=tech

We welcome any feedback you might have, from small typo corrections to
major issues.  Feedback or questions can be sent as a reply to this
message on isa-dev, to me directly, or as a pull request or issue on
the riscv-isa-manual GitHub repo.

This new version of the document changes the behavior of C.LWSP (and some related compressed opcodes) so that now rd=0 is not reserved anymore. Is this also part of the 45-day ratification period?

This is a backwards incompatible change with v2.2 of the ISA spec (which includes v2.0 of the compressed spec).

Spike was also changed now to match the new behavior.

Rocket always implemented the previously incorrect, now correct, behavior.

When I joined RISC-V there used to be two promises:

1. No backwards incompatible changes after the 2.0 release of a spec, and

2. Spike is the executable golden reference.

Rocket is not a reference implementation.  It is coincidental that Rocket had the behavior that is now specified to be "correct."

Spike is intended to be the reference, until a formal model is formally adopted.  This does not imply that Spike is correct implementation; Spike has bugs sometimes.

When a formal model is formally adopted, it will probably have bugs, too, and those shouldn't imply things about the spec.

But now it looks like the spec and spike are changed at will to match whatever Rocket does. I find this a *very* concerning trend.

Here is the change in spike:

https://github.com/riscv/riscv-isa-sim/commit/d336aee08ba9c5715d5d7836a39003e62ee4ada8

Here is the change in the spec:

https://github.com/riscv/riscv-isa-manual/commit/272d038abebe7f006ed7960b522f1e51890bb982

(This also effects C.LQSP and C.LDSP but I personally care more about C.LWSP because I have a processor out there, in silicon, that matches the previous behavior of spike and will now be throwing an illegal instruction exception for something that is now suddenly deemed a valid instruction.)

Is Spike still the "executable golden reference", or is it in fact Rocket and everything else may be changed at any time to match whatever Rocket happens to implement?

(This change also throws away 64 reserved code points in c.lwsp for nothing. I hope nobody ever tells me again that there is not enough compressed encoding space left for the 24 code points that XBitmanip is asking for.)

I am deeply concerned about the direction the RISC-V process seems to be going here. Are we going to build RISC-V processors, or are we building Rocket-compatible processors?

The commit messages claim that this is not a spec change but in fact just clearing up an "ambiguity" in the spec. This is incorrect because spike presumably is the golden reference and the behavior of spike was changed. The whole point of having an executable spec like spike is that it can be used to resolve ambiguities. If clearing up an ambiguity was the goal here, then spike should have change unmodified and the English language spec should have been changed to match spikes behavior. But instead the spec and spike was changed to match Rockets behavior.

The spec *was* ambiguous!  When we wrote the spec, our intent was that the English was the spec, and the annotations next to the encoding table were shorthand that *helped* express the spec.

For example, C.LUI's description says "C.LUI is only valid when rd !=0 and rd != 2."  There was no analogous text for "C.LWSP is only valid when rd != 0."  My intent in writing the spec was that C.LWSP was valid when rd = 0.  You might say my intent doesn't matter, and that would be a fair criticism.

I assume this discrepancy between the text and the table arose because Krste wrote one and I wrote the other.  I screwed up.  Sorry.

regards,

 - Clifford

--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG5EYeU0xvNX-uRXO%2Bp8%3D_PBEBaSasF6xZ5pOB%2BC%3Dixp5XuVQg%40mail.gmail.com.

[Clifford Wolf]

Hi,

On Fri, May 4, 2018 at 5:39 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

Rocket is not a reference implementation.  It is coincidental that Rocket had the behavior that is now specified to be "correct."

Spike is intended to be the reference, until a formal model is formally adopted.  This does not imply that Spike is correct implementation; Spike has bugs sometimes.

When a formal model is formally adopted, it will probably have bugs, too, and those shouldn't imply things about the spec.

No it won't. That's the whole point.

There will be FORMAL PROOFS that the formal spec is equivalent to a significant number of implementations, including spike. There is already continuous integration set up that weekly runs formal equivalence checks between spike and the MIT formal spec via riscv-formal.

The whole point is to formally verify the same formal spec against so many implementations that even if there is a "bug" in the formal spec, since everyone is provably implementing that spec, we would always keep the behavior in the formal spec stable and change the English language spec to match what the formal spec and all the implementations do.

But if you guys keep changing the spec so it coincidentally matches the one implementation you are working on and therefore break compliance with the cores already formally verified against spike, then at one point people will simply stop following your spec changes and we will have a fragmented RISC-V universe.

 

The spec *was* ambiguous!  When we wrote the spec, our intent was that the English was the spec, and the annotations next to the encoding table were shorthand that *helped* express the spec.

If spike is intended to be an executable spec then no the spec certainly was not ambiguous.

You can't claim both! Logic just doesn't work that way!

Either spike is an executable golden reference, then the spec was not ambiguous. (Maybe wrong, but not ambiguous!)

Or the spec was ambiguous, then spike is not the golden reference.

You simply can not have it both ways!

Also: The spec not matching your intent does not automatically make the spec ambiguous. The spec can simply deviate from your intent in an unambiguous way. And I would claim that this is the case here.

For example, C.LUI's description says "C.LUI is only valid when rd !=0 and rd != 2."  There was no analogous text for "C.LWSP is only valid when rd != 0."  My intent in writing the spec was that C.LWSP was valid when rd = 0.

There are three places in the english language spec that touch on this.

(1) The text in the "Load and Store Instructions" section in the C extension chapter.

(2) The table in the "Load and Store Instructions" section in the C extension chapter.

(3) The table in the "RVC Instruction Set Listings" section in the C extension chapter.

And in addition to that

(4) The reference implementation in Spike.

Of those (2), (3), and (4) all agreed that C.LWSP with rd=0 is an illegal instruction, and (1) simply did not mention a valid range for rd at all.

I think the main question at this point is not what you or Krste intended when writing the spec.

The main question instead should be, how would have an implementer understood that spec. And I think it is pretty clear that someone who has not access your internal thought processes would have clearly understood the spec as C.LWSP with rd=0 being an illegal instruction. After all, it is stated that way in three (!) different places and there is nothing in the spec that claims the contrary.

 

Btw, (2) *still* lists "dest != 0" in the PDF that Daniel Lustig attached to his mail:

You might say my intent doesn't matter, and that would be a fair criticism.

This is not about blame. I don't want to criticize you. (But I understand that you feel criticized. I am being harsh and emotional and I'm sorry for not being more relaxed, but to me this is not just a small issue. My basic (no-system, no-fence) RV32IC model has been stable and formally verified against spike for quite a while now and people are formally verifying their cores against it. This spec change wrecks all those proofs.)

For me this is about ensuring consistency of a frozen spec. And if you want to clear up an ambiguity in the spec, then the only thing that should matter is how people would likely have understood the spec up until this point. And if you intended one thing, but  most people would have understood it differently, then the ambiguity should be resolved to (A) match what people likely would have understood when reading the ambiguous spec and (B) still guarantee backward compatibility either way.

Making a legal opcode illegal would be backward compatible. In that case older processors would simply implement an opcode that newer code generators would never output. That is okay. It might as well be a custom extension.

On the other hand, making an illegal opcode legal is not a backward compatible change. Older processors would throw an illegal instruction exception for an instruction that they are suddenly supposed to support.

I assume this discrepancy between the text and the table arose because Krste wrote one and I wrote the other.

Please understand that no matter what the original intent was, this is a SPEC CHANGE. It is not simply a clarification. The spec used to be that rd=0 is invalid and now it is that rd=0 is valid. Even if the spec text itself might have been ambiguous, the implementation in spike was not, and is not, and is different now from what it used to be before. (But as I argued above I think it is pretty clear that even if the spec was ambiguous, it was clearly leaning towards rd=0 being invalid.)

And now we have processors out there that have correctly implemented the old spec, even formally verified against it, but suddenly are not correct RISC-V implementations anymore!?

Will silicon that raises an illegal instruction exception for C.LWSP with rd=0 pass the compliance test?

Need people who want to be able to claim that their chip is RISC-V compatible re-spin their chips now?

 

I screwed up. Sorry.

This is not about assigning blame. Not for me at least. And I think the real screw-up did not happen yet. Because in my opinion the real screw-up would be the non-backward-compatible spec change that you are planning on including in v2.3. Please don't do that.

regards,

 - Clifford

[Tommy Thorn]

Besides the points Clifford raised (which I largely agree with), what is the rationale for making this legal?

We either have to tone down the public boasting that the "spec is frozen" or actually live up to this.

FWIW, IMO, the standard is be defined by the spec, the *tests*, and Spike, in that order and they should

of course be consistent.

Spike has a lot of issues as a spec; it's very hard to extract the intended semantics from it (try to figure out

float 32-bit behavior from it, I dare you).  Besides the bugs and Spike lagging behind the spec (that has happened

at least once), you can't easily tell what's intentional semantics or just accidental; there are lots of optional

behavior for which Spike implements just one option.  Did I mention how awful Spike is to read?

Tommy

Hi,

<image.png>

You might say my intent doesn't matter, and that would be a fair criticism.

This is not about blame. I don't want to criticize you. (But I understand that you feel criticized. I am being harsh and emotional and I'm sorry for not being more relaxed, but to me this is not just a small issue. My basic (no-system, no-fence) RV32IC model has been stable and formally verified against spike for quite a while now and people are formally verifying their cores against it. This spec change wrecks all those proofs.)

For me this is about ensuring consistency of a frozen spec. And if you want to clear up an ambiguity in the spec, then the only thing that should matter is how people would likely have understood the spec up until this point. And if you intended one thing, but  most people would have understood it differently, then the ambiguity should be resolved to (A) match what people likely would have understood when reading the ambiguous spec and (B) still guarantee backward compatibility either way.

Making a legal opcode illegal would be backward compatible. In that case older processors would simply implement an opcode that newer code generators would never output. That is okay. It might as well be a custom extension.

On the other hand, making an illegal opcode legal is not a backward compatible change. Older processors would throw an illegal instruction exception for an instruction that they are suddenly supposed to support.

I assume this discrepancy between the text and the table arose because Krste wrote one and I wrote the other.

Please understand that no matter what the original intent was, this is a SPEC CHANGE. It is not simply a clarification. The spec used to be that rd=0 is invalid and now it is that rd=0 is valid. Even if the spec text itself might have been ambiguous, the implementation in spike was not, and is not, and is different now from what it used to be before. (But as I argued above I think it is pretty clear that even if the spec was ambiguous, it was clearly leaning towards rd=0 being invalid.)

And now we have processors out there that have correctly implemented the old spec, even formally verified against it, but suddenly are not correct RISC-V implementations anymore!?

Will silicon that raises an illegal instruction exception for C.LWSP with rd=0 pass the compliance test?

Need people who want to be able to claim that their chip is RISC-V compatible re-spin their chips now?

 

I screwed up. Sorry.

This is not about assigning blame. Not for me at least. And I think the real screw-up did not happen yet. Because in my opinion the real screw-up would be the non-backward-compatible spec change that you are planning on including in v2.3. Please don't do that.

regards,

 - Clifford

--
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/CAG5EYeXJgB35PKbhBO07Ucy44_b4MB%2B5B7kjPj2PjLXoAwibsw%40mail.gmail.com.

[Andrew Waterman]

That’s a valid point. I will revert the change.

But you really don’t need to be so confrontational. You can’t hide behind being emotional as an excuse: being emotional is precisely the problem.

[Andrew Waterman]

On Fri, May 4, 2018 at 10:15 AM Tommy Thorn <tommy...@esperantotech.com> wrote:

Besides the points Clifford raised (which I largely agree with), what is the rationale for making this legal?

We either have to tone down the public boasting that the "spec is frozen" or actually live up to this.

FWIW, IMO, the standard is be defined by the spec, the *tests*, and Spike, in that order and they should

of course be consistent.

Spike has a lot of issues as a spec; it's very hard to extract the intended semantics from it (try to figure out

float 32-bit behavior from it, I dare you).  Besides the bugs and Spike lagging behind the spec (that has happened

at least once), you can't easily tell what's intentional semantics or just accidental; there are lots of optional

behavior for which Spike implements just one option.  Did I mention how awful Spike is to read?

The goal, as you are well aware, is to have a formal model replace Spike.

[Tommy Thorn]

On May 4, 2018, at 10:22 , Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

Spike has a lot of issues as a spec; it's very hard to extract the intended semantics from it (try to figure out

float 32-bit behavior from it, I dare you).  Besides the bugs and Spike lagging behind the spec (that has happened

at least once), you can't easily tell what's intentional semantics or just accidental; there are lots of optional

behavior for which Spike implements just one option.  Did I mention how awful Spike is to read?

The goal, as you are well aware, is to have a formal model replace Spike.

Until that mythical day, I'd focus on making the riscv-tests be as comprehensive as humanly possible (*).

(At one company I know of, the test suite (substantial) was considered the single-most

valuable IP).

(*) Yes, I still some additions.

Tommy

[Andrew Waterman]

I agree with that pragmatic approach. This is something the entire community can help with (though contributions are currently rare).

[Luke Kenneth Casson Leighton]

On Fri, May 4, 2018 at 6:21 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

That’s a valid point. I will revert the change.

But you really don’t need to be so confrontational. You can’t hide behind being emotional as an excuse: being emotional is precisely the problem.

 i believe he was scared and alarmed because the work he (and others, unknown) have put in would need to be thrown away: many people are beginning to base their livelihoods on RISC-V (whether they should or not).  how could he have put that differently and still convey the same information, ha i am definitely not the one to ask _that_ :)

 from here, looks like you're doing great, andrew.

l.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, May 4, 2018 at 6:32 PM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:

> I agree with that pragmatic approach. This is something the entire community
> can help with (though contributions are currently rare).

*blink*... idea. these are the two formal spec efforts that i know
of (are there any more)?

https://github.com/cliffordwolf/riscv-formal
https://github.com/rsnikhil/RISCV_ISA_Formal_Spec_in_BSV

would it be reasonable to embed the test suites *in* the formal
spec(s) (for them to be extracted by command-line tools and
automatically pushed to riscv-test), and, for rishiyur and clifford a
question: would it actually be more than theoretically possible to
*auto-generate* any parts of the test suite assembly code, *directly*
from the respective formal specs that you have been working on?

l.

[Clifford Wolf]

Hi,

On Fri, May 4, 2018 at 7:21 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:

On the other hand, making an illegal opcode legal is not a backward compatible change. Older processors would throw an illegal instruction exception for an instruction that they are suddenly supposed to support.

That’s a valid point. I will revert the change.

Thanks!

I really mean it. Thanks!

 

But you really don’t need to be so confrontational. You can’t hide behind being emotional as an excuse: being emotional is precisely the problem.

Sorry. I'll try to be better.

regards,

 - Clifford

[Michael Clark]

>
> On Fri, May 4, 2018 at 7:21 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:
> On the other hand, making an illegal opcode legal is not a backward compatible change. Older processors would throw an illegal instruction exception for an instruction that they are suddenly supposed to support.

I also shared Clifford’s interpretation from the compressed opcode table “Table 12.6: Instruction listing for RVC, Quadrant 2.” which has rd≠0 for C.LWSP

- https://github.com/michaeljclark/riscv-meta/blob/master/compression#L36
- https://github.com/michaeljclark/riscv-meta/blob/master/constraints

This LaTeX is generated from the constraints associated with the instructions for constraints that have annotations in the constraint table which is used to generate a decoder/encoder:

- https://github.com/michaeljclark/rv8/blob/master/doc/pdf/riscv-instructions.pdf

[Jacob Bachmeyer]

Loading a word to x0 is nonsensical, since x0 is hardwired zero and we
already have C.NOP. This creates an interesting issue with C.LDSP and
C.LQSP, which become C.FLWSP and C.FLDSP on processors with narrower
XLEN than they require. For RVF, register zero *is* a valid destination
for a compressed load. Avoiding the situation where rd==0 is reserved
depending on XLEN would be nice, since this complicates decoding on
multi-width implementations.

Could we make rd==0 reserved in all cases for these opcodes? That would
simplify the spec and make the reserved RVC encodings available on all
ISA widths instead of making these additional RVC opcodes that would not
be available on RV32. The price is that stack-relative loads to f0
would no longer be compressible. The gain is six encoding slots for
1-operand instructions on any register (at the minor expense of
introducing a second location for rs1/rd in RVC) or three encoding slots
for 2-operand instructions on the RVC common registers (at the further
expense of introducing alternate positions for rs1'/rd' and rs2' in RVC).


-- Jacob

[Andrew Waterman]

On Fri, May 4, 2018 at 7:17 PM Jacob Bachmeyer <jcb6...@gmail.com> wrote:

Michael Clark wrote:
>> On Fri, May 4, 2018 at 7:21 PM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:
>> On the other hand, making an illegal opcode legal is not a backward compatible change. Older processors would throw an illegal instruction exception for an instruction that they are suddenly supposed to support.
>>     
>
> I also shared Clifford’s interpretation from the compressed opcode table “Table 12.6: Instruction listing for RVC, Quadrant 2.” which has rd≠0 for C.LWSP
>
> - https://github.com/michaeljclark/riscv-meta/blob/master/compression#L36
> - https://github.com/michaeljclark/riscv-meta/blob/master/constraints
>
> This LaTeX is generated from the constraints associated with the instructions for constraints that have annotations in the constraint table which is used to generate a decoder/encoder:
>
> - https://github.com/michaeljclark/rv8/blob/master/doc/pdf/riscv-instructions.pdf
>   

Loading a word to x0 is nonsensical, since x0 is hardwired zero and we
already have C.NOP.  This creates an interesting issue with C.LDSP and
C.LQSP, which become C.FLWSP and C.FLDSP on processors with narrower
XLEN than they require.  For RVF, register zero *is* a valid destination
for a compressed load.  Avoiding the situation where rd==0 is reserved
depending on XLEN would be nice, since this complicates decoding on
multi-width implementations.

Loads to x0 aren’t quite NOPs, as they still check for address validity. In practice, they are prefetches expressing intent to read, but are only valid for valid addresses. (In the case of LWSP, this property is not especially useful.)

[Jacob Bachmeyer]

Andrew Waterman wrote:
> On Fri, May 4, 2018 at 7:17 PM Jacob Bachmeyer <jcb6...@gmail.com

> <mailto:jcb6...@gmail.com>> wrote:
>
> [...]

>
> Loading a word to x0 is nonsensical, since x0 is hardwired zero
> and we
> already have C.NOP. This creates an interesting issue with C.LDSP
> and
> C.LQSP, which become C.FLWSP and C.FLDSP on processors with narrower
> XLEN than they require. For RVF, register zero *is* a valid
> destination
> for a compressed load. Avoiding the situation where rd==0 is
> reserved
> depending on XLEN would be nice, since this complicates decoding on
> multi-width implementations.
>
>
> Loads to x0 aren’t quite NOPs, as they still check for address
> validity. In practice, they are prefetches expressing intent to read,
> but are only valid for valid addresses. (In the case of LWSP, this
> property is not especially useful.)

Even C.LQSP is limited to less than 1KiB above the the stack pointer, so
these are not even useful for ensuring space to expand the stack. (None
of the C.*L?SP instructions can reach beyond a page unless x2 is very
close to a page boundary.) In the general instruction set, these "hard
prefetch" loads are fine and a consequence of the regular encoding, but
I question their worth in the much more limited RVC encoding space,
where regularity of encoding is less of a goal and many other
instructions are defined "except on x0". Note that I am also suggesting
making C.FLWSP and C.FLDSP to *_f0_* illegal, to permit these opcodes to
be unconditionally reclaimed for all ISA widths. Similar irregularities
exist elsewhere in RVC, so why not here? The ABI uses f0 as an FP
temporary, so code that leans heavily on RVC can simply avoid using that
register.


Also, I suggest clarifying the expansions of these opcodes to clearly
show that low-order zero bits are inserted: "lw rd, offset[7:2](x2)"
could be misinterpreted as *dividing* the offset by four. I suggest "lw
rd, {offset[7:2], 2'b00}(x2)" as an initial alternative.


-- Jacob

[Richard Herveille]

 

<snippets>

… the document changes the behavior of C.LWSP (and some related compressed opcodes) so that now rd=0 is not reserved anymore.

 

This is a backwards incompatible change with v2.2 of the ISA spec (which includes v2.0 of the compressed spec).

 

Spike was also changed now to match the new behavior.

 

When I joined RISC-V there used to be two promises:

 

1. No backwards incompatible changes after the 2.0 release of a spec, and

 

2. Spike is the executable golden reference.

 

 

These promises were/are reiterated at the RISC-V workshop. Just as Clifford, we too have CPUs in the field that would now be considered ‘broken’ and (I assume just like Cliffort) I got a slight panic attack.

Even if the spec was wrong, you can’t just change it as that will break all CPUs in the field. Once the spec is frozen, that’s it. Any changes to the ‘frozen’ ISA would need to go through some rigorous user review and approval before they can be made. You definitely can’t ‘just’ update the spec. That will be a major dip in trust of the RISC-V foundation (promises) and ultimately will lead to fragmentation/forking of RISC-V, something we all try to prevent.

I know Andrew reverted the change and I welcome that. I tried to come up with easy ways to prevent/report this. But seeing the enormous amount of emails already generated and the limited amount of time to read them all (I can’t keep up!!), I can only consider ‘not touching the frozen spec’ as the simplest/cleanest solution.

We’re all over worked and are all trying to do what’s best. I thank you all and keep up the good work!!

 

Cheers,

Richard

 

[Allen Baum]

A weaker standard would be no backwards incompatible changes, rather than no changes.

-Allen

--

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/EA5C3B2D-B01F-4F13-BF88-DAAF457D62A5%40roalogic.com.

[Luke Kenneth Casson Leighton]

On Mon, May 7, 2018 at 9:48 AM, Richard Herveille
<richard....@roalogic.com> wrote:

> Even if the spec was wrong, you can’t just change it as that will break all
> CPUs in the field. Once the spec is frozen, that’s it. Any changes to the
> ‘frozen’ ISA would need to go through some rigorous user review and approval
> before they can be made. You definitely can’t ‘just’ update the spec. That
> will be a major dip in trust of the RISC-V foundation (promises) and
> ultimately will lead to fragmentation/forking of RISC-V, something we all
> try to prevent.

this is why, after realising the significance of what guy raised,
i've been working on the mvendorid-marchid-mimplid idea, as in an
emergency it is a way to provide a safe transition of *official*
incompatible variants of the RISC-V Standard. although... that covers
actual instruction encoding changes: it doesn't cover semantic
changes.

> We’re all over worked and are all trying to do what’s best. I thank you all
> and keep up the good work!!

:)

[Bruce Hoult]

I thought that's exactly what we have, pre ratification.

To my great surprise, in a recent twitter conversation I found that Clifford and I disageed on what constitutes incompatible changes!

https://twitter.com/oe1cxw/status/992385001047117825

In a post here, Clifford had written:

"This new version of the document changes the behavior of C.LWSP (and some related compressed opcodes) so that now rd=0 is not reserved anymore. Is this also part of the 45-day ratification period?

This is a backwards incompatible change with v2.2 of the ISA spec (which includes v2.0 of the compressed spec)."

I wrote to him:

"Just a side issue: I believe you have “no incompatible changes” backwards. The goal is for old software to work on new CPUs, not for old CPUs to run new software. Reserved opcodes are always intended to be able to be used in later specs, not illegal forever."

On Mon, May 7, 2018 at 10:17 PM, Allen Baum <allen...@esperantotech.com> wrote:

A weaker standard would be no backwards incompatible changes, rather than no changes.

-Allen

On May 7, 2018, at 10:48 AM, Richard Herveille <richard.herveille@roalogic.com> wrote:

 

<snippets>

… the document changes the behavior of C.LWSP (and some related compressed opcodes) so that now rd=0 is not reserved anymore.

 

This is a backwards incompatible change with v2.2 of the ISA spec (which includes v2.0 of the compressed spec).

 

Spike was also changed now to match the new behavior.

 

When I joined RISC-V there used to be two promises:

 

1. No backwards incompatible changes after the 2.0 release of a spec, and

 

2. Spike is the executable golden reference.

 

 

These promises were/are reiterated at the RISC-V workshop. Just as Clifford, we too have CPUs in the field that would now be considered ‘broken’ and (I assume just like Cliffort) I got a slight panic attack.

Even if the spec was wrong, you can’t just change it as that will break all CPUs in the field. Once the spec is frozen, that’s it. Any changes to the ‘frozen’ ISA would need to go through some rigorous user review and approval before they can be made. You definitely can’t ‘just’ update the spec. That will be a major dip in trust of the RISC-V foundation (promises) and ultimately will lead to fragmentation/forking of RISC-V, something we all try to prevent.

I know Andrew reverted the change and I welcome that. I tried to come up with easy ways to prevent/report this. But seeing the enormous amount of emails already generated and the limited amount of time to read them all (I can’t keep up!!), I can only consider ‘not touching the frozen spec’ as the simplest/cleanest solution.

We’re all over worked and are all trying to do what’s best. I thank you all and keep up the good work!!

 

Cheers,

Richard

 

--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/EA5C3B2D-B01F-4F13-BF88-DAAF457D62A5%40roalogic.com.

--

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/08EAA410-6862-4EF2-B91C-27715B11E8D8%40esperantotech.com.

[kr...@berkeley.edu]

For the purposes of clarifying Bruce/Clifford's differences, let's
assume the base spec was as Clifford understood it, and as it now
stands.

Whether this change would have been backward-compatible comes down to
whether the change is considered an addition to the base spec or a new
"Zclwsprd0" extension. The former is not backwards-compatible, while
the latter is.

There is no requirement for an implementation to trap currently
reserved encodings, so even old Rocket implementations that didn't
trap on this case are compliant with the base spec.

A CPU is even free to reuse some standard extension encoding space for
non-standard extensions provided it does not claim to implement that
standard extension.

This stance has been documented for a long time in the "Extending
RISC-V" chapter, under "Standard-Compatible Global Encoding".

Krste

>>>>> On Mon, 7 May 2018 23:19:33 +1200, Bruce Hoult <br...@hoult.org> said:

| I thought that's exactly what we have, pre ratification.
| To my great surprise, in a recent twitter conversation I found that Clifford
| and I disageed on what constitutes incompatible changes!

| https://twitter.com/oe1cxw/status/992385001047117825

| In a post here, Clifford had written:

| "This new version of the document changes the behavior of C.LWSP (and some
| related compressed opcodes) so that now rd=0 is not reserved anymore. Is this
| also part of the 45-day ratification period?

| This is a backwards incompatible change with v2.2 of the ISA spec (which
| includes v2.0 of the compressed spec)."

| I wrote to him:

| "Just a side issue: I believe you have “no incompatible changes” backwards. The
| goal is for old software to work on new CPUs, not for old CPUs to run new
| software. Reserved opcodes are always intended to be able to be used in later
| specs, not illegal forever."

| On Mon, May 7, 2018 at 10:17 PM, Allen Baum <allen...@esperantotech.com>
| wrote:

| A weaker standard would be no backwards incompatible changes, rather than
| no changes.

| -Allen

| On May 7, 2018, at 10:48 AM, Richard Herveille <richard.herveille@roalogic.

com| wrote:
|  

| <snippets>

| … the document changes the behavior of C.LWSP (and some related
| compressed opcodes) so that now rd=0 is not reserved anymore.

| This is a backwards incompatible change with v2.2 of the ISA spec
| (which includes v2.0 of the compressed spec).

| Spike was also changed now to match the new behavior.

| When I joined RISC-V there used to be two promises:

| 1. No backwards incompatible changes after the 2.0 release of a spec,
| and

| 2. Spike is the executable golden reference.

| These promises were/are reiterated at the RISC-V workshop. Just as
| Clifford, we too have CPUs in the field that would now be considered
| ‘broken’ and (I assume just like Cliffort) I got a slight panic attack.
| Even if the spec was wrong, you can’t just change it as that will bre

| all CPUs in the field. Once the spec is frozen, that’s it. Any changes
| to the ‘frozen’ ISA would need to go through some rigorous user review
| and approval before they can be made. You definitely can’t ‘just’
| update the spec. That will be a major dip in trust of the RISC-V
| foundation (promises) and ultimately will lead to fragmentation/forking
| of RISC-V, something we all try to prevent.

| I know Andrew reverted the change and I welcome that. I tried to come
| up with easy ways to prevent/report this. But seeing the enormous
| amount of emails already generated and the limited amount of time to
| read them all (I can’t keep up!!), I can only consider ‘not touching
| the frozen spec’ as the simplest/cleanest solution.

| We’re all over worked and are all trying to do what’s best. I thank you
| all and keep up the good work!!

|  

| Cheers,

| Richard

|  

| --
| 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/EA5C3B2D-B01F-4F13-BF88-
| DAAF457D62A5%40roalogic.com.

| --
| 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/08EAA410-6862-4EF2-B91C-
| 27715B11E8D8%40esperantotech.com.

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

| CAMU%2BEkyPNay2Lhv-%2B0JL7N2wmuK5q79e%2BbZu563QZhkd6%2BkweQ%40mail.gmail.com.

[Luke Kenneth Casson Leighton]

On Mon, May 7, 2018 at 2:56 PM, <kr...@berkeley.edu> wrote:

> Whether this change would have been backward-compatible comes down to
> whether the change is considered an addition to the base spec or a new
> "Zclwsprd0" extension. The former is not backwards-compatible, while
> the latter is.

a Zclwsprd0 extension sounds perfectly logical and reasonable to me,
and matches well with my understanding of how long-term successful
standards work.

> A CPU is even free to reuse some standard extension encoding space for
> non-standard extensions provided it does not claim to implement that
> standard extension.

now that is *very* interesting. i'll make a special note of this in
the isa-conflict-resolution document, and think about it some more
over the next few days, the other known cases were custom-custom
(only), standard-standard (future approved RV-base vs *older* approved
RV-base); custom over-riding *standard* opcode space makes an ISA
conflict resolution system *even more* important.

thank you krste.

l.

p.s. thank you to everyone who gave tutorials today.

[John Hauser]

Krste wrote:
> There is no requirement for an implementation to trap currently
> reserved encodings, so even old Rocket implementations that didn't
> trap on this case are compliant with the base spec.

That's news to me.  Since I evidently overlooked it, where's the wording
in the spec that backs up that claim?

I just searched through the two spec documents, and, as far as I can
tell, they don't explicitly speak to the matter one way or the other.
You may argue that this silence implies permission not to trap all
reserved encodings as illegal.  I think it's equally tenable for someone
to claim there's a strong implication that reserved encodings _must_ be
trapped as illegal.  Certainly the documents do mention that certain
instructions cause illegal instruction traps when not implemented, often
enough that I feel one could be forgiven for inferring this to be a
general rule.  In fact, I suspect many subscribers to this list assumed
it was true, and will be surprised to hear it isn't.

At the very least, because some other processors are nominally specified
to trap on all non-defined encodings, people familiar with those
processors will be at risk to assume this is implied for RISC-V as well,
without an explicit statement to the contrary in the documents.

Regards,

    - John Hauser

[John Hauser]

Krste wrote:
> This stance has been documented for a long time in the "Extending
> RISC-V" chapter, under "Standard-Compatible Global Encoding".

I'm sorry, I should've responded to this with my previous message.

I recognize that this chapter says that some implementations may use
reserved encoding space for their nonstandard extensions, but the text
leaves a lot of doubt about whether such implementations will altogether
be considered to conform to the RISC-V standard.  If a processor
implements nonstandard extensions that use reserved encoding space in
conflict with standard RISC-V extensions, are we supposed to intuit
that this processor may still be certifiable as conforming to the RISC-V
standard?  (Or to some subset of it, I presume?)

Let's consider a specific example:  Imagine we have an RV32I processor,
and we choose to reuse the encodings for the RV64-only "word-size"
instructions, ADDW, SUBW, etc., for a nonstandard extension.  You seem
to believe that's allowed, Krste.  However, in the RV64I chapter of
the base spec, section 4.2, it says, "These "*W" instructions ... cause
an illegal instruction exception in RV32I."  Does the spec mean what it
says?  Are the "*W" instructions really a special exception to your rule
that reuse of the reserved encoding space is allowed?  If so, why?

There seem to be a number of similar exceptions sprinkled around the
documents like that.

Ultimately, for many people, the issue will be what different kinds of
gold-star certificates the RISC-V Foundation makes available, and what
requirements one has to meet to get each one.  Unfortunately, these
questions can't definitively be answered by anyone other than officially
by the Foundation.

I'm not saying that the current intention is "wrong", only that it's
still quite muddied, to the point that I'm not sure everybody involved
is really in sync.

Regards,

    - John Hauser

[Alex Bradbury]

On 8 May 2018 at 11:55, John Hauser <jhause...@gmail.com> wrote:
> Krste wrote:
>> This stance has been documented for a long time in the "Extending
>> RISC-V" chapter, under "Standard-Compatible Global Encoding".
>
> I'm sorry, I should've responded to this with my previous message.
>
> I recognize that this chapter says that some implementations may use
> reserved encoding space for their nonstandard extensions, but the text
> leaves a lot of doubt about whether such implementations will altogether
> be considered to conform to the RISC-V standard. If a processor
> implements nonstandard extensions that use reserved encoding space in
> conflict with standard RISC-V extensions, are we supposed to intuit
> that this processor may still be certifiable as conforming to the RISC-V
> standard? (Or to some subset of it, I presume?)
>
> Let's consider a specific example: Imagine we have an RV32I processor,
> and we choose to reuse the encodings for the RV64-only "word-size"
> instructions, ADDW, SUBW, etc., for a nonstandard extension. You seem
> to believe that's allowed, Krste. However, in the RV64I chapter of
> the base spec, section 4.2, it says, "These "*W" instructions ... cause
> an illegal instruction exception in RV32I." Does the spec mean what it
> says? Are the "*W" instructions really a special exception to your rule
> that reuse of the reserved encoding space is allowed? If so, why?
>
> There seem to be a number of similar exceptions sprinkled around the
> documents like that.

Another notable one is RV32E:

"RV32E uses the same instruction set encoding as RV32I, except that
use of register specifiers
x16–x31 in an instruction will result in an illegal instruction
exception being raised."

"Any future standard extensions will not make use of the instruction
bits freed up by the reduced
register-specifier fields and so these are available for non-standard
extensions."

The issue is that "will result in an illegal instruction exception
being raised" may not have the meaning you expect. The intending
meaning seems to be "will result in an illegal instruction exception
being raised unless the encoding space has been reused by non-standard
extensions".

I'm not saying this is bad, in general I'm strongly in favour of
allowing maximum room for extensions. Just something that might be
made clearer.

Best,

Alex

[Guy Lemieux]

Pragmatically, the purpose of an illegal instruction trap is to
prevent bad (corrupt) code from executing.

If the encoding is used to implement non-standard extensions, then of
course you wouldn't expect to get an illegal instruction trap (the
code is intentional). However, when the same code is run on an
implementation that does not support those extensions, the illegal
instruction trap is expected -- it might even be possible to emulate
the non-standard extensions in the trap handler.

Thus, both forms are correct (to trap, or to not trap).

So the pedantic question here is: what does it take to be considered
compliant and get a gold star?

The behaviour above suggests that compliance means an illegal
instruction trap will occur if an instruction is not recognized by the
implementation as a valid encoding. Yes, this means different
behaviour on different implementations with non-standard extensions,
but that's exactly the behaviour you want (and are advertising
anyways).

One final thought -- perhaps compliance means all CPUs with
non-standard and/or custom extensions must have a "mode" which only
allows standard instructions + extensions and traps on all others, for
a common behaviour mode. This mode allows users who don't want to use
any custom instructions to catch any/all non-standard encodings
through the trap handler. Hmmm, I wonder if there is a mechanism to
enable/switch between instruction set implementations...?

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/CA%2BwH2959AnUkqURvwObByLNx6KMU_pwmgFr%3DhL8-VTx8HnanmA%40mail.gmail.com.

[Alex Bradbury]

On 8 May 2018 at 12:01, Alex Bradbury <a...@asbradbury.org> wrote:
> Another notable one is RV32E:
>
> "RV32E uses the same instruction set encoding as RV32I, except that
> use of register specifiers
> x16–x31 in an instruction will result in an illegal instruction
> exception being raised."
>
> "Any future standard extensions will not make use of the instruction
> bits freed up by the reduced
> register-specifier fields and so these are available for non-standard
> extensions."
>
> The issue is that "will result in an illegal instruction exception
> being raised" may not have the meaning you expect. The intending
> meaning seems to be "will result in an illegal instruction exception
> being raised unless the encoding space has been reused by non-standard
> extensions".
>
> I'm not saying this is bad, in general I'm strongly in favour of
> allowing maximum room for extensions. Just something that might be
> made clearer.

Thinking more about the source of confusion. This is one area where
you might view standard/non-standard extension as not being purely
additive. I certainly would have an expectation that RV32IXfhqwhgads
acts just like RV32I. With the way the spec is currently written, it
seems that the expetation these non-standard extensions might
invalidate statements about "foo will generate an illegal instruction
exception".

It seems there are 3 classes of instruction patterns:
1. Has defined 'useful' semantics. Unless explicitly left
implementation-defined, these can't be modified while claiming
conformance with the relevant part of the ISA spec
2. Defined to always cause an illegal instruction, no matter what
extensions are implemented. I think this is only the all-ones and
all-zeroes instructions?
3. Unallocated. May or may not cause an illegal instruction trap
depending on what extensions are implemented. This describes the
majority of the encoding space. Does it also include SLLI/SRLI/SRAI
with imm[5] != 0? For a system that claims it _only_ implements a
given standard ISA string such as RV32I is it required that these
instructions trap or not?

Best,

Alex

[Luke Kenneth Casson Leighton]

On Tuesday, May 8, 2018, John Hauser <jhause...@gmail.com> wrote:

.  I think it's equally tenable for someone
to claim there's a strong implication that reserved encodings _must_ be
trapped as illegal.  Certainly the documents do mention that certain
instructions cause illegal instruction traps when not implemented, often
enough that I feel one could be forgiven for inferring this to be a
general rule.  In fact, I suspect many subscribers to this list assumed
it was true, and will be surprised to hear it isn't.

At the very least, because some other processors are nominally specified
to trap on all non-defined encodings, people familiar with those
processors will be at risk to assume this is implied for RISC-V as well,
without an explicit statement to the contrary in the documents.

Sorry using phone, not well, brief. No guaranteed trap if not implemented means hw cannot use sw to keep now-legacy impl relevant until convenient to replace hw in the field (if that is even possible).

--

[Jacob Bachmeyer]

"Non-defined" cannot be guaranteed because those reserved opcodes could
map to a non-standard extension in some implementations.


-- Jacob

[Jacob Bachmeyer]

John Hauser wrote:
> Krste wrote:
> > This stance has been documented for a long time in the "Extending
> > RISC-V" chapter, under "Standard-Compatible Global Encoding".
>
> I'm sorry, I should've responded to this with my previous message.
>
> I recognize that this chapter says that some implementations may use
> reserved encoding space for their nonstandard extensions, but the text
> leaves a lot of doubt about whether such implementations will altogether
> be considered to conform to the RISC-V standard. If a processor
> implements nonstandard extensions that use reserved encoding space in
> conflict with standard RISC-V extensions, are we supposed to intuit
> that this processor may still be certifiable as conforming to the RISC-V
> standard? (Or to some subset of it, I presume?)

It should still conform to some subset of the RISC-V standard. A
non-RVF processor can reuse the floating-point opcodes for some
non-standard extension, but standard extensions are not permitted to
conflict with each other. The only exception here is the RVI/RVE base,
since implementing the entire base ISA is the minimum to call a
processor "RISC-V" in the first place.

> Let's consider a specific example: Imagine we have an RV32I processor,
> and we choose to reuse the encodings for the RV64-only "word-size"
> instructions, ADDW, SUBW, etc., for a nonstandard extension. You seem
> to believe that's allowed, Krste. However, in the RV64I chapter of
> the base spec, section 4.2, it says, "These "*W" instructions ... cause
> an illegal instruction exception in RV32I." Does the spec mean what it
> says? Are the "*W" instructions really a special exception to your rule
> that reuse of the reserved encoding space is allowed? If so, why?

If OP-32/OP-32-IMM is reused for a non-standard extension, then the
processor is not "RV32I" -- it is "RV32I_Xwhatever".


-- Jacob

[Jacob Bachmeyer]

Alex Bradbury wrote:
> [...]

> It seems there are 3 classes of instruction patterns:
> 1. Has defined 'useful' semantics. Unless explicitly left
> implementation-defined, these can't be modified while claiming
> conformance with the relevant part of the ISA spec
> 2. Defined to always cause an illegal instruction, no matter what
> extensions are implemented. I think this is only the all-ones and
> all-zeroes instructions?
> 3. Unallocated. May or may not cause an illegal instruction trap
> depending on what extensions are implemented. This describes the
> majority of the encoding space. Does it also include SLLI/SRLI/SRAI
> with imm[5] != 0? For a system that claims it _only_ implements a
> given standard ISA string such as RV32I is it required that these
> instructions trap or not?
>

I would argue that such instructions should be required to trap if the
system claims to support only RV32I.


-- Jacob

[Cesar Eduardo Barros]

But does "support only RV32I" mean "can run software written for RV32I",
or "cannot run anything other than software written for RV32I"? Is the
definition inclusive, or exclusive?

To put it another way, is it a closed world (everything which is not in
RV32I must trap), or an open world (everything which is in RV32I must
not trap)?

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

[Jacob Bachmeyer]

The use of the word "only" makes it a closed world. An implementation
that "supports RV32I" fits in your "open world" category.

A specific implementation that claims to be "RV32I" would claim to
support only RV32I. An implementation that claims to support
"RV32I_Xwhatever" still claims to support RV32I, but also supports an
"Xwhatever" extension.


-- Jacob

[Alex Bradbury]

This discussion does highlight a subtlety about naming the ISA variant
supported by a processor. I'd previously thought that a core vendor
could reasonably market a core as RV32IMAC even if it secretly
supported extra extensions that they didn't disclose. However doing so
means important information is lost - you need to know whether this
core implements _only_ RV32IMAC (or has writable misa which can select
this) in order to know whether you can rely on the ability to trap and
emulate current and future standard extensions.

Best,

Alex

[Allen Baum]

Just a reminder: the POR for the compliance test suite is to 

 - check that which is claimed to be implemented is really implemented - and more to the point, 

 - do not check that which is not claimed.

There are several classes of encodings, e.g. reserved for base ISA, reserved for custom extensions, or reserved for optional extensions.

IF there are encodings that are *specifically* spec'ed to trap if an extension or architecture is not implemented, then compliance should check that it traps if the extension or architecture is not implemented

Otherwise: If a specific extension is not implemented, then we cannot say anything about what executing those encoding will do, and compliance tests will not contain an instructions with those encodings.

My canonical example is an implementation that implements the multiply op, but not division.

If MISA.M is set, tests will try to execute divide, and it will trap - that's a compliance failure.

So, MISA.M should to clear in this case - and therefore compliance tests will not even try to test multiply, even though it is implemented using the same encoding that an implemention that does implement the full M-extension uses. 

Effectively, this case, the multiply op is a custom extension, and compliance doesn't/can't check nything that is custom.

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BwH296Up477Q9Gg36KbXRSuZnrFPUKi0cWUst3bM5H39Si-6A%40mail.gmail.com.

[Bruce Hoult]

But is it not true that the user-mode compliance checks will be user-mode programs only, and they won't check precise timings, but only results?

So a system that claims M (and only a system can make such a claim, not a bare core) might well implement multiply in hardware but trap and emulate division.

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/CA%2BwH296Up477Q9Gg36KbXRSuZnrFPUKi0cWUst3bM5H39Si-6A%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DAsAxdB25UAQ97Y580nDAYN%3DFmDYeFpq-fEwXdOrED0Aw%40mail.gmail.com.

[Allen Baum]

That’s an interesting case, and starts to get into platform profile issues.

 As you say, a bare core core ISA Test can’t depend on anything beyond the core- so those tests will not try testing Mul/Div unless an assertion that the M-extension is present

But, If we assert to the compliance framework that the M-extension is present, and part of the compliance test is to check that MISA.M is set ( and it should)- and it isn’t set- you fail compliance.

Platform level tests, which must be run with vendor supplied support code (and we haven’t started discussing platform level tests) could test that- but it isn’t clear how we communicate this to test infrastructure.

-Allen

[Alex Bradbury]

On 9 May 2018 at 14:44, Allen Baum <allen...@esperantotech.com> wrote:
> That’s an interesting case, and starts to get into platform profile issues.
> As you say, a bare core core ISA Test can’t depend on anything beyond the
> core- so those tests will not try testing Mul/Div unless an assertion that
> the M-extension is present
> But, If we assert to the compliance framework that the M-extension is
> present, and part of the compliance test is to check that MISA.M is set (
> and it should)- and it isn’t set- you fail compliance.

Why would a compliance test probe misa?

1) Compliance for the unprivileged RV32M standard extension is surely
orthogonal to compliance with the privileged specification. misa is
not defined in the user/unprivileged specification
2) The current privileged specification explicitly states that it's
valid for a CSR read of misa to return 0 anyway

Best,

Alex

[Samuel Falvo II]

Not only that, but it's also been mentioned here that it's perfectly
acceptable for different privileged ISA extensions to exist as well.
So, for example, if I wanted to (not that I'm motivated to do this), I
could theoretically make a processor that implements RV32/64IM at the
non-privileged level, and implement a privileged mode which supports
Burroughs-like segmentation, or maybe even implement a completely
different ISA all-together (e.g., in this case, the RV32/64IM
environment would relate to the core ISA as ARM Thumb relates to the
full-width ARM ISA).

> --
> 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/CA%2BwH297cGqC0yNy0hY%3D3Ca5H8_SerqCVRJ0grpnT7zcsyoWYDg%40mail.gmail.com.



--
Samuel A. Falvo II

[Andrew Waterman]

On Wed, May 9, 2018 at 9:32 PM Samuel Falvo II <sam....@gmail.com> wrote:

Not only that, but it's also been mentioned here that it's perfectly
acceptable for different privileged ISA extensions to exist as well.
So, for example, if I wanted to (not that I'm motivated to do this), I
could theoretically make a processor that implements RV32/64IM at the
non-privileged level, and implement a privileged mode which supports
Burroughs-like segmentation, or maybe even implement a completely
different ISA all-together (e.g., in this case, the RV32/64IM
environment would relate to the core ISA as ARM Thumb relates to the
full-width ARM ISA).

User-ISA compliance tests should not test privileged features, but obviously the privileged-ISA compliance tests will.

It should be possible to claim compliance to the user ISA without claiming compliance to the privileged ISA or a hardware platform. Qemu-user is in this boat, as is the situation you described.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsokuyXT-jgM3zQ8BXaoX4%3Duo5NqF4saJ7R2raPnG66r4CQ%40mail.gmail.com.

[Liviu Ionescu]

On 9 May 2018 at 22:41:50, Andrew Waterman (and...@sifive.com) wrote:

> It should be possible to claim compliance to the user ISA without
> claiming compliance to the privileged ISA or a hardware platform.

Which compliance test are you considering?

Maybe I'm not up to date, but I could not identify anything similar in
the latest proposal for profiles and compliance (distributed on the
compl...@workspace.riscv.org list).


Regards,

Liviu

[Andrew Waterman]

I was just expressing an opinion.

Realistically, we do need a way to certify qemu-user compliance, so it seems like the same problem to me.

Regards,

Liviu

[Luke Kenneth Casson Leighton]

>> On May 9, 2018, at 12:04 PM, Bruce Hoult <br...@hoult.org> wrote:
>>
>> But is it not true that the user-mode compliance checks will be user-mode
>> programs only, and they won't check precise timings, but only results?
>>
>> So a system that claims M (and only a system can make such a claim, not a
>> bare core) might well implement multiply in hardware but trap and emulate
>> division.

On Wed, May 9, 2018 at 1:44 PM, Allen Baum <allen...@esperantotech.com> wrote:
> That’s an interesting case, and starts to get into platform profile issues.
> As you say, a bare core core ISA Test can’t depend on anything beyond the
> core- so those tests will not try testing Mul/Div unless an assertion that
> the M-extension is present
> But, If we assert to the compliance framework that the M-extension is
> present, and part of the compliance test is to check that MISA.M is set (
> and it should)- and it isn’t set- you fail compliance.

ok yes, so i was going to ask about this. another example where it's
explicitly permitted to do a software-implementation is: TLB. TLB
*surely* must not fail compliance just because the TLB lookup is in
software rather than hardware?

also i was going to suggest a compromise for liviu (was it you who
wants to reduce the core size further by having zero-CSRs not be
there?) - let them be excluded, issue a trap, the trap *in software*
makes it *look* like the read-only CSRs are actually there by
fake-returning zero.

and, also, as part of not-so-simple-v i was going to suggest that a
minimum-compliant implementation just provide the CSRs for
configuration, and on detection of vectors run a trap so that the trap
*emulates* the vector operation in software.

also, older cores that previously met standards may require exception
traps to implement (and obtain re-certification) of latest versions of
the RISC-V Spec... surely they would not be failed as "no longer
compliant" just for having a hybrid *hardware-software*
implementation?

many many examples where actual compliance *could* be met... if
implementor-supplied software / firmware is presented as a critical
integral "symbiotic" part of the hardware.

question: is this permitted?

l.

[Allen Baum]

Lots of good comments and opinions. Please come to the face to face at 9am tomorrow- errr- today to the compliance face to face meeting and we can talk about this.

A couple of comments I'll make are
- that the compliance test will test the version of the spec that someone claims to be in compliance with; E.g. one of the options that would be declared is that MISA is read-only zero- and I (at least) would expect to test that. Your mileage may differ, but I do welcome debate.

Another comment is that a TLB is a good idea, but is absolutely not required. M-onky cores won't even have translation

Another- if you're doing decode for zero CSRs to trap, it's just as easy to just return zero- it might even save logic ( but we are talking small handfuls of gates either way)

And, if you're replacing the entire privileged state with your own, you need to declare that as well, and if it's a spec'ed alternative we'd select different tests, and if it's not we test-- ?nothing? - that will be an interesting discussion. And I will need a few hours of sleep before I'll be capable of discussing it properly.

-Allen

[Luke Kenneth Casson Leighton]

On Thu, May 10, 2018 at 12:37 AM, Allen Baum
<allen...@esperantotech.com> wrote:

> Lots of good comments and opinions. Please come to the face to face at 9am tomorrow- errr- today

:)

> to the compliance face to face meeting and we can talk about this.

appreciated, apologies, i'm not (can't be) a member, also wasn't well
tuesday night, had to take it easy. also project sponsor arrived,
meeting with him today.

> A couple of comments I'll make are
> - that the compliance test will test the version of the spec that someone claims to be in compliance with; E.g. one of the options that would be declared is that MISA is read-only zero- and I (at least) would expect to test that. Your mileage may differ, but I do welcome debate.

as a certification mark holder i had to think through how to cover
things like this, and also i looked at how OSHWA allow "self-cert".
my main question is, if an implementation cannot be compliant unless
it has certain implementor-provided software (for the trap-handlers to
provide "missing" features *or to correct silicon errata*) supplied
with it, that would imply it would need to be linked in to the
compliance tests?

if so... thinking that through... on whom does the burden fall to do
the integration into the compliance software suite? thinking _that_
through... if the compliance suite is entirely libre-licensed then a
libre software/hardware team can do that work themselves. if it's a
proprietary team (who may have binary-only high-security software)
then they can do that too... oh and pay the foundation a bit more for
the extra time it takes to go over what they're doing :)

are compliance tests to be made public and are they BSD/MIT-licensed
(without the non-commercial restrictions)? that would be important
(i.e. not GPL/LGPL/AGPL) so proprietary implementors don't get
unhappy.

l.

[kr...@berkeley.edu]

I would propose that ISA compliance tests only test the encodings
standardized in that ISA module.

For the base instruction set, we have proposed 16 0s and 32 1s are
required to raise illegal instruction exceptions, and only these
should be checked in base ISA compliance suite.

Platform compliance tests can check additional constraints for that
platform. For example, one platform profile might demand that all
unimplemented standard encodings and all reserved encodings cause
illegal instruction traps to ensure forward compatibility. Other
platform profiles might not care.

Krste

| 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/CA%2BwH296Up477Q9Gg36KbXRSuZnrFPU
| Ki0cWUst3bM5H39Si-6A%40mail.gmail.com.

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

| CAF4tt%3DAsAxdB25UAQ97Y580nDAYN%3DFmDYeFpq-fEwXdOrED0Aw%40mail.gmail.com.

[Michael Clark]

> On 24/05/2018, at 11:10 AM, kr...@berkeley.edu wrote:
>
>
> I would propose that ISA compliance tests only test the encodings
> standardized in that ISA module.
>
> For the base instruction set, we have proposed 16 0s and 32 1s are
> required to raise illegal instruction exceptions, and only these
> should be checked in base ISA compliance suite.
>
> Platform compliance tests can check additional constraints for that
> platform. For example, one platform profile might demand that all
> unimplemented standard encodings and all reserved encodings cause
> illegal instruction traps to ensure forward compatibility. Other
> platform profiles might not care.

Agree. I can see a need for negative extension testing, sometimes purely as “observations”, and sometimes for “compliance”, particularly in the platform profiles.


## Negative Testing of Extensions

While negative existence testing is not always necessary required for compliance, it is genuinely useful to test for the absence of extensions, such that a test suite can make observations; and in other cases it may be necessary for compliance. Negative existence testing of course does not make sense if the encoding space of the unsupported extension is deployed for a custom extension as it would also result in unexpected behaviour. Perhaps there is some way to define these scenarios:

e.g.

IM tests I and M
IM-A tests I and M and for the absence of A (illegal instruction traps)
IMAFD tests I, M, A, F and D
IMA-F-D tests I, M, A and for the absence of F and D (illegal instruction traps)
E tests E, tests that registers >= 16 trap (illegal instruction traps)
EMAC tests E, M, A and C, tests that registers >= 16 trap (illegal instruction traps)
EMAFD illegal combination

Emulators such as Spike and QEMU can be made to conform to a subset of the RISC-V extension suite, and when restricting the emulated environment it would be beneficial to test that the restrictions correctly apply. Extended functionality however does not necessarily make them non-compliant, well except for RVE. The emulators are useful, in general, for testing pre-silicon as one may want to test software in a restricted functional simulation of the target environment to test that that libraries will work on hardware for the specific target environment. e.g. making sure that code doesn’t use atomics or out of bound registers, especially when linking with vendor libraries. If a library uses custom assembly then the ELF flags will not be sufficient, and of course they indicate ABI not ISA.

One example is RVE. Presently QEMU does not throw illegal instructions for registers >= 16, however it does support the RVE calling convention in linux-user emulation. Instructions that access registers >= 16 will work instead of trapping with an illegal instruction exception, which is incorrect behaviour for RVE. Of course this is on the list of things to fix. i.e. for behavioural / functional emulation fidelity.

“RV32E uses the same instruction set encoding as RV32I, except that use of register specifiers x16–x31 in an instruction will result in an illegal instruction exception being raised.”

That raises an interesting question about compliance of RVE, if for example an implementation used the extra bit, for examples sake - to zero-extend.


## Test Reporting Mechanisms

A practical aside…

Some of the tests in the pre-existing open source riscv-tests suite have dependence on an HTIF test reporting interface versus. Some of the tests just require simple console IO. I am able to run all of the Base ISA ‘V’ tests in QEMU, however i’m currently looking at Privileged ISA MMU tests in particular. Some of these still use a proprietary HTIF test reporting interface. Test reporting mechanisms will have to be considered in a way that places lightweight restrictions on the target environment. e.g. vendor implements target specific putc (HTIF, UART, etc). This is based on the observation that one only requires a simple parser and the ability to log output from the target environment, or provide input data if required for the tests.

Many of the existing tests in riscv-tests already use the simple console reporting mechanism. If a more sophisticated HTIF Test Reporting mechanism was required to be implemented by the vendor, it raises the complexity required to run the tests and the interface needs to be adequately documented.

I think character IO and a test identification mnemonic, test number and PASS or FAIL might be the simplest, perhaps an evolution of the scheme in riscv-tests…

The reason I’m raising this now is that I’m trying to port some of the MMU tests that are dependent on the HTIF Test reporting interface so that they will run in QEMU… Not to pre-empt the compliance working group direction here, rather as a practicality based on the continued maintenance of the pre-existing open source riscv-tests suite, and to minimise the footprint or dependence on the test environment. e.g. requiring HTIF support.


I can see that there will be crossover between functional verification and compliance testing. It’s just that i’m poking around in riscv-tests right now… and have been working on constraining QEMU to model restricted environments… hence the interest in negative testing of extension opcode space…

[Luke Kenneth Casson Leighton]

On Thu, May 24, 2018 at 12:10 AM, <kr...@berkeley.edu> wrote:

> Platform compliance tests can check additional constraints for that
> platform. For example, one platform profile might demand that all
> unimplemented standard encodings and all reserved encodings cause
> illegal instruction traps to ensure forward compatibility.

this would allow RV to be perceived as a versatile standard that can
adapt and grow over the next N decades.

> Other platform profiles might not care.

yes... i can see why for example area-constrained or embedded
"one-shot" (e.g. washing machine controller or HDD controller or Motor
Controller) implementations might not wish to have to catch absolutely
every missing instruction, they're never (ever) going to care as the
firmware is *never* going to be "upgraded".

i think it's safe to say that the correlation between "RV impls may /
never need upgrading of the SW/FW" and "RV impls will / never need to
trap all unimplemented / reserved encodings" is 100%, and consequently
the standard needs to make it absolutely clear:

"If an implementation is to have embedded firmware that will never
change, is factory-installed, or {insert other isolated types of
scenarios}, it MAY ignore unimplemented and reserved encodings. If
however an implementation is intended to be user-upgraded, or
interacts with the larger world-wide community in any way {you get the
general idea here, exact wording TBD}, it MUST cause illegal
instruction traps"

i'm struggling to think of exact wording as it's quite hard to
define: i just know from experience of having looked at the
characteristics that properly forward-thinking successful future-proof
standards have, that this is really important to get right.

l.

[Clifford Wolf]

Hi,

On Thu, May 24, 2018 at 1:10 AM, <kr...@berkeley.edu> wrote:

I would propose that ISA compliance tests only test the encodings
standardized in that ISA module.

For the base instruction set, we have proposed 16 0s and 32 1s are
required to raise illegal instruction exceptions, and only these
should be checked in base ISA compliance suite.

I fully agree with this goal.

However, I'm not sure how such a check would look like in reality. If I understood you correctly at the workshop in Barcelona, the idea is that an implementation might come with their own priv spec and only implement the "User level RISC-V ISA", and should still be able to claim "base ISA compliance". (And I think that's great because I maintain one such core. :)

But how do I check with a portable test if an implementation raises an illegal instruction exception, if the base spec does not specify how those exceptions are handled by a compliant implementation?

Section 1.3 of the base spec ("Exceptions, Traps, and Interrupts") allows for a wide range of behaviors in an implementation. In my interpretation this range of possible behaviors include

- Trigger an imprecise trap that may be delayed by an arbitrary (non-deterministic) number of instructions and/or cycles

- Simply treat all illegal instructions as NOPs, or treat them as instructions that set some error flag and otherwise behave as NOPs

- Completely halt the processor

Or in other words, the spec gives no guarantees that an implementation:

- Triggers a precise trap, or a trap at all

- Can recover from an exception (i.e. exceptions might simply halt the processor)

- Can distinguish different types of exceptions when handling the trap

There are also a few related issues. For example, consider an implementation that does not claim to implement the C extension, or any ISA extension that adds instructions that aren't multiples of 4 bytes in size. What is the range of allowed behaviors for such a processor when encountering a branch or JAL instruction that doesn't jump a multiple of 4 bytes? To pick an extreme example: Would an implementer be allowed to repurpose imm[1] as imm[21]^imm[20] for JAL (imm[13]^imm[12] for branch) in order to double the range of the jump instructions and still claim to be RISC-V compatible?

I've had private email exchanges with Allen Baum regarding those issues. My proposal is to create a separate set of tests for each type of exception and just tell the implementer that when they execute any of the test cases from say the "illegal instruction" set, they should expect the core to do whatever it does for an illegal instruction exception. Some cores might be able to distinguish the different exception types and then the implementer should check that the correct exception is triggered. Other cores might just hang on any kind of exception and then all an implementer would need to do is check that all the tests that are expected to trigger an exception actually do hang the core, and that the remaining tests do not hang the core.

However, this is not a very satisfying solution imo because it violates the doctrine that compliance tests should not be self-checking but always output a "signature" that can be checked externally.

regards,

 - Clifford

PS: 32 1s is illegal? Wasn't there the proposal that 16 1s should already be an illegal prefix? Also: What is with implementations that do not claim "C"? Are they required to treat everything as illegal instruction that starts with a prefix of 16 0s? Or can they use this prefix in custom 32 bit instructions?

[kr...@berkeley.edu]

Most non-Unix embedded systems of the kind you mention, compile all
new code from source when producing a new firmware image, avoiding the
need to trap-and-emulate new standard extensions. Even when using new
pre-compiled third-party libraries, these would most likely be offered
in versions that remain compatible with the instruction extensions
already present in the hardware.

The only scenario where you would want to mandate illegal instruction
traps for non-Unix field-upgradeable embedded systems is if:

a) you were contemplating adding a new third-party binary-only library
that was compiled using instructions you did not have in your hardware

AND

b) the performance of trap-and-emulate meant you could still
contemplate doing this in a product.

An embedded profile can define the instructions that are required, and
most 3rd-party library suppliers would want to always supply libraries
compatible with the existing profiles, as well as offer libraries for
future extended platform profiles. So, I don't think there'll be a
great desire to support trap-and-emulate in these kinds of embedded
systems, as they can be future proof without.

There are, of course, many Unix-based embedded systems that would
stick with Unix platform, which might very well include
the trap-all-standard/reserved requirement.

Krste

>>>>> On Thu, 24 May 2018 11:12:17 +0100, Luke Kenneth Casson Leighton <lk...@lkcl.net> said:
|| Other platform profiles might not care.

| yes... i can see why for example area-constrained or embedded
| "one-shot" (e.g. washing machine controller or HDD controller or Motor
| Controller) implementations might not wish to have to catch absolutely
| every missing instruction, they're never (ever) going to care as the
| firmware is *never* going to be "upgraded".

| i think it's safe to say that the correlation between "RV impls may /
| never need upgrading of the SW/FW" and "RV impls will / never need to
| trap all unimplemented / reserved encodings" is 100%, and consequently
| the standard needs to make it absolutely clear:

| "If an implementation is to have embedded firmware that will never
| change, is factory-installed, or {insert other isolated types of
| scenarios}, it MAY ignore unimplemented and reserved encodings. If
| however an implementation is intended to be user-upgraded, or
| interacts with the larger world-wide community in any way {you get the
| general idea here, exact wording TBD}, it MUST cause illegal
| instruction traps"

| i'm struggling to think of exact wording as it's quite hard to
| define: i just know from experience of having looked at the
| characteristics that properly forward-thinking successful future-proof
| standards have, that this is really important to get right.

| 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+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/CAPweEDwD9oX1dJCKC5T_bzp6JCiAt9cmsCyaJ0Ns_5Nw7MbCfw%40mail.gmail.com.

[Allen Baum]

Nevertheless, if a platform is looking to the future and wants to reserve current illegal opcodes, compliance tests should have a way to test that- and once you can specify that to the infrastructure it's pretty easy to make it an arbitrary set of opcodes. Anything not explicitly reserved is not tested.

To me, the difficult part is defining the grammar that the compliance framework interprets to determine which opcodes it should test for trapping as illegal.

-Allen

[Liviu Ionescu]

On 10 May 2018 at 02:37:29, Allen Baum (allen...@esperantotech.com) wrote:

> And, if you're replacing the entire privileged state with your
> own, you need to declare that as well, and if it's a spec'ed alternative
> we'd select different tests, and if it's not we test-- ?nothing?
> - that will be an interesting discussion.

that's why I suggested to restructure the minimum test to not depend
on the privileged definition at all, but cover only the instruction
set.

in other words, you check what extensions are present, and check them
one by one.

at this level, in addition to the instructions themselves, you only
need a way to identify which extesions are present, probably a single
CSR, nothing more.

once you're done with instructions, you need a second register to tell
what profile you use (privileged, microcontroller, custom), and you
possibly run a second set of tests. if the profile is custom and you
do not know how to test it, you stop, but at least you validated the
instructions.

one note about extensibility: the compliance framework preferably
should be extensible, those who define custom extensions and/or custom
profiles should have a method to extend the framework with custom
tests.


regards,

Liviu

[Luke Kenneth Casson Leighton]

On Thu, May 24, 2018 at 5:42 PM, <kr...@berkeley.edu> wrote:

> Most non-Unix embedded systems of the kind you mention, compile all
> new code from source when producing a new firmware image, avoiding the
> need to trap-and-emulate new standard extensions. Even when using new

>[...]

> future extended platform profiles. So, I don't think there'll be a
> great desire to support trap-and-emulate in these kinds of embedded
> systems, as they can be future proof without.

yeah that sounds like a perfectly reasonable analysis to me.
question is, how would it be worded in a succinct, unambiguous and
clear way that could be included in the standard?

> There are, of course, many Unix-based embedded systems that would
> stick with Unix platform, which might very well include
> the trap-all-standard/reserved requirement.

yehyeh, likewise.

l.

[Luke Kenneth Casson Leighton]

On Thu, May 24, 2018 at 6:00 PM, Allen Baum
<allen...@esperantotech.com> wrote:

> To me, the difficult part is defining the grammar that the compliance framework interprets to determine which opcodes it should test for trapping as illegal.

yeh... the formal-definition bit has me a bit stumped / stymied as well :)

l.

[kr...@berkeley.edu]

It is impossible to check that all reserved encodings trap properly.

The longer instruction encodings, in particular, make it very easy to
hide a valid encoding in a long bit string (e.g., an implementation
supports exactly one 256-bit encoding).

There are tricks using PMPs or VM that might help determine an
implementation's ILEN, but these obviously don't work when you don't
have either of these. Even then, once ILEN grows, it becomes
exponentially difficult to test for compliance with an "illegal
instructions must trap" mandate.

We can test some things, but I'm not sure of the value of very
sparsely sampled tests of compliance for illegal instruction traps.

Platforms requiring that reserved instructions trap might have to rely
on careful specifications and vendor assertions of compliance.


Krste

[kr...@berkeley.edu]

>>>>> On Thu, 24 May 2018 14:57:32 +0200, Clifford Wolf <cliffor...@gmail.com> said:
| Hi,
| On Thu, May 24, 2018 at 1:10 AM, <kr...@berkeley.edu> wrote:

| I would propose that ISA compliance tests only test the encodings
| standardized in that ISA module.

| For the base instruction set, we have proposed 16 0s and 32 1s are
| required to raise illegal instruction exceptions, and only these
| should be checked in base ISA compliance suite.


| I fully agree with this goal.

| However, I'm not sure how such a check would look like in reality. If I
| understood you correctly at the workshop in Barcelona, the idea is that an
| implementation might come with their own priv spec and only implement the "User
| level RISC-V ISA", and should still be able to claim "base ISA compliance".
| (And I think that's great because I maintain one such core. :)

| But how do I check with a portable test if an implementation raises an illegal
| instruction exception, if the base spec does not specify how those exceptions
| are handled by a compliant implementation?

The compliance tests can define a region of the test signature in
which detected exceptions are reported, and the test execution
environment for the platform should cause an exception to write its
platform-independent details there (e.g., for ISA-only compliance,
this might just report the PC offset of instructions that caused
illegal instruction traps).

I think an argument could be made that no exception checks should be
made in ISA-only compliance tests, as this implies a given platform
exception model.

But there is at least one reason to have a defined illegal instruction
pattern, in that compilers want something to put on "should never be
executed" bad code paths. This could be EBREAK, but this causes
overloading of EBREAK between "stop here" and "error here".


[...]

| There are also a few related issues. For example, consider an implementation
| that does not claim to implement the C extension, or any ISA extension that
| adds instructions that aren't multiples of 4 bytes in size. What is the range
| of allowed behaviors for such a processor when encountering a branch or JAL
| instruction that doesn't jump a multiple of 4 bytes? To pick an extreme
| example: Would an implementer be allowed to repurpose imm[1] as imm[21]^imm[20]
| for JAL (imm[13]^imm[12] for branch) in order to double the range of the jump
| instructions and still claim to be RISC-V compatible?

| I've had private email exchanges with Allen Baum regarding those issues. My
| proposal is to create a separate set of tests for each type of exception and
| just tell the implementer that when they execute any of the test cases from say
| the "illegal instruction" set, they should expect the core to do whatever it
| does for an illegal instruction exception. Some cores might be able to
| distinguish the different exception types and then the implementer should check
| that the correct exception is triggered.

See above, for one idea on how to encode platform-independent
exception catch.

| Other cores might just hang on any
| kind of exception and then all an implementer would need to do is check that
| all the tests that are expected to trigger an exception actually do hang the
| core, and that the remaining tests do not hang the core.
| However, this is not a very satisfying solution imo because it violates the
| doctrine that compliance tests should not be self-checking but always output a
| "signature" that can be checked externally.

Right. Having cores hang on exceptions does not ever sound like a good
idea. It also makes building an automated compliance suite very
difficult. If you can detect the exception, you should try to do
something better with your hardware.

The whole point of compliance is to ensure cores meet some minimum
standard, and while it's fine for folks to develop cores below that
minimum, there's no reason for them to expect to get a compliance gold
star.

| regards,
|  - Clifford

| PS: 32 1s is illegal? Wasn't there the proposal that 16 1s should already be an
| illegal prefix?

Instruction decoders will see all 1s as an instruction of ILEN, which
is at least 32 so will gather all >=32 bits before reporting an
exception. So there's no implementation benefit to requiring just 16
1s to be illegal, but there would be a negative of impinging on very
long instruction encoding space.

| Also: What is with implementations that do not claim "C"? Are
| they required to treat everything as illegal instruction that starts with a
| prefix of 16 0s? Or can they use this prefix in custom 32 bit
| instructions?

Terminology nit: Custom means "not standard and not reserved", so it
was never possible to use for custom instructions.

I guess we could separate IALIGN=32 implementations to only check 32 all
0s as illegal to allow non-standard 32-bit encodings with high bits 0.

Krste

[Allen Baum]

More good questions and comments.

I've been on vacation, and far too distracted to write this up until now.
I talked with Krste (and others) at the workshop, and (I think) now understand more nuances.

CSR read/write ops are not in themselves privileged - except that if the CSR address is considered part of the op, then (since the allowed privilege modes are 2 of the address bits) some CSR read/write ops are privileged.

It's a corner case. So, ISA U-mode tests could test CSRRW ops that touch only the defined U-Mode CSR

I'll be writing some of this up, but another issue (on my part) is the difference between a profile and a platform, and how it relates to compliance tests.

A profile is something that is implemented.

A platform is a minimal set of profiles required for some application set (e.g. running Unix application binaries)

So, a compliance test for a platform could require MUL and DIV .

If the profile includes the M-extension, then U-mode M-extension tests (should) just work.

if the profile doesn't include the M-extension but it is required by the platform, then the profile must include a run-time illegal instruction handler that emulates them (or maybe DIV only if HW implements MUL), and M-mode (and/or S-mode) M-extension tests will pass.

But: can you pass user ISA MUL/DIV tests without actually implementing MUL/DIV and having the MISA.M set?

If you try, and it isn't set, you'll trap on one or the other of them - and now you're testing privileged architecture features of trap handling, which isn't U-mode, and you'll fail.

.

So, then answer here is along the lines of "if it hurts when you do that, don't do that".

The compliance framework will be told the platform (MUL/DIV op support is required), the profile (there is no M-extension), and what the test environment is (which includes the run-time environment code with MUL/DIV emulation support), and will run U-mode ISA tests without MUL/DIV tests, and M/S-mode tests that with MUL/DIV tests.

[Luke Kenneth Casson Leighton]

On Tue, May 29, 2018 at 3:34 AM, Allen Baum
<allen...@esperantotech.com> wrote:

> But: can you pass user ISA MUL/DIV tests without actually implementing
> MUL/DIV and having the MISA.M set?
> If you try, and it isn't set, you'll trap on one or the other of them - and
> now you're testing privileged architecture features of trap handling, which
> isn't U-mode, and you'll fail.

ok, so the key question is: is an implementation permitted to be made
that will pass the compliance tests by partly implementing the
specification in software (as traps) and partly in software.

in my mind it makes no sense for the answer to that question to be
"no".... *regardless* of how ridiculously slow the real-world
performance of such a system might be. the reasons:

(1) area-constrained implementations.
(2) upgrades to the RISC-V specification that an implementation
previously passed (and would now otherwise fail)
(3) silicon errata

now, should such an implementation be permitted to claim compliance
WITHOUT having the supporting (certified) traps? of course it should
not!

just a thought.

l.

[Bruce Hoult]

I agree.

User-mode compliance testing should test whether programs containing legal instructions produce the correct results.

Users who care about particular performance levels on particular hardware should benchmark available hardware options on the code they plan to run (or a reasonable approximation to it, or read benchmarking reports from 3rd parties).

[Clifford Wolf]

Hi,

On Mon, May 28, 2018 at 10:27 PM, <kr...@berkeley.edu> wrote:

The compliance tests can define a region of the test signature in
which detected exceptions are reported, and the test execution
environment for the platform should cause an exception to write its
platform-independent details there (e.g., for ISA-only compliance,
this might just report the PC offset of instructions that caused
illegal instruction traps).

My reading of section 1.3 of the spec is that there is no requirement

for the execution environment to provide precise traps. So requiring

the compliance test to report the PC offset of the instruction that caused

the trap is problematic imo because it requires functionality beyond

the requirement laid out by the spec.

If the compliance test requires illegal instruction exceptions to trigger

a precise trap, than this should also required by the spec. Right now

the spec does not require exceptions to trigger any kind of trap,

precise or imprecise.

I think an argument could be made that no exception checks should be
made in ISA-only compliance tests, as this implies a given platform
exception model.

But there is at least one reason to have a defined illegal instruction
pattern, in that compilers want something to put on "should never be
executed" bad code paths.  This could be EBREAK, but this causes
overloading of EBREAK between "stop here" and "error here".

I agree that if possible all-0s and all-1s should be checked by compliance tests

for exactly that reason. I'm just not sure how it can be done without requiring

more than what the spec requires.

Btw, this also raises the question how EBREAK and ECALL should be handled

in the base-ISA compliance test.

It is not quite clear to me what the bounds of legal behavior for those instructions

is for an implementation that has their own priv spec.

| Other cores might just hang on any
| kind of exception and then all an implementer would need to do is check that
| all the tests that are expected to trigger an exception actually do hang the
| core, and that the remaining tests do not hang the core.
| However, this is not a very satisfying solution imo because it violates the
| doctrine that compliance tests should not be self-checking but always output a
| "signature" that can be checked externally.

Right. Having cores hang on exceptions does not ever sound like a good
idea.  It also makes building an automated compliance suite very
difficult.  If you can detect the exception, you should try to do
something better with your hardware.

I think the point is not whether it is a good idea but whether if it is allowed by

the spec.

If it is allowed by the spec then I think the compliance test should be compatible

with such an implementation.

If the compliance test is not going to be compatible with such an implementation

then I think the spec should not allow it.

The whole point of compliance is to ensure cores meet some minimum
standard, and while it's fine for folks to develop cores below that
minimum, there's no reason for them to expect to get a compliance gold
star.

But if the compliance test has requirements above and beyond the spec requirements,

then it is not a spec compliance test anymore but something else. I think a core that

complies to the spec should be able to pass the compliance test.

(There is the issue of cores with ridiculously small address spaces. I think the extra

requirement of for example at least 4 kB code ROM and at least 256 bytes RAM

would make sense. And even though not all RISC-V *systems* will have this much

memory, it will be possible to build a system that meets those requirements with

every *core*. But this is not the case with cores that for example to not provide

precise traps for illegal instruction exceptions.)

| PS: 32 1s is illegal? Wasn't there the proposal that 16 1s should already be an
| illegal prefix?

Instruction decoders will see all 1s as an instruction of ILEN, which
is at least 32 so will gather all >=32 bits before reporting an
exception.  So there's no implementation benefit to requiring just 16
1s to be illegal, but there would be a negative of impinging on very
long instruction encoding space.

That makes sense. Thanks for the explanation.

(One argument against this definition would be that this would mean that

we can't trust that unwritten flash regions will cause an illegal instruction

trap because there is no guarantee that the unwritten "gap" is larger than

16 bits.)

Also, for an illegal instruction at the end of the page, I thought the algorithm

for determining whether to raise an illegal instruction exception or an instruction

page fault was as follows:

(1) Read IALIGN length instruction prefix

(2) If that IALIGN-length prefix encodes for an unsupported instruction

length then raise an illegal instruction exception

(3) Read entire rest of the instruction *without* early-exit if the instruction can
already be determined to be illegal.

(4) If any part of the instruction triggers a page fault then raise an
instruction page fault exception.
(5) Otherwise, if the instruction encodes for an illegal instruction then
raise an illegal instruction exception.

So, if I understood you correctly, the algorithm should in fact be:

(1) Read IALIGN length instruction prefix

(1a) If IALIGN=16 and the two LSB bits of the instruction are 11, then read two

more bytes, triggering instruction page fault exception if necessary.

(2) If that 16-bit or 32-bit prefix encodes for an unsupported instruction length then

raise an illegal instruction exception

(3) Read entire rest of the instruction *without* early-exit if the instruction can
already be determined to be illegal.

(4) If any part of the instruction triggers a page fault then raise an
instruction page fault exception.
(5) Otherwise, if the instruction encodes for an illegal instruction then
raise an illegal instruction exception.

(With the added step 1a and changed "that IALIGN-lenght prefix" to "that 16-bit or 32-bit prefix".)

Is this correct?

| Also: What is with implementations that do not claim "C"? Are
| they required to treat everything as illegal instruction that starts with a
| prefix of 16 0s? Or can they use this prefix in custom 32 bit
| instructions?

Terminology nit: Custom means "not standard and not reserved", so it
was never possible to use for custom instructions.

Ah. So reusing the C space in that way would be "non-standard" but not "custom". Got it.

I guess we could separate IALIGN=32 implementations to only check 32 all
0s as illegal to allow non-standard 32-bit encodings with high bits 0.

* "with low bits 0" I guess. :)

Yes, I think that would make sense.

regards,

 - clifford

[Luke Kenneth Casson Leighton]

On Wednesday, May 30, 2018, Clifford Wolf <cliffor...@gmail.com> wrote:

Hi,

(There is the issue of cores with ridiculously small address spaces. I think the extra

requirement of for example at least 4 kB code ROM and at least 256 bytes RAM

would make sense. 

Like the STM8S003, sells for $0.20 in qty one, it goes into washing machines and microwave ovens by the billion. Has 1k EEPROM and 256 bytes RAM if vague memory serves.

--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Michael Clark]

> On 25/05/2018, at 12:57 AM, Clifford Wolf <cliffor...@gmail.com> wrote:
>
> Hi,
>
> On Thu, May 24, 2018 at 1:10 AM, <kr...@berkeley.edu> wrote:
> I would propose that ISA compliance tests only test the encodings
> standardized in that ISA module.
>
> For the base instruction set, we have proposed 16 0s and 32 1s are
> required to raise illegal instruction exceptions, and only these
> should be checked in base ISA compliance suite.
>
> I fully agree with this goal.
>
> However, I'm not sure how such a check would look like in reality. If I understood you correctly at the workshop in Barcelona, the idea is that an implementation might come with their own priv spec and only implement the "User level RISC-V ISA", and should still be able to claim "base ISA compliance". (And I think that's great because I maintain one such core. :)
>
> But how do I check with a portable test if an implementation raises an illegal instruction exception, if the base spec does not specify how those exceptions are handled by a compliant implementation?
>
> Section 1.3 of the base spec ("Exceptions, Traps, and Interrupts") allows for a wide range of behaviors in an implementation. In my interpretation this range of possible behaviors include
>
> - Trigger an imprecise trap that may be delayed by an arbitrary (non-deterministic) number of instructions and/or cycles
>
> - Simply treat all illegal instructions as NOPs, or treat them as instructions that set some error flag and otherwise behave as NOPs
>
> - Completely halt the processor
>
> Or in other words, the spec gives no guarantees that an implementation:
>
> - Triggers a precise trap, or a trap at all
>
> - Can recover from an exception (i.e. exceptions might simply halt the processor)
>
> - Can distinguish different types of exceptions when handling the trap

"The instruction descriptions in following chapters describe conditions that raise an exception during execution. Whether and how these are converted into traps is dependent on the execution environment, though the expectation is that most environments will take a precise trap when an exception is signaled (except for floating-point exceptions, which, in the standard floating-point extensions, do not cause traps).”

There is a clear expectation that the execution environment can signal the specified traps and exceptions. The current Privileged ISA describes a concrete mechanism to do this.

There is nowhere that says a Compliance specification can’t turn that expectation into a requirement i.e. have stronger wording that specifies that traps and exceptions documented in the Base ISA must be able to be distinguished for compliance purposes. The Base ISA itself does not specify the mechanism for which compliance is tested, however it does indicate expectations on the execution environment.

That expectation, combined with a mechanism can be translated into a test harness with an interface to detect the specified traps. i.e. PC and some cause code that can be mapped to the causes mentioned in the Base ISA spec (a harness could translate codes to the Privileged ISA codes).

If one replaces the Privileged ISA, then this will place a burden on a test harness to translate the exceptions in the English text of the Base ISA into bit patterns sent to a trap handler that can be used by the test harness. It seems like a minimal harness based on the exception handling interface and bit patterns / codes specified by the current Privileged ISA might be a decent interface. One simply needs a small map of integers.

I think that if the specification requires that X exception is generated, that it is a /reasonable/ expectation that this can be tested. Clearly however this is not strong enough wording. i.e. expectation is too soft. It’s clearly /unreasonable/ to be able to Test for compliance without getting some cause for illegal and/or misaligned exceptions. i.e. the exceptions mentioned in the Base ISA spec.

Clifford, do you think an undistinguishable behaviour like a processor hang would comply with the specification when a distinct exception is documented to be signaled? It seems like a “profile” that can’t test for any illegal behaviour. I don’t think this is the expectation.

I think we should apply common sense, rather than language lawyer a “possible reading” that is essentially untestable. I think the “expectation” is that compliance can be tested.

> There are also a few related issues. For example, consider an implementation that does not claim to implement the C extension, or any ISA extension that adds instructions that aren't multiples of 4 bytes in size. What is the range of allowed behaviors for such a processor when encountering a branch or JAL instruction that doesn't jump a multiple of 4 bytes? To pick an extreme example: Would an implementer be allowed to repurpose imm[1] as imm[21]^imm[20] for JAL (imm[13]^imm[12] for branch) in order to double the range of the jump instructions and still claim to be RISC-V compatible?
>
> I've had private email exchanges with Allen Baum regarding those issues. My proposal is to create a separate set of tests for each type of exception and just tell the implementer that when they execute any of the test cases from say the "illegal instruction" set, they should expect the core to do whatever it does for an illegal instruction exception. Some cores might be able to distinguish the different exception types and then the implementer should check that the correct exception is triggered. Other cores might just hang on any kind of exception and then all an implementer would need to do is check that all the tests that are expected to trigger an exception actually do hang the core, and that the remaining tests do not hang the core.
>
> However, this is not a very satisfying solution imo because it violates the doctrine that compliance tests should not be self-checking but always output a “signature" that can be checked externally.

Agree that we should have a goal of outputting a signature from the test suite which can be diffed with an exemplar.

There are a few simple things we improve in the pre-existing open source test infrastructure:

- a test in a suite does not prevent another test from running
- tests output the test mnemonic, test number and test result
- dependencies on the execution environment are minimised

[Clifford Wolf]

Hi,

On Wed, May 30, 2018 at 3:34 PM, Michael Clark <michae...@mac.com> wrote:

I think we should apply common sense, rather than language lawyer a “possible reading” that is essentially untestable. I think the “expectation” is that compliance can be tested.

Sorry, I think you fundamentally misunderstood me. I'm not saying it must be allowed because of this or that reading of the current spec.

I'm saying that, if it is not allowed, then the spec should be explicit about that. Just relying on "common sense" is not enough!

For example, if a processor that cannot distinguish between different exceptions is not deemed compliant, than the spec should

state explicitly that this is a requirement.

It is perfectly fine to guide such clarifications in the spec by what common sense dictates and/or what the expectation is. But the

clarification is necessary! Just relying on "common sense" is completely unacceptable when it comes to spec ambiguities imo.

And at least to me the spec phrase ".. the expectation is that most environments will .." does not have normative character and

simply expresses a recommendation, not a requirement that must be fulfilled in order to be spec compliant.

Clifford, do you think an undistinguishable behaviour like a processor hang would comply with the specification when a distinct exception is documented to be signaled?

Can you point me to the paragraph in the spec that says the exception must be "signaled", and furthermore, can you point me to

the paragraph that states what information about that signaled exception must be made available, and in which form?

Because that is certainly not part of section "1.3 Exceptions, Traps, and Interrupts" of the base spec.

All that section does is specify that exceptions can "occur" at run time.

If they are converted to traps, if those traps are precise, and what information about the exception might

be made available to the trap handler is completely implementation defined afaics.

The spec is pretty explicit that there is no requirement to convert exceptions to traps (quoting 1.3):

"The instruction descriptions in following chapters describe conditions that raise an exception during  execution.   Whether  and

how  these  are  converted  into  traps  is  dependent  on  the  execution environment .."

It also provides a definition of what exactly a trap is:

"We use the term trap to refer to the synchronous transfer of control to a trap handler caused by an exceptional condition occurring within a RISC-V thread."

So if that is the definition of a trap, and it is implementation defined whether an exception is converted into a trap, then I think yes, a processor

that would simply hang (until some kind of external reset) in response to an exception could be compliant with the spec as it is currently worded.

regards,

 - clifford

[Jacob Bachmeyer]

Clifford Wolf wrote:
> [...]

>
> The spec is pretty explicit that there is no requirement to convert
> exceptions to traps (quoting 1.3):
>
> "The instruction descriptions in following chapters describe
> conditions that raise an exception during execution. Whether and
> how these are converted into traps is dependent on the
> execution environment .."
>
>
> It also provides a definition of what exactly a trap is:
>
> "We use the term trap to refer to the synchronous transfer of
> control to a trap handler caused by an exceptional condition
> occurring within a RISC-V thread."
>
>
> So if that is the definition of a trap, and it is implementation
> defined whether an exception is converted into a trap, then I think
> yes, a processor
> that would simply hang (until some kind of external reset) in response
> to an exception could be compliant with the spec as it is currently
> worded.

Such a processor could also be useful: I suggested a model in the past
where each S-mode hart provides "S-mode" for some number of U-mode-only
harts, which halt and send an interrupt to their "supervisor hart"
whenever a full hart would trap. These harts can be effectively a
number of per-mode minimal cores.

In other words, an exception may (usefully) cause the thread
encountering the exception to halt and cause a trap on *another* thread
(that presumably spends most of its time halted on WFI).


-- Jacob

[Luke Kenneth Casson Leighton]

On Fri, Jun 1, 2018 at 2:42 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:

> In other words, an exception may (usefully) cause the thread encountering
> the exception to halt and cause a trap on *another* thread (that presumably
> spends most of its time halted on WFI).

oo nice. would make a lot of sense on a hyperthreaded
implementation, and also if cores are non-uniform (different
capabilities).

l.

[Cesar Eduardo Barros]

Em 31-05-2018 22:42, Jacob Bachmeyer escreveu:

> Clifford Wolf wrote:
>>
>> So if that is the definition of a trap, and it is implementation
>> defined whether an exception is converted into a trap, then I think
>> yes, a processor
>> that would simply hang (until some kind of external reset) in response
>> to an exception could be compliant with the spec as it is currently
>> worded.
>
> Such a processor could also be useful:  I suggested a model in the past
> where each S-mode hart provides "S-mode" for some number of U-mode-only
> harts, which halt and send an interrupt to their "supervisor hart"
> whenever a full hart would trap.  These harts can be effectively a
> number of per-mode minimal cores.
>
> In other words, an exception may (usefully) cause the thread
> encountering the exception to halt and cause a trap on *another* thread
> (that presumably spends most of its time halted on WFI).

This is a very interesting idea (and conceptually similar to a software
microkernel, where traps are serviced by a separate process, with the
kernel only doing the necessary context switching). However, unless
there's one "S-mode" hart for every "U-mode" hart, this could have
performance issues similar to the "Big Kernel Lock" we had on Linux
decades ago: all S-mode accesses are effectively serialized.

The current design where every hart can be used as either U-mode or
S-mode, switching between them based on demand for the respective mode,
is probably optimal in use of hardware resources and performance.

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

[Allen Baum]

A  core that claimed to be RISC-V complaint, and claimed to implement the priv mode, but did not in fact - it halts, lets some other core handle it, then starts up again - is NOT compliant, by my understanding..

However, the platform - which includes all the handler code and the other core(s) as a system - would be. (IMHO)

(Oh, and it would have to pass compliance tests, of course :-)

You need to be very specific as to where you draw the boundary around what you claim is compliant.

Then you can argue about it.

[Jacob Bachmeyer]

For general purpose systems, probably so. For specialized applications
that spend almost all of their time in U-mode and rarely make system
calls or do I/O (or I/O is memory-mapped at user level), such a design
might make sense. I first suggested it in response to a question about
grid computing with RISC-V. (I have probably misunderstood "grid
computing" but...) The idea was that a U-mode-only hart might be
simpler (since its TLBs are operated by its supervisor hart and might be
shared between some number of U-mode-only harts) to implement in
hardware and an application with a very unbalanced workload might be
able to benefit from additional U-mode-only harts more than it loses
from the limited availability of the supervisor.


-- Jacob

[Jacob Bachmeyer]

Allen Baum wrote:
> A core that claimed to be RISC-V complaint, and claimed to implement
> the priv mode, but did not in fact - it halts, lets some other core
> handle it, then starts up again - is NOT compliant, by my understanding..
> However, the platform - which includes all the handler code and the
> other core(s) as a system - would be. (IMHO)
> (Oh, and it would have to pass compliance tests, of course :-)
>
> You need to be very specific as to where you draw the boundary around
> what you claim is compliant.
> Then you can argue about it.

Such a hart would need to be declared as "U-mode-only" and therefore
would *not* claim to implement the privileged modes, only the RISC-V
user ISA. Could it be compliant in this sense? (Presumably it would
only run the "RISC-V user ISA" compliance tests.)


-- Jacob

[Allen Baum]

I thought this had been discussed.
Passing the basic Umode ISA test is necessary for compliance, but not sufficient.
That might be all that you need for an educational simulator, but little else- but I don't think that is enough to be able to use the RISCV trademark- which the point if the compliance tests.

I suppose you could say that you passed the basic RiscV Umode ISA compliance tests (but I am not a lawyer)

-Allen