[Top][All Lists]

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

Re: [PATCH] Add "riscv" as an alias for "riscv32"

From: Palmer Dabbelt
Subject: Re: [PATCH] Add "riscv" as an alias for "riscv32"
Date: Thu, 21 Jun 2018 12:11:19 -0700 (PDT)

I like the idea of forcing an explicit target declaration for our cross compilers -- it's stronger than even just "riscv-*" needs it, as "riscv32-*" isn't sufficient to determine the target. This behavior manifests because the RISC-V ISA is defined as a set of base ISAs along with a set of extensions. The base ISAs are

* rv32e: 16 integer registers, each of 32 bits
* rv32i: 32 integer registers, each of 32 bits
* rv64i: 32 integer registers, each of 64 bits

and the currently defined user-mode extensions are

* m: Adds multiplication and division instructions
* a: Adds atomic operations (lr/sc and various AMOs)
* f: Adds 32 single precision registers along with single-precision instructions * d: Extends the F register set to double precision and adds the corresponding instructions.
* c: Adds compressed versions of many common instructions

We express this to the compiler using the "-march" argument, via a string that looks something like "-march=rv64imafdc", which controls the instructions available for code generation. We also have an ABI selection argument, -mabi, which allows users to select the calling convention used (this exists to allow things like Intel's x32 and ARM's softfloat/softfp/hardfp). There's a third argument, -mtune, that controls how to tune for a particular microarchitecture.

Toolchains will default to one {-march, -mabi, -mtune} value, which is a compile-time setting. binutils and GCC always support code generation for all legal {-march, -mabi, -mtune} settings, but a multilib toolchain is necessary to have multiple libc/libgccs (and even then we limit this to the commonly used settings, as otherwise there would be hundreds). The current scheme is that "riscv32-*" defaults to some rv32i-based target and "riscv64-*" defaults to some rv64i-based target, but nothing tells you which one. The currently appearing "riscv-*" binaries might default to rv32i or rv64i depending on who produced it.

We originally kicked around the idea of calling the targets "riscv32imac-*", but when we ended up with the mostly orthogonal -mabi and -mtune arguments we decided to give up as a tuple like "riscv32imacilp32rocket-*" seemed just too insane to deal with. As a result we just tell users that they should always fully specify {-march, -mabi, -mtune} when cross compiling, and that build systems should just ignore the tuple as it doesn't really mean anything.

I'd like to keep the behavior for native compilers where the default target is the native host, as otherwise we'll end up with unnecessary arguments floating around everywhere.

I've written a blog post about our target compiler options if you're interested

Sorry if that's a bit too much detail...

On Thu, 21 Jun 2018 11:46:21 PDT (-0700), address@hidden wrote:
Ah OK. So this boils down to the difference between configs for targets
and configs for toolchains. Configs for targets should be precise as
possible [1], and `riscv-*` makes no sense. Configs for tools are
actually the *set* of configs the tool targets and so `riscv-` does
indeed make make perfect sense [2]. So we can add a flag to gnu config
(with sensible default) to only allow stuff like this for the latter
tool case. We could also choose to add another shell script answering
"does (tool) config a cover config b", codifying that relation. I would
volunteer to do both of these things if a RISC-V person can give me a
table with the intend relation.

I agree with the gist of what Earnie says. To preserve symmetry and not
surprise the user with weird defaults, I'd say a `riscv-*` tool-chain
shouldn't default to 32-bit, 64-bit, or anything else. So the `-m64` or
whatever is required. Or perhaps to make native compilation a bit easier
a RISC-V tool chain should *only* default to a specific variant of
RISC-V if that platform is the host platform, so cross compilation must
be explicit, but native compilation with explicit-config tools can be


[1] Configs for targets are more known with LLVM than GNU tools, and
their `-target` flag. But certain GNU binutils (e.g. objdump) do support
`--target` so it's not just an LLVMism.
[2] Yet another example of autotools and friends forcing a single target
platform muddying the waters.

On 06/21/18 13:49, Earnie wrote:
On 6/20/2018 7:55 PM, Palmer Dabbelt wrote:
The one saving grace here is that most of the RISC-V toolchains support
generating code for all targets -- in other words "riscv32-*-gcc
-march=rv64gc" is a valid thing to do, and will generate 64-bit code
(and links against a 64-bit libc).  As a result, none of this actually

Given this I can understand the frustration of needing the 32/64
specifier.  I would then suggest the patch removes riscv32 and riscv64
specifics and use riscv* instead.  I.E. use riscv*-* as the filter.

reply via email to

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