Built on a 2 nanometer technology node, the processor’s design will contain 11 high-performance cores operating at more than 5.7 GHz, AI inference accelerators for in-transaction fraud detection, a dedicated on-chip data processing unit for I/O acceleration, and a large cache architecture for demanding enterprise workloads. The chip is architected to not contain separate Arm and IBM cores: each processor core can natively execute Arm and IBM Z, or Arm and LinuxONE, instructions concurrently while prioritizing the platform’s established performance, security, encryption, and availability characteristics. IBM Z and LinuxONE platforms are capable of scaling to hundreds of cores and tens of terabytes of memory.
↫ IBM press release
IBM is still doing some amazing chip architecture design. ServeTheHome has more details of how this works:
A key choice here is that IBM implemented AArch64 in full hardware rather than through translation. This design uses a little-endian Arm implementation alongside big-endian z/Architecture, with AArch64 v9.3, SVE and SVE2 support, and 2,792 implemented AArch64 instructions. IBM also claims Arm SystemReady compliance, which matters for how much off-the-shelf Arm software this core can absorb. This is absolutely crazy technology. Arm software sees a native Arm processor. Arm runs unmodified, out-of-the-box, and onto a standard Arm platform. IBM said the 2792 AArch64 instructions are more than twice the Z instructions. IBM made a funny quip about “reduced” in RISC.
↫ Patrick Kennedy at ServeTheHome
This is bonkers technology. We can only dream of this ever serving a home.
Every time I see this chip mentioned, I think of the possibility of a core that has decoders for both x86-64 and RISC-V. Like this IBM chip, a custom instruction would switch the core from one ISA to the other on the fly. This would bring perfect forward and backward compatability. Perfect for transitioning between ecosystems.
I don’t see how “transitioning between ecosystems” would “bring perfect forward and backward compatability”. Emulation does it already, without requiring that many transistors. I would have better liked a Transmeta Crusoe approach on this instead.
Kochise,
Emulation has limits though. For “cycle accurate” emulation, one needs a massively more powerful chip as small things like which flag bits are set, or how faults are handled have major implications on regular workflows
That being said…
RP2040 has ARM cores, which are used to port Linux… by emulating RISC-V which has MMU. But it is essentially a very fast interpreter.
(ARM0 cores natively do not support MMU, and hence cannot run vanilla Linux, only ucLinux variants)
You can of course use emulation but that is always slow, even for “fast” interpretters. Hardware level support for multiple ISA is different.
I thought you were talking about the RP2350 that can execute either ARM or RISC-V code? If you are talking about tiny cores that codes pennies, having both on the same SoC is totally viable. Hence, the RP2350 that has both ARM and RISC-V cores that you can select between. But you are never going to build a usable laptop or server that relies on both.
If you have a system with many cores that can each be one ISA or the other, you can perfectly match the OS and application demands (what ISA they want) without the overhead of virtualization. Ideally, the same underlying execution resources are used regardless of ISA. After an encoder step resolves semantic differences, the back-end may not need to know the original ISA explicitly (though the μop sequences will differ in length and content).
LeFantome,
I’d contest the “always slow” part as an absolute truism. Emulation doesn’t have to be slow if what you’re emulating has 1:1 mappings. The problem is when an architecture being emulated can’t map to the host architecture for various reasons. This can be an asymmetric problem with complex architectures with lots of special flags and modes leading to instruction multiplication for the emulator to implement them.
For example, on x86 one instruction might set a flag. Flags are usually used soon after they are set, but x86 doesn’t require this. Like all registers, flags persist until they get set again. This means flags and registers can persist across dozens of instructions, functions calls, returns, etc before being used. Even though the majority of the time those values will not be used, the emulator doesn’t know this. It may be compelled too add instructions to calculate those values just in case they need to be used later.
In principal we could have an architecture that’s designed to be emulator friendly so that it runs efficiently on just about any host. I think there’s merit in this approach because it solves other problem we have. Modern compilers target not only x86 architecture in general but specific CPUs models and feature within the x86 umbrella. In practice though we download and run binaries that’s not been optimized for our CPU because it’s logistically problematic to compile software with dozens of x86 targets.
The solution is for the compiler to output an emulator friendly architecture (sometimes thought of as a byte code) that can easily be translated to the local native architecture with none of the optimization ambiguities that stem from having to emulate/transpile something like x86.
This would also solve a lot of our portability problems too. Not only that, but it could free computer engineers to optimize their instruction sets without having to worry about backwards compatibility because the byte code already takes care of that. I really think there would be a lot of benefits if we did things this way, but I also doubt this can can happen because achieving critical mass across the industry is probably impossible.
But if you use an architecture that minimizes the overhead of virtualization to nearly zero, I think virtualization is the better approach (because of the other benefits this buys us).
@Alfman
> Emulation doesn’t have to be slow if what you’re emulating has 1:1 mappings
Well. Sure. But either that means either both ISA are effectively the same other than the labels used or that one ISA is a pure subset of the other. I think the latter is what you are driving at when you talk about a “virtualization friendly” ISA.
I largely agree with you. In fact, I would argue that RISC-V has kind of gone down that road. What is RV64I for example (or RV32I for 32 bit)? You could implement an efficient VM for that ISA on most processors. The whole point is to be a subset of the larger RISC-V ISA that is easy to implement in silicon and to implement as a VM. In fact, college kids routinely do both these days.
But the reason that a modern RISC-V application processor implements more than just RV64I is that there are many, many use cases which can be run more efficiently or more performantly with additional instructions. An easy and obvious example is that RV64I lacks special instructions for multiplication and division. You can still do multiplication but it is going to take many more instructions. More advanced examples include virtualization, vector math, and bit manipulation. All these extra instructions make the chips bigger, make the power needs greater, and make the efficiency of emulation on a foreign ISA worse. Your examples of x86 flag usage is another good example.
So, the goal of simplifying your ISA to make it easy to virtualize is somewhat at odds with making the ISA performant for modern workflows. I mean, as ALL chips get more advanced, the chance that one ISA provides everything the other needs go up. If you find that you can do a 1:1 mapping between one ISA and the other, you get efficient emulation exactly as you say.
Emulating MIPS or LoongSon on RISC-V would be pretty efficient. ARM pretty good too but less so. And emulating x86-64 on RISC-V would be the hardest to do well. By the time you get to the latter, you will find that having two decoders in silicon is your best bet.
LeFantome,
I don’t think they’re that much at odds though. A virtual instruction set that contains multiplication and division can still be run on an architecture that lacks them. Moreover the emulation/translation software can use the most efficient known native algorithm known to work on the host architecture. In principal this would be as efficient as compiling the same software directly to the target architecture that lacks these instructions. In other words there would be no runtime emulator overhead versus “native”.
Another example could be tensor operations. Even though the host may not support such operations, the translator can never-the-less translate these virtual instructions into the most efficient implementation on the target CPU. A huge benefit of this approach is that if future CPU models gain native tensor operations, the application could start using these features automatically even without new software from the publisher. This ability for existing software to use future optimizations is awesome property of intermediate application code.
I’d have to look closer at the specific architectures to really see if they’re good candidates for emulation, however I think you are prematurely dismissing the potential of a purpose built instruction set that is intentionally designed to be easy to emulate. This solves emulation efficiency problems, which in turn opens up the potential to use emulation in areas where we otherwise would have dismissed it because of inefficiency.
The Transmeta approach failed despite some very smart people working on it. Sustained and consistent performance proved too difficult to achieve. Like IA64, they lost out to the massive gains achieved by dynamic out-of-order execution in modern cores.
And “that many transistors” is a red herring. The encoder is a small part of the overall die and duplication there does not materially increase the size of the chip. I mean, the current generation of x86-64 chips basically demonstrate this. This is why people sometimes say that x86-64 chips are “RISC internally”. While it is not a “true” statement, it does describe the evolution of the x86 where the micro-architecture moved a lot of the complexity in the ISA to the decoder to push the back end to higher performance using techniques inspired by earlier RISC designs.
LeFantome,
It’s not strictly the the number of transistors or the size on the die that matters though. It’s whether those transistors are active and their proportion of the overall transistors that are actively doing work. Modern CPUs have a great number of transistors going unused running typical software. The point being, it’s not really the proportion of the front end transistors to the overall die that matters – this ratio is tiny but also irrelevant. It’s the proportion (and duty cycle) of the front end decoder transistors to the transistors that are doing real work. This is mathematically going to be a larger proportion – how much so depends on the actual software running.
When engineers optimize for speed, adding more transistors to run in parallel can be fine so long as there’s enough thermal and energy headroom for them. But when optimizing for power, every additional active transistor inherently adds cost and x86 is an example of an architecture that’s not been well engineered for power.
Also it’s worth noting that even with more transistors for decoding, the added compexity still results in performance tradeoffs like x86 CPUs being able to decode fewer instructions in parallel compared to ARM CPUs because ARM instructions are easier to read. Apple’s ARM processors have this advantage. Knowing what we now know, x86 would not have been designed with suboptimal properties for parallel decoding; engineers would exploit the opportunities to optimize away unnecessary decoder complexity. Of course intel engineers at the beginning had no idea that their instruction set would become the standard so many decades later optimizing for this wasn’t even on the radar.
The width of a modern x86 front end is determined primarily by the throughput its back end (Int, FP, SIMD, L/S, and other FUs) can effectively process, not by some fundamental limitation on decoding instructions in parallel.
x86’s encoding does make instruction boundary detection slightly more complex than with fixed width RISC instructions, but that is principally an implementation cost involving a bit of additional predecode and control logic. It is not an inherent barrier to building a wide, parallel decoder.
@Alfman
Of course every transistor comes with a cost. But so too does executing six instructions to emulate one instruction from a foreign ISA. But I am not suggesting that creating an SoC that can handle more than one ISA natively comes for free.
@Xanady
I certainly agree with all that.
In many ways, a modern x86-64 chip has a back-end that is built to efficiently execute a simpler ISA than x86-64 really is and then a front-end that breaks down the actual ISA into a form the back-end can effectively manage.
It is exactly this abstraction that opens up the possibility of having one back-end that can be fed by multiple decoders representing more than a single ISA. In fact, you could argue that x86 and x86-64 are already that.
Xanady Asem,
I didn’t say there was a fundamental limitation on decoding in parallel, I just said it’s more costly for x86 than for ARM, which it is.
If x86 backwards compatibility weren’t at stake, engineers could and would optimize the architecture to make fetching instructions simpler using fewer transistors. More transistors can allow for more parallelism, but it’s not free because it increases other costs like energy and creating deeper logic propagation paths. Deeper propagation paths increase the time it takes to compute outputs, which potentially limits clock speed. Obviously architects are mitigating x86 fetch costs using u-op cache. But large quantities of static ram is costly too, so they’re relatively small and it doesn’t take that many instructions to overrun the cache with long instruction streams.
Of course there are large segments of the industry that have decided that x86 compatibility is just too important to throw away. I get it, but it’s just unfortunate we standardized on x86 instead of something more modern. We’re finally seeing ARM CPUs competing on x86’s turf, which is great, but the caveat is that ARM vendors suck at standardization. ARM has been much less attractive for people like myself who want to install our own OS.
LeFantome,
I agree with you about this, but optimizing the fetch mechanism and executing six instructions to emulate one instruction is talking about two different topics.
@Alfam
At this point, the incremental hardware complexity of x86 decoding relative to ARM is essentially noise. Eg. variable length instruction boundary detection is tiny compared with the dominant structures in a modern out-of-order core, while high performance RISC designs now employ similarly sophisticated front ends, including µop and trace caches. Aside from some additional control logic and datapaths for routing rare or pathological instructions through sequenced microcode, high performance ARM and x86 decoders have broadly similar resource footprints.
That is why it never made technical or economic sense for AMD/Intel to abandon x86’s enormous binary ecosystem merely to save a negligible amount of front end logic. The idea that x86 imposes an inherent ceiling on performance or parallel decode is a decades old misconception at this point.
Modern core width is dictated far more by the resources of the core as a whole, particularly the back end, than by instruction encoding. The differences between some narrower AMD and Intel x86 cores and some ultrawide ARM designs reflect different area budgets, PDN technologies, V/F targets, and power and thermal envelopes, not fundamental ISA limitations.
Xanady Asem,
The OO cores are fast, but have their own cons in terms of energy efficiency. Never the less it’s a different debate. In terms of the cost of x86 front end, you keep comparing it’s complexity to other subsystems but that’s not a good indicator of how much of a bottleneck it can be. The reason Apple’s ARM chips decode more instructions in parallel isn’t because x86 couldn’t keep throwing more transistors at the problem, but that doing so would just increase the gap apple has over x86 at energy efficiency. In other words there are cons to x86’s complexity. Doing more work with more transistors is one possibility, but doing more work with fewer transistors is even better.
Yes, that’s what I said. I’m glad we agree. Compatibility with pre-existing code is a high enough priority that customers can overlook the shortcomings of it’s legacy ISA.
@Alfam
Again, no.
x86 decoding has not been a fundamental performance or complexity constraint since the P6 era, more than 3 decades ago! P6 established the basic model still used today: decode architectural x86 instructions into simpler internal ops, then execute those operations through a conventional out-of-order back end. Once instructions have been decoded, the renaming, scheduling, issue, execution, and retirement machinery is conceptually no different from that of any other high performance out-of-order core.
The additional x86 specific machinery is concentrated in a relatively small portion of the front end: instruction length/boundary identification, some additional FSMs, and a microcode sequencer for the rare pathological instructions.
Modern high performance ARM cores do not have “simple RISC front ends” either. They also translate/crack some instructions into multiple µops, fuse others, and employ elaborate branch predictors, queues, caches, and wide fetch/decode machinery. Fixed-width RISC encoding makes boundary detection easier, but that advantage represents a small implementation detail, not some transformative reduction in overall core complexity or increase in efficiency.
The incremental resource difference between a modern high performance ARM decoder and an x86 decoder is roughly on the order of a percentage point of the total core budget. That is essentially noise compared with the ROB, reg files, schedulers, issue queues, EUs, L/S queues, branch predictors, and cache hierarchy where most of the transistors, power, and design complexity actually reside.
The belief that x86 inherently limits decode or front end performance/complexity is simply old RISC vs CISC folklore repeated online by people with little understanding of modern microarchitecture.
Some ARM cores can be more energy efficient than contemporary x86 cores, but the meaningful reasons are their design targets and implementations: process technology, std cell libraries, pipeline depth, speculation policy, cache hierarchy, PDN design, V/F targets, power management, packaging, and thermal envelope. Those factors dominate. There is nothing magical about the ARM instruction encoding that automatically produces a wider or more efficient core.
It doesn’t have to be purely one approach or the other. Apple showed this with their x86 memory modes. Just find the slow paths, and bake something in hardware to help with that, then build the rest in emulation. It’s the same with economies – hybrid models tend to work better.
FWIW, most x86 microarchitectures have been doing some version of that for decades. The original AMD64 implementation, for example, effectively supported multiple ISA personalities within the same front end: legacy 32bit x86 and the new x64 extensions.
The Pentium Pro front end did something similar with 32bit code and legacy 16bit x86, part of the reason its performance on 16bit workloads was so uneven.
IBM used to do so much cool stuff. They still do a lot of research, but I kinda miss the fact that they also manufactured them. My Model M keyboard is turning 40 in January, still going strong and no shiny keys!
The “reduced” in RISC refers to instruction complexity, not instruction quantity, I expected IBM to know this, but nope.
And the fact that it sounds like only a “subset” of the total number of AArch64 instructions is even more laughable.
How much of a “complete” implementation is it ? Is the rest emulated like in 68040/68060 processors, needing software libraries to execute non hardware implemented instructions ?
RISC has always been a (mostly) meaningless term because there has never been a consistent definition of what, exactly, is being “Reduced”: instruction count, CPI, encoding/semantic/implementation complexity, addressing modes, etc.
It is essentially a cool sounding acronym that someone came up with at the last minute for a paper submission that somehow stuck, and became a permanent architectural taxonomy.
The funniest part is that a (initially) mobile-centric RISC architecture accumulated a significantly larger ISA than a far older CISC mainframe architecture. At this point, the labels for instruction encoding tell very little about the actual machines.
RISC is about instruction set size. See Patterson, 1980:
FWIW Patterson’s early manifestos were somewhat vague, mainly to challenge the prevailing assumption of that time (late 70s, early 80s) that increasingly complex ISAs necessarily represented progress. So much of the early RISC arguments were handwavy rather than quantitatively rigorous.
It eventually evolved from “fewer instructions” to “reduced complexity,” although even that was still vague. At one extreme were very simple architectures such as PIC and early SPARC, which omitted even some fundamental arithmetic insts and relied heavily on software libraries/emulation. At the other was IBM POWER, which debuted w more instructions than the contemporary 486. And every variation in between.
What ultimately defined RISC was not instruction count, but a set of common design principles: simple mostly single cycle operations, a load/store architecture w/o complex addressing modes, and primarily register-to-register ops. None of those inherently requires a small instruction set.