[lowrisc-dev] Codename for architecture (GNU autotools, etc)?

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Sat Nov 1 20:37:30 GMT 2014

2014-11-01 17:33 Alex Bradbury:
>On 1 November 2014 15:01, Manuel A. Fernandez Montecelo
><manuel.montezelo at gmail.com> wrote:
>> In recent times and for the most popular devices, ARM seems to go mostly
>> with little endian, but there are also big-endian systems.  IBM created
>> and seems to be investing more effort in ppc64el after having ppc64,
>> because apparently there is a stronger demand for customers.  MIPS have
>> also mips/mipsel and mips64/mips64el.  In these cases (and same for many
>> other CPUs), they have "registered" the full range of architecture names
>> in these GNU autotools files, while there is only the aforementioned
>> "riscv32 | riscv64" for RISC-V, with no "le/el" or "be/eb" attached.
>Little endian is our priority, I don't see any real benefit in
>splitting effort and I doubt there's enough interest in big-endian.
>There's nothing stopping a big-endian RISC-V implementation, but is
>there really demand for it?

I do not know about the demand, I was just asking what were the plans.
Little endian is fine by me.

>> So, my doubts are:
>> - RISC-V is little-endian in principle, so I guess that the names above
>>  "riscv32 | riscv64" will imply little-endianness, but the ISA manual
>>  says that there can be big or bi-endian variants.
>>  Which one does lowRISC plan to use?  And what will be the codename of
>>  the architecture in that case -- "riscv64el/-le", "riscv64eb/-be", or
>>  just plainly "riscv64" (implying little endian)?
>I suppose these are issues to be sorted out with the wider risc-v
>community. The main processor core will be RV64 'G' as described in
>the ISA spec (i.e. base integer spec + mul/div + atomics + float +
>double) which is what I imagine riscv32/risc64 would commonly be
>interpreted as. For compilers, we'll want something like
>march/mcpu/mtune to specify compilation for a specific implementation
>with given extensions.
>> - Does lowRISC plan to use different extensions or modifications of
>>  RISC-V, so that the architecture name will be different from
>>  "riscv64*" in any case?
>We will have instruction set extensions for manipulating our tagged
>memory support (initial thoughts on tagged memory are here
>https://speakerdeck.com/asb/lowrisc-a-first-look). For arm, you can
>specify -march=armv8-a+crc to indicate armv8-a with the optional crc
>extensions. Possibly we'd have something similar. I can't answer
>precisely, because this needs a bigger conversation with the wider
>RISC-V community, and the GCC and LLVM community who can advise on how
>well the architecture feature selection interface works on existing

About the two items above, apart from endianness, I was asking because
this is important when choosing a baseline when creating large bodies of

For example, in the GNU/Linux world, there are two important examples
related with these issues:

- In x86, some newer distributions targetted only 586 or 686 (I think
  that Ubuntu and Fedora did that since the beginning), while other
  older distributions provided binaries capable of running also on 386
  or 486, without special "ports" for newer systems.  In the former
  case, users of older systems cannot even install and run the
  distribution, but in the latter case, users of newer systems will run
  binaries which are not optimised for their processors.

  (One option to alleviate this problem when the baseline is 386/486 is
  to provide packages specially optimised for the newer flavours of the
  architecture, like libc or media players -- when the advantages in
  performance are relevant enough).

- When the Raspberry Pi came out, instead of being able to use the armel
  or armhf architecture in Debian which was already available, people
  had to go and recompile everything in the new distribution Raspbian
  (or would have to create a new port in Debian or other distributions).

So in the case of lowRISC/RISC-V, there are two possibilities:

- one possibility would be to create a base system targetting the "RV64
  G" that you mention, so people could use it if/when other RISC-V based
  systems become available.  Special applications taking advantage of
  the tagged memory in lowRISC could of course be provided (similar to
  having a baseline of 486, but with special versions of some
  applications only able to run in lowRISC-compatible systems).

- if the extension of tagged memory is central to the idea of lowRISC
  and it's intended that all libraries and applications use it, then the
  whole body of software would be compiled to use these extensions.  But
  then it would mean that the software could not be shared with other
  possible RISC-V 64 systems coming in the future, and that the effort
  to maintain the collection of software would have to be taken by the
  lowRISC community exclusively.

Perhaps as you say it's too early for this, but it is important to take
this into account before people start to create collections of software
for this system -- this is often a multi-year effort with many people

>> - What would be the architecture triplet name, for GNU toolchain?  The
>>  compiler from RISC-V github repositories so far provides:
>>  riscv64-unknown-linux-gnu.
>Same as above really.
>> Maybe some of these questions are not decided yet, or things like naming
>> in GNU autotools files depend mostly on decisions to be taken by RISC-V
>> folks rather than people involved in list...  But I would be grateful of
>> any information and pointers that you can provide.
>Sorry this response doesn't contain many solid answers, as you say a
>lot of this comes down to the RISC-V, GCC, and LLVM communities.

Well, I expected as much, just wanted to get a feeling of the current
plans :-)

Thanks for the replies.

Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>

More information about the lowrisc-dev mailing list