[Bpf] ISA: do individual instructions still need their own IANA status?

[Bpf] ISA: do individual instructions still need their own IANA status?

[dthaler1968=40googlemail.com]

[-- Attachment #1.1: Type: text/plain, Size: 970 bytes --]

Previously (draft -00) we said that each instruction would have a status of

Permanent, Provisional, or Historical in the IANA registry.

 

However, we now have conformance groups about to be merged into the ISA doc,

and at IETF 118 we discussed having each conformance group have a status of

Permanent, Provisional, or Historical.  That is, it makes sense for the
status to
be at the granularity of conformance group since one should implement all

instructions in a conformance group together.

 

As a result I now believe that each individual instruction no longer needs
its own

status since it can be derived from the status of the conformance group(s)
it

belongs to.  So in the IANA Considerations section, I plan to remove
"status"

from the list of fields in the instruction sub-registry and ONLY have
"status"

in the list of fields for the conformance group sub-registry).

 

Let me know if anyone has a good reason to keep it per-instruction.

 

Dave


[-- Attachment #1.2: Type: text/html, Size: 2950 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] ISA: do individual instructions still need their own IANA status?

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Fri, Feb 02, 2024 at 08:36:02PM -0800, dthaler1968=40googlemail.com@dmarc.ietf.org wrote:
> Previously (draft -00) we said that each instruction would have a
> status of Permanent, Provisional, or Historical in the IANA registry.
>
> However, we now have conformance groups about to be merged into the
> ISA doc, and at IETF 118 we discussed having each conformance group
> have a status of Permanent, Provisional, or Historical.  That is, it
> makes sense for the status to be at the granularity of conformance
> group since one should implement all instructions in a conformance
> group together.
>
> As a result I now believe that each individual instruction no longer
> needs its own status since it can be derived from the status of the
> conformance group(s) it belongs to.  So in the IANA Considerations
> section, I plan to remove "status"
>
> from the list of fields in the instruction sub-registry and ONLY have
> "status" in the list of fields for the conformance group
> sub-registry).
> 
> Let me know if anyone has a good reason to keep it per-instruction.

No objection from me. AFAICT this matches what RISC-V does, which again
seems reasonable to emulate.

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Bpf] ISA: do individual instructions still need their own IANA status?

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

On Fri, Feb 02, 2024 at 08:36:02PM -0800, dthaler1968=40googlemail.com@dmarc.ietf.org wrote:
> Previously (draft -00) we said that each instruction would have a
> status of Permanent, Provisional, or Historical in the IANA registry.
>
> However, we now have conformance groups about to be merged into the
> ISA doc, and at IETF 118 we discussed having each conformance group
> have a status of Permanent, Provisional, or Historical.  That is, it
> makes sense for the status to be at the granularity of conformance
> group since one should implement all instructions in a conformance
> group together.
>
> As a result I now believe that each individual instruction no longer
> needs its own status since it can be derived from the status of the
> conformance group(s) it belongs to.  So in the IANA Considerations
> section, I plan to remove "status"
>
> from the list of fields in the instruction sub-registry and ONLY have
> "status" in the list of fields for the conformance group
> sub-registry).
> 
> Let me know if anyone has a good reason to keep it per-instruction.

No objection from me. AFAICT this matches what RISC-V does, which again
seems reasonable to emulate.

Thanks,
David

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf