Toolchain architecture and abi support

[Tommy Murphy]

Is the info here up to date and authoritative with regard to architecture and abi support in the toolchain?

https://github.com/riscv/riscv-gnu-toolchain

Some specific questions - if there is already documentation that answers any of these questions then just point me at it...

1. Are rv32i and rv64i with any combination of the m, a, f, d or g (= mafd) extensions the full list of architectures supported or are there more?
2. That page doesn't mention the c (compressed) extension or other extensions mentioned in the spec (https://riscv.org/specifications/) so are these not explicitly supported at the moment?
3. Is the full list of supported abis as follows: ilp32, ilp32d, ilp32f, lp64, lp64f, lp64d or are there also others?
4. I presume that the 32 bit abis are only supported by the 32 bit architectures (assuming the appropriate extensions are also supported) and not also by 64 bit architectures?
5. I presume that the 64 bit abis are not supported by any rv32 architecture?
6. The only reference to configure --enable-multilib is to the linux build of the tools but doesn't this also work for the bare metal/newlib tools?
7. Is there any specific rationale for the default set of multilibs built (https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/t-elf-multilib)?

Thanks a lot

Regards

Tommy

[Richard Herveille]

It seems like (4) is true, although that feels very weird. I would assume an RV64 CPU would be able to execute RV32 code, but that doesn’t seem to be the case.

Richard

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/084434b2-3af8-46b4-8ea9-9c6665ae66f3%40groups.riscv.org.

[Michael Chapman]

Correct  - the 32 bit instruction set is not a subset of the 64 bit one and a binary generated for the 32 bit ISA set will in general *not* run on the 64 bit ISA.

Personally I think this is a short-sighted error.

Mike

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/12C8E750-94BE-44EF-BF75-7518D5220EBA%40roalogic.com.

[Tommy Murphy]

Following on from my original post ... does a full list of all valid architecture/abi tuples exist anywhere or is it possible to easily generate same?

I was trying to figure this out from the comments in the multilib-generator script but am still a bit confused...

[Liviu Ionescu]

> On 29 Jun 2017, at 19:11, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> ... a full list of all valid architecture/abi tuples ...

$ riscv64-unknown-elf-gcc -print-multi-lib
.;
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32imac/ilp32;@march=rv32imac@mabi=ilp32
rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f
rv64imac/lp64;@march=rv64imac@mabi=lp64
rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d


regards,

Liviu

[Tommy Murphy]

Thanks Liviu.

Isn't that a list of multilibs that a build of the tools supports (when configure --enable-multilib) is used?

As opposed to the theoretical full list of tuples that might be created which is what I'm asking about here.

--enable-multilib uses this to build different libs but I don't think that it's an exhaustive list?

https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/t-elf-multilib

Regards

Tommy

[Liviu Ionescu]

> On 29 Jun 2017, at 19:23, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> Thanks Liviu.
> Isn't that a list of multilibs that a build of the tools supports (when configure --enable-multilib) is used?

that's correct.

> As opposed to the theoretical full list of tuples that might be created which is what I'm asking about here.

ah, ok, perhaps there are a few more.

in my opinion there are already too many, you need to run a toolchain build and you'll know what I'm talking about...


regards,

Liviu

[Richard Herveille]

I think any combination is possible. 

I changed the multi-lib configuration file and added some combinations. The toolchain builds them. Although I am now building the libraries on the fly, because the toolchain always picks up the default 64Bit libraries (bug?!). 

Richard

Sent from my iPad

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/94ffa5a3-a3c1-42db-9c39-6b19e5f92f6d%40groups.riscv.org.

[Palmer Dabbelt]

On Thu, 29 Jun 2017 09:29:04 PDT (-0700), i...@livius.net wrote:
>
>> On 29 Jun 2017, at 19:23, Tommy Murphy <tommy_...@hotmail.com> wrote:
>>
>> Thanks Liviu.
>> Isn't that a list of multilibs that a build of the tools supports (when configure --enable-multilib) is used?
>
> that's correct.
>
>> As opposed to the theoretical full list of tuples that might be created which is what I'm asking about here.
>
> ah, ok, perhaps there are a few more.

We support all the ISA combinations allowed by the spec except Q, and all the
legal ABI combinations where __riscv_xlen/8 == SIZEOF_LONG. Illegal ABIs are
simply when the ABI defines that arguments are passed in F register bits that
don't exist (ie, lp64d on rv64if).

Here's my attempt at creating a list, but it might be wrong. I find the
constraints easier to reason about than the list.

$ for b in rv32e rv32i rv64i; do for m in "" m; do for a in "" a; do for f in
"" f fd; do for c in "" c; do for ab in ilp32 lp64; do for af in "" $(echo $f |
cut -c1) $(echo $f | cut -c2); do echo "-march=$b$m$a$f$c -mabi=$ab$af"; done;
done; done; done; done; done; done | grep -v -e '-march=rv32e.*f' | grep -v -e
'-march=rv64.*-mabi=ilp32.*' | grep -v -e '-march=rv32.*-mabi=lp64.*' | sort |
uniq

-march=rv32e -mabi=ilp32
-march=rv32ea -mabi=ilp32
-march=rv32eac -mabi=ilp32
-march=rv32ec -mabi=ilp32
-march=rv32em -mabi=ilp32
-march=rv32ema -mabi=ilp32
-march=rv32emac -mabi=ilp32
-march=rv32emc -mabi=ilp32
-march=rv32i -mabi=ilp32
-march=rv32ia -mabi=ilp32
-march=rv32iac -mabi=ilp32
-march=rv32iaf -mabi=ilp32
-march=rv32iaf -mabi=ilp32f
-march=rv32iafc -mabi=ilp32
-march=rv32iafc -mabi=ilp32f
-march=rv32iafd -mabi=ilp32
-march=rv32iafd -mabi=ilp32d
-march=rv32iafd -mabi=ilp32f
-march=rv32iafdc -mabi=ilp32
-march=rv32iafdc -mabi=ilp32d
-march=rv32iafdc -mabi=ilp32f
-march=rv32ic -mabi=ilp32
-march=rv32if -mabi=ilp32
-march=rv32if -mabi=ilp32f
-march=rv32ifc -mabi=ilp32
-march=rv32ifc -mabi=ilp32f
-march=rv32ifd -mabi=ilp32
-march=rv32ifd -mabi=ilp32d
-march=rv32ifd -mabi=ilp32f
-march=rv32ifdc -mabi=ilp32
-march=rv32ifdc -mabi=ilp32d
-march=rv32ifdc -mabi=ilp32f
-march=rv32im -mabi=ilp32
-march=rv32ima -mabi=ilp32
-march=rv32imac -mabi=ilp32
-march=rv32imaf -mabi=ilp32
-march=rv32imaf -mabi=ilp32f
-march=rv32imafc -mabi=ilp32
-march=rv32imafc -mabi=ilp32f
-march=rv32imafd -mabi=ilp32
-march=rv32imafd -mabi=ilp32d
-march=rv32imafd -mabi=ilp32f
-march=rv32imafdc -mabi=ilp32
-march=rv32imafdc -mabi=ilp32d
-march=rv32imafdc -mabi=ilp32f
-march=rv32imc -mabi=ilp32
-march=rv32imf -mabi=ilp32
-march=rv32imf -mabi=ilp32f
-march=rv32imfc -mabi=ilp32
-march=rv32imfc -mabi=ilp32f
-march=rv32imfd -mabi=ilp32
-march=rv32imfd -mabi=ilp32d
-march=rv32imfd -mabi=ilp32f
-march=rv32imfdc -mabi=ilp32
-march=rv32imfdc -mabi=ilp32d
-march=rv32imfdc -mabi=ilp32f
-march=rv64i -mabi=lp64
-march=rv64ia -mabi=lp64
-march=rv64iac -mabi=lp64
-march=rv64iaf -mabi=lp64
-march=rv64iaf -mabi=lp64f
-march=rv64iafc -mabi=lp64
-march=rv64iafc -mabi=lp64f
-march=rv64iafd -mabi=lp64
-march=rv64iafd -mabi=lp64d
-march=rv64iafd -mabi=lp64f
-march=rv64iafdc -mabi=lp64
-march=rv64iafdc -mabi=lp64d
-march=rv64iafdc -mabi=lp64f
-march=rv64ic -mabi=lp64
-march=rv64if -mabi=lp64
-march=rv64if -mabi=lp64f
-march=rv64ifc -mabi=lp64
-march=rv64ifc -mabi=lp64f
-march=rv64ifd -mabi=lp64
-march=rv64ifd -mabi=lp64d
-march=rv64ifd -mabi=lp64f
-march=rv64ifdc -mabi=lp64
-march=rv64ifdc -mabi=lp64d
-march=rv64ifdc -mabi=lp64f
-march=rv64im -mabi=lp64
-march=rv64ima -mabi=lp64
-march=rv64imac -mabi=lp64
-march=rv64imaf -mabi=lp64
-march=rv64imaf -mabi=lp64f
-march=rv64imafc -mabi=lp64
-march=rv64imafc -mabi=lp64f
-march=rv64imafd -mabi=lp64
-march=rv64imafd -mabi=lp64d
-march=rv64imafd -mabi=lp64f
-march=rv64imafdc -mabi=lp64
-march=rv64imafdc -mabi=lp64d
-march=rv64imafdc -mabi=lp64f
-march=rv64imc -mabi=lp64
-march=rv64imf -mabi=lp64
-march=rv64imf -mabi=lp64f
-march=rv64imfc -mabi=lp64
-march=rv64imfc -mabi=lp64f
-march=rv64imfd -mabi=lp64
-march=rv64imfd -mabi=lp64d
-march=rv64imfd -mabi=lp64f
-march=rv64imfdc -mabi=lp64
-march=rv64imfdc -mabi=lp64d
-march=rv64imfdc -mabi=lp64f

[Tommy Murphy]

Hi Richard - I think that this is something that you flagged in another thread?

Is there an bug/issue logged relating to this?

Do you mean that this issue specifically affects builds targeting rv64 (e.g. -march=rv64...) and not also rv32?

And is it your experience is that it always links the default (rv64g?) libs so that, for example, using -march=rv64ima (i.e. no hard float support) results in your program code trying to link with libraries that use hard float support and resulting in linker errors due to the mismatch?

I think that I have seen that too but assumed that I was simply doing something wrong.

[Tommy Murphy]

Thanks a lot Palmer.

That's some list alright! :-)

On Thursday, 29 June 2017 20:56:18 UTC+1, Palmer Dabbelt wrote:

We support all the ISA combinations allowed by the spec except Q, and all the
legal ABI combinations where __riscv_xlen/8 == SIZEOF_LONG.  Illegal ABIs are
simply when the ABI defines that arguments are passed in F register bits that
don't exist (ie, lp64d on rv64if).

Here's my attempt at creating a list, but it might be wrong.  I find the
constraints easier to reason about than the list.

$ for b in rv32e rv32i rv64i; do for m in "" m; do for a in "" a; do for f in
"" f fd; do for c in "" c; do for ab in ilp32 lp64; do for af in "" $(echo $f |
cut -c1) $(echo $f | cut -c2); do echo "-march=$b$m$a$f$c -mabi=$ab$af"; done;
done; done; done; done; done; done | grep -v -e '-march=rv32e.*f' | grep -v -e
'-march=rv64.*-mabi=ilp32.*' | grep -v -e '-march=rv32.*-mabi=lp64.*' | sort |
uniq

<snip>

[Richard Herveille]

Hi Tommy,

I have not flagged a bug for this, not sure where/how.

I’ve seen the issue for both RV32 and RV64. The directory structure seems like this:

- default (RV64G)

- multilib dirs (with multiple subdirs)

During linking I get an error that the chosen ABI doesn’t match the target ABI. When examining the message, this is related to the tool picking up the default (RV64G) library, instead the ones from the multi-lib directories.

BTW that’s for 6.1. I don’t know if this is fixed in 7.x

Richard

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/e70f7a20-2766-4dac-8d7d-86818dfc131a%40groups.riscv.org.

[Tommy Murphy]

OK - I'm not sure if I'm having the same issue.

I'm building the tools from the latest github contents as follows:

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain/riscv-gcc
contrib/download_prerequisites
cd ..
./configure --prefix=`pwd`/riscv-unknown-elf-gcc --enable-multilib
make

After building the tools I have these multilib folders:

$ tree -d lib riscv64-unknown-elf/lib/
lib
└── gcc
    └── riscv64-unknown-elf
        └── 7.1.0
            ├── include
            ├── include-fixed
            ├── install-tools
            │   └── include
            ├── rv32i
            │   └── ilp32
            ├── rv32iac
            │   └── ilp32
            ├── rv32im
            │   └── ilp32
            ├── rv32imac
            │   └── ilp32
            ├── rv32imafc
            │   └── ilp32f
            ├── rv64imac
            │   └── lp64
            └── rv64imafdc
                └── lp64d
riscv64-unknown-elf/lib/
├── ldscripts
├── rv32i
│   └── ilp32
├── rv32iac
│   └── ilp32
├── rv32im
│   └── ilp32
├── rv32imac
│   └── ilp32
├── rv32imafc
│   └── ilp32f
├── rv64imac
│   └── lp64
└── rv64imafdc
    └── lp64d

36 directories

I am able to compile programs for our RV32IM target OK.

I am also able to compile programs for our RV64GC target if I tweak some settings (and at the moment I ignore the C extension capability):

-march=rv64g
-mabi=lp64d
-mcmodel=medany

Initially I was using the following - ignoring some of the capabilities of the RV64GC target and just trying to compile integer abi only code:

-march=rv64i
-mabi=lp64

but then I was getting the link errors about mismatched hard (library?) and soft (the program?) float modules.

Perhaps here there is no multilib to match the selected arch/abi tuple but if that's the case why does it seem to go and try to link another multilib and then fail?

I probably need to look at the verbose linker output to see exactly what is being fed into the link process in the successful and failure cases.

Regards

Tommy

[Richard W.M. Jones]

On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
> Correct - the 32 bit instruction set is not a subset of the 64 bit one
> and a binary generated for the 32 bit ISA set will in general *not* run
> on the 64 bit ISA.
>
> Personally I think this is a short-sighted error.

OTOH it's how it works on aarch64. AArch32 isn't a subset, and it's
not guaranteed to be present (although most current chips do have it).

In RHEL/aarch64 we deliberately broke compatibility with 32 bit
binaries by choosing a larger page size, so you can't run 32 bit
binaries directly even if the hardware supports it. If you want to
run 32 bit binaries, you run them under qemu - either fully
virtualized or using qemu-user. In practice this is never a problem.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Bruce Hoult]

On Sun, Jul 9, 2017 at 1:37 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:

On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
> Correct  - the 32 bit instruction set is not a subset of the 64 bit one
> and a binary generated for the 32 bit ISA set will in general *not* run
> on the 64 bit ISA.
>
> Personally I think this is a short-sighted error.

OTOH it's how it works on aarch64.  AArch32 isn't a subset, and it's
not guaranteed to be present (although most current chips do have it).

Not really a great example, as the instruction sets are totally different.

PowerPC did it right. The 32 bit instruction set contained, for example both "lw" (load signed 32 bit word) and "lwz" (load unsigned 32 bit word) from the start, and compilers used them consistently for signed and unsigned quantities, even though they did EXACTLY THE SAME THING. Later on, when 64 bit CPUs arrived in 2002 (32 bit in 1994) one of those instructions sign-extended and the other zero-extended 32 bit values to 64 bit and 32 bit software worked fine on a 64 bit CPU.

RISC-V on the other hand adds unsigned 32 bit loads only in the 64 bit instruction set, and unsigned 64 bit loads only in the 128 bit instruction set. Even though those instruction encodings are not used for anything else in the narrower ISA and it would be *trivial* to have signed and unsigned 32 bit loads decode to the same operation on a 32 bit CPU. *TRIVIAL*. It consists of making bit 14 (the MSB of the "func3" field) for LW a "don't care" (thus also matching LWU) instead of "must be 0".

In other words, making a 32 bit CPU accept both LW and LWU as the same operation requires *less* circuitry than the way it is actually specified!

The same goes for making ADDW, SUBW, SLLW, SRLW, SRAW, ADDIW, SLLIW, SRLIW, SRAIW available in RV32I. Just make matching bit 3 "don't care" instead of the current "must be 0" for  ADD, SUB, SLL, SRL, SRA, ADDI, SLLI, SRLI, SRAI and you are done.

Again, gaining upward compatibility for software *simplifies* the smaller hardware.

I agree with Michael Chapman that this incompatibility is unfortunate, short sighted, and perhaps even worse: gains no advantage.

[Richard W.M. Jones]

On Sun, Jul 09, 2017 at 08:24:59PM +0300, Bruce Hoult wrote:
> On Sun, Jul 9, 2017 at 1:37 PM, Richard W.M. Jones <rjo...@redhat.com>
> wrote:
>
> > On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
> > > Correct - the 32 bit instruction set is not a subset of the 64 bit one
> > > and a binary generated for the 32 bit ISA set will in general *not* run
> > > on the 64 bit ISA.
> > >
> > > Personally I think this is a short-sighted error.
> >
> > OTOH it's how it works on aarch64. AArch32 isn't a subset, and it's
> > not guaranteed to be present (although most current chips do have it).
> >
>
> Not really a great example, as the instruction sets are totally different.

You omitted the rest of my message which contains my central point.

What is running 32 bit instructions good for, which cannot be achieved
by using virtualization or emulation?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Christopher Celio]

> I agree with Michael Chapman that this incompatibility is unfortunate, short sighted, and perhaps even worse: gains no advantage.
>

RVC decodes the same opcodes to different instructions based on RV32 vs RV64 vs RV128 (JAL vs ADDIW, FSW vs SD, etc.). So maintaining compatibility would mean a suffering of code compression for 2 out of the 3 architectures. Then the knives come out to decide which of the three should be favored.

There are some other subtle reasons that make the RV32-is-a-subset a Siren Song, and a previous mailing list thread briefly discusses this:
https://groups.google.com/a/groups.riscv.org/forum/#!searchin/isa-dev/subset/isa-dev/cqtEfUI6BPQ/TqVx9Z44BgAJ

To add to that link, I think there might be a further opcode crunch beyond RVC of adding 64b versions of all instructions that will have subtly different behaviors (AUIPC?) and then having to additionally carry the RV32-is-a-subset promise throughout every added extension.


-Chris

[Bruce Hoult]

On Sun, Jul 9, 2017 at 9:01 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:

On Sun, Jul 09, 2017 at 08:24:59PM +0300, Bruce Hoult wrote:
> On Sun, Jul 9, 2017 at 1:37 PM, Richard W.M. Jones <rjo...@redhat.com>
> wrote:
>
> > On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
> > > Correct  - the 32 bit instruction set is not a subset of the 64 bit one
> > > and a binary generated for the 32 bit ISA set will in general *not* run
> > > on the 64 bit ISA.
> > >
> > > Personally I think this is a short-sighted error.
> >
> > OTOH it's how it works on aarch64.  AArch32 isn't a subset, and it's
> > not guaranteed to be present (although most current chips do have it).
> >
>
> Not really a great example, as the instruction sets are totally different.

You omitted the rest of my message which contains my central point.

What is running 32 bit instructions good for, which cannot be achieved
by using virtualization or emulation?

Apparently something, or they would not have been explicitly added to RV64 (but with different opcodes than they have in RV32!)

[Bruce Hoult]

On Sun, Jul 9, 2017 at 10:21 PM, Christopher Celio <ce...@eecs.berkeley.edu> wrote:

> I agree with Michael Chapman that this incompatibility is unfortunate, short sighted, and perhaps even worse: gains no advantage.
>

RVC decodes the same opcodes to different instructions based on RV32 vs RV64 vs RV128 (JAL vs ADDIW, FSW vs SD, etc.). So maintaining compatibility would mean a suffering of code compression for 2 out of the 3 architectures. Then the knives come out to decide which of the three should be favored.

I'm well aware of that, and it's unfortunate too. However, other than C.JAL, the others don't affect RV32IC code running on RV64C or RV128C, but only FP code.

It would be easy enough for code intended to be portable across the range to use a compiler mode that avoided C.JAL, and C.F(LD|ST)(W|D)(|SP) and instead use uncompressed instructions for those. The cost of that is very low, especially for integer programs, with C.JAL very rarely being possible in larger programs anyway.

 

There are some other subtle reasons that make the RV32-is-a-subset a Siren Song, and a previous mailing list thread briefly discusses this:
https://groups.google.com/a/groups.riscv.org/forum/#!searchin/isa-dev/subset/isa-dev/cqtEfUI6BPQ/TqVx9Z44BgAJ

I find Andrew's example not very convincing:

> Not actually.  The opcodes are almost all completely legal, but the 

> semantics differ.  For example, 

> 

> addi t0, x0, 1 

> slli t0, t0, 16 

> slli t0, t0, 16 

> 

> results in t0 == 0 for RV32 and t0 == 2^32 in RV64/128. 

If, as I suggested above, the "word" opcodes from RV64 were made available in RV32 too, then a C compiler would generate the following for unsigned variables...

> addiw t0, x0, 1 

> slliw t0, t0, 16 

> slliw t0, t0, 16 

... which would have identical behaviour on both RV32 and RV64 (the same as Andrew's code does on RV32).

Signed variables would produce the current opcodes. Overflow has undefined behaviour for signed variables in C anyway.

[Richard Herveille]

> On 09 Jul 2017, at 20:01, Richard W.M. Jones <rjo...@redhat.com> wrote:
>
> On Sun, Jul 09, 2017 at 08:24:59PM +0300, Bruce Hoult wrote:
>> On Sun, Jul 9, 2017 at 1:37 PM, Richard W.M. Jones <rjo...@redhat.com>
>> wrote:
>>
>>> On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
>>>> Correct - the 32 bit instruction set is not a subset of the 64 bit one
>>>> and a binary generated for the 32 bit ISA set will in general *not* run
>>>> on the 64 bit ISA.
>>>>
>>>> Personally I think this is a short-sighted error.
>>>
>>> OTOH it's how it works on aarch64. AArch32 isn't a subset, and it's
>>> not guaranteed to be present (although most current chips do have it).
>>>
>>
>> Not really a great example, as the instruction sets are totally different.
>
> You omitted the rest of my message which contains my central point.
>
> What is running 32 bit instructions good for, which cannot be achieved
> by using virtualization or emulation?

Virtualisation and/or emulation is for the ‘big’ guys. I’m in the embedded market, where running a 32bit library on a 64bit architecture makes perfect sense.
The amount of times I had customers that had legacy 3rd party libraries, that could not be updated to 64bit (due to the 3rd party going bankrupt or simply due to cost reasons) is quite staggering.

Richard

>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20170709180159.GH31999%40redhat.com.

[Richard W.M. Jones]

On Mon, Jul 10, 2017 at 08:11:19AM +0000, Richard Herveille wrote:
>
> > On 09 Jul 2017, at 20:01, Richard W.M. Jones <rjo...@redhat.com> wrote:
> >
> > On Sun, Jul 09, 2017 at 08:24:59PM +0300, Bruce Hoult wrote:
> >> On Sun, Jul 9, 2017 at 1:37 PM, Richard W.M. Jones <rjo...@redhat.com>
> >> wrote:
> >>
> >>> On Thu, Jun 29, 2017 at 02:43:59PM +0200, Michael Chapman wrote:
> >>>> Correct - the 32 bit instruction set is not a subset of the 64 bit one
> >>>> and a binary generated for the 32 bit ISA set will in general *not* run
> >>>> on the 64 bit ISA.
> >>>>
> >>>> Personally I think this is a short-sighted error.
> >>>
> >>> OTOH it's how it works on aarch64. AArch32 isn't a subset, and it's
> >>> not guaranteed to be present (although most current chips do have it).
> >>>
> >>
> >> Not really a great example, as the instruction sets are totally different.
> >
> > You omitted the rest of my message which contains my central point.
> >
> > What is running 32 bit instructions good for, which cannot be achieved
> > by using virtualization or emulation?
>
> Virtualisation and/or emulation is for the ‘big’ guys. I’m in the
> embedded market, where running a 32bit library on a 64bit
> architecture makes perfect sense.
>
> The amount of times I had customers that had legacy 3rd party
> libraries, that could not be updated to 64bit (due to the 3rd party
> going bankrupt or simply due to cost reasons) is quite staggering.

That's exactly the point: There's no legacy with RISC-V. There are no
historical proprietary 32 bit RISC-V binaries.

It's far more likely the legacy you'll be wanting to run is x86, so
emulation will be required. Of course that won't work well in tiny
embedded environments, but that's an entirely different issue.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Bruce Hoult]

But there WILL BE legacy in the future.

Since it exists, people will start by using RV32 in small devices and writing and compiling/coding for it. And buying 3rd party libraries.

As technology or their use-case advances they may want to move to RV64, and take their -- now legacy -- libraries with them.

No doubt there will always be restrictions with that -- for example you'll only be able to run such code in the top and bottom 2 GB of the address space. That's still quite a lot, for many uses.

But why would you want to put artificial barriers in their way by, for instance in my current example, preventing RV32 code from using the *W opcodes operating on 32 bit data that are currently defined as being part of RV64, not RV32?

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20170710084948.GI31999%40redhat.com.

[Tommy Murphy]

HI Richard

Apropos of this, my experience is that if I specify -march=X -mabi=Y and the multilib folder .../riscv64-unknown-elf/lib/X/Y exists then the libs there are linked.

But if that folder does not exist then the toolchain falls back to linking the libs in .../riscv64-unknown-elf/lib and these are 64 bit (not sure what abi/arch?) and may not work in some cases - e.g. certainly not if X=RV32*.

So if I specify -march=rv32imf -mabi=ilp32f then this gives link errors because the required multilibs oe not exist and the tools try to link the "default" 64 bit libs.

So it seems more like a case of missing multilibs than anything else?

(Apologies if this is already obvious to you/others!).

Which leads me back to something that I may have asked before - if one wanted to build a toolchain that could be used for ANY valid arch/abi tuple (as enumerated by Palmer here? https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/t-elf-multilib)  then what arguments should be passed to multilib-generator (https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/multilib-generator) in order to generate the required t-elf-multilib file (https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/t-elf-multilib)?

I also wonder how long such a toolchain build would take but I can obviously try that myself if I can get some guidance on generating a "complete" t-elf-multilib file enumerating all possible valid arch/abi tuples.

Cheers

Tommy

On Friday, 30 June 2017 12:30:09 UTC+1, richard.herveille wrote:

[Liviu Ionescu]

FYI, buildind the current tollchain, with current multi-libs and newlib nano (which buils everything again), for all 5 platforms (mac, 32/64 linux, 32/64 win), takes about one full day on a dedicate mac mini.

Regards,

Liviu

[Tommy Murphy]

Thanks Liviu.