WIXLIB

floppy drive which would allow you to boot it on that shiny new AMD Opteronworkstation.Backward compatibility of the x86 processor family goes way beyond what most otherCPU architectures (including SPARC) have to offer. Sun Microsystem's Solaris/SPARCbinary compatibility guarantee only ensures that applications (not operating systemsor other low-level code) written on and for previous OS/hardware will continue to runon recent OS/hardware combinations, but it does not claim that old versions of theSolaris Operating Environment will run on processors that were yet unreleased at thetime a specific release shipped. This is different on x86. New versions of x86 CPUsfrom whatever vendor run older operating systems just fine. Incompatibilities if at allrise from the lack of device driver support for newer integrated peripherals, but notfrom the newer CPU's inability to function like its predecessors.Since introduction of the Intel i80386 in 1985 (!), most features of the x86 architecturehave remained remarkably constant. SMP support (via APIC) and support for morethan 4GB physical memory (via PAE) was added in the Pentium respectively to thePentiumPro processors; after that, only instruction set extensions (MMX, SSE) wereadded but no externally-visible changes were done to other core subsystems of x86.From the point of view of Solaris/x86, it was never necessary therefore to have morethan one kernel, /platform/i86pc/kernel/unix, for supporting the operating systemon x86 processors. Put this in context and compare it with Solaris in SPARC: For thevarious SPARC generations (maximum number of architectures concurrentlysupported in Solaris 2.6: sun4, sun4c, sun4d, sun4m, sun4u, sun4u1), each timeseparate platform support was required. Even today, Solaris 9 delivers ten (!) differentkernels for the various SPARC platforms, while Solaris 9 for x86 still has only one.This strict insistence on binary compatibility with its predecessors obviously hasdisadvantages as well. The way how the i80386 introduced 32bit support in some areaslooks illogical and counterintuitive, especially when comparing it with 32bitarchitectures that were designed for 32bit from their very beginnings. Some examplesof this will be given later.After releasing the i80386 32bit processor, Intel decided to keep future versions ofx86-compatible (“IA32” in Intel's terms) CPUs on 32bit. Each generation became fasterand added functionality, but the limitation to 32bit remained. In the early 1990s, thisdid not seem a problem because the major markets for x86 at that time (Microsoft DOSand Windows) were 16bit only anyway, and Intel's evolutionary path to 64bit had beenlayed out in the agreement with HP to co-develop a new 64bit architecture: IA64, thendubbed “Merced”, is today found in the Intel Itanium processors.But IA64 has nothing to do with x86. The instruction sets have nothing in common andexisting programs or operating systems written for 32bit x86 processors cannot run onmachines with IA64/Itanium processors in it. The Itanium, though produced by Intel, isa genetic child of HP's PA-RISC architecture, but only a distant relative to Intel's ownx86/IA32.In addition to that, Intel and HP were late at delivering the IA64 CPU – very late.So late that back in 2000, AMD stepped in and decided to extend the old x86architecture another time – to 64bit. AMD had, with varying success, been buildingx86-compatible processors since the early 1980s and saw Intel's de-facto terminationof x86 as a chance to extend its own market reach. The AMD64 (64bit x86)architecture was done in a way very similar to how Intel had done the i80386, andprocessors based on AMD64 (much unlike Itanium/IA64) are, in good old x86 tradition,fully binary backward compatible. Of course, actually using the new 64bit operatingmode requires porting operating system and applications (like using 32bit on the102.Introduction to x86 architectures

i80386 did require at the time). But even when running a 64bit operating system doesAMD64 provide a sandboxed 32bit environment to run existing applications in (again,like the i80386 which allowed the same for 16bit programs running on a 32bit OS).Therefore the AMD64 architecture offers much better investment protection than IA64– which will not run existing 32bit operating systems or applications.By the time the AMD Opteron 64bit processor became available, the Itanium, on themarket for three years then, had seen very little adoption – while users and softwarevendors kept pushing ever harder on Intel to follow AMD's lead and provide 64bitcapabilities in their x86 processor line as well. Intel resisted this for several years inorder not to jeopardize the market for their Itanium processors but eventually gave inand cloned AMD64. For obvious reasons Intel doesn't call their 64bit-capable x86processors “AMD64-compatible” but uses the term EM64T (Enhanced Memory 64bitTechnology) for the architecture and IA32e for the 64bit instruction set extension.Intel CPUs with EM64T are compatible to AMD64 – which Intel confirms in the FAQfor the 64bit Extension tensions/faq.htm notes that:Q9: Is it possible to write software that will run on Intel's processors withIntel EM64T, and AMD's 64-bit capable processors?A9: Yes, in most cases. Even though the hardware microarchitecture foreach company's processor is different, the operating system and softwareported to one processor will likely run on the other processor due to theclose similarity of the instruction set architectures.How the future of x86 will look remains to be seen. But the x86 architecture, withmore than 25 years of age, has far surpassed the success of all other (non-embedded)processor architectures ever developed. With 64bit extensions that have rejuvenatedx86, and x86-compatible processors with 64bit capabilities becoming commonplacenow, this is unlikely to change in the near future.2.Introduction to x86 architectures11

2.2.Characteristics of x86There are two factors responsible for the main characteristics of the machineinstruction set for what is commonly termed “x86 architecture”: The long history of x86 has left its mark on the instruction set.x86 machine code carries a huge legacy of (mis-)features from the time when thearchitecture was still 16bit only, and in parts even from pre-x86 8bit days (in theform of limited compatibility with the Intel 8008). The need to introduce new capabilities without breaking binary compatibility haslead to a lot of instruction set extensions that are optional, and whose presenceneeds to be detected by applications / operating systems that want to make use ofthem. In addition, x86 never was a vendor-locked-in architecture, even thoughIntel's decisions have dominated its evolution. Both operating systems andapplication code for x86 therefore needs to expend some efforts on determiningwhich CPU by what vendor it runs on, and what instruction set extensions this CPUprovides before it can make use of optimized code.This is fortunately much improved by AMD64 which establishes a new “64bit x86baseline”.In addition to that, x86 CPUs use the so-called little endian way of ordering data inmemory. Endianness becomes very relevant once data needs to be exchanged betweensystems of differing architecture.2.2.1.CISC and RISCBack in the early days of CPU design in the 1970s and early 1980s, manufacturingtechnology did not allow for anything close to the complexity we have today. CPUdesigners then had to make tradeoffs, mostly between a feature-rich assemblylanguage, but few registers and generally lower instruction throughput, and a featurepoor assembly language with many registers and faster execution for the simpleinstructions that there were.The x86 architecture is the classical example of a so-called CISC processor. The termCISC stands for Complex Instruction Set Computer, and is used to describe a processorwhose instruction set offers single, dedicated CPU instructions for possibly veryinvolved tasks. Philosophically, the ultimate design goal for a CISC processor is toachieve a 1:1 match between CPU instructions and instructions in a high-levelprogramming language.CISC is almost a requirement for CPUs which maintain full backward compatibilitysuch as the x86 family. Adding functionality to an existing architecture always meansadding instructions and complexity. A pure evolutionary CPU development as Intel hasdone it therefore almost necessitates a CISC architecture.All in all, Intel's latest instruction set reference needs two volumes and more than1000 pages to describe all x86 instructions supported by the latest x86 CPUs by Intel.For comparison - the sparcv9 architecture reference manual only has 106 pagesdescribing all sparcv9 assembly instructions.Given the focus on instruction functionality vs. versatility, CISC architectures tend tohave features like: 12many special-purpose instructions.An example on x86 would be two separate instructions for comparison – the genericCMP instruction and the TEST instruction which will only check for equality orzeroness.2.Introduction to x86 architectures

the ability to modify a memory location directly, without the need to load itscontents into a register first.This is done to offset the lack of registers – the idea is that if destination or sourceof an operation can be memory, less registers are needed. instructions with varying length.This is both due to the fact that CISC architectures usually allow to embed (large)constants into the instruction, and because feature additions over time haverequired the introduction of longer opcodes (instruction encodings).Another consequence of this is that there are few gaps (undefined or illegalopcodes) in the instruction set. As we will see, to an x86 CPU random data makes upfor a decodeable instruction stream ! few general-purpose registers.Historically there had to be a tradeoff between using the space on the CPU die toprovide more registers or more-capable instructions. CISC CPU designers chose todo the latter, and it often proved difficult to extend the register set even aftermanufacturing technologies would have allowed for it. The x86 architecture livedwith only eight registers, until AMD designing the 64bit mode finally took thechance and extended the register set to 16.The x86 architecture is the single major remaining CISC architecture out there today.Most other CPU architectures on the market today, whether SPARC, PowerPC, ARM or(to a degree) even IA64, have gone the other way – RISC.SPARC assembly sourcebinary machine codedisassembler outputfunc:tst%i0orcc %g0, %i0, %g0set1234, %i0or%g0, 1234, %i0cmp%i0, %i1subcc %i0, %i1, %g0clr%i0or%g0, %g0, %i0mov%i1, %i0or%g0, %i1, %i0.size func,.-funcsection0: 804: 808: b0c: b010: 8014: 8018: b01c: b020: b024: 610101010.text00 1800 1824 d224 d200 1900 1900 0000 0000 1900 19.text%i0%i00x4d2, %i00x4d2, %i0%i0, %i1%i0, %i1%i0%i0%i1, %i0%i1, %i0Illustration 1 - machine code example on RISC, synthetic instructionsSPARC and all its incarnations are a classical example of RISC (Reduced InstructionSet Computer), and share many generic features with other RISC architectures: Lots and lots of CPU registers are available. For example, SPARC provides at least32 general-purpose registers (internally hundreds, via register windows). To modify data in memory, one must load it into a register, modify the registercontents and store the register back into memory. This is called a load-storearchitecture. RISC instructions usually have a fixed instruction size. All SPARC instructions, forexample, are 32bit. RISC Instruction sets are rather designed than evolved. Instructions often are multi-purpose. A RISC CPU, for example, may not haveseparate instructions for subtracting values, comparing values or testing values forzero – instead, typically, “SUB” will be used but the result (apart from conditionbits) be ignored. See the SPARC assembly code example above. Instructions tend to be simple. If a RISC CPU offers complex instructions at all, they2.Introduction to x86 architectures13

are usually completed by help of the operating system - instructions leading tocomplex system activity will trap and require software help to finish.Unlike CISC, the focus for RISC is on raw execution power - the more instructions perunit of time a CPU can process the faster it will be in the end. Executing a dozensimple instructions as fast as theoretically possible often proves to provide betterthroughput than executing a single, slow instruction to achieve the same effect. RISCoriginally was invented to allow for simpler CPU designs running at higher clockspeed.RISC pays for this by often requiring more instructions to achieve an equivalent resultas CISC gets with just one or two instructions:x86 assemblybinary codeSPARC assemblybinary codemovq 0x123456789abcdef0,%raxaddq %rax,var48 b8f0 de bc 9a78 56 34 1248 01 04 25XX XX XX 93901392d494d4%hi(0x12345400), %o1%o1, -0x279, %o1%hi(0x65432000), %o0%o0, -0x110, %o0%o1, 32, %o1%o1, %o0, %o0%hi(var), %o1%o1, %lo(var), %o1[%o1], %o2%o0, %o2, %o2%o2, 587c8f02008XXXX000a00Illustration 2 - RISC & CISC: Adding a 64bit constant to a global variable “var”Today, most arguments in the CISC vs. RISC debate have become obsoleted bytechnical progress.Since the introduction of Intel's Pentium-IV and AMD's Athlon, modern x86 processorsinternally "recompile" x86 instructions into RISC instruction sets. Intel calls this µ-ops,while AMD uses the term ROPs (RISC ops) openly. These RISC execution engines inx86 CPUs are not exposed to the user - the step of decoding/compiling x86 instructionsinto the underlying micro-ops is done by an additional layer of hardware in theinstruction decoder part of these CPUs.Likewise, RISC CPUs over time have added complex instructions such as hardwaremultiply/divide which had to be done purely in software in early RISC designs.Additionally, instruction set extensions like the Visual Instruction Set (VIS) onUltraSPARC or AltiVec on PowerPC allow for DSP-like (SIMD) functionality just likeMMX/SSE do on x86.So what is a modern x86 CPU then ? CISC or RISC ?The answer is:Both. It is a CISC CPU, but to perform best, one has to program it like a RISC CPU.For example, AMD in their Software Optimization Guide for AMD Athlon64 and AMDOpteron Processors explains it like this:The AMD64 instruction set is complex; instructions have variable-lengthencodings and many perform multiple primitive operations. AMD Athlon 64and AMD Opteron processors do not execute these complex instructionsdirectly, but, instead, decode them internally into simpler fixed-lengthinstructions called macro-ops. Processor schedulers subsequently breakdown macro-ops into sequences of even simpler instructions called microops, each of which specifies a single primitive operation.142.Introduction to x86 architectures

and a little later:Instructions are classified according to how they are decoded by theprocessor. There are three types of instructions:Instruction Type DescriptionDirectPath Single A relatively common instruction that the processordecodes directly into one macro-op in hardware.DirectPath Double A relatively common instruction that the processordecodes directly into two macroops in hardware.VectorPathA sophisticated or less common instruction that theprocessor decodes into one or more [ . ] macro-ops [ . ].and finally:Use DirectPath instructions rather than VectorPath instructions.In short:Bypass the CISC runtime translation layer to get best performance out of theunderlaying RISC execution engine.Similar notes can be found in the respective manuals for Intel's Pentium IV CPU familyand later.2.Introduction to x86 architectures15

2.2.2.EndiannessThe x86 CPU family is traditionally Little Endian. What does this mean ?The topic of how bytes that form multi-byte (or, for that matter, multi-bit) entitiesshould be ordered in the

with SPARC assembly, Solaris Internals and some Crashdump Analysis the fundamentals of x86 assembly and Solaris on x86 platforms, strongly focusing on "what's similar" and "what's different" between the low-level Solaris kernel on SPARC and x86 platforms. I was to a large degree surprised by the amount of interest this material generated