RISC-V HardFP ABI

[rsaxvc]

I've noticed that function calls with floating point arguments are a little heavier than on RISC-V and ARM32, for the same GCC12.2.0, due to the ABI in use. Here's a trivial example:

Code: Select all

float fmac(float a, float b, float c) {
    return a * b + c;
}

RISC-V, F-ABI(not for ESP chips):

Code: Select all

fmac(float, float, float):
        fmadd.s fa0,fa0,fa1,fa2 #do the multiply-accumulate
        ret

ESP32-S3:

Code: Select all

fmac(float, float, float):
        entry   sp, 32
        wfr     f1, a2 #copy integer reg to FPU reg
        wfr     f0, a4 #copy integer reg to FPU reg
        wfr     f2, a3 #copy integer reg to FPU reg
        madd.s  f0, f1, f2 #do the multiply-accumulate
        rfr     a2, f0 #copy FPU reg to integer reg
        retw.n

With larger functions, the overhead is less of a percentage, but has anyone else ever considered what a HardFP ABI would look like for Xtensa?

On a related note, can Espressif mention if future chips will use Xtensa, or if the future is RISC-V for ESP32s?

[MicroController]

has anyone else ever considered what a HardFP ABI would look like for Xtensa?

Maybe. But Tensilica/Cadence does not specifiy a float ABI, and consequently gcc does not implement one. Might also be a bit awkward to do alongside the windowed integer ABI.

Allowing gcc to inline respective functions may be the best alternative.

[Sprite]

On a related note, can Espressif mention if future chips will use Xtensa, or if the future is RISC-V for ESP32s?

As far as I know, we do not have any plans for Xtensa-based chips; everything I know of is RISC-V.

[MicroController]

Tensilica/Cadence does not specifiy a float ABI,

I have to correct myself here. From the Xtensa ISA summary:

The Hardware Floating Point ABI is optionally supported on configurations with hardware
floating point. ... . Each variable is passed in a single register, starting with register 0.
Register 0 can also be used for returning a variable.
...
The Hardware Floating Point ABI is not compatible with the traditional ABI. Both caller and
callee must be compiled with the same ABI. Other than compatibility, there is no advantage in
selecting the traditional ABI.