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

[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

[Bruce Hoult]

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

On Fri, Jul 15, 2022 at 5:44 PM Liviu Ionescu <i...@livius.net> wrote:

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

--
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.

[BGB]

On 7/15/2022 3:15 AM, Bruce Hoult wrote:
> So , apparently, does RISC-V, as those 10 billion cores shipped aren't
> in laptops or phones.
>

FWIW:
* The core ISA design makes sense for microcontrollers;
* Laptops and phones would imply competing with both ARM and Intel
** I don't think this fight would be "winnable" at this time.

At least for the base ISA, it is possible to implement RISC-V cheaply.
* RV32I or RV64I doesn't ask too much of an FPGA or ASIC
* RV32G or RV64G would ask a little more though.


Getting decent performance at low cost seems difficult.
* Going superscalar isn't free.
* This is why my own efforts ended up going VLIW.
** VLIW allows speeds closer to a superscalar, but at lower cost.
*** (Apparently would be 'LIW' by the original terminology though).
** Nevermind if it makes things a bit harder for the compiler.
** Did keep some RISC-like features though in the design.
*** Interlocks and Branch-Predictors are worth their cost.
** Also designed things to still run RISC-like code reasonably well.
*** Does not adversely effect performance or code density.
*** Just, RISC-style code can't exceed 1 IPC
**** This would require the mechanisms for superscalar.
* So, it seemed like a potentially interesting experiment
** Which then ate up years of my time...
** And probably wouldn't make as much sense in a PC or phone.
*** PC class CPUs are typically OoO.
*** OoO would mean the CPU effectively ignores the VLIW bundling.
** So, more: "Scalar RISC isn't fast enough, but OoO is too expensive"

Can note that my own effort also wasn't really intended for PC or phone,
and the design is not well optimized to this use-cases.

But, a lot also comes down to the relative cost and performance of
in-order superscalar (if compared with a 1-wide scalar core, or core
running a VLIW design, but, say, costing 40% more LUTs than a
similarly-featured scalar core, ...).



As for ABI thoughts:
* Not really any ideas for obvious ways to improve the performance of
the RISC-V ABI (design already seems "pretty reasonable" on this front).

Can note though that in many cases, interrupt latency may be overrated.
The cost of saving or restoring registers isn't usually enough to have a
significant impact on overall performance IME.

For most purposes, as long as the latency is much under a few kilocycles
or similar, it it probably "good enough" (except with potentially
high-frequency interrupt sources).

...

>
> On Fri, Jul 15, 2022 at 5:44 PM Liviu Ionescu <i...@livius.net
> <mailto:i...@livius.net>> wrote:
>
>
>
> > On 15 Jul 2022, at 00:41, Jim Wilson <jim.wil...@gmail.com

> <mailto:jim.wil...@gmail.com>> wrote:
> >
> > On Thu, Jul 14, 2022 at 9:21 AM Liviu Ionescu <i...@livius.net
> <mailto: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.
>
> 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
>
> --
> 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

> <mailto:sw-dev%2Bunsu...@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

> <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/30558065-D266-4BE5-8566-EC52E3CC0A8F%40livius.net>.

>
> --
> 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
> <mailto: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/CAMU%2BEkz-cmiY2X5Gah8zrUwH-SWi927noKd3X-A3U_80ZXuTpw%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAMU%2BEkz-cmiY2X5Gah8zrUwH-SWi927noKd3X-A3U_80ZXuTpw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[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.