riscv(32) vs riscv64 in poky

[Trevor Woerner]

Hi,

I'm looking into preparing the Yocto/OE work for upstreaming
https://github.com/riscv/riscv-poky/

Looking at the changes that were made in the openembedded-core layer I find
things like the following:

--- openembedded-core/meta/classes/insane.bbclass 2016-09-07 11:38:16.820204821 -0400
+++ riscv-poky/meta/classes/insane.bbclass 2016-09-16 14:55:24.384220936 -0400
@@ -88,6 +88,8 @@
+ "riscv": (243, 0, 0, True, 64),
+ "riscv64": (243, 0, 0, True, 64),

--- openembedded-core/meta/classes/siteinfo.bbclass 2016-07-26 12:53:17.226461247 -0400
+++ riscv-poky/meta/classes/siteinfo.bbclass 2016-09-16 14:55:24.392220973 -0400
@@ -42,7 +42,8 @@
+ "riscv": "endian-little bit-64 riscv-common",
+ "riscv64": "endian-little bit-64 riscv-common",

--- openembedded-core/meta/classes/kernel-arch.bbclass 2016-03-16 02:17:40.921134615 -0400
+++ riscv-poky/meta/classes/kernel-arch.bbclass 2016-09-16 14:55:24.384220936 -0400
@@ -14,14 +14,17 @@
- nios2"
+ nios2 \
+ riscv"
@@ -30,6 +33,7 @@
+ elif re.match('riscv(|64)', a): return 'riscv'


It seems like there's a conflation of riscv and riscv64? Both are described as
being 64-bit. Sometimes both are added to a given table, while at other times
only one is added.

Shouldn't "riscv" be reserved for 32-bit (should it be called riscv32?) and
"riscv64" used for 64-bit?

If they should be kept separate, does anyone know what is the ELF machine
number for riscv? The table from insane.bbclass lists both riscv and riscv64
as being ELF machine 243. My attempts to google the answer haven't been
successful.

Best regards,
Trevor

[Michael Clark]

Hi Trevor,

It's seems intuitive that they should be explicit in the context where the bit width is relevant, versus referring to the architecture suite in general.

The problem is that until a runtime can emulate all of the various extensions, then there are in fact many arch combinations:

- RV32E

- RV32I[M][A][F][D]

- RV64I[M][A][F][D]

- RV128I[M][A][F][D]

It seems intuitive that riscv on its own should only refer to the architecture suite and not a specific bit width or set of extensions. Note: the RV prefix is used in the privileged spec.

The ELF machine is 243 and is bit width neutral. ELFCLASS32 vs ELFCLASS64 is currently used to distinguish bit width.

With respect to extensions I don't think there is any distinction in the ELF metadata and it may result in illegal instruction traps if you run an RV32IMA executable on RV32E.

There is the EI_OSABI and other fields that /could/ be used for more precision. I know arm had a lot of ABI variants i.e. is a bit of a mess.

The ELF mapping needs some consideration. I don't know if ELF128 exists but it's logical that the Addr types would be extended and ELFCLASS128 = 3

Sent from my iPhone

--
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/20160921132850.GA23087%40openSUSE-i7.site.

[Martin Maas]

Hi Trevor,

The conflation of riscv and riscv64 is more of a historical artifact rather than intentional. When I started working on the Yocto port, "riscv" was used as the arch throughout the RISC-V toolchain. This was later changed to riscv32 and riscv64, which I believe are still the ones in use today. I initially left them both in there to make migration easier, but at this point, it should be possible to remove the legacy "riscv" arch name.

I never got around to cleaning this up in poky, but making this consistent is a good idea. I agree with Michael's point that it's worth to spend some time thinking about how to handle the different RISC-V extensions/variants in Yocto. One approach could be to use riscv32, riscv64, riscv128 as the arch name, and then have additional settings to select the specific variant and extensions to target.

Thanks,

Martin

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/B95816B1-71C5-463D-A934-C2793E87060A%40mac.com.

[Richard W.M. Jones]

On Wed, Sep 21, 2016 at 10:59:41AM -0700, Martin Maas wrote:
> I never got around to cleaning this up in poky, but making this consistent
> is a good idea. I agree with Michael's point that it's worth to spend some
> time thinking about how to handle the different RISC-V extensions/variants
> in Yocto. One approach could be to use riscv32, riscv64, riscv128 as the
> arch name, and then have additional settings to select the specific variant
> and extensions to target.

FWIW in Fedora we are hoping to do this.

riscv32 / riscv64 / riscv128 would be the base architecture,
corresponding to RV32G / RV64G / RV128G (any hardware not capable of
doing IMAFD would not be supported at all).

We would hope to handle other extensions entirely at runtime, through
whatever is the equivalent of CPUID or /proc/cpuinfo, and using ifunc
or some other dynamic instruction selection.

Over time we might expand the base requirements, eg. by requiring
extension C or a particular vector implementation. We'll see how real
server hardware pans out.

In other words -- a lot like x86.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Stefan O'Rear]

On Wed, Sep 21, 2016 at 2:15 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:
> On Wed, Sep 21, 2016 at 10:59:41AM -0700, Martin Maas wrote:
>> I never got around to cleaning this up in poky, but making this consistent
>> is a good idea. I agree with Michael's point that it's worth to spend some
>> time thinking about how to handle the different RISC-V extensions/variants
>> in Yocto. One approach could be to use riscv32, riscv64, riscv128 as the
>> arch name, and then have additional settings to select the specific variant
>> and extensions to target.
>
> FWIW in Fedora we are hoping to do this.
>
> riscv32 / riscv64 / riscv128 would be the base architecture,
> corresponding to RV32G / RV64G / RV128G (any hardware not capable of
> doing IMAFD would not be supported at all).

I agree this is pretty reasonable; if your system has enough RAM and
"disk" for systemd and the GNU userland, not having a FPU would be a
strange allocation of resources, and it can be simulated in M-mode
anyway. Just don't try to ship a RV32G memcpy() that copies through
floating point registers or anything like that.

Supporting multiarch is a good future direction (and we've been trying
not to do anything that would conflict with it), since in the
post-Moore era the memory savings of ILP32 are hard to ignore,
especially if your workload looks like "100 processes, each using
300MB". This requires running RV32 processes on a RV64 kernel, which
is not possible in priv1.9 but seems likely from conversations here.

> We would hope to handle other extensions entirely at runtime, through
> whatever is the equivalent of CPUID or /proc/cpuinfo, and using ifunc
> or some other dynamic instruction selection.

Agreed; IMO the biggest missing point of the current U-mode spec is
the lack of a feature detection mechanism. (You can't just use a
SIGILL handler for this because an implementation that omits a
standard extension is explicitly permitted (§10.1 under
"Standard-compatible global encodings") to reuse the opcode space for
something non-standard.) Parsing /proc/cpuinfo will work for now but
I'd love something kernel independent.

> Over time we might expand the base requirements, eg. by requiring
> extension C or a particular vector implementation. We'll see how real
> server hardware pans out.
>
> In other words -- a lot like x86.

For a long time on x86 "what features does your processor support" and
"how old is your processor" were mostly the same question. We're
seeing more orthogonal features in x86 now, and ARM has always had
more practically relevant subsets, but RISC-V will probably see far
more ISA variants in the wild due to the fact that we permit and
encourage non-standard extensions.

In the long term, for medium to large computers, I see a future where
generic binaries (RV64G + ifuncs) are relatively rare and mostly used
for bootstrap programs and installers, with other executable code
being generated in myriad variations by either build farms, on-target
compilation, or JITs. Gentoo was the butt of jokes for many years but
iOS (build farms) and Android (on-target compilation?) are doing the
same thing now, and I expect this to spread to the rest of the
non-embedded market.

-s