Please reinstate the rv32ec/ilp32e libraries

[basilhussain]

I note that all new releases since September 2024 (v14.2.0-2, v13.3.0-2, v12.4.0-2, v11.5.0-2) no longer feature rv32ec/ilp32e libraries. Was there a specific reason for the removal?

Such removal is detrimental to all (myself included) who rely on xPack RISC-V GCC to compile code for RV32E microcontrollers that support the 'C' compact instruction extension. For example, the very popular CH32V00x series of microcontrollers.

The impact is that any code being compiled and linked with -mabi=ilp32e -march=rv32ec gets silently 'downgraded' to instead use the rv32e/ilp32e libraries, and the resulting compiled binaries become larger, even with no other changes. When this happens, there may be no clue readily apparent to the user as to why - I believe the only indication is via the library paths given in map file output (i.e. from -Wl,-Map).

Without the rv32ec library functions, compiled binary sizes can increase by hundreds of bytes or potentially kilobytes! When dealing with microcontrollers that have flash memory measured in only tens of kilobytes, such increases could make the difference between code fitting within the available flash and suddenly not.

Could you please reinstate the rv32ec/ilp32e libraries?

[ilg-ul]

Was there a specific reason for the removal?

I have nothing agains rv32ec in particular, just that the previous list of libraries was combinatorial and grew too large. Having no other inspiration, when I had to cut it to a reasonable size, I used the same list as Debian packages.

Could you please reinstate the rv32ec/ilp32e libraries?

I'll consider this for the next release.

I would like to ask you a favour. I have no experience with the new RISC-V devices available on the market. Could you do a small study and check if their architectures are supported by the xPack toolchain, and possibly suggest new libraries to be included?

[ilg-ul]

I took a look at the current list. As a temporary workaround, if your code does not use atomic instructions, could you use the rv32eac library?

[basilhussain]

I'll consider this for the next release.

Thanks! 😃

I would like to ask you a favour. I have no experience with the new RISC-V devices available on the market. Could you do a small study and check if their architectures are supported by the xPack toolchain, and possibly suggest new libraries to be included?

I'm not really familiar with the variety of what's around, but I found this article which seems to give a pretty good run-down.

For WCH microcontrollers in particular (which is what I'm most familiar with), while device models are too numerous to list here, they basically only have three different CPU cores:

• QingKeV2A - RV32EC
• QingKeV2C - RV32EmC*
• QingKeV3A - RV32IMAC
• QingKeV3B - RV32IMCB*
• QingKeV3C - RV32IMCB*
• QingKeV4A - RV32IMAC
• QingKeV4B - RV32IMAC
• QingKeV4C - RV32IMAC
• QingKeV4F - RV32IMACF

(* 'm' - Zmmul only; 'B' - unsure if conforms to ratified standard)

As far as microcontrollers goes in general - as opposed to larger SoCs - I think it's safe to say that at least the following is needed:

• EC
• IMC
• IMAC
• IMACF

RISC-V microcontrollers pretty much always support 'C', because small code size is typically of great importance in embedded applications, due to limited on-chip flash sizes.

As a temporary workaround, if your code does not use atomic instructions, could you use the rv32eac library?

If it means the library code will contain Atomic extension instructions, then no. CH32V00x is strictly RV32EC only; I suspect you'd just get an illegal instruction hard fault if it tried to execute any 'A' instruction.

[ilg-ul]

but I found this article

Yes, good article.

I think it's safe to say that at least the following is needed...

imacf is present as rv32imafc_zicsr.

So only ec, imc, imac are missing?

Tommy @TommyMurphyTM1234, any comments on this proposal?

If it means the library code will contain Atomic extension instructions, then no. CH32V00x is strictly RV32EC only; I suspect you'd just get an illegal instruction hard fault if it tried to execute any 'A' instruction.

I did not check the compiler and the library source code, so I might be wrong, but I don't think that the compiler has any reasons to generates atomic instructions for usual C code, you need to explicitly include <stdatomic.h> to get atomic support, which I doubt you do.

I suggest you give it a try.

It'll probably take me some time, possibly a few weeks, to prepare a new maintenance release with the new libraries.

[TommyMurphyTM1234]

Tommy @TommyMurphyTM1234, any comments on this proposal?

I saw the issue being logged and updated but I haven't had a chance yet to review matters and the proposed modified set of multilibs...

I did not check the compiler and the library source code, so I might be wrong, but I don't think that the compiler has any reasons to generates atomic instructions for usual C code, you need to explicitly include <stdatomic.h> to get atomic support, which I doubt you do.

That's my understanding too - i.e. that the compiler will never "automatically" generate atomic instructions.

[basilhussain]

So only ec, imc, imac are missing?

That would appear to be the case, yes. I would bet that set of 4 would cover 99% of RISC-V microcontrollers.

I did not check the compiler and the library source code, so I might be wrong, but I don't think that the compiler has any reasons to generates atomic instructions for usual C code, you need to explicitly include <stdatomic.h> to get atomic support, which I doubt you do.

I suggest you give it a try.

I would hope that would be the case, but I wouldn't feel safe relying on that assumption.

In any case, I tried compiling one of my code bases with 13.3.0-2 and rv32eac and I only get a single-byte difference between that and the same compiled with 13.3.0-1 and rv32ec. So, for this code base at least (which uses minimal libgcc and libc functions), I get usable results.

(Side note: I'm a bit confused by this single-byte difference, as it's in a section of my own code, and it's a addi a3,a3,-1316 that has become a addi a3,a3,-1315. No idea why an offset literal value would change when literally every other byte in the binary is identical... 😕)

It'll probably take me some time, possibly a few weeks, to prepare a new maintenance release with the new libraries.

Not a problem for me personally. I'm just continuing to use the older versions anyway. 😄

For people who've inadvertently upgraded their riscv-none-elf-gcc package, in the meantime they could downgrade I suppose.

[ilg-ul]

To summarise, the missing libraries are:

• rv32ec
• rv32imc
• rv32imac

The WCH specific extensions are out of my scope.

[TommyMurphyTM1234]

The WCH specific extensions are out of my scope.

Can you clarify what you're referring to here?
I presume something like...

1. __attribute __ ((interrupt("WCH-Interrupt-fast")))
2. WCH (or QingKe?) proprietory non-standard extension xw
3. Other?

[ilg-ul]

All of the above.

[basilhussain]

The WCH specific extensions are out of my scope.

Yes, of course, because none of that is in mainline GCC. Although it would be nice if they added XW support.

[ilg-ul]

it would be nice if they added XW support.

Sure, ask them, perhaps they'll do it. I have no contacts there.

[TommyMurphyTM1234]

The WCH specific extensions are out of my scope.

Yes, of course, because none of that is in mainline GCC. Although it would be nice if they added XW support.

Did MounRiver ever release their modifications to GCC that added support for it, as they're obviously obliged to do under GPL?

[ilg-ul]

No idea.