Public review for Non-ISA Specification: psABI

[Kito Cheng]

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:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc3


which was generated from the source available in the following GitHub repo:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc


To respond to the public review, please either email comments to the
public isa-dev (isa...@groups.riscv.org) mailing list or add issues
and/or pull requests (PRs) to the GitHub repo
(https://github.com/riscv-non-isa/riscv-elf-psabi-doc). 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

[Liviu Ionescu]

> On 14 Jul 2022, at 19:10, Kito Cheng <kito....@sifive.com> wrote:
>
> ... To respond to the public review, please either email comments to the
> public isa-dev

I did not follow the recent developments, was the idea to have a RISC-V EABI discarded? Since there is no reference to it in the mentioned document.

Regards,

Liviu

[Jim Wilson]

On Thu, Jul 14, 2022 at 9:21 AM Liviu Ionescu <i...@livius.net> wrote:

I did not follow the recent developments, was the idea to have a RISC-V EABI discarded? Since there is no reference to it in the mentioned document.

There was no agreement on what the EABI should be, and not enough time and manpower to create a consensus.  So it was deferred indefinitely.

Jim

 

[Bruce Hoult]

People who want an EABI want it to decrease interrupt latency -- generally I think in a "it's better if you can match ARMv7-M" thinking. I get the impression there was some shock at how much having fewer A and T registers slowed down code such as Embench. Also __attribute__((interrupt)) solves any latency problem in most cases, with even lower latency than ARMv7-M because the code only saves registers it absolutely needs to.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALNwTfz-fVZmzFrQqop1xS7j783AdkVK3OF7DdtwZ9w_f_LEfA%40mail.gmail.com.

[Jim Wilson]

On Thu, Jul 14, 2022 at 5:12 PM Bruce Hoult <br...@hoult.org> wrote:

People who want an EABI want it to decrease interrupt latency -- generally I think in a "it's better if you can match ARMv7-M" thinking. I get the impression there was some shock at how much having fewer A and T registers slowed down code such as Embench. Also __attribute__((interrupt)) solves any latency problem in most cases, with even lower latency than ARMv7-M because the code only saves registers it absolutely needs to.

There was no agreement on how to reduce interrupt latency, or whether we even needed to reduce interrupt latency.  One contributor wanted to reduce the number of temp and arg registers.  One contributor wanted to keep the ABI unchanged and determine what registers to save at link time by using register usage info saved in object files.  Attribute interrupt works well for leaf functions.  But if your interrupt function calls another function, then the compiler needs to save a lot of registers unless you change the ABI, or else you use link time optimization to determine the exact set of registers that need to be saved across the function call.

Anyways, as I said, there was no consensus on anything, and not enough time or manpower to create a consensus.  This really should be a separate discussion.

Jim

[Liviu Ionescu]

Ok, I read it as "there was no interest in a RISC-V microcontroller profile, so focus was kept on Unix class devices".

No problem, Arm covers the microcontroller space just fine.

Liviu

[Bruce Hoult]

So , apparently, does RISC-V, as those 10 billion cores shipped aren't in laptops or phones.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/30558065-D266-4BE5-8566-EC52E3CC0A8F%40livius.net.

[Tommy Murphy]

> So , apparently, does RISC-V, as those 10 billion cores shipped aren't in laptops or phones.

*Claimed* to have been shipped?

I've seen zero independent verification of that figure and industry watchers have also struggled to find any.

[Andrew Waterman]

Folks, chill. Liviu was just letting off some steam; we do care about and will eventually have an EABI; and this thread need not digress any further.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/LO2P265MB4776FB82B2BD82D97A701C5CF98B9%40LO2P265MB4776.GBRP265.PROD.OUTLOOK.COM.