x32 Support For Linux Kernel Called In For Review

[elanthis]

I'm wondering how this will change Linux ecosystem. Likely that most application always using less than 4gb of memory will always be compiled using the x86 ABI. But isn't it reducing the 64bit usefullness?

The x86-64 CPUs has a shitload of advantages over IA32 beyond just having a bigger memory space.

In particular, even in x86 mode:

- native computation with 64-bit integers
- twice as many registers, both general purpose and SSE
- instruction pointer relative addressing
- guaranteed SSE2 register availability (x87 FP is basically only used for long doubles on x64/x32)
- register usage in calling convention instead of shoving everything on the stack
- access to various other new CPU features that are only enabled in long (64-bit) mode

If you don't need the extra memory space, and don't want to pay the price of larger data and hence higher memory bandwidth requirements and worse cache utilization, but want to have access to all those extra features and performance, then x32 is a pretty cool idea.

[smitty3268]

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

Do you have a link to a blog post or something explaining that Doxbox issue? AFAIK it should be very simple to do this, so I'm curious what the issue is.

[aceman]

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?

The way I understand it is this:
32bit apps + 32bit libs + 64bit kernel = you can do this today, but the apps will only use x86 registers and 32bit pointers (so 4GB (or less) of memory each), but the kernel will use all 64bit features.
64bit apps + 64bit libs + 64bit kernel = you can do this today, the apps will use all new registers (x86_64) but they will also use 64bit pointers (all memory) so can be slower due to cache contention.
x32 apps + x32 libs + x32 enabled kernel (64bit) = this is the new proposed feature, the apps will use all new registers (x86_64) but only 32bit pointers. If 4GB per app is enough for the app, then this mode can be fastest.

[l_bratch]

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?

[smorovic]

Do you have a link to a blog post or something explaining that Doxbox issue? AFAIK it should be very simple to do this, so I'm curious what the issue is.

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.

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

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

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

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

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