[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] Add "riscv-" for embedded cross toolchains

From: Liviu Ionescu
Subject: [RFC] Add "riscv-" for embedded cross toolchains
Date: Sat, 23 Jun 2018 13:21:20 +0300


Thank you all for the valuable feedback on the previous related thread 

However I think the topic needs a reset.

The initial assumption for the patch was:

> Most RISC-V toolchains can generate code for all RISC-V targets, but are
> currently named "riscv32-*" and "riscv64-*".  Users have suggested that
> these names are unintuitive and would like tuples to be "riscv-*".

Well, I don't know other users who suggested this, so I'll speak only for 
myself, based on the experience with the GNU MCU Eclipse RISC-V Embedded GCC 

First, I'll state what this proposal **is not**:

- it **is not** about renaming the Linux RISC-V compiler, in any Linux 
- it **is not** about automatically renaming `riscv-` to anything else
- generally it **is not** about disturbing any native RISC-V compiler, in any 
Linux distribution, in any way; from my point of view the naming scheme for the 
native compilers is ok, and I see no reason to change it.

However, the use case for native compilers is different from the use case for 
embedded cross toolchains, since embedded cross toolchains:

- do not need to be 'guessed' for capabilities in configure scripts,
- are not related, in terms of 32/64-bit capabilities, to the host platform 
where they run,
- generally are distributed as a single executable that is capable of 
generating binaries for multiple architectures/ABIs, with multilibs.

The RISC-V non-Linux toolchain is no exception, a single executable can 
generate binaries for many architectures/ABIs based on separate `-march` & 
`-mabi` options (in their RISC-V GCC distribution, Microsemi identified 39(!) 
different multilib combinations).

In this context, it is more natural to invoke the compile using something like:

  riscv-xxx-gcc -march=rv32i -mabi=ilp32  <- generate a 32-bit binary
  riscv-xxx-gcc -march=rv64i -mabi=lp64   <- generate a 64-bit binary

Since the current config.sub file does not accept `riscv-`, and only explicit 
`riscv32-` and `riscv64-` are allowed, this leads to confusing invocations, 

  riscv32-unknown-elf-gcc -march=rv64i -mabi=lp64 <- generate a 64-bit binary

The current proposal adds exactly this, the `riscv-*` tuple prefix alongside 
the existing `riscv32-*` and `riscv64-*`.

I think that this can be an incremental step towards a more elaborate mechanism 
that John defined as "config-for-target vs config-for-toolchain". I agree that 
"exact-target" and "toolchain" use-cases are fundamentally different, and one 
specifics should not be imposed on the other.

I definitely welcome John volunteering to implement such a mechanism.



p.s. For completeness, the proposed patch, as already used in GNU MCU Eclipse 
RISC-V Embedded GCC is:

diff --git a/config.sub b/config.sub
index d1f5b54..cc4d9ed 100755
--- a/config.sub
+++ b/config.sub
@@ -752,7 +752,7 @@ case $basic_machine in
        | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* \
        | pru-* \
        | pyramid-* \
-       | riscv32-* | riscv64-* \
+       | riscv32-* | riscv64-* | riscv-* \
        | rl78-* | romp-* | rs6000-* | rx-* \
        | sh-* | sh[1234]-* | sh[24]a-* | sh[24]aeb-* | sh[23]e-* | sh[34]eb-* 
| sheb-* | shbe-* \
        | shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
@@ -1522,6 +1522,8 @@ case $os in
+       embed)
+               ;;

In addition, this patch adds `embed` as an acceptable suffix for the tuple, for 
explicit use in embedded toolchains that do not have a separate embedded ABI 
(RISC-V case for now).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]