RISC-V: Public review for Non-ISA Specification: psABI

Code Generation RISCV
1

We are delighted to announce the start of the public review period for psABI.

The review period begins today, 2022/07/14, and ends on 2022/08/29 (inclusive).

This Non-ISA specification is described in the PDF available at:

which was generated from the source available in the following GitHub repo:

To respond to the public review, please either email comments to the public isa-dev (isa-dev@groups.riscv.org) mailing list or add issues and/or pull requests (PRs) to the GitHub repo (GitHub - riscv-non-isa/riscv-elf-psabi-doc: A RISC-V ELF psABI Document). We welcome all input and appreciate your time and effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and suggestions, will be gathered for review by the psABI Task Group. Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the psABI Task Group will recommend the updated specifications be approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Kito Cheng

2 Likes
2

Hi Kito,

First of all - a huge thanks for all of the work that you and Jessica have put into maintaining and evolving the psABI documentation. It’s a huge and I’m sure often thankless task, and I particularly appreciate the efforts you’ve gone to in order to help coordinate between GCC and Clang/LLVM.

As we discussed this psABI ratification process in the RISC-V sync-up call last Thursday, I wanted to attempt to summarise some of what was said (if anyone thinks I’m misrepresenting, do dive in with corrections). Some of this might translate to issues on the riscv-elf-psabi-doc repo, while for others it’s less obvious.

Notes:

  • Questions were raised about whether the process of ratification would involve a technical editor / author working through the document. It sounds like the answer is that this isn’t currently part of the process.
  • One area of concern was about spec details where GCC and LLVM differ. There were a couple of dimensions to this.
    • Are we confident that there’s full understanding of which parts of the specification are currently implemented by GCC and LLVM (and indeed, that everything specified actually is implemented that way by at least one of GCC and LLVM)? If not, there was a feeling we should be sure to understand it - is it a case where the spec is failing to match reality, where there’s a disagreement to be resolved, or “just an implementation bug”.
    • For pieces of the spec that aren’t currently implemented by both GCC and LLVM, and argument was made these should not be ratified at this point