Hi,
Thank you all for the valuable feedback on the previous related thread
(http://lists.gnu.org/archive/html/config-patches/2018-06/threads.html).
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
distribution.
First, I'll state what this proposal **is not**:
- it **is not** about renaming the Linux RISC-V compiler, in any Linux
distribution
- 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,
like:
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.
Regards,
Liviu
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
;;
none)
;;
+ embed)
+ ;;
*-eabi)
;;
*)
```
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).
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
