x32 Support For Linux Kernel Called In For Review

[curaga]

If your 64-bit system in 2012 is struggling to find resources to run a 32-bit application, then your choice of ABI is probably the least of your issues.

Honestly if this makes gzip or apache or postgres run any faster, it's well worth any extra added libraries.

Besides, Solaris SPARC has been doing more or less the same thing for over a decade and they don't seem to mind.

You don't seem to see my point.

*apache x32 chugging along, faster than x64*
*hi vsftpd here x64, may I have the cpu?*
*apache continues*

The speed comes from fitting better in the cache. If the other apps force that cache to themselves often enough, it's going to be slower than native x64.

[unknown2]

imagine what will happen to linux ecosystem:

developer - i should write program in 32 bit only
32 bit is more portable and might be a little bit faster.
maintaining both 32 and 64 bit program is tedious.


gnome/kde/xfce developer - more and more programs are written in 32 bit, need to solve problem for pointer/data exchange/communication between 32 and 64 bit land.
new libraries may be needed.
We need more time to develop and maintenance.


distribution maker - 32 bit libraries should be included for compatability
The distribution size may be x2 bigger
Ubuntu can fit into 1 CD before, now need DVD


donator - What are those distribution guys thinking?
Their network traffic go up x2 recently!
Do they think that network bandwidth and hardware resource are free?


user in rich country - What are those distribution guys doing?
The distribution size go bloated up x2 recently!
Do they know that SSD are small and expensive?


user in third country - What are those distribution guys doing?
The distribution size go bloated up x2 recently!
Do they know that we are using 56K modem?


hacker - x2 library and code
=> x2 chance to find security loophole
=> Hurray!


security auditor - x2 library and code+kernel ABI
=> x2 more work to audit
=> Who will pay me x2 salary?


kernel developer - x32+x64 abi
=> more development, more maintenance + more chance of bug report
=> Why spend time support this obsolete x32 technology?


angry user - my program crashed because my document is greater than 4GB?
Those short-sighted developers design the program in 32bit because it is 5% faster!!!
It is already 21st century! All program should support unicode+64 bit.
Don't they feel ashamed?



of course, it is only imagination...

[frantaylor]

welcome to 2012

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.

If your 64-bit system in 2012 is struggling to find resources to run a 32-bit application, then your choice of ABI is probably the least of your issues.

Honestly if this makes gzip or apache or postgres run any faster, it's well worth any extra added libraries.

Besides, Solaris SPARC has been doing more or less the same thing for over a decade and they don't seem to mind.

[smorovic]

Well, it might not have anything to do with what you say, but you misreaded what I said. I didn't said 16 bit modes weren't supported on 32 bit x86, I said 16 bit modes aren't supported in that way by 64 bit mode in AMD64. You need to emulate it in the latter case.

OK, I misread. The emulator in question doesn't care because it emulates 16-bit code inside it's own process which is either 32 or 64-bit.

Regarding native 16-bits, CPU in long (64-bit) mode actually can execute 16-bit protected mode code (this was used for win16 apps). MS simply chose not to support that, because it's old enough to be retired. Virtual and real mode (DOS apps) are not supported in hardware.

[mrugiero]

No, 16 bit mode has nothing to do wih it. 16 bit modes were supported on 32-bit x86 in a same sense as x86 (32bit) is supported in 64-bit mode on Intel/AMD processors. This emulator runs only as one process compiled either for 32 or 64 bit architecture.

Well, it might not have anything to do with what you say, but you misreaded what I said. I didn't said 16 bit modes weren't supported on 32 bit x86, I said 16 bit modes aren't supported in that way by 64 bit mode in AMD64. You need to emulate it in the latter case.

[smorovic]

Might be that x86_64 has no native 16bits support in 64bits mode.

No, 16 bit mode has nothing to do wih it. 16 bit modes were supported on 32-bit x86 in a same sense as x86 (32bit) is supported in 64-bit mode on Intel/AMD processors. This emulator runs only as one process compiled either for 32 or 64 bit architecture.

[l_bratch]

That said, if I get to help paint the bikeshed, I vote for x64s, e.g. "x64 mode with Small address space." Or for the obsessively verbose GNU/Linux folks, x86-64s.

x64 on its own still loses too much historical meaning for my liking. x86-64s sounds perfect!

[unknown2]

i doubt whether it is a good idea.

If somehow the technology advance so fast that we get 128 bit or 256 bit processor, then there may be something like "x16/x32/x64/x128 support for linux kernel Called In For Review"

The kernel developer need to maintain so many ABI, and the distribution need to include 16/32/64/128 bit library for compatibility, so tedious... Leave time for developer to focus on better quality

It is normal for new computer to have more than 10G ram, why stay at 32 bit? The program size may be smaller, but differ for a few MB only.


32bit application is already history, wipe them out and let them live in virtual machine only.

[elanthis]

Why the name x32? If x86 comes from Intel 8086 and its derivatives (which are now 32-bit), and x86-64 is x86 with 64-bit extensions, why is it meaningful to call this x32?

It is confusing. (Heck, I even confused myself in my last post and accidentally wrote x86 where I meant to write x32, sigh.)

On the other hand, I can't think of anything better. x86_64-32? x64-32? IA32+64-32?

x64 is a common moniker for the new long mode, and x86 is the common moniker for the old mode. It's already confusing enough as is. Why is the new mode a smaller number like it's an older version? If x86 is shorthand for "something"-86, then is x64 shorthand for "something-86-extended-to"-64(-bits)? They could have stuck with AMD64 and IA32, and then this mode could just be AMD32. But then jumping around bit-sizes like that would make IA64 confusing.

That said, if I get to help paint the bikeshed, I vote for x64s, e.g. "x64 mode with Small address space." Or for the obsessively verbose GNU/Linux folks, x86-64s.

[mrugiero]

No, it was only discussed in their forums (a theme that pops up occassionally), so you may try asking there. AFAIK, dyncore required different implementation for amd64 (ended up slower), due to some legacy x86 features that are missing, but I don't remember details.

Might be that x86_64 has no native 16bits support in 64bits mode.