For years I've been getting questions about the UEFI implementation found on many low-cost tablets and 2-in-1 platforms. Why would a system with a 64-bit Intel processor ship with 32-bit UEFI? Why can't I get Linux* on a 32-bit UEFI system? The answer, as with many things, involves money.
The main thing we need to understand is a core concept of the UEFI Specification: the OS and firmware architecture need to match. For most non-Intel processors, this isn't a big deal since they only have one architecture. The "x86 compatible" processor is a bit different, and can switch into various 16/32/64 bit modes for application compatibility. Because most Intel platforms support both 32-bit & 64-bit architecture, along with old school Intel 8086/80286 16-bit instructions, the UEFI firmware on these platforms can be compiled in IA32 or x64 mode. This is reflected in firmware provided for 32/64-bit platforms (ex: MinnowBoard MAX*) or 32-bit platforms (ex: Intel® Galileo & MinnowBoard*).
On a legacy BIOS system the firmware-OS hand-off happened in 16-bit real mode, and the OS was expected to transition to 32/64-bit protected mode. Aside from a number of technical limitations and security problems in the legacy BIOS boot model, this caused problems between the 16-bit BIOS runtime interfaces and 32/64-bit OS services. Vincent Zimmer, as usual, provides a lot of detail on problems facing firmware interfaces at runtime. The TL;DR version is that it's easier for the OS to get along with the firmware if they run at the same bitness (32-bit OS boots from 32-bit firmware, 64-bit OS boots from 64-bit firmware) and this is reflected as a fundamental principle of the UEFI Specification.
Now look at this from the side of a Linux vendor back in 2011-2012 when UEFI was becoming the dominant firmware interface. The main targets for off-the-shelf distributions like Ubuntu* and Fedora* are servers and the typical desktop/laptop "client" system. These are usually 64-bit systems with a legacy BIOS (UEFI Class 0), UEFI with legacy compatibility (UEFI Class 2) or UEFI-only firmware (UEFI Class 3). So the "UEFI capable" Linux installer sits along side the legacy BIOS installer in a multi-volume CD/DVD ISO image.
At the time, this 64-bit mixed image approach was the primary use case for Linux users. Go to the store, buy a system, make references to the questionable parentage of software developers in Redmond, and install Linux. Those systems would be designed to boot Microsoft Windows 8 x64 or Server 2012 x64, so there was no need for mainstream support of a 32-bit UEFI environment.
As tablets and cheaper laptops came into the market, more manufacturers started to ship Microsoft Windows 8.1 x86 … the 32-bit version. This decision was driven by cost, but not the cost of the software. A 64-bit OS does theoretically perform better than a 32-bit OS, but those performance gains are tied to larger amounts of memory (over 4GB). The 64-bit version of Windows takes up more disk space, thanks to larger binaries (hello, bigger opcodes) and any underlying 64/32-bit translation layers. This means your Black Friday special purchase with 2GB of RAM and 16-32GB of internal flash storage doesn't see any 64-bit architecture benefits.
Apparently my "Black Friday" clipart is woefully out of date.
So now that cheap computer doesn't run popular versions of free software out of the box. This isn't a grand conspiracy, it's a side-effect of how the market adapted to build cheaper systems. For Intel it was easy to support, just recompile the UEFI C-code in IA32 mode instead of x64. For Linux distros, it's a bit more complex.
Matthew Garrett has an in-depth description of the problems Linux vendors face trying to build an all-purpose 32-bit distribution. From the distro point of view, adding a UEFI loader to the i386 distribution built for older systems introduces compatibility issues because those systems haven't been tested with UEFI capable software. My problem with Matt's assessment has always been that he's trying to solve the wrong problem. The ecosystem doesn't need an all-purpose 32-bit Linux distro, it just needs one that supports UEFI IA32. That el-cheapo tablet/laptop/2-in-1 doesn't even have a CD/DVD drive, and won't have legacy BIOS compatibility, so why bother with an El Torito ISO image? An IMG or ZIP file works just fine for distributing a UEFI OS image.
There's nothing technically preventing someone from building a UEFI IA32 Linux distribution. Angstrom Linux has an image for the original MinnowBoard that's 32-bit only with no dependencies on legacy BIOS. But Angstrom is focused on embedded computing. The mainstream Linux vendors perceived IA32 as an architecture for the embedded market, not low-cost consumer devices that hobbyists often use as Linux targets.
The market for budget Intel platforms looks a bit fragmented from a UEFI standpoint … some run Microsoft* Windows 8.1 x86 (the 32-bit version), some run Microsoft Windows 8.1 x64 and some run Android* x64. That presents a mix of UEFI IA32 and UEFI x64 firmware for Linux vendors to support and validate, which is a business decision for how they wish to allocate resources. Free code doesn't negate the time and resources required to package a new distro for download, and eventually those things add costs to development.
The shift away from CD/DVD as the "default install media" is a big help in building a UEFI IA32 only distribution. UEFI boots from a standard file system, not a magic disk sector or an esoteric specification named for the Mexican restaurant where it was conceived. It seems pointless to build an ISO image for OS installation when the target media is a FAT32 formatted USB thumb drive or SDHC memory card. Almost all of the problems Matthew raises in his analysis go away when you remove considerations for ISO packaging, El Torito and legacy BIOS compatibility.
So again, we're down to money. Vendors use a 32-bit version of Windows because they can make a cheaper product (cost matters to end users), and they typically aren't interested in testing an OS that's not shipping with the platform (QA doesn't work for free). Intel's customers want the option for UEFI IA32 and x64 on the same core hardware, and Intel wants their money (sorry kids, Brian's gotta eat). Linux distros need more resources to add UEFI IA32 support, which eventually costs them money (test hardware eats into the beer fund).
Will vendors stop shipping 32-bit versions of 64-bit platforms anytime soon? It's hard to tell, but I doubt demand will cease for cheaper consumer devices. So Linux support for UEFI IA32 is still an unanswered question. Linux users have requested this option, and some work has been done to bridge the gap … but it's still an unofficial hack with mixed results. That means Linux distros have to evaluate how they support cheaper Intel devices, and Linux users have to do a bit homework when selecting a new system for experimentation.
Update: Thanks to Steve for pointing out that Debian* 8.1.0 has a "multi-dist" image that works around this issue.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804