Why does a user who doesn't know what *bitwidth* they want pass an
explicit config anyways? IMO it's a shame legacy ones need have both
explicit and implicit variants on so many axes---one has to know the
fully history to tell what's going on which might be fine for greybeards
but is hostile to new programmers. The required bitwidth for new arches
like wasm and riscv restores the symmetry, and so is pleasing to the
eye, clearer to the beginner, and simpler for the implementation. I am
strongly against this change.
John
On 06/20/18 13:24, Palmer Dabbelt wrote:
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 unintuiative and would like tuples to be "riscv-*".
This patch enables "riscv-*" tuples by adding a config.sub rule that
replaces "riscv-*" with "riscv32-*". The first ISA described by the
RISC-V specification is RV32I, a 32-bit ISA, so making "riscv-*" mean
32-bit seems like the sane way to go. There are also handful of tests
added, which all pass for me.
This has been discussed on various mailing lists a half dozen times, but
I never got around to submitting a patch