device compliance question for partially implemented standard extensions

[simon5656]

If a designer implements a device which supports

• Machine Privilege
• RISCV32 I
• RISCV32 M (Multiply instructions, but no Divide)

Is the device compliant RV32I ?

Is the device compliant RV32IM ?

thanks Simon Davidmann, Imperas

[aswaterman]

I think the litmus test is, does the corresponding compliance suite run? A device that cannot execute the DIV instruction cannot claim to implement the M extension, but implementing only a subset of the M extension is a perfectly valid thing to do, and doesn’t break RV32I compliance.

On Wed, Jul 17, 2019 at 7:44 AM Simon Davidmann notifications@github.com wrote:

If a designer implements a device which supports

• Machine Privilege
• RISCV32 I
• RISCV32 M (Multiply instructions, but no Divide)

Is the device compliant RV32I ?

Is the device compliant RV32IM ?

thanks Simon Davidmann, Imperas

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUOZT5EYGRV333FC3DP74V6PA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G7YKHKQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH3XQW4OK6XEWIAWKOMXATP74V6PANCNFSM4IERF6UQ .

[pdonahue-ventana]

What if divides get invisible traps and are emulated by the EE? Does the compliance suite test the EE or the underlying hardware?

[neelgala]

@aswaterman what if the MUL opcode is re-used as a custom op by device? Would you still consider it to be RISC-V compliant? If not then you need tests to verify that the absence of a standard extension undergoes a trap, in which case implementing a subset of M would deem non-compliance.

[aswaterman]

Emulation via invisible traps is intended to be a valid approach—though if the execution environment is bare-metal M-mode, can a trap to M-mode possibly be invisible?

On Wed, Jul 17, 2019 at 10:44 AM Paul Donahue notifications@github.com wrote:

What if divides get invisible traps and are emulated by the EE? Does the compliance suite test the EE or the underlying hardware?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQTGH5V57ATFSX2FWQ3P75LAFA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2F5JKY#issuecomment-512480427, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH3XQXHJG74IBZQ2WHJ7ULP75LAFANCNFSM4IERF6UQ .

[aswaterman]

If the MUL opcode doesn’t do what the spec says the MUL opcode does, then it’s obviously noncompliant with the M extension, but it could still be compliant with RV32I.

On Wed, Jul 17, 2019 at 10:49 AM Neel Gala notifications@github.com wrote:

@aswaterman https://github.com/aswaterman what if the MUL opcode is re-used as a custom op by device? Would you still consider it to be RISC-V compliant? If not then you need tests to verify that the absence of a standard extension undergoes a trap, in which case implementing a subset of M would deem non-compliance.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUOEBJYGRPNG6OQFZ3P75LTHA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GAIHI#issuecomment-512492573, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH3XQXZ364U4UNJRR3JGFLP75LTHANCNFSM4IERF6UQ .

[pdonahue-ventana]

Emulation via invisible traps is intended to be a valid approach—though if the execution environment is bare-metal M-mode, can a trap to M-mode possibly be invisible?

How about an implementation with two modes, one unprivileged and one non-standard privileged which emulates divides that are invisibly trapped from the unprivileged mode? There can obviously be no standard compliance tests for the non-standard privileged architecture but there must be a way to test compliance of the standard-compliant unprivileged mode.

Is this true: The compliance suite must declare an implementation that invisibly traps and emulates divides as compliant. The compliance suite tests the EE, not the hardware.

[aswaterman]

I agree with that sentiment, Paul, but I don't actually know what the current compliance suite does.

On Wed, Jul 17, 2019 at 11:05 AM Paul Donahue notifications@github.com wrote:

Emulation via invisible traps is intended to be a valid approach—though if the execution environment is bare-metal M-mode, can a trap to M-mode possibly be invisible?

How about an implementation with two modes, one unprivileged and one non-standard privileged which emulates divides that are invisibly trapped from the unprivileged mode? There can obviously be no standard compliance tests for the non-standard privileged architecture but there must be a way to test compliance of the standard-compliant unprivileged mode.

Is this true: The compliance suite must declare an implementation that invisibly traps and emulates divides as compliant. The compliance suite tests the EE, not the hardware.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUGKPOM4JF3HVZO2HDP75NOVA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GDNFQ#issuecomment-512505494, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH3XQTXAVIJFT7HKVVIVQ3P75NOVANCNFSM4IERF6UQ .

[neelgala]

I don't think the compliance suite will declare an emulation of an instruction op as compliant to that op. Please see here for more info .

Is this true: The compliance suite must declare an implementation that invisibly traps and emulates divides as compliant. The compliance suite tests the EE, not the hardware.

[neelgala]

I went through the current definitions of standard, reserved, custom, non-standard, and non-conforming extensions. I believe then the compliance suite should only check for standard-extension compatibility and shouldn't worry about the existence/absence of the remaining. Would you agree?

So a device with standard RV32I and non-conforming RV32M extensions can still be called a valid RISC-V device supporting RV32I.

Thanks :)

If the MUL opcode doesn’t do what the spec says the MUL opcode does, then it’s obviously noncompliant with the M extension, but it could still be compliant with RV32I.

[allenjbaum]

Absolutely: it would be conforming to RV32i - but not to necessarily to a platform that requires RV32IM (i.e. that programs that use MUL and DIV ops work correctly) So this comes down to whether compliance should test compliance to a spec, or to a platform. If the implementation either traps correctly MUL/DIV (illegal op) or executes MUL/DIV correctly - its compliant to that platform. The real issue is that we don't necessarily have infrastructure to test partial implementations. That would require changes to the reference model to specify to it which ops are implemented in HW (and/or which give illegal op traps), and associated changes/additions to the test suite and framework. (adding illegal opcode traps)

[cliffordwolf]

I can't find anything about the following in the spec document, but I remember conversations at a RISC-V workshop where it was discussed to use the Y-prefix for when a core supports individual instructions from extensions. E.g. RV32I_Ymul_Ymulh_Ymulhsu_Ymulhu. @aswaterman Is this still (was it ever) the plan?

[aswaterman]

I forgot where we came down on that. @kasanovic?

[eroom1966]

I would like to ask a more fundamental question which is the following:

I am aware of an implementation which has "re-purposed" an instruction decode in the standard extension space, let us say for purpose of this example, it is the MUL operation

if a device is tested to be compliant to RV32I but contains (hidden) decodes matching some instructions from another standard extension eg RV32IM(MUL), then is it truly RV32I ?

Does the inclusion of a set, explicitly define the exclusion (complement) of all others ?

in which case, is RV32(extensions) defined as: a) contains RV32(extensions) instructions, and no other instructions, or b) contains RV32(extensions) instructions.

If the definition is (a) then (for example) portable code could be written using MUL/DIV instructions to execute on either a device reported as I or IM, by including a trap handler to implement MUl/DIV using I only instructions on I the MUL/DIV will trap and emulate on IM the MUL/DIV will execute in hardware

if the definition is (b) then the code can never be portable as the incorrect (and non-declared) implementation of the MUL operation, will cause a functional difference, and so the execution results cannot be deterministic

I apologize in advance if this question seems irrelevent, but it is important in terms of compliance testing to define whether compliance testing should determine whether a device provides a

• definitive set of capabilities for that given device, or
• a potentially incomplete subset of observed capabilities

[marceg]

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.

The base ISA explicitly defines as "non-conforming" a non-standard extension that uses standard or reserved encodings. It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings. Is that a correct interpretation?

If a "conforming implementation" is defined as an implementation without any non-conforming extensions. Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps. Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap. Anything else might be taken as a non-conforming extension. Again, is this a correct interpretation?

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension. If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly. (Is this a correct interpretation?)

So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap. (One more time -- Is this a correct interpretation? :)

Might it be useful to additionally define some terms to help classify conformance.

• "Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X. These and fully conformant implementations can emulate any standard extensions.

• "Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated. This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance. Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated. Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements. For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

[allenjbaum]

That's a really good analysis. I think that if the reference model and framework can be augmented to fully label what is implemented in "HW", and what is not, then partial conformance can be checked as well. I doh't think partial-F is really very different than partial-M (e.g Mul without Div). It does require that FCSR be correctly implemented for the ops that are supported (and FS in MCSR.both of which follows from the fact that those ops are supported and those are basically extra result bits)) , but shouldn't be any more than that. Am I missing something?

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier notifications@github.com wrote:

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.

The base ISA explicitly defines as "non-conforming" a non-standard extension that uses standard or reserved encodings. It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings. Is that a correct interpretation?

If a "conforming implementation" is defined as an implementation without any non-conforming extensions. Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps. Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap. Anything else might be taken as a non-conforming extension. Again, is this a correct interpretation?

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension. If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly. (Is this a correct interpretation?)

So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap. (One more time -- Is this a correct interpretation? :)

Might it be useful to additionally define some terms to help classify conformance.

-

"Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X. These and fully conformant implementations can emulate any standard extensions.

"Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated. This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance. Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated. Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements. For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVKNG3TIOYS6PRCJETQACNVTA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JDP5I#issuecomment-512899061, or mute the thread https://github.com/notifications/unsubscribe-auth/AHPXVJV5YFMZ3CVDAV4BBADQACNVTANCNFSM4IERF6UQ .

[pdonahue-ventana]

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier notifications@github.com wrote:

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.

I agree.

The base ISA explicitly defines as "non-conforming" a non-standard

extension that uses standard or reserved encodings. It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings. Is that a correct interpretation?

Sounds good to me.

I'm concerned with the declaration in 1.3 that "custom extensions are not non-conforming" because:

1. custom extensions are not defined
2. if it means "non-standard extensions" then this statement is clearly not true because it depends on which encodings each extension uses.

If a "conforming implementation" is defined as an implementation without

any non-conforming extensions.

It doesn't say that anywhere but it sounds reasonable. Then let's also assume that the compliance suite should be checking for whether the test target is a conforming implementation and it should fail if not.

Then, if a standard extension is not present on a conforming

implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps. Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap. Anything else might be taken as a non-conforming extension. Again, is this a correct interpretation?

Can you point me to somewhere that says that reserved and/or custom encodings that are unimplemented are required to trap (or to exhibit any particular behavior at all)? I see lots of specific examples of required illegal instruction traps when accessing certain CSRs and whatnot but not the blanket statement I've seen in other architectures. I think that there is no such requirement, though I'd like to be proven wrong since it would simplify things.

This message from Krste specifically says that if Zifencei isn't implemented then FENCE.I doesn't have to trap (though traps are "highly recommended"): https://lists.riscv.org/g/tech-privileged/message/6 (Also relevant to this conversation, it says that the compliance suite shouldn't test for FENCE.I if Zifencei isn't implemented.)

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension. If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly. (Is this a correct interpretation?)

I can agree with that, though the two "if" statements substantially reduce the impact of this observation.

So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap. (One more time -- Is this a correct interpretation? :)

Only if unimplemented encodings are required to take an illegal instruction trap.

Might it be useful to additionally define some terms to help classify conformance.

-

"Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X. These and fully conformant implementations can emulate any standard extensions.

"Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated. This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance. Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated. Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements. For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

Those terms can be defined but I'm not sure they can be tested without a trap requirement. This lack of a trap requirement really complicates a lot of things for a test suite that has to run on any legal implementation.

Thanks,

-Paul

[marceg]

Partial F is perhaps likely to always implement all of FCSR, making it easy enough to provide a version of FP emulation that assumes a hardware FCSR.

Maybe a better example is the hypervisor (H) extension.  It adds lots of state, lots of bitfields across a large number of CSRs.  The possible combinations of implementing only a portion of the H extension are immense, and many may affect what emulation must do.  Not so easy to test in a standard way.

-M

Allen Baum wrote on 2019-07-18 17:34:

That's a really good analysis. I think that if the reference model and framework can be augmented to fully label what is implemented in "HW", and what is not, then partial conformance can be checked as well. I doh't think partial-F is really very different than partial-M (e.g Mul without Div). It does require that FCSR be correctly implemented for the ops that are supported (and FS in MCSR.both of which follows from the fact that those ops are supported and those are basically extra result bits)) , but shouldn't be any more than that. Am I missing something?

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier notifications@github.com wrote:

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.

The base ISA explicitly defines as "non-conforming" a non-standard extension that uses standard or reserved encodings. It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings. Is that a correct interpretation?

If a "conforming implementation" is defined as an implementation without any non-conforming extensions. Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps. Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap. Anything else might be taken as a non-conforming extension. Again, is this a correct interpretation?

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension. If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly. (Is this a correct interpretation?)

So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap. (One more time -- Is this a correct interpretation? :)

Might it be useful to additionally define some terms to help classify conformance.

-

"Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X. These and fully conformant implementations can emulate any standard extensions.

"Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated. This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance. Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated. Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements. For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVKNG3TIOYS6PRCJETQACNVTA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JDP5I#issuecomment-512899061, or mute the thread

https://github.com/notifications/unsubscribe-auth/AHPXVJV5YFMZ3CVDAV4BBADQACNVTANCNFSM4IERF6UQ .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAQHPIIOLD3GBMSSCHRD3NTQADOVDA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2J3MHY#issuecomment-512996895, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQHPIOBEHAYJPD5O22NZ3LQADOVDANCNFSM4IERF6UQ.

[aswaterman]

FWIW, when I wrote emulation libraries for the F/D extensions, I found it straightforward to provide two variants: one assuming none of the architectural state (no f-registers and no fcsr), and one assuming all of the architectural state, loads, stores, and moves to/from x-registers, and any arbitrary subset of the computational instructions. I don't think the design points in the middle of the architectural-state space (fcsr without f-regs, or f-regs without fcsr) make too much sense.

[marceg]

Paul Donahue wrote on 2019-07-18 20:17:

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier notifications@github.com wrote:

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.

I agree.

The base ISA explicitly defines as "non-conforming" a non-standard

extension that uses standard or reserved encodings. It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings. Is that a correct interpretation?

Sounds good to me.

I'm concerned with the declaration in 1.3 that "custom extensions are not non-conforming" because:

1. custom extensions are not defined

Right, Section 1.3 does seem like the right place to explicitly define "custom extensions".  It takes careful reading to figure out that a "custom extension" is one that only uses "custom" opcodes.  I've created a pull request, #413.

2. if it means "non-standard extensions" then this statement is clearly not true because it depends on which encodings each extension uses.

No, that's different.

If a "conforming implementation" is defined as an implementation without any non-conforming extensions.

It doesn't say that anywhere but it sounds reasonable. Then let's also assume that the compliance suite should be checking for whether the test target is a conforming implementation and it should fail if not.

Conforming is not the same as compliant.  The testsuite tests compliance. It can test conformance if an implementation claims to be conformant. An implementation can be compliant and non-conformant.

Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps. Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap. Anything else might be taken as a non-conforming extension. Again, is this a correct interpretation?

Can you point me to somewhere that says that reserved and/or custom encodings that are unimplemented are required to trap (or to exhibit any particular behavior at all)?

No, nothing explicit.  My interpretation is that anything other than an illegal instruction trap can be considered a non-conforming extension.

In other words, an implementation doesn't have to trap.  But if it wants to claim that it is free of any non-conforming extension, then by the above reasoning it must trap.  Which (if correct) highlights the value of claiming no non-conformance (or simply, "conformance", to avoid double negatives).

I see lots of specific examples of required illegal instruction traps when accessing certain CSRs and whatnot but not the blanket statement I've seen in other architectures. I think that there is no such requirement, though I'd like to be proven wrong since it would simplify things.

This message from Krste specifically says that if Zifencei isn't implemented then FENCE.I doesn't have to trap (though traps are "highly recommended"): https://lists.riscv.org/g/tech-privileged/message/6 (Also relevant to this conversation, it says that the compliance suite shouldn't test for FENCE.I if Zifencei isn't implemented.)

Right.  "Conformance" (absence of non-conforming extensions) is not a requirement for compliance.

(Maybe there's a better term.  "Conformance" and "compliance" are very similar.)

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension. If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly. (Is this a correct interpretation?)

I can agree with that, though the two "if" statements substantially reduce the impact of this observation.

So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap. (One more time -- Is this a correct interpretation? :)

Only if unimplemented encodings are required to take an illegal instruction trap.

If there are no non-conformant extensions, it seems traps must be taken.

If MISA.X is implemented and cleared, any non-standard extensions, which includes both custom and non-conformant extensions, must be turned off. So effectively, there should be no active non-conformant extensions, and again it seems traps must be taken.

-M

Might it be useful to additionally define some terms to help classify conformance.

-

"Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X. These and fully conformant implementations can emulate any standard extensions.

"Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated. This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance. Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated. Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements. For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

Those terms can be defined but I'm not sure they can be tested without a trap requirement. This lack of a trap requirement really complicates a lot of things for a test suite that has to run on any legal implementation.

Thanks,

-Paul

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAQHPIJFFOILSM2MNLNDLODQAEBZLA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KGG6I#issuecomment-513041273, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQHPII3DAJA2MSAEICZS4TQAEBZLANCNFSM4IERF6UQ.

[pdonahue-ventana]

On Fri, Jul 19, 2019 at 4:57 PM Marc Gauthier notifications@github.com wrote: Paul Donahue wrote on 2019-07-18 20:17: Section 1.3 does seem like the right place to explicitly define "custom extensions". It takes careful reading to figure out that a "custom extension" is one that only uses "custom" opcodes. I've created a pull request, #413.

​I saw that. Thanks.​

Conforming is not the same as compliant. The testsuite tests compliance. It can test conformance if an implementation claims to be conformant. An implementation can be compliant and non-conformant.

​​OK.​ Such similar terms can be confusing but I understand and agree.

Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps.

I see what you're saying. That's an interesting idea but I don't think it's the intent of the architecture. We're both trying to interpret something that's not explicitly stated, though.

Can @aswaterman weigh in?

Let's say I have the simplest RV32I implementation with no other extensions of any kind. An implementation with such a configuration cannot possibly trap. At least it cannot meaningfully trap since without the standard privileged architecture (or some other extension) there is no trap information (cause/epc/etc.) and without Zicsr (or a non-standard CSR extension) there would be no way for the handler to see those CSRs anyway.

Does such an implementation as above implement a non-conforming extension because FP instructions (and many others) are NOPs rather than trapping? To take it a bit further, what if the decoder doesn't look at certain bits that are don't-care for decoding the minimal RV32I subset and consequently FP instructions are decoded as arbitrary integer instructions?

[aswaterman]

It's totally reasonable for certain platform specifications to illegalize non-conforming extensions--i.e., to mandate that a standard encoding must either trap or perform the standard-specified action. However, the ISA spec itself does not appear to take a position on the compliance of non-conforming extensions.

I would describe reinterpreting an FP opcode as a NOP, or as some arbitrary integer instruction, as a non-conforming ISA extension, which happens to be non-compliant with respect to the F extension. Such an implementation might be compliant with respect to the RV32I base ISA, but might not be compliant to some platform specifications that require the F extension either be implemented or to faithfully trap.

There's lots of options here (too many), and as usual I'm going to punt to the need for platform specifications to constrain the set of valid implementations and behaviors.

[kasanovic]

This is a very long thread that isn't really an ISA spec issue - so I suggest conversation move to compliance group.

To help understand the philosophy though, one important RISC-V goal is to maximize reuse of the specifications. This is why an implementation that uses a MUL opcode to do a DIVIDE operation can still be compliant with the RV32I ISA. This implementation can reuse all the software tools and libraries that only rely on RV32I. It is clearly not compliant with RV32IM ISA.

A software ecosystem (e.g., DebianLinux, AmazonFreeRTOS, etc,) can specify that their platform compliance forbids non-conforming implementations by requiring every opcode is either standard or takes an illegal instruction trap. While this would seem like a generally "good idea" to enable forward compatibility, this is only a virtue in environments where emulating newly defined instructions on old hardware is both practical and desirable. I believe that this kind of forward compatibility is only useful for a tiny fraction of systems shipped in practice (e.g., Unix servers and workstations), so mandating it for all systems unnecessarily limits use of RISC-V infrastructure in other areas.

The downside to the forward-compatibility mandate is that applications that are content with the existing RISC-V infrastructure won't be allow to reuse that infrastructure while adding non-conforming instructions to customize for some task. e.g. embedded systems customized for the task at hand.

[allenjbaum]

I'll echo what Krste said. (I confess I've probably been using the word "conforming" incorrectly...) The goal of compliance is to test whether an implementations assertions about what it supports is (non-proper) superset of a platform's requirements. This gets a bit tricky if an implementation implements only MUL, but not DIV. It will be compliant to RV32i, but not to RV32im, as Krste said. Nothing more needs to be said if the platform is RV32i, or RV32im, but those are likely toy platforms that are classroom projects only. From the perspective of a platform that requires both MUL and DIV to be implemented, however, it will be compliant IFF DIV traps properly - because it can then be emulated. Compliance will not test that the emulation of DIV is correct, however - just that it is possible to be implemented via the correct trapping behavior. We do need the infrastructure to ensure that the reference model will faithfully trap on DIV but not MUL in this case (or any other op that is required by not implemented by HW)

On Sat, Jul 20, 2019 at 11:41 AM Krste Asanovic notifications@github.com wrote:

This is a very long thread that isn't really an ISA spec issue - so I suggest conversation move to compliance group.

To help understand the philosophy though, one important RISC-V goal is to maximize reuse of the specifications. This is why an implementation that uses a MUL opcode to do a DIVIDE operation can still be compliant with the RV32I ISA. This implementation can reuse all the software tools and libraries that only rely on RV32I. It is clearly not compliant with RV32IM ISA.

A software ecosystem (e.g., DebianLinux, AmazonFreeRTOS, etc,) can specify that their platform compliance forbids non-conforming implementations by requiring every opcode is either standard or takes an illegal instruction trap. While this would seem like a generally "good idea" to enable forward compatibility, this is only a virtue in environments where emulating newly defined instructions on old hardware is both practical and desirable. I believe that this kind of forward compatibility is only useful for a tiny fraction of systems shipped in practice (e.g., Unix servers and workstations), so mandating it for all systems unnecessarily limits use of RISC-V infrastructure in other areas.

The downside to the forward-compatibility mandate is that applications that are content with the existing RISC-V infrastructure won't be allow to reuse that infrastructure while adding non-conforming instructions to customize for some task. e.g. embedded systems customized for the task at hand.

pA separate goal is supporting compliance

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVWDATAKWOPWAUKOI3QANL35A5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NTZQA#issuecomment-513490112, or mute the thread https://github.com/notifications/unsubscribe-auth/AHPXVJVDLEFCJ7VONJDMQE3QANL35ANCNFSM4IERF6UQ .

[aswaterman]

I believe the main thrust of this thread has been addressed.