5 ms·
How many registers does an x86-64 CPU have? (2020)
- sylware 9mo agoDon't forget x86_64 like ARM is IP-locked, RISC-V is not.
- dlcarrier 9mo agoFun fact: the AMD64 patents have expired, with AMD-V patents expiring this year, so there really isn't a need for an x86 license to do anything useful. All that's still protected is various AVX instruction sets, but those are generally used in heavily optimized software, like emulators and video encoders, that tend to be compiled to the specific processor instruction set anyway.
- sylware 9mo agoAs far as I can remember, it is not only a "patent" issue. It seems there are other legal mechanisms. That said, I would not use a x86_64 CPU without AVX nowadays.
- dlcarrier 9mo agoAs far as intellectual property protections go, You wouldn't be able to copy the layout of an old AMD or Intel processor copyright infringement, not that anyone would want to, because it wouldn't be cost effective to use the exact same process decades later. There's no trademark protection, as AMD was unable to register the x86-64 trademark (https://tsdr.uspto.gov/#caseNumber=76032083 https://tsdr.uspto.gov/#caseNumber=76032083) Other than protections against industrial espionage, that exhausts all forms of intellectual property rights in the US.
- kens 9mo agoThe microcode is protected by copyright; see NEC Corporation v. Intel Corporation.
- dlcarrier 9mo agoMicrocode is specific to a given implementation, so if you make your own x86 implementation, it's not going to run AMD's or Intel's microcode unless you go out of your way to make it do so. NEC didn't infringe Intel's copyright, because their processor ran different microcode than Intel's, and NEC won that lawsuit.
- sylware 9mo agoAllright, the ISA itself is probably protected under some copyrights(+patents), which in the US last for ~one century (cf Disney). In the end, nobody sane would try its luck, better go for something non "IP-locked". Aka RISC-V, not to mention that for a modern implementation RISC-V is more friendly.
- ksec 9mo agoI would love to see an Open Source, free to use x86 CPU design.
- dlcarrier 9mo agoThere's an open-source 80486 project, called ao486, but I don't know of anything now modern.
- saagarjha 9mo agoHow could we given you keep bringing it up whether it’s relevant or not?
- deleted 9mo ago[deleted]
- JonChesterfield 9mo agoGood post! Stuff I didn't know x64 has. Sadly doesn't answer the "how many registers are behind rax" question I was hoping for, I'd love to know how many outstanding writes one can have to the various architectural registers before the renaming machinery runs out and things stall. Not really for immediate application to life, just a missing part of my mental cost model for x64.
- cmovq 9mo agoIf you’re asking about the register file, it’s around a couple hundred registers varying by architecture. You’d need several usages of the ISA register without dependencies to run out of physical registers. You’re more likely to be bottlenecked by execution ports or the decoder way before that happens.
- JonChesterfield 9mo agoI've seen claims that it's different for different architectural registers, e.g. _lots_ of backing store for rax, less for rbx. It's likely to be significant for the vector registers too which could plausibly have features like one backing store for the various widths, in which case deliberately using the smaller vectors would sometimes win out. I'll never bother to write the asm by hand with that degree of attention but would like better cost models in the compiler backend.
- adrian_b 9mo agoIn the Intel-AMD CPUs, there are separate register files for renaming the 16 general-purpose registers (which will become 32 registers in Intel Nova Lake and Diamond Rapids, by the end of this year) and for renaming the 16 (AVX) or 32 (AVX-512) vector registers. Both register files have a few hundred of scalar, respectively vector registers. Besides these 2 big register files, there are a few other registers for renaming some special registers, e.g. the flags register and the AVX-512 mask registers. Between the general-purpose registers there are no renaming differences, any of the 16 registers can be mapped to any of the hundreds of hidden registers, regardless if the register name used in the program is RAX, RCX or whatever. Some differences between apparently similar instructions may be caused not by the fact that they use RAX or another register, but by whether they affect the flags or not, because the number of renaming registers available for flags is much smaller than the hundreds available for GPRs.
- fuhsnn 9mo agoIntel's next gen will add 16 more general purpose registers. Can't wait for the benchmarks.
- Joker_vD 9mo agoSo every function call will need to spill even more call-clobbered registers to the stack! Like, I get that leaf functions with truly huge computational cores are a thing that would benefit from more ISA-visible registers, but... don't we have GPUs for that now? And TPUs? NPUs? Whatever those things are called?
- throwaway17_17 9mo agoWhy does having more more registers lead to spilling? I would assume (probably) incorrectly, that more registers means less spill. Are you talking about calls inside other calls which cause the outer scope arguments to be preemptively spilled so the inner scope data can be pre placed in registers?
- CamelCaseCondo 9mo agoop is probably referring to the push all/pop all approach.
- Joker_vD 9mo agoNo, I don't. I use a common "spill definitely reused call-invariant registers at the prologue, spill call-clobbered registers that need to survive a call at precisely the call site" approach, see the sibling comment for the arithmetic.
- saagarjha 9mo agoThat’s the push all/pop all approach.
- Joker_vD 9mo ago
- nefsim 9mo ago[dead]
- Sharlin 9mo agoOne thing that has happened since 2020 is that recent AMD CPUs support AVX-512, so that raises the number of registers by 16+16+32.
- theandrewbailey 9mo agoIntel's client CPUs still don't (officially*) support AVX-512, but pretty much all AMD CPUs with DDR5 do. * Outside of older Alder Lake CPUs, and even then, it's kind of a hack.
- 1011101001000 9mo agox86-64 ISA general-purpose register containers: low-er 8 to 16 bits of the 64 bit GPR.
- burnt-resistor 9mo agoConservatively though, another answer could be when not considering subset registers as distinct: 16 GP 2 state (flags + IP) 6 seg 4 TRs 11 control 32 ZMM0-31 (repurposes 8 FPU GP regs) 1 MXCSR 6 FPU state 28 important MSRs 7 bounds 6 debug 8 masks 8 CET 10 FRED ========= 145 total And don't forget another 10-20 for the local APIC. "The answer" depends upon the purpose and a specific set of optional extensions. Function call, task switching between processes in an OS, and emulation virtual machine process state have different requirements and expectations. YMMV. Here's a good list for reference: https://sandpile.org/x86/initial.htm https://sandpile.org/x86/initial.htm
- bonzini 9mo agoZMM registers are separate from the 8 FPU registers. That's because the ZMM set is separate from MM registers. So there's 8 more. In hardware, however, renaming resources are shared between ST/MM registers and the eight Kn mask registers.
- noelwelsh 9mo agoThis is how many registers the ISA exposes, but not the number of registers actually in the CPU. Typical CPUs have hundreds of registers. For example, Zen 4 's integer register file has 224 registers, and the FP/vector register file has 192 registers (per Wikipedia). This is useful to know because it can effect behavior. E.g. I've seen results where doing a register allocation pass with a large number of registers, followed by a pass with the number of registers exposed in the ISA, leads to better performance.
- saagarjha 9mo agoWhat compilers do this?
- noelwelsh 9mo agoOne writeup I know about is: "Smlnj: Intel x86 back end compiler controlled memory."
- solarexplorer 9mo agoWhat you describe sounds counter-intuitive. And the paper you cite seems to suggest an ISA extension to increase the number architected (!) registers. That is something very different. It makes most sense in VLIW architectures, like the ones described in the paper. Architectures like x86 do hardware register renaming (or similar techniques, there are several) to be able to exploit as much instruction level parallelism as possible. That is why I find you claim hard to believe. VLIW architectures traditionally provide huge register sets and make less use of transparent register renaming etc, that part is either explicit in the ISA or completely left to the compiler. These are very different animals than our good old x86...
- noelwelsh 9mo agoI'm not sure we're talking abou the same paper. Here's the one I'm referring to: https://smlnj.org/compiler-notes/k32.ps https://smlnj.org/compiler-notes/k32.ps E.g. "Our strategy is to pre-allocate a small set of memory locations that will be treated as registers and managed by the register allocator." There are more recent publications on "compiler controlled memory" that mostly seem to focus on GPUs and embedded devices.
- diffuse_l 9mo agoSome minor nitpicks, but hey, we're counting registers, it's already quite nitpicky :) Add far as I van remember, you can't access the high/low 8 bits of si, di, sp. ip isn't accessible directly at all. The ancestry of x86 can actually be traced back to 8 bit cpus - the high/low bits of registers are remenants of an even older arch - but I'm not sure about that from the top of my head. I think most of the "weird" choices mentioned there boil down to limitations that seem absurd right now, but were real constraints - x87 stack can probably traced back to exposing minimal interface to the host processor - 1 register instead of 8 can save quite a few data line - although a multiplexer can probably solve this - so just a wild guess. MMX probably reused the register file of x87 to save die space.
- rep_lodsb 9mo agoThe low 8 bits of SI, DI, BP and SP weren't accessible before, but now they are in 64-bit mode. The earliest ancestor of x86 was the CPU of the Datapoint 2200 terminal, implemented originally as a board of TTL logic chips and then by Intel in a single chip (the 8008). On that architecture, there was only a single addressing mode for memory: it used two 8-bit registers "H" and "L" to provide the high and low byte of the address to be accessed. Next came the 8080, which provided some more convenient memory access instructions, but the HL register pair was still important for all the old instructions that took up most of the opcode space. And the 8086 was designed to be somewhat compatible with the 8080, allowing automatic translation of 8080 assembly code. 16-bit x86 didn't yet allow all GPRs to be used for addressing, only BX or BP as "base", and SI/DI as "index" (no scaling either). BP, SI and DI were 16-bit registers with no equivalent on the 8080, but BX took the place of the HL register pair, that's why it can be accessed as high and low byte. Also the low 8 bits of the x86 flag register (Sign,Zero,always 0,AuxCarry,always 0,Parity,always 1,Carry) are exactly identical to those of the 8080 - that's why those reserved bits are there, and why the LAHF and SAHF instructions exist. The 8080 "PUSH PSW" (Z80 "PUSH AF") instruction pushed the A register and flags to the stack, so LAHF + PUSH AX emulates that (although the byte order is swapped, with flags in the high byte whereas it's the low byte on the 8080).
- bonzini 9mo ago
- jsrcout 9mo agoTried to answer this question years back for just the "basic" x86 registers. Quickly realized there was never going to be any single answer until I had mastered the entire ISA. Oh well.
- jcalvinowens 9mo agoHeh, am I the only one who was expecting an article about register renaming?
- Someone 9mo agoFTA: “For design reasons that are a complete mystery to me, the MMX registers are actually sub-registers of the x87 STn registers” I think the main argument for doing that was that it meant that existing OSes didn’t need changes for the new CPU. Because they already saved the x87 registers on context switch, they automatically saved the MMX registers, and context switches didn’t slow down. It also may have decreased the amount of space needed, but that difference can’t have been very large, I think
- adrian_b 9mo agoBy "existing OSes", that really means Microsoft Windows, other OSes would not have had any problems with the negligible update required to save and restore more registers. During many decades, Intel has introduced a lot of awful workarounds in their CPUs for the only reason that Microsoft was too lazy to update their OS so the newer better CPUs had to be managed by the OS exactly in the same way as the old worse CPUs, even if that moved inside the CPUs various functions that can be done much more efficiently by the OS, so their place is not inside the CPU. So the MMX registers were aliased over the FPU registers because in this way the existing MS Windows saved them automatically at thread switching. Eventually the limitations of MMX were too great, and due to competitive pressure from AMD (3DNow!) and Motorola (AltiVec), Intel and Microsoft were forced to transition to SSE in 1999, for which a couple of new save and restore instructions have been added and used by the OS, allowing an increase in the number and size of registers.
- rep_lodsb 9mo agoNitpick (footnote 3): "64-bit kernels can run 32-bit userspace processes, but 64-bit and 32-bit code can’t be mixed in the same process. ↩" That isn't true on any operating system I'm aware of. If both modes are supported at all, there will be a ring 3 code selector defined in the GDT for each, and I don't think there would be any security benefit to hiding the "inactive" one. A program could even use the LAR instruction to search for them. At least on Linux, the kernel is perfectly fine with being called from either mode. FASM example code (with hardcoded selector, works on my machine): format elf executable at $1_0000 entry start segment readable executable start: mov eax,4 ;32-bit syscall# for write mov ebx,1 ;handle mov ecx,Msg1 ;pointer mov edx,Msg1.len ;length int $80 call $33:demo64 mov eax,4 mov ebx,1 mov ecx,Msg3 mov edx,Msg3.len int $80 mov eax,1 ;exit xor ebx,ebx ;status int $80 use64 demo64: mov eax,1 ;64-bit syscall# for write mov edi,1 ;handle lea rsi,[Msg2] ;pointer mov edx,Msg2.len ;length syscall retfd ;return to caller in 32 bit mode Msg1 db "Hello from 32-bit mode",10 .len=$-Msg1 Msg2 db "Now in 64-bit mode",10 .len=$-Msg2 Msg3 db "Back to 32 bits",10 .len=$-Msg3
- ronsor 9mo agoThis is also true on Windows. Malware loves it! https://encyclopedia.kaspersky.com/glossary/heavens-gate/ https://encyclopedia.kaspersky.com/glossary/heavens-gate/
- bonzini 9mo agoIsn't it how recent Wine runs 32-bit programs?
- josephh 9mo agoMuch like there is 64-bit "code", there is also 32-bit "code" that can only be executed in the 32-bit (protected) mode, namely all the BCD, segment-related, push/pop-all instructions that will trigger an invalid opcode exception (#UD) when executed under long mode. In that strictest sense, "64-bit and 32-bit code can’t be mixed".
- dang 9mo agoRelated. Others? How many registers does an x86-64 CPU have? (2020) - https://news.ycombinator.com/item?id=36807394 https://news.ycombinator.com/item?id=36807394 - July 2023 (10 comments) How many registers does an x86-64 CPU have? - https://news.ycombinator.com/item?id=25253797 https://news.ycombinator.com/item?id=25253797 - Nov 2020 (109 comments)
- saagarjha 9mo agoThese seem more “past discussion” than “related” to me tbh
- bradley13 9mo agoThe amount of accumulated cruft in the x86 architecture is astounding. Being a geezer, I remember when there was, for a brief moment, a genuine question whether National Semiconductor, Motorola, or Intel would win the PC market. The NS processors had a nice, clean architecture. The Motorola processors, meh, ok. Intel already had cruft from earlier efforts like the 4004, and was just ugly. Of course, Intel won, Motorola came in second, and NS became a footnote. The x86 architecture has only gotten uglier over time.
- userbinator 9mo agoYou have to evolve to compete. Look what happened to MIPS, the classic "pure RISC". (I know about RISC-V, but at this point it's become just another cheap core for those who don't want to pay for ARM licenses.)
- snvzz 9mo agoRISC-V is not a core, it is an ISA. Beware chips with high performance microarchitectures compliant with RVA23 are coming later this year.
- userbinator 9mo agoSame difference. You can't get high performance without more complex instructions like ARM or x86.
- snvzz 9mo agoWe'll have to agree to disagree. Fortunately, this will be determined in practice in just months, not years from now.
- effnorwood 9mo agoAfrican or European?
- stevefan1999 9mo agoYou also have to account for register renaming, which basically means each pipeline may have their own register set invisible to the others. And that IIRC depends on how the instruction scheduler is planning the the execution and SRAM space needed, therefore calculating the total SRAM space that the registers taken would be far more realistic.