x32 Support For Linux Kernel Called In For Review

[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.

[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

[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.

[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.

[XorEaxEax]

Right you are and good points!

[smitty3268]

CPU registers are the fastest place in the computer in which to perform operations on data (much faster than cpu caches) and therefore it's extremely beneficial for 64-bit cpu's to have these 8 extra registers when doing cpu intensive stuff (particularly since the 32-bit cpu only had 8 to begin with).

Just to clarify, registers are the ONLY places that you can perform operations on data. CPU caches exist so that storing/loading data into the registers is faster than going out to main memory (which in turn is faster than acessing a hdd). Having more registers means you need fewer load/store operations and can leave the data you need directly in the cpu.

Also, besides doubling the number of registers it also doubles their size. Some code, like pointers, takes up the whole new 64bit size, but for really critical code you can now try and use 1 register for 2 32bit components, giving you up to 4 times the number of registers.

[curaga]

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?

Though if a server mainly does one thing, this wouldn't matter.

[XorEaxEax]

The biggest _performance_ increase from going 64bit came not from more addressable memory but from the addition of 8 more cpu registers. CPU registers are the fastest place in the computer in which to perform operations on data (much faster than cpu caches) and therefore it's extremely beneficial for 64-bit cpu's to have these 8 extra registers when doing cpu intensive stuff (particularly since the 32-bit cpu only had 8 to begin with).

The drawback is that the code size gets larger in 64-bit mode due to address references being 64-bit instead of 32-bit, which leads to the cache filling up faster which in turn may lead to less performant code. But even so, 64-bit code usually wins out over 32-bit code with a wide margin due to those extra 8 registers.

Now enter x32 ABI, in this mode you can use the extra 8 registers for that increased performance while still only using 32-bit address references which means more code can fit into the cache which may lead to extra performance. Also, as the code uses 32-bit addressing the resulting binaries are smaller (iirc typically a 64-bit system is ~15% larger than an equivalent 32-bit system), so if you don't need 64-bit addressing ( > 4g ram ) then x32 is pretty much best of both worlds.

[Kano]

You should not think that the 08/15 Linux user will benefit from it. The main purpose is to optimize for specific benchmarks. Some are fine with 64 bit binaries, others are faster with 32 bit, so in order to get the max speed he wants to combine the best results. Thats why he uses SPEC benchmark results. It has definitely nothing to do if you use pidgin as 32 or 64 bit binary. It is just to squeeze out the max performance for time critical apps.

[Veerappan]

I don't think it will change much, the OS is still 64-bit and can address more than 4 gb and you can compile things like gimp that may need more than 4 gb of ram in 64-bit. Why though do I need a 64-bit pidgin?

edit: I see what your saying "what if you don't know it'll use more or less than 4 gb, isn't this the advantage of a 64-bit sytem?"

true, I think if you have any kind of inkling it might use 4 gb it's best to build 64-bit.

What you said... Pretty sure that this will be most useful for applications which will never need >= 4GB of memory, but can benefit from the increased register count of the x86_64 ISA.

This might also be useful when porting some applications from 32-bit to 64-bit where the original developer was using some really messed up pointer arithmatic. The pointer manipulation should be fixed anyway, but this might help out as a bridge.