16 ms·
The legend of “x86 CPUs decode instructions into RISC form internally” (2020)
- stncls 3y agoNeeds (2020). It explains why, for example, Zen 2 & 3 are not discussed.
- mhh__ 3y agoThey don't really add that much to the picture. Zen is a pretty boring (in a good way) architecture in the big picture.
- compressedgas 3y agoNo mention of AMD's RISC86 which was the patented internal decoding of X86 instructions into a RISC instruction set. https://patents.google.com/patent/US5926642A/en https://patents.google.com/patent/US5926642A/en (1996)
- cwzwarich 3y agoEven though AMD filed the patent a few years later, this was actually from NextGen, who AMD acquired: https://en.wikipedia.org/wiki/NexGen https://en.wikipedia.org/wiki/NexGen Here's an old BYTE article from 1994: https://halfhill.com/byte/1994-6_cover-nexgen.html https://halfhill.com/byte/1994-6_cover-nexgen.html
- p_l 3y agoBefore NextGen, AMD built an instruction decoder from x86 to AMD29k (which was Berkeley RISC style) and used it in K5.
- fulafel 3y agoAre there references about it using the actual 29k instruction set internally? Some (non primary) sources from cursory web search seems to say it used custom micro-ops which it did call "RISC ops", and had other implementation pieces carried from a abandoned 29k chip project.
- p_l 3y agoThere are persistent mentions of being able to switch off the decoder and use plain AMD29K instructions, but I never found any proper docs - don't have K5 to test against either.
- gumby 3y agoWow, really? Cool! The 29K was a really cool architecture and I’m sorry it didn’t make it. AMD’s pathetic marketing of the time couldn’t even beat MIPS’ terrible marketing, plus MIPS had SGI (and later SGI had MIPS).
- p_l 3y agoFunnily enough, new AMD29050 are still being made (maybe even with further development) by Honeywell - they form the basis of their range of avionics computers like Flight Management Systems etc.
- inkyoto 3y agoThe 29k was a pretty rad architecture, indeed. The CPU register file had 128 local registers and more than 64 global registers as well as two program counters, to start off with. Local registers could also be accessed indirectly. At a time of the register starved mainstream x86 architecture, it felt like rolling in gold and shrieking like a little piglet in ecstasy.
- mumbel 3y agoGot interested in amd29k for about a week before finding something else to mess with. Quick attempt at ghidra support, but never really RE'd with it, so no clue how does on larger projects. https://github.com/mumbel/ghidra_a29k https://github.com/mumbel/ghidra_a29k
- boramalper 3y agoOut of context: The level of detail and the quality of writing in older consumer magazines always amaze me.
- rany_ 3y agoI'm not sure how true this is or if it's a legend but I remember reading about this originating from Intel marketing in response to the rise of the popularity of RISC in the 1990s. In essence it intended to give the impression that there is no need for RISC architecture because x86 was already a RISC behind the scenes. So you got the best of both worlds.
- Sharlin 3y agoProbably apocryphal, since the 8086 was already microcode-based: http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-...
- weinzierl 3y agoThat is how I remember it and I believe it was at the time when Apple made a big marketing drama that their top of the line RISC machine is so fast that it falls under US export control. Due to that, there was a spike in popularity of RISC and Intel marketing being like "We are also RISC!". At least according to my memory.
- jeffbee 3y agoThat was already a misleading campaign at the time and certainly did not age well. When the G4 Mac launched at best 450MHz (delayed 6 months and derated from advertised 500MHz) it was going head-to-head with the 733MHz Pentium III "Coppermine" that was available, cheap, and faster from most points of view. By the time you could actually buy a 500MHz G4, you could also buy a 1000MHz AMD Athlon. To make it seem like the whole PowerPC thing had been a good idea you had to cherry-pick the best Mac and an old PC as a baseline.
- mikequinlan 3y ago>Final verdict >There is some truth to the story that x86 processors decode instructions into RISC-like form internally. This was, in fact, pretty much how P6 worked, later improvements however made the correspondence tortuous at best. Some microarchitecture families, on the other hand, never did anything of the sort, meaning it was never anywhere near a true statement for them.
- p_l 3y agoP6 was normal microcoded architecture, very much not RISC-like, though. Especially with its 143 bit long instructions and memory-memory operands. Now, K5 was a different beast, with it's "microcode" being a frontend that converted x86 to AMD29k
- rollcat 3y agoSomewhat related: http://danluu.com/new-cpu-features/ http://danluu.com/new-cpu-features/ discussion: https://news.ycombinator.com/item?id=31093430 https://news.ycombinator.com/item?id=31093430
- ajross 3y ago"RISC" architectures are doing something effectively identical to uop fusion though. The real myth is the idea of a CISC/RISC dichotomy in the first place when frankly that notion only ever applied to the ISA specifications and not (except for the very earliest cores) CPU designs. In point of fact beyond the instruction decode stage all modern cores look more or less identical.
- jeffbee 3y agoThat's because there are only a few ISAs left standing. The ISA does have consequences for core design. This becomes apparent for ISAs that were unintentionally on the wrong side of the development of superscalar. The dead ISAs assumed in-order, single-issue, fixed-length pipelines and as soon as the state of the art shifted those ISAs became hard to implement. MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.
- ajross 3y ago> MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques. I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway. No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see. [1] Branch delay slots and integer multiply instruction notwithstanding I guess.
- jeffbee 3y agoThe design of RISC-V starts with an entire chapter excoriating MIPS for being useless and impossible to reduce to transistors.
- 3y ago
- cachvico 3y agoSaved this great article from a couple of years ago, https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020-7b4d42c9a9de https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020...
- adrianmonk 3y agoIf someone says x86 decodes to RISC internally, they might be getting at one of two different ideas: (1) RISC really is the fastest/best way for CPUs to operate internally. (2) x86 performance isn't held back (much) by its outmoded instruction set. x86 architectures were for a while translating into effectively RISC but stopped doing it. Now internally they are less RISC-like. This suggests #1 is false and #2 is true. They could if they want to (because they have) but they don't want to anymore. Presumably because it's not the best way to do it. Although I guess it could be slightly better but not worth the cost of translating.
- pclmulqdq 3y agoI think if you want to analyze this to the same level of pedantry as the original blog post, the thing people actually mean is: "x86 instructions decompose into operations that feel somewhat RISC-like" And this is pretty much true. The author of this piece somewhat fixates on RISC-V as the anointed version of "RISC-ness" when it really is just one expression of the idea. The whole RISC vs CISC distinction is pretty silly anyway, because there isn't really a clear criterion or dividing line (see ARM's "RISC" instruction set) that separates "RISC" from "CISC." They're basically just marketing terms for "my instructions are reasonably simple" (RISC) and "my instructions are reasonably expressive" (CISC).
- jylam 3y ago"(the code is 32-bit just to allow us to discuss very old x86 processors)" fsck, that hurts.
- hinkley 3y agoDamn kids. I was an early adopter of 32 bit coding. When I was in a big hurry to get my career started there was still plenty of 16 big code around, even Netscape ran on the 16 bit version of the Windows API. I ended up tapping the brakes and changing gears to make sure I didn’t have to deal with that bullshit. Most of my CS classes had been taught on 32 bit Unix boxes so it just felt like sticks and rocks. The jump from 32 bit to 64 was not so dramatic. I Wonder if I’ll be around for 128 bit. I suspect the big disruption there will be changing the CPU cache line size, which has been stuck at 64 bytes for ages. I can’t imagine 4 words per cache line will be efficient.
- CalChris 3y agoI've never liked this idea that x86 CPUs decode instructions into RISC form internally. Before there was RISC, before there was even x86, there were microcoded instruction sets [1]. They were first implemented in Wilkes' 1958 EDSAC 2. Indeed the Patterson Ditzel paper even comments on this: Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control. [2] These horizontally microprogrammed instructions interpreted the architectural instruction set. The VAX 11/750 microcode control program had an interpreter loop. There could be more than 100 bits in these horizontal instructions with 30+ fields. Horizontally microprogrammed instructions were not in any way reduced. Indeed, reduction would mean paying the decode tax twice. There was another form, vertical microprogramming, which was closer to RISC. But there was no translation from complex to vertical. [1] https://www.cs.princeton.edu/courses/archive/fall10/cos375/BestWay.pdf https://www.cs.princeton.edu/courses/archive/fall10/cos375/B... [2] https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pd...
- fulafel 3y agoYep, and microcomputer processors were also microcoded. See eg 8086 here https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html https://www.righto.com/2022/11/how-8086-processors-microcode... And current x86 still implement some instructions via microcode. Some are even performance sensitive (eg rep movsb)
- p_l 3y agoP6 architecture was always microcoded - it's even somewhat archetypical example of superscalar microcoded CISC. With quite horizontal microcode.
- fulafel 3y agoFrontend decoding x86 instructions to uops, like from P6 onwards, is a bit different from microcode in the usual terminology. I guess you could make an argument that uops are also a type of microcode. But it gets confusing since there is also traditional ROM based microcode in post-P6 x86 chips.
- peter_d_sherman 3y agoRelated: https://news.ycombinator.com/item?id=27334855 https://news.ycombinator.com/item?id=27334855 https://www.google.com/search?q=%22christopher+domas%22+x86+%22god+mode%22 https://www.google.com/search?q=%22christopher+domas%22+x86+... https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set >"In 2018 Christopher Domas discovered that some Samuel 2 processors came with the Alternate Instruction Set enabled by default and that by executing AIS instructions from user space, it was possible to gain privilege escalation from Ring 3 to Ring 0.[5] Domas had partially reverse engineered the AIS instruction set using automated fuzzing against a cluster of seven thin clients.[12] Domas used the terms "deeply embedded core" (DEC) plus "deeply embedded instruction set" (DEIS) for the RISC instruction set, "launch instruction" for JMPAI, "bridge instruction" for the x86 prefix wrapper, "global configuration register" for the Feature Control Register (FCR), and documented the privilege escalation with the name "Rosenbridge".[5]" Also -- I should point out that the debate of if x86 (CISC) CPU's contain RISC cores -- is largely academic. Both RISC and CISC CPU's contain ALU's -- so our only debate, really, if we have one, is how exactly data that the ALU is going to process -- is going to wind up at the ALU... It is well known in the x86 community that the x86 instructions are an abstraction, a level of abstraction which runs on top of lower-level of abstraction, the x86 microcode layer... Historically, intentionally or unintentionally, most x86 vendors have done everything they can to hide, obfuscate, and obscure this layer... There (to the best of my knowledge, at this point in time) is no official documentation of this layer, how it works (etc., etc.) from any any major x86 vendor. x86 microcode update blobs -- are binary "black boxes" and encrypted. Most of our (limited) knowledge in this area comes from various others who have attempted to understand the internal workings of x86 microcode: https://www.google.com/search?q=%22reverse+engineering+x86+processor+microcode%22 https://www.google.com/search?q=%22reverse+engineering+x86+p... https://github.com/RUB-SysSec/Microcode https://github.com/RUB-SysSec/Microcode https://twitter.com/_markel___/status/1262697756805795841 https://twitter.com/_markel___/status/1262697756805795841 https://www.youtube.com/watch?v=lY5kucyhKFc https://www.youtube.com/watch?v=lY5kucyhKFc It should be pointed out that even if a complete understanding of x86 microcode were to be had for one generation of CPU -- there would always be successive generations where that implementation might change -- leaving anyone who would wish to fully understand it, back at square one... To (mis)quote Douglas Adams: "There is a theory which states that if ever anyone discovers exactly what the x86 microcode layer is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable." There is another theory which states that this has already happened." :-) <g>
- phendrenad2 3y agoNo mention of RISC86[1] and the hype[2] surrounding it. [1] https://patents.google.com/patent/US6336178B1/en https://patents.google.com/patent/US6336178B1/en [2] https://halfhill.com/byte/1996-1_amd-k6.html https://halfhill.com/byte/1996-1_amd-k6.html
- 0xr0kk3r 3y agoIt is fascinating that semantic confusion over RISC vs CISC persists since I was in college in the 80's. It is largely meaningless. The naive idea behind RISC is essentially to reduce the ISA to near-register-level operations: load, store, add, subtract, compare, branch. This is great for two things: being the first person to invent an ISA, and teaching computer engineering. Look at the evolution of RISC-V. The intent was to build an open source ISA from a 100% clean slate, using the world's academic computer engineering brains (and corporations that wanted to be free of Arm licensing) ... and a lot of the subtext was initially around ISA purity. Look at the ISA today, specifically the RISC-V extensions that have been ratified. It has a soup of wacky opcodes to optimize corner cases, and obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!). Ultimately the combination of ISA, implementation (the CPU), and compiler struggle to provide optimal solutions for the majority of applications. This inevitably leads to a complex instruction set computer. Put enough engineers on the optimization problem and that's what happens. It is not a good or bad thing, it just IS.
- ip26 3y agothere is an iron triangle operating on ISA design. I would propose the vertexes are complexity, performance, and memory model. The ideal ISA has high performance, a strong memory model, and a simple instruction set, but it cannot exist.
- thesz 3y agoDefine high performance. Also, define strong memory model. This is the first time I hear that memory model can be strong. And, finally, define what is "simple" in instruction set.
- sweetjuly 3y agoStrong and weak as terms to describe memory models is very common, the standard RISC-V memory model is called "weak memory ordering" after all :)
- kens 3y agoA question that maybe HN can help me answer: are there any new instruction set architectures since, say, 1985 that are CISC? (Excluding, of course, ISAs that are extensions of previous CISC ISAs.)
- exmadscientist 3y agoI'd guess there are a few hiding in the corners of the processor world. Think ultra-low-power (TI MSP430?) or DSP (TI C2000?). (I've used both of those two examples, but it's been a while, and I don't have any particular desire to crack open their architecture manuals to see how CISCy or RISCy they are. It's kind of an academic distinction anyway at this point.)
- exmadscientist 3y agoI thought of one! Recent ESP32 processors have a "ULP Coprocessor" for ultra-low-power operations. Its instruction set is... well... not very RISCy: https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32/api-guides/ulp_instruction_set.html https://docs.espressif.com/projects/esp-idf/en/v4.2/esp32/ap... (Spoiler alert for the lazy: it has single instructions for ADC reads and I2C transactions and such. I don't think it gets more CISC than that!)
- phire 3y agoEh... It's a load/store architecture with fixed size instruction and all instructions execute in 1 cycle (unless they stall due to IO) That makes it quite RISCy. The overpowered instructions are just because it's an IO processor, they don't do much work on the CPU core itself, just trigger an IO component.
- exmadscientist 3y agoPersonally, I think that when one of your instructions has a cycle count of 23 + max(1, SAR_AMP_WAIT1) + max(1, SAR_AMP_WAIT2) + max(1, SAR_AMP_WAIT3) + SARx_SAMPLE_CYCLE + SARx_SAMPLE_BIT cycles to execute 4 cycles to fetch next instruction and when that instruction is one of your ISA's main reasons for existing, and the whole thing is designed to be programmed directly rather than compiled, that's pretty CISC to me. Even if most of the instructions available are your standard RISC stuff (or just the basics). But this whole discussion is and has always been rather fuzzy, so it's something of a moot point.
- fooblaster 3y agoI'm not sure how you could write something like this without considering something like the micro op cache, which is present in all modern x86 and some arm processors. The micro op cache on x86 is effectively is the only way an x86 processor can get full ipc performance, and that's because it contains pre decoded instructions. We don't know the formats here, but we can guarantee that they are fixed length instructions and that they have branch instructions annotated. Yeah sure, these instructions have more complicated semantics than true risc instructions, but they have the most important part - fixed length. This makes it possible for 8-10 of them to be dispatched to the backend per cycle. In my mind, this definitely is the "legend" manifested.
- jabl 3y agoDo we know they are fixed length? They could e.g. use a table with offsets to instruction boundaries in the cache?
- gpderetta 3y agoWe know that they are over 100 bits (which is not very RISCy) and not fixed length as some constants cause the instructions to take more than one cache slots. IIRC they are also not necessarily load store.
- fooblaster 3y agoAny source on some of the details here? I'm interested to know more.
- SinePost 3y agoThe "Final Verdict" is very plain and is hardly enhanced by reading the body of the article. It would make more sense if it was put in the opening of the article, creating a complete abstract.
- kens 3y agoWhat I find most interesting is the "social history" of RISC vs CISC: how did a computer architecture issue from the 1980s turn into something that people vigorously debate 40 years later? I have several theories: 1. x86 refused to die as expected, so the RISC vs CISC debate doesn't have a clear winner. There are reasonable arguments that RISC won, CISC won, or it no longer matters. 2. RISC vs CISC has clear teams: now Apple vs Intel, previously DEC, Sun, etc vs Intel. So you can tie the debate into your "personal identity" more than most topics. The debate also has an underdog vs entrenched monopoly vibe that makes it more interesting. 3 RISC vs CISC is a simple enough topic for everyone to have an opinion (unlike, say, caching policies). But on the other hand, it's vague enough that nobody can agree on anything. 4. RISC exists on three levels: First, a design philosophy / ideology. Second, a style of instruction set architecture that results from this philosophy. Finally, a hardware implementation style (deep pipelines, etc) that results. With three levels for discussion, there's lots of room for debate. 5. RISC vs CISC has a large real-world impact, not just for computer architects but for developers and users. E.g. Apple switching to ARM affects the user but changing the internal bus architecture does not. (I've been trying to make a blog post on this subject, but it keeps spiraling off in random directions.)
- phire 3y ago> 4. RISC exists on three levels... Finally, a hardware implementation style (deep pipelines, etc) that results. I agree with the philosophy and ISA, but I don't think RISC is actually counts as a hardware architecture. Yes, there is a certain style of architecture strongly associated with RISC, the "classic RISC pipeline" that a lot of early RISC implementations share. But RISC can't claim ownership over the concept of a pipelined CPUs in general and designers following the RISC philosophy almost immediately branched out into other hardware architectures directions like superscalar and out-of-order execution (some also branched into VLIW). Today, the "class RISC pipeline" is almost entirely abandoned outside of very low-power and low-gate count embedded cores. The primary advantage of the RISC philosophy was that it allowed them to experiment with new hardware architecture ideas several years early than those competitors who were stuck supporting legacy CISC instruction sets. Especially when they could just dump their previous ISA and create a new one hyper-specialised for that exact hardware architecture. Those CISC designers also followed the same path in the 80s and 90s, implementing pipelined architectures, and then superscalar and then out-of-order, but their designs always had to dedicate more gates to adapting their legacy ISAs to an appropriate internal representation. ---- But eventually silicon processes got dense enough for this inherent advantage of the RISC philosophy to fade away. The overhead of supporting those legacy CISC ISAs got smaller and smaller. All high-performance CPUs these days seem to have settled on a common hardware architecture, doesn't matter if they use CISC or RISC ISAs, the diagrams all seem to look more or less the same. This architecture doesn't really have a name (which might be part of the reason why everyone is stuck arguing RISC vs CISC), but it's the out-of-order beast with absolutely massive reorder buffers, wide-decoders, physical register files, long-pipelines, good branch predictors, lots of execution units and (often) an uOP cache. Intel's Sandybridge is the first example of this exact hardware architecture (though that design linage starts all the way back with the Pentium pro, and you also have AMD examples that get close), but Apple quickly follows up with Cyclone and then AMD with Zen. Finally ARM starts rapidly catching up from about the Cortex A76 onwards.
- sobkas 3y agoThere are some similarities with Transmeta.
- CalChris 3y agoTransmeta Crusoe first interpreted x86, Linus Torvalds worked on the interpreter, and then JIT'd hotspots into a 128-bit wide VLIW. There's no way that VLIW could be confused with RISC. https://www.zdnet.com/article/transmetas-crusoe-how-it-works/ https://www.zdnet.com/article/transmetas-crusoe-how-it-works...
- bjourne 3y agoRISC just means that the instruction set is reduced (compared to what was the norm in the early 1980s). It does not say whether the architecture is register-memory or load-store (though most RISC ISAs are load-store). As long as the x86 CPUs does not decode to more than, say, two dozen microcode types it uses RISC "internally".
- moomin 3y agoOne woman’s RISC is another man’s CISC. The “perform operation and branch on flags” operation described here might not be part of RISC-V, but it 100% was part of ARM 1 when ARM was at the forefront of the movement.
- snvzz 3y ago>but it 100% was part of ARM 1 when ARM was at the forefront of the movement. ARM1 is what it is. They didn't have the time to do it properly, or the hindsight we have now. They had to get their product out.
- cptskippy 3y agoI grew up in the 80s and 90s, and what I gathered from listening to the grey beards talk was that RISC based designs were more elegant, easier to understand, and more efficient. When I first started hearing about then modern CISC cpus decoding to RISC, it was pushed as a justification that RISC was fundamentally superior. This was around the time IBM was pushing Power and everyone thought it was poised to dominate the industry.
- userbinator 3y agoSome actually do use something resembling an actual RISC core --- the VIA Alternate Instruction Set (https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set) basically exposes the uop format, and if you look at the documentation, you'll find that it's like they took a MIPS core and stripped out irrelevant instructions while adding other ones more useful to x86; even the opcode map and encoding is identical for the instructions that remained. IMHO the RISC vs CISC debate was never about implementation, only ISA. Even the 8086 uses a combination of microcoded and non-microcoded instructions (https://news.ycombinator.com/item?id=35939168 https://news.ycombinator.com/item?id=35939168). Also, calling it a "legend" in the title is rather clickbaity.
- throwawaylinux 3y agoRISC vs CISC was intimately about implementation. John Cocke's project came about because the complexity of mainframe and other CISC ISAs made implementation difficult, as did the other RISC efforts that soon followed it. One part of it was certainly about quantitatively adding instructions that could be used (by the programmer / compiler), but that was inextricably linked to the other side of the coin which is to define instructions that could be implemented in a performant way. Instruction complexity, addressing modes, lack of load-op, etc were all based on simplicity and high frequency pipelining. To a fault in some cases, famously branch delay slots in Stanford's architecture, a choice only explainable as a decision to complicate the ISA in order to make (contemporary) implementations simpler. Others as well though -- it's not that compilers were incapable of using or benefiting from load-op instructions for example. It's just that they were harder to implement.
- Farfignoggen 3y agoThe main issue with Intel's CISC/"RISC" Like Execution Engine is that it takes more transistors to implement that and the Instruction Decoders are huge relative to any ARM/RISC like ISA that has the majority of the ARM ISA Assembly Language Instructions actually translated directly to the Micro-OP format on a one to one basis, assembly language instruction to micro-op instruction. So for the x86 ISA that has most of its assembly language instructions decode into multiple micro-ops on a one to many basis there and that's a more energy intensive process there. And more transistors used to implement all that on the x86 designs use more power and leak more power as well. It takes many times that die area to Implement a full x86 ISA Instruction Decoder compared to and ARM 64 bit only Instruction Decoder and its fewer numbers of total instructions there on say the Apple A14/Firestorm core where Apple could easily fit 8 ARM 64 bit ISA Instruction Decoders on the A14/Later Performance core designs! So the A14/Later wide decode there is 8 Instructions Decoded per cycle and all that feeds into a ridiculously large reorder buffer to extract more instruction level parallelism and get that dispatched to a very wide array of execution ports. So and x86 core has to be much larger there and most of that is currently 6 or less Instruction Decoders wide with AMD being only 4 Instruction Decoders wide the with Zen-4/Earlier and Intel Being 6 wide with Golden Cove that's got only One complex x86 decoder and 5 "Simple" x86 decoders on that design that the tech press has never deep dived the difference there Complex/Simple in that Golden Cove Instruction Decoder design. But the x86 cores are usually clocked around 2GHz higher than Apple's A14/Later cores in Apple's M series SOC designs and really are nowhere near as power efficient as the RISC cores there as the x86 cores are narrower and have lower IPC relative to the A14/Later Apple cores that are extra wide and high IPC in design that can be clocked well inside their Performance/Watt sweet spot range on laptops and have the best battery life metrics on the consumer market. And that's compared to the x86 cores that have to be clocked higher there and outside their Performance/Watt sweet spots where the x86 designs have to be down-clocked on battery power there whereas as the M series Apple laptops run at the same clocks on mains power or battery power. Talk all you want about CISC and RISC but the simpler Instruction Sets of the RISC designs allow for more room for wider ranks of Instruction Decoders on the Custom ARM core designs that send that to wider execution dispatch there to ALUs, and other execution ports that are all 64 bits mostly(Neon and AVX aside) now that get the same work done only that's wider there for the custom ARM designs from Apple that have such high IPC that the processors can be clocked well inside their Performance/Watt sweet spots unlike the narrow x86 cores that have to get clocked well outside their Performance/Watt sweet spots to achieve a similar single core performance than the extra wide order superscalar A14/Later Apple designs. And Apple's A14/Later core designs can be used in Smartphones/Tablets and Laptop/PC as well unlike the x86 designs that never really made inroads into that smartphone market. So actually is the ability of the RISC ISA processors to be made wider order superscalar there to get more done per clock cycle and well inside the Performance/Watt sweet spots there on whatever process node utilized!
- wscott 3y agoThe splitting of "store address" and "store data" is an intentional performance feature and not a "quirk" of the implementation. If you had a single store uop then the memory system couldn't start doing a lookup on the address until the data to be stored was available. The data is usually the long pole. By having the address in a separate uop the data dependency is broken and the cache accesses allocating that line in the cache can be started much sooner.