I also hope whoever gave risc-v seperate floating-point registers stubs their toe on a rusty nail

Show thread

This only made sense in the 80s where the FPU was a seperate piece of silicon.
Nowadays there's no reason to have a seperate FPU even in a space-constrained microcontroller

Show thread

@iska
It makes no sense to make floating point capabilities mandatory, microcontrollers aren't SBCs — some of them are very basic.
Floating point capabilities are still optional even in the latest Cortex-M cores: en.wikipedia.org/wiki/ARM_Cort

@m0xee@social.librem.one @iska@catposter.club

It makes no sense to make floating point capabilities mandatory

I didn't say that. I'm talking about F/D extensions creating seperate register spaces, making programming burdensome and dies larger

That's kinda contradictory. What is your point?

I'm talking about different extensions. Making x1-x31 operate on floats is free, making v0 a mask register on low bits isn't.
This has also been done in Azul Vega manycore CPUs.

Follow

@iska
I see! No idea why it's this way, I think the reasoning behind it might be less obvious and has to do with internal schematics, could be that using the same register for integer and IEEE 754 encoded values makes the load-store paths significantly more complex 🤷

@m0xee@social.librem.one @iska@catposter.club not by much, and probably made up by not creating 32+ extra registers.
It's more of a historical artifact than anything

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml