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

Alex Bradbury asb at asbradbury.org
Sat Nov 1 22:41:50 GMT 2014


On 1 November 2014 20:37, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> About the two items above, apart from endianness, I was asking because
> this is important when choosing a baseline when creating large bodies of
> software.
>
> 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
> involved.

In terms of what's defined right now, the safest target is the RV64
'G'. However, for people doing research, adding new extensions, or
proposing ABI changes being able to re-bootstrap is I think a high
priority. This is trivial with buildroot/yocto and others but sadly
significantly less straightforward with Debian, despite the work over
the past few years via Wookey and GSoC students.

Regarding tagged memory, and software compatibility I agree this is a
concern. Compatibility will be one of the things we consider carefully
when pinning down exactly what the ISA interface to tagged memory is.
However, for the read-only protection of return address + vtable
pointers I described in my talk, which we imagine would be compiled-in
by default, a little bit of extra metadata could allow binaries to be
transformed in a straight-forward manner at install time or even load
time. Use of tagged memory in lowRISC is an idea that I think has lots
of promise and can provide real security benefits, but we certainly
don't want that to be at the cost of causing a hard fork in the RISC-V
community from day one. This sort of issue is the sort of thing I'm
hoping all of us RISC-V implementers and distributors can discuss at
the workshop in January <http://riscv.org/workshop/>.

Having a situation like exists with armhf for Raspberry Pi (armv6) and
for armv7 is is definitely what we want to avoid. Either we're able to
accommodate the potential lack of availability of certain extensions
by detection at load or install time, or in the worst case this is
infeasible and we need to work so that the overhead in supporting
different variants of packages is minimal.

Alex

On 1 November 2014 20:37, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 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
>> archs.
>
>
> About the two items above, apart from endianness, I was asking because
> this is important when choosing a baseline when creating large bodies of
> software.
>
> 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
> involved.
>
>
>>> - 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>
>
> _______________________________________________
> lowrisc-dev mailing list
> lowrisc-dev at lists.lowrisc.org
> http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org



More information about the lowrisc-dev mailing list