riscv: Introduce T-Head extensions relevant to E serie

[VynDragon]

Adds xtheadba, xtheadbb, xtheadbs, xtheadcmo, xthead, xtheadcondmov, xtheadfmv, xtheadint, xtheadmac, xtheadmemidx, and xtheadsync.

GCC can take those options already, but it doesnt do anything at this moment as there is no implementation

These extensions are available on T-Head E907, and some as well on T-Head E906. These instructions are relevant for devices like Bouffalolab BL616, Allwinner V853, Artin D133...

[github-actions]

Hello @VynDragon, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[fkokosinski]

Hi, thanks for the PR!

GCC can take those options already, but it doesnt do anything at this moment as there is no implementation

Which GCC can? From the changelog I can see that GCC 13 supports those extensions: https://gcc.gnu.org/gcc-13/changes.html

But in Zephyr SDK we're using GCC 12.2.0 (with custom Zephyr patches): https://github.com/zephyrproject-rtos/gcc/commits/zephyr-gcc-12.2.0

[VynDragon]

Hi, it doesn't do anything with gcc 13 either, there is still no implementation of those extensions in mainline/riscv gcc at all beside the extension names input.

LLVM/clang does support them fully, I believe they share target_riscv.cmake so that also gives it the support as well.

[fkokosinski]

Hi, it doesn't do anything with gcc 13 either, there is still no implementation of those extensions in mainline/riscv gcc at all beside the extension names input.

LLVM/clang does support them fully, I believe they share target_riscv.cmake so that also gives it the support as well.

I get that.

My main concern is that even though the GCC 12.2.0 that Zephyr SDK uses can "accept" (i.e. it doesn't error out when they are passed) these extensions in the march cmdline argument, we're still essentially providing it extensions that it doesn't even mention in it's source code. This could give a wrong impression to the next person working on adding a new SoC, and selecting these Kconfig options without knowing that they are essentially unsupported by the GCC version shipped with Zephyr SDK.

But I guess that falls more into the "Toolchain Integration" area of maintenance, so @tejlmand or @stephanosio would have to chime in here.

[stephanosio]

But I guess that falls more into the "Toolchain Integration" area of maintenance, so @tejlmand or @stephanosio would have to chime in here.

The question is: does Binutils support these extensions? (i.e. can the assembler assemble the instructions from these extensions?)

If yes, then I do not think we need to do anything special here since -march flag does not imply GCC actively emitting all the instructions from the specified extensions -- it just needs to be able to recognise and assemble the instructions from the specified extensions in inline assembly.

If no, then we should emit a warning.

[VynDragon]

they are essentially unsupported by the GCC version shipped with Zephyr SDK.

Ah sorry, yes, but currently it does have the extensions listed in 13 but still does nothing with them as mentioned, so it's just inline with the current support status, even on 12. The difference is likely that on 13 you dont have to specify the version to avoid a error.

The question is: does Binutils support these extensions? (i.e. can the assembler assemble the instructions from these extensions?)

If you mean does it take 'th.icache.iall' in __asm__, no it does not, had to use .insn and direct CSR numbers for bl616 that requires xtheadcmo to work.