This feels like a baby step towards Arm being able to emulate z/Arch workloads, maybe with a bit of secret sauce for certain specific operations, which doesn't seem very much like IBM.
I thought about that, too. I think they’re doing this for the same reason IBM has supported Linux LPARs:
since a lot of customers who lease System/z currently probably get overprovisioned hardware that they’ll never fully use, why not try a last-ditch attempt to sell the excess capacity as ARM LPARs?
IIRC, they had different licensing prices for cores that would run z/OS workloads and cores that would run Linux on s390x (and other tier for Java, I think). This looks like they’ll have one for Linux on ARM as well.
ARM has better software support for AI applications and half of their presentation was about their inference accelerators that can go in the mainframes (and POWER machines).
IBM mainframes are almost designed by their users. The previous generation skipped a lot of speed boost on the CPU side because their users didn’t want the machine to blow over their power delivery limits.
Now, with their architecture behind it, I’m sure these ARM Linux partitions will have the fastest ARM cores ever made. My experience with Linux on s390x is that it feels like a normal server that’s just ludicrously fast - almost as if it came from the future.
At least back in the day, there was talk about Nvidia + ppc64le. Wasn't there even a supercomputer with that setup? But I guess that has fallen by the wayside.
No, this is more like any modern processor, which translates instruction codes into micro-ops. To over-simplify IBM just has two of these units per thread rather than one.
I wonder how they handle potential differences in memory barriers, instruction order scheduling and other stuff and do they run the core in one mode continuously or do the mix instruction streams from different instruction sets? Anybody got a link to an article?
Possible different micro ops for different semantics.
They also don’t mix instructions sets within the same process - the diagram I saw had ARM Linux as a guest under z/VM or KVM. For generations now no OS (not VM, not z/OS) hasn’t seen the bare metal machine, only ran under the PR/SM hypervisor, which is what does the logical partitions now.
In order to properly run OSs for the 360 and 370 generations, s390x also has instructions for setting up CPU flags to more precisely emulate older machines. From an s390x binary you can, IIRC, do a jump to an address telling it that, from the jump forward the ISA is the one of a 360 until it encounters a return, which restores 390 mode.
I had much the same question, which is one of the reasons I used the term "over-simplify". my guess is that many of the units have a toggle "arm mode / z mode", which would mean that mixing streams would be unlikely. I wonder if they chose ARM over x86 or other options partly because important aspects like the memory model of ARM and z were more similar than the memory models of x86 and z.
Yep. All modern Intel and AMD architectures, save maybe some Atom variants, effectively JIT compile the incoming instructions. It's part of the reason the faster-than-static Java/JVM promises never came to fruition. The goal posts moved after the mainstream chips coopted the approach, in a sense, and they continue to move as pipelines get deeper and broader and transistor count goes up.
Transmeta was a classic failure--right idea, wrong place & time.
Intel and AMD were more or less 'Jitting' since the PPro and K5, and that's ignoring NexGen's Nx586 (which was shipping in hardware about a year before the PPro).
All of them are way before Transmeta shipped a CPU. Where Transmeta tried to innovate was by using VLIW rather than a RISC-like core, along with their other special tech (Which they later licensed to lots of companies, including Intel,) to provide reasonable mobile performance with a low power draw. Oh, there's also the bit where Transmeta CMS is much more software based (likely, partially to push enough to software and avoid an x86 CPU license lawsuit) but even modern Intel chips AFAIK are still doing more translation on the CPU layer.
IBM’s microcode is really something. Not too long ago I heard about writing “millicode” as something that’s not at the microcode level, but not quite up at the ISA level.
Transmeta did code translation with a software JIT. The hardware side had specific support for x86 semantics, similar to how Apple's M-series has supporting hardware for Rosetta's AOT translation, but neither executes x86 machine code directly.
If by that you are asking whether it has a dynamic ISA controllable at runtime, it appears not. This looks to be a Z processor with arm instructions implemented.
That being said I think it's a natural consequence of the difference between a mainframe and commodity servers. A mainframe is going to be running pretty disparate workloads simultaneously, so it makes sense to steal from your neighbor if they aren't using their cache. Whereas it's more likely that a commodity server is just running the same server on each core, and if you have a different workload, you pick a different shape of server to run it on. There are pros and cons to both.
I do wonder about the spectre consequences of borrowing cache lines from other cores though.
Even though their CPUs are insanely fast, the real power of mainframes is in their IO. The amount of data you can push through those machines is absolutely mind blowing.
The z mainframe team does good technical work but then the high price cancels out all the value of that work. I'm not sure if that counts as innovation or not.
At this point no one is buying into mainframes are they?
So they are just selling to the existing pool of users for which the price just has to come in under the cost/risk of rewriting all their ancient stuff.
For starters, IBM did also do the CPU for the GameCube, and that was likely a part of the Wii using an upgraded PPC arch for that.
On the flipside, there is the theory (I think even Copetti brings it up in their XBox 360 Architecture breakdown [0]) that IBM using the Cell PPE for the 360's tri-cores left a sour taste in Toshiba, but more-so Sony's mouths.
I think the big 'X factor' though, was that, for as much pain as it caused AMD in the short term, (it's so easy to forget their 'malaise' era, i.e. Early Bulldozer and the GloFo split pains to their margins[1]), AMD made all the 'right' choices to let the console vendors have their cake and eat it too.
Namely, AMD was more than happy to do a custom core if there was a volume contract (similar to what IBM was willing to for the 360/GC/Wii) but also now had a capable, in-house GPU. (And thankfully had Bobcat as a stepping point towards Jaguar[2])
There's part of me that asks, if AMD had an ARM core, if we would have all Consoles powered by AMD chips now. Nintendo likely bought into Tegra because it was an ARM core, and for better or worse their mobile stuff by the time of making that choice had 15+ years of proven ARM success (GBA, DS, 3DS) behind it.
(See also, Intel in the 2010s scrambling with half-assed promises of integrating custom functionality or FPGAs with x86 cores.)
[1] - From what I recollect, the GloFo split and how the contracts were drawn up as far as their production, had a huge impact on their ability to produce due to yields and thermals, as well as the contracts for how GloFo got paid; it was at least part of them diversifying with TSMC as soon as they reasonably could.
[2] - As a Rant, I am pretty sure, if Jaguar had Desktop/Mobile versions that included a Dual channel DDR controller, they would have cleaned up on the low cost laptop market. I had one with, I think it was an A5000 or A5200, and for how tiny the battery was it could last wayyyy longer than any of the intel laptops I had for the time, but churned if you were doing memory heavy stuff.
> On the flipside, there is the theory (I think even Copetti brings it up in their XBox 360 Architecture breakdown [0]) that IBM using the Cell PPE for the 360's tri-cores left a sour taste in Toshiba, but more-so Sony's mouths.
It's more than a theory. It's pretty much spelled out explicitly in The Race For A New Game Machine how salty not just Sony and Toshiba were in the broad sense, but also the Sony and Toshiba engineers that the IBM team worked with felt pretty betrayed.
I think Nintendo used Tegra because it was super cheap. AMD has access to the same ARM cores as everyone else (see Seattle and Sound Waves) but a semi-custom chip would have been more expensive than an overstocked Tegra.
To your point... yeah, Switch was the only 'real' big volume hit for Tegra that I remember (Although I did like my 2012 Nexus 7) with any staying power.
Hell Nvidia was so desperate they did the whole Shield thing...
PS3 used the Cell processor but it’s debatable how much that was an asset vs handicap. Total PlayStation sales dropped for that generation vs both PS2 and PS4. The manufacturing costs didn’t fall nearly as fast as expected and it was a poor fit in terms of cross platform development etc.
Because simple similarity doesn’t usually result in a lawsuit? Especially if one of the words isn’t a public product name and also happens to be an existing word with no existing specific use in the industry.
I'm guessing that they were safe in that it was more or less a 'codename' for a specific product's CPU that nobody else could buy, versus a product out on the market, left enough clear separation to avoid Trademark complaints.
The combined might of IBM and Microsoft's legal teams, even (possibly even moreso?) then, was better than Intel's to be sure.
This feels like a baby step towards Arm being able to emulate z/Arch workloads, maybe with a bit of secret sauce for certain specific operations, which doesn't seem very much like IBM.
I thought about that, too. I think they’re doing this for the same reason IBM has supported Linux LPARs: since a lot of customers who lease System/z currently probably get overprovisioned hardware that they’ll never fully use, why not try a last-ditch attempt to sell the excess capacity as ARM LPARs?
Now you’re thinking like a Big Blue sales rep.
IIRC, they had different licensing prices for cores that would run z/OS workloads and cores that would run Linux on s390x (and other tier for Java, I think). This looks like they’ll have one for Linux on ARM as well.
why is IBM moving forward that way
Huh. ARM instead of ppc64le?
ARM has better software support for AI applications and half of their presentation was about their inference accelerators that can go in the mainframes (and POWER machines).
IBM mainframes are almost designed by their users. The previous generation skipped a lot of speed boost on the CPU side because their users didn’t want the machine to blow over their power delivery limits.
Now, with their architecture behind it, I’m sure these ARM Linux partitions will have the fastest ARM cores ever made. My experience with Linux on s390x is that it feels like a normal server that’s just ludicrously fast - almost as if it came from the future.
At least back in the day, there was talk about Nvidia + ppc64le. Wasn't there even a supercomputer with that setup? But I guess that has fallen by the wayside.
Yes. There was a generation of POWER that offered NVLink.
Is this like the Transmeta processors doing code translation in hardware?
No, this is more like any modern processor, which translates instruction codes into micro-ops. To over-simplify IBM just has two of these units per thread rather than one.
I wonder how they handle potential differences in memory barriers, instruction order scheduling and other stuff and do they run the core in one mode continuously or do the mix instruction streams from different instruction sets? Anybody got a link to an article?
Possible different micro ops for different semantics.
They also don’t mix instructions sets within the same process - the diagram I saw had ARM Linux as a guest under z/VM or KVM. For generations now no OS (not VM, not z/OS) hasn’t seen the bare metal machine, only ran under the PR/SM hypervisor, which is what does the logical partitions now.
In order to properly run OSs for the 360 and 370 generations, s390x also has instructions for setting up CPU flags to more precisely emulate older machines. From an s390x binary you can, IIRC, do a jump to an address telling it that, from the jump forward the ISA is the one of a 360 until it encounters a return, which restores 390 mode.
I had much the same question, which is one of the reasons I used the term "over-simplify". my guess is that many of the units have a toggle "arm mode / z mode", which would mean that mixing streams would be unlikely. I wonder if they chose ARM over x86 or other options partly because important aspects like the memory model of ARM and z were more similar than the memory models of x86 and z.
They were pretty clear at Hot Chips that it's native
.... I -so- miss RealWorldTech write-ups, I'd love to see what David Kanter would have to say about this thing...
"code translation in hardware" microcode is called "native"
Yep. All modern Intel and AMD architectures, save maybe some Atom variants, effectively JIT compile the incoming instructions. It's part of the reason the faster-than-static Java/JVM promises never came to fruition. The goal posts moved after the mainstream chips coopted the approach, in a sense, and they continue to move as pipelines get deeper and broader and transistor count goes up.
Transmeta was a classic failure--right idea, wrong place & time.
Eh?
Intel and AMD were more or less 'Jitting' since the PPro and K5, and that's ignoring NexGen's Nx586 (which was shipping in hardware about a year before the PPro).
All of them are way before Transmeta shipped a CPU. Where Transmeta tried to innovate was by using VLIW rather than a RISC-like core, along with their other special tech (Which they later licensed to lots of companies, including Intel,) to provide reasonable mobile performance with a low power draw. Oh, there's also the bit where Transmeta CMS is much more software based (likely, partially to push enough to software and avoid an x86 CPU license lawsuit) but even modern Intel chips AFAIK are still doing more translation on the CPU layer.
IBM’s microcode is really something. Not too long ago I heard about writing “millicode” as something that’s not at the microcode level, but not quite up at the ISA level.
Transmeta did code translation with a software JIT. The hardware side had specific support for x86 semantics, similar to how Apple's M-series has supporting hardware for Rosetta's AOT translation, but neither executes x86 machine code directly.
I was curious, is it conceptually similar to Data General Fountainhead project?
If by that you are asking whether it has a dynamic ISA controllable at runtime, it appears not. This looks to be a Z processor with arm instructions implemented.
Oh I see, thanks!
I was reading HN comments yesterday shitting on modern IBM for being a non tech consulting company that has not innovated since the mid nineties.
To be fair, IBM did this in the 90s with the PowerPC 615, which had PowerPC and x86 decoders on the same core.
But those ARM and s390x decoders have a “Telum III” architecture behind them with a cache that’s pretty innovative.
IBM has never stopped innovating. It’s just that most people can’t afford their machines.
Yeah, their cache work is undeniably really cool.
That being said I think it's a natural consequence of the difference between a mainframe and commodity servers. A mainframe is going to be running pretty disparate workloads simultaneously, so it makes sense to steal from your neighbor if they aren't using their cache. Whereas it's more likely that a commodity server is just running the same server on each core, and if you have a different workload, you pick a different shape of server to run it on. There are pros and cons to both.
I do wonder about the spectre consequences of borrowing cache lines from other cores though.
Even though their CPUs are insanely fast, the real power of mainframes is in their IO. The amount of data you can push through those machines is absolutely mind blowing.
The z mainframe team does good technical work but then the high price cancels out all the value of that work. I'm not sure if that counts as innovation or not.
At this point no one is buying into mainframes are they?
So they are just selling to the existing pool of users for which the price just has to come in under the cost/risk of rewriting all their ancient stuff.
Someone has to be buying mainframes. Otherwise, there's no point in continuing to develop them. Shareholders would revolt.
The existing 1,000 customers replace their old mainframes with newer models.
More like mid-2000s, even with the least charitable interpretation.
There was a time when IBM dominated console CPUs for a massively successful generation (PS3, Xbox 360, Nintendo Wii).
Having a presence in the consumer market is not a requirement for being innovative.
IBM stopped building servers based on x86 because the margins were too thin for their tastes, but they never stopped building on top of POWER and Z.
It's a little more complex than that, IMO.
For starters, IBM did also do the CPU for the GameCube, and that was likely a part of the Wii using an upgraded PPC arch for that.
On the flipside, there is the theory (I think even Copetti brings it up in their XBox 360 Architecture breakdown [0]) that IBM using the Cell PPE for the 360's tri-cores left a sour taste in Toshiba, but more-so Sony's mouths.
I think the big 'X factor' though, was that, for as much pain as it caused AMD in the short term, (it's so easy to forget their 'malaise' era, i.e. Early Bulldozer and the GloFo split pains to their margins[1]), AMD made all the 'right' choices to let the console vendors have their cake and eat it too.
Namely, AMD was more than happy to do a custom core if there was a volume contract (similar to what IBM was willing to for the 360/GC/Wii) but also now had a capable, in-house GPU. (And thankfully had Bobcat as a stepping point towards Jaguar[2])
There's part of me that asks, if AMD had an ARM core, if we would have all Consoles powered by AMD chips now. Nintendo likely bought into Tegra because it was an ARM core, and for better or worse their mobile stuff by the time of making that choice had 15+ years of proven ARM success (GBA, DS, 3DS) behind it.
(See also, Intel in the 2010s scrambling with half-assed promises of integrating custom functionality or FPGAs with x86 cores.)
[0] - https://www.copetti.org/writings/consoles/xbox-360/
[1] - From what I recollect, the GloFo split and how the contracts were drawn up as far as their production, had a huge impact on their ability to produce due to yields and thermals, as well as the contracts for how GloFo got paid; it was at least part of them diversifying with TSMC as soon as they reasonably could.
[2] - As a Rant, I am pretty sure, if Jaguar had Desktop/Mobile versions that included a Dual channel DDR controller, they would have cleaned up on the low cost laptop market. I had one with, I think it was an A5000 or A5200, and for how tiny the battery was it could last wayyyy longer than any of the intel laptops I had for the time, but churned if you were doing memory heavy stuff.
> On the flipside, there is the theory (I think even Copetti brings it up in their XBox 360 Architecture breakdown [0]) that IBM using the Cell PPE for the 360's tri-cores left a sour taste in Toshiba, but more-so Sony's mouths.
It's more than a theory. It's pretty much spelled out explicitly in The Race For A New Game Machine how salty not just Sony and Toshiba were in the broad sense, but also the Sony and Toshiba engineers that the IBM team worked with felt pretty betrayed.
I think Nintendo used Tegra because it was super cheap. AMD has access to the same ARM cores as everyone else (see Seattle and Sound Waves) but a semi-custom chip would have been more expensive than an overstocked Tegra.
To your point... yeah, Switch was the only 'real' big volume hit for Tegra that I remember (Although I did like my 2012 Nexus 7) with any staying power.
Hell Nvidia was so desperate they did the whole Shield thing...
Xbox 360 used an Intel CPU.
PS3 used the Cell processor but it’s debatable how much that was an asset vs handicap. Total PlayStation sales dropped for that generation vs both PS2 and PS4. The manufacturing costs didn’t fall nearly as fast as expected and it was a poor fit in terms of cross platform development etc.
PS4 moved to AMD.
> Xbox 360 used an Intel CPU.
No. It was a PowerPC based one called, IIRC, Xenon.
Wow, you’re right.
Xeon vs Xenon
I had always assumed with chip names that similar it was an Intel product. How on earth didn’t they get sued?
Because simple similarity doesn’t usually result in a lawsuit? Especially if one of the words isn’t a public product name and also happens to be an existing word with no existing specific use in the industry.
I'm guessing that they were safe in that it was more or less a 'codename' for a specific product's CPU that nobody else could buy, versus a product out on the market, left enough clear separation to avoid Trademark complaints.
The combined might of IBM and Microsoft's legal teams, even (possibly even moreso?) then, was better than Intel's to be sure.
Not even the DoJ could make Microsoft bend its knee.
And in fact it was basically a Cell PPE with a larger vector unit strapped to the side of it.
There are already microcontrollers that have both arm + riscv support. This isn't something insane.
RP2350 has separate cores for that. This is one core that speaks both.
well that's nonsense. IBM does incredibly cool stuff.
https://research.ibm.com/blog
Their research is usually behind paywalls. I miss the days when they published their journals and made PDFs available for download.
Those takes are wrong with or without this particular processor.
Right click -> Open image in new tab -> zoom in
If you haven't already.
Oh is that why the page is like 50 megs.
Yep, it's wood.