kernel 3.4发布了，其中一个更新是加入对x32 ABI的支持。
与此前曾介绍的armel与armhf关系一样，x32并不是intel处理器的一种新架构，而是在intel 64位处理器上（也许将来也会用到ARM上？）的一种二进制程序调用规范。它的主要想法是：
在64位处理器上，所有的指针自然也应该是64位的，但很多应用程序在运行时并不需要超过4GB的内存，因此64位的指针是浪费的。这些浪费体现在程序大小上、程序运行后可执行代码占用的内存上，当然这些都是相对来说不必考虑的，但从CPU cache的角度考虑，64位的指针和32位的指针，对本来容量就很小的cache就意义重大了。从逻辑上，32位指针应该可以让cache缓存更多内容，并且在一致性维护上的开销更小。
但如果在64位CPU上纯粹地以兼容模式跑32位程序，又无法充分利用64位CPU的一些特性，例如更大的寄存器、更快的函数参数传递、更快的浮点运算、更快的syscall等。
因此，出现了x32这种折中。与armhf类似，它的改动也很简单：在x64 ABI基础上，将指针全部改为32位。
一份性能测试结果如下（完整介绍在这里）：
On Core i7 2600K 3.40GHz:
Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over Intel64.
Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32.
Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against Intel64.
Comparing against ia32 PIC, x32 PIC:
Improved SPEC CPU 2K INT by another 10%.
Improved SPEC CPU 2K FP by another 3%.
Improved SPEC CPU 2006 INT by another 6%
Improved SPEC CPU 2006 FP by another 2%.
作为一种独立于编译工具和应用程序的通用优化方法，这种改进的效果可以说是非常显著而有价值的。
虽然说起来简单，但实际要做的工作并不少。因为这两种调用约定在二进制级别并不能兼容，从armel到armhf迁移的经验来看，需要的工作应该是：开发工具链、内核支持和迁移、公用代码库迁移、常用软件迁移等。这一次kernel的更新，应该是指第二步已经完成了。
linux社区在armhf和x32这两种新的ABI上的动作，给我两种感觉：从小的来说，随着编译优化的不断前进，以往忽略的ABI可能是性能的瓶颈，在这方面是否还有进一步修改优化的余地？从大的看，ABI这种已经形成实施标准的东西，居然也是可以迁移和并存的，考虑另一些领域，例如网络、例如总线，在广泛应用的事实标准存在的情况下，有没有可能出现新的更优方案？以往总认为代价太大而不值得，但现在这两件事提供了参考。