Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

Minutes

Content:

Semi-Hosting custom hint opcodes change of category

A poll was undertaken to see if there were objections to changing the
category of two hint opcodes used by the semi-hosting spec from custom
to standard.  These have been informally used by semi-hosting software
for a considerable time.  No objections were registered over the last
month, and so these two custom hint opcodes will now be removed from
the custom space and moved into the standard space in the main ISA
specification.  This addresses the concern with the semi-hosting spec,
which can now move forward in the ratification process.

HTI (Host Trace Interface)

A request was made to separate the host trace interface from the
E-trace specification and present as a separate specification that
could also apply to N-trace.  ARC approved for pursuit as a fast track.

CBO to PoP Fast Track approval

A request was made to pursue as a fast track a new cache block instruction to make a block persistent. ARC believes this topic is complex and needs wider discussion within the RISC-V community and so recommends this be pursued as a regular task group to fully consider all the aspects of an extension in this realm.  There are likely more issues past the following initial list.

  • An explicit architectural definition of the semantics of "cleaning" data to a "point of persistence" and what constitutes a "point of persistence", is needed.

  • What "points of persistence" should there be? Other architectures have more than one.

  • Is an address-based operation useful?  Should this be an "all address" operation? 

  • CBOs do not have strict ordering semantics.  This would normally be provided through use of an appropriate FENCE instruction.  How is this new operation treated wrt FENCE operations? 

  • Current FENCE instructions do not provide completion semantics (only ordering semantics).  How should ensuring completion to software be handled?  Is a new instruction needed to support this? 

  • What usage scenarios need this extension that cannot be supported by eADR (Enhanced Asynchronous DRAM Refresh)? 

  • How does this proposal relate with the CXL.mem GPF (global persistence flush) support? 

  • In some applications there can be a need for a stronger "persistence order" relative to the standard global visibility order. How would this factor into this extension?


Standard_2.png

  • No labels