x32 Support For Linux Kernel Called In For Review

[XorEaxEax]

Right you are and good points!

[XorEaxEax]

Unless you'll be running a pure x32 system, there's going to be two sets of libs competing for ram and cache, the native 64bit and the x32 ones. Assuming any multiprocessing machine, is this not a downside?

Yes probably, but I think it's unlikely you'd want to run a hybrid system. If you have more than 4gb ram then you'd likely want all your programs to be able to use that and then you would run a pure 64bit system. If you have 4gb or less then x32 would be the 'best' choice if you are running on a 64-bit cpu.

[drago01]

This sounds great! I assume (and hope it doesn't make an ass out of me) that this means that native 32-bit applications can run on a 64-bit system without problems (or libraries built specifically for it, like nspluginwrapper). Or is that hoping for too much?

Yes you completely missed the point.
This just adds a third set of libs/binaries ... in a multilib system it makes thinks even more complicated if anything.

[ninez]

Yes probably, but I think it's unlikely you'd want to run a hybrid system. If you have more than 4gb ram then you'd likely want all your programs to be able to use that and then you would run a pure 64bit system. If you have 4gb or less then x32 would be the 'best' choice if you are running on a 64-bit cpu.

While for the most part this 'may' be true, i think it's a bit of a black / white perspective. There are definitely situations where a person might want (or have little other choice, but) to run 32bit apps in a 64bit system.

I for one use lots of 32-bit applications on my system. For me, the main/required 32bit software are Windows VST plugins (synths and FX, that kind of thing). So if and when x32 support comes, i could use it with wine / those apps - so there could be a nice benefit here, for some people.

...then of course, there are the odd apps which may only come as 32bit (for whatever reason, be it technical or otherwise) - although i would hope at this point, 64bit would be the focus. ...then again, there also might be a situation where someone is building 32bit apps, but also would like to be able to use them locally (on their 64bit system), with the added benefits of x32 support.

cheerz

[smitty3268]

I'm not sure x32 code would actually be compatible with x86 (32bit) code

Just like x64 isn't compatible with x86, I'm not sure this new x32 code would be either. So I'm not sure everyone hoping for WINE support, etc., would get anything out of this.

Although i'm not 100% sure of how it all works together, so i could be wrong.

[AnonymousCoward]

Just like x64 isn't compatible with x86, I'm not sure this new x32 code would be either.

It's not compatible, it's a new ABI. It can be used with and will benefit only Linux programs compiled for it.

[smorovic]

Only difference to AMD64 is address size, so pointers are 32 bit. Everything else is identical to 64 bit mode and has all advantages of this new instruction set, without the main disadvantage - code size. Porting: long is 8 bits, pointers 4 bits in C so a it is a mix.

Downsides: another parallel set of libraries needed in distros (and similar support in other OS-es after Linux tests ground). As most apps won't ever need >4 Gb of memory, I think we will eventually see many of them shipped exclusively as x32 versions, once libraries are in place. Another step towards getting rid of x86. I think distros would already be phasing out x86 builds if there wasn't for early Intel Atoms (2008 and earlier models). Another problem is binary stuff, like, previously, flash plugin.

Even if distros could be 64 bit only on x86 (kernel), userpace won't give up that easily. I know of at least one example where ancient x86 architecture is still the best. Dosbox emulates a x86 processor, using a dynamic recompilation technique. This works much faster on x86 due to similarity of the arch to the one being "recompiled" - AMD64 doesn't have necessary bits to do that well (despite attempts to optimize for it). There are probably other examples where peculiarities of x86 bring advantage.

[tettamanti]

Just like x64 isn't compatible with x86, I'm not sure this new x32 code would be either. So I'm not sure everyone hoping for WINE support, etc., would get anything out of this.

Although i'm not 100% sure of how it all works together, so i could be wrong.

The idea is to use the long mode with all its benefits (native 64bit registers, more GP and SSE registers, SSE for FP, more efficient function calls, etc.) while keeping "long" (as in the data type) and pointers 32bit long.
You can find more details in the presentation by hpa at LPC:

http://linuxplumbersconf.org/2011/ocw/proposals/531

[ninez]

The idea is to use the long mode with all its benefits (native 64bit registers, more GP and SSE registers, SSE for FP, more efficient function calls, etc.) while keeping "long" (as in the data type) and pointers 32bit long.
You can find more details in the presentation by hpa at LPC:
http://linuxplumbersconf.org/2011/ocw/proposals/531

ya, i also just read that

there is also the x32 ABI's site itself, here;

http://sites.google.com/site/x32abi/

cheerz

[smitty3268]

The idea is to use the long mode with all its benefits (native 64bit registers, more GP and SSE registers, SSE for FP, more efficient function calls, etc.) while keeping "long" (as in the data type) and pointers 32bit long.
You can find more details in the presentation by hpa at LPC:
http://linuxplumbersconf.org/2011/ocw/proposals/531

Yeah, i got that. But you can't load traditional 32bit plugins into an x32 application, just like you can't load them into an x64 app. It wasn't clear to me if the ABI would be backwards compatible in some way, since all the data types were the same size, but i doubted it. It means everyone hoping this brings about better 32bit app support is exactly backwards - this would just introduce a 3rd platform you might need in certain cases, and wouldn't be compatible at all with anything windows related.