[sw-dev]gcc builtin functions like __sync_fetch_and_add if A-extension not supported

[Sober Liu]

When I configure gcc with --with-arch=rv64im I get following error when build benchmark/mm:

undefined reference to `__sync_fetch_and_add_4'

 

I see in atomic.c (riscv-gnu-toolchain/riscv-gcc/libgcc/config/riscv) there is a macro #ifdef __riscv_atomic to check and implement these functions.

Is it expected that these function to be undefined if A-extension not supported? Or do we need to implement them even __riscv_atomic undefined?

 

Thanks.

 

 

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

[Khem Raj]

On 9/20/17 8:32 PM, Sober Liu wrote:
> When I configure gcc with --with-arch=rv64im I get following error when
> build benchmark/mm:
>
> undefined reference to `__sync_fetch_and_add_4'
>
>  
>
> I see in atomic.c (riscv-gnu-toolchain/riscv-gcc/libgcc/config/riscv)
> there is a macro #ifdef __riscv_atomic to check and implement these
> functions.
>
> Is it expected that these function to be undefined if A-extension not
> supported? Or do we need to implement them even __riscv_atomic undefined?

The implementation in atomic.c assumes atomic memory instructions being
available since its using sc.w.rl and lr.w.aq, therefore when using
instruction set without atomic instruction like you said would probably
require different fallback implementation may be by using spin lock.

[Bruce Hoult]

I you don't have the A-extension then hopefully you're on a uniprocessor system. You'll probably need to disable interrupts to implement the gcc built-ins. If the code will be running privileged then this can be done by writing to the mie CSR. If running in U mode then you'll need to call the supervisor.

It doesn't make a lot of sense to ask the supervisor to disable interrupts, run a couple of instructions in U mode, and then ask the supervisor to enable interrupts. For U mode software it would be better to tell the compiler to generate A instructions anyway, and have the supervisor emulate them.

--
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+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/a5a75b1dc3dd4540a277e51fd7d35c2e%40HKMAIL101.nvidia.com.

[Sober Liu]

Merge the thread.

Yes, to disable interrupt or sw-lock are nature solutions if without atomic instruction.

I was just hesitate whether I can simply tell MCU users (sw guys) that these builtin functions are not implemented in a toolchain.

 

“U mode to generate A instructions anyway, and have the supervisor emulate them” is an interesting idea. But looks a little bit heavy.

How about to implement a memory-mapped address to write/read as a locker (implemented by HW)?

 

From: bruce...@gmail.com [mailto:bruce...@gmail.com] On Behalf Of Bruce Hoult
Sent: Thursday, September 21, 2017 2:05 PM
To: Sober Liu <sob...@nvidia.com>
Cc: RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev]gcc builtin functions like __sync_fetch_and_add if A-extension not supported

 

I you don't have the A-extension then hopefully you're on a uniprocessor system. You'll probably need to disable interrupts to implement the gcc built-ins. If the code will be running privileged then this can be done by writing to the mie CSR. If running in U mode then you'll need to call the supervisor.

 

It doesn't make a lot of sense to ask the supervisor to disable interrupts, run a couple of instructions in U mode, and then ask the supervisor to enable interrupts. For U mode software it would be better to tell the compiler to generate A instructions anyway, and have the supervisor emulate them.

 

 

From: Khem Raj [mailto:raj....@gmail.com]
Sent: Thursday, September 21, 2017 2:01 PM
To: Sober Liu <sob...@nvidia.com>; RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: Re: [sw-dev]gcc builtin functions like __sync_fetch_and_add if A-extension not supported

 

The implementation in atomic.c assumes atomic memory instructions being available since its using sc.w.rl and lr.w.aq, therefore when using instruction set without atomic instruction like you said would probably require different fallback implementation may be by using spin lock.

 

 

On Thu, Sep 21, 2017 at 6:32 AM, Sober Liu <sob...@nvidia.com> wrote:

When I configure gcc with --with-arch=rv64im I get following error when build benchmark/mm:

undefined reference to `__sync_fetch_and_add_4'

 

I see in atomic.c (riscv-gnu-toolchain/riscv-gcc/libgcc/config/riscv) there is a macro #ifdef __riscv_atomic to check and implement these functions.

Is it expected that these function to be undefined if A-extension not supported? Or do we need to implement them even __riscv_atomic undefined?

 

Thanks.

 

 

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

--

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 post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/a5a75b1dc3dd4540a277e51fd7d35c2e%40HKMAIL101.nvidia.com.

 

--

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 post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkwwup73pr0OXgmKa4ozYmRyeb1caHh4GWfro5Jk6HmX_w%40mail.gmail.com.

[Palmer Dabbelt]

As part of the feedback on our Linux patches, we've decided to mandate the A
extension for Linux-capable systems for the time being. We used to have a
special vDSO entry that would allow non-A systems (which were supported for
uniprocessors) to emulate atomic operations and while I'm not opposed to bring
that back I'd prefer to get our port upstream before we start adding too many
new features. As this would be an extension to the ABI (we'd add support for
non-A systems), there's no clock on doing this.

There's some tricks you can use in the vDSO entry, so it turns out you don't
actually even need to enter kernel mode (or disable interrupts) in order to
emulate atomic operations. It's not as fast as emitting A instructions
in-line, but it's a lot faster than trap-and-emulate.

[David Chisnall]

On 21 Sep 2017, at 17:36, Palmer Dabbelt <pal...@sifive.com> wrote:
>
> As part of the feedback on our Linux patches, we've decided to mandate the A
> extension for Linux-capable systems for the time being. We used to have a
> special vDSO entry that would allow non-A systems (which were supported for
> uniprocessors) to emulate atomic operations and while I'm not opposed to bring
> that back I'd prefer to get our port upstream before we start adding too many
> new features. As this would be an extension to the ABI (we'd add support for
> non-A systems), there's no clock on doing this.
>
> There's some tricks you can use in the vDSO entry, so it turns out you don't
> actually even need to enter kernel mode (or disable interrupts) in order to
> emulate atomic operations. It's not as fast as emitting A instructions
> in-line, but it's a lot faster than trap-and-emulate.

Given how easy it is to implement atomics on uniprocessor systems, there doesn’t seem much advantage to doing this. Anything that’s so area constrained that it can’t manage uniprocessor atomics probably doesn’t have extravagant things like caches or more than a few KB of ROM / RAM, or an MMU. Supporting the privileged spec adds far more complexity to a uniprocessor design than supporting atomics.

David

[Stefan O'Rear]

Is there any reason to consider systems that might want LR/SC but not
the full set of AMOs?

-s

[David Chisnall]

I did wonder about that, but on a uniprocessor system it’s actually easier to implement the atomic RMW operations, because they’re all known worst-case performance and so you can simply defer interrupt delivery for X cycles (and nothing else can cause a data race). In an in-order pipeline, you can simply not dispatch any other instructions until the atomic RMW has completed, in an out-of-order pipeline you have to ensure that you have correct serialisation of loads and stores (but you need most of that anyway).

These instructions only become complex when you start caring about very high performance designs, but by that stage they’re only complex in absolute terms: your floating point unit and register rename engine are far more difficult.

I’d be broadly in favour of mandating the A extension for anything that implements the privileged spec.

David