x32 Support For Linux Kernel Called In For Review

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

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.

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

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

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