Software > User Zone
Void Linux thread
q66:
--- Quote from: nglevin on November 30, 2019, 11:04:43 pm ---Since it's mentioned as a distinguishing factor in this port, are there benchmarks showing the impact of ELFv2 on ppc64be or ppc32?
--- End quote ---
ELFv1/ELFv2 are 64-bit ABIs, 32-bit uses the SVR4 ABI, so it's not relevant there. ELFv2 on 64-bit supposedly has faster library calls and stuff, but I haven't benchmarked it. It's nicer/simpler/less annoying from programming perspective though, and there is just no reason to go with a 30 years old legacy ABI when there's a choice not to, if people have some legacy binaries or something, they can spin a debian chroot or whatever legacy environment for it, there's nothing preventing that.
I don't even see how I'd go about benchmarking that as it would mean having to have a reasonably large ELFv1 testing environment in the first place (i.e. compiled with otherwise the same flags etc., so another distro won't do) which I never had (ELFv1 was never even attempted).
nglevin:
That's fair. Benchmarks can be deceiving as they are further isolated from their original context.
POWER is one of those ABIs that I hadn't had much experience in. Based on your reference to SVR4, found this 2014 slide deck introducing ELFv2 in the context of what came before and the default 64-bit Linux POWER ABIs (ELFv1 for be, ELFv2 for el) in the GCC compiler options.
This clears things up, thanks.
Raion:
Neat stuff you're doing q66 for Void Power.
Aikatsu's a cute anime, I saw that in your shot. Checking the docs you have, it's not clear - does this distro have qemu-kvm support?
q66:
--- Quote from: Raion on December 03, 2019, 01:09:11 am ---Neat stuff you're doing q66 for Void Power.
Aikatsu's a cute anime, I saw that in your shot. Checking the docs you have, it's not clear - does this distro have qemu-kvm support?
--- End quote ---
Sure, there's just one caveat when using it as a host system: when using -machine newer than pseries-2.x, qemu will complain about not having 64kB pages, as Void uses 4kB pages for its kernels; the workaround is either to further limit HPT to 4k (like -machine <whatever you want to use>,cap-hpt-max-page-size=4096) - this will work but also limit guests to 4k when using HPT (on POWER9 when using Radix MMU, which is default, 64k guests will work fine unless booted in HPT mode), alternatively use something like -machine pseries-2.11 which will boot 64kB guests regardless of other settings.
So basically mostly affects POWER8 users, or those who explicitly disable Radix (for KVM-PR or whatnot) and even most of those can just use some pseries-2.x machine type and it'll work alright. The only ones out of luck are those who have older hw, require 64kB guests, and also require some feature available only in newer machine types, but vast majority of users don't need to care.
q66:
Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.
I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version