Re: Question about extensions not mentioned in profiles

Greg Favor

On Thu, Apr 6, 2023 at 3:29 PM David Weaver <david.weaver@...> wrote:

Profile-compliant Hardware must implement everything specified as Mandatory in the Profile.  
It may or may not implement features specified as Optional in the Profile.
It may or may not implement custom features using opcodes set aside for that purpose (custom opcode space).
It must appear to software that it does not implement any other instructions in the standard opcode space (e.g. trap on them)**.

                   ** this one is MHO, and is probably the part most under discussion in this thread 

Krste, in this past week's CCM meeting, explained that the RVA profiles strongly suggest to trap unimplemented opcodes since they can't require that behavior - because that would prevent designs compatible with a future profile from still being compatible with a current profile.  In other words, for the opcodes used by a new arch extension in that future profile, they would be required to be trapped in an implementation compatible with a current profile.  Any given implementation can't simultaneously have both the old behavior and the new behavior for the same opcodes, and hence can't be compatible with both profiles.

To be able to mandate in RVA profiles that all unimplemented opcodes must be trapped, but without running into the preceding problem (so as to allow a new design implementing new extensions to be backward-compatible with a previous profile), it seems like the current wording:

Implementations are strongly recommended to raise illegal-instruction exceptions on attempts to execute unimplemented opcodes.

Needs to change to something like this:

Implementations must either raise an illegal-instruction exception on an attempt to execute an unimplemented opcode, or must execute that opcode as it is defined by a standard architecture extension.


Join to automatically receive all group messages.