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.
The diagram is the last picture, and according to it you choose the ISA at the VM level: either Linux on s390x or Linux on arm64, but not both on the same VM.
Interesting that z/VM doesn't seem to support spinning up ARM Linux VMs, at least according to this diagram, but it does support bringing up s390x Linux VMs (the LinuxONE Community Cloud creates Linux VMs under z/VM). Also, it looks like z/OS is running directly on the LPAR, which wasn't common the last time I looked (a decade ago, more or less).
I suspect that is not an inherent limitation of the dual-ISA design (the HotChips slides mention some sort of bidirectional thread state mapping between arm and z), but just about there not being z/VM release that supports that (building such a thing is probably SMoP, but another question is whether that makes business sense).
In general implementing a weaker memory model (e.g. aarch64) on a stronger memory model (e.g. x86_64 or s390x) is fairly easy, while the reverse is more difficult (see Apple's processors which have a dedicated "stronger" mode to better support execution of translated x86_64 code). It all requires some additional complexity, but starting from a complicated high-performance CISC architecture which already supports a wide range of backwards compatibility modes you are already going to have many of the building blocks on hand to support something new.
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.
Millicode used custom extensions to the ISA but is otherwise regular s390 code. For example there is a separate register file and the "original" registers are available with either (I don't remember exactly) special instructions or special memory addresses.
Intel by the way did the same for SGX, they called it xucode.
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.
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 found this article with the diagram that you mention: https://wccftech.com/ibm-worlds-first-dual-architecture-proc...
The diagram is the last picture, and according to it you choose the ISA at the VM level: either Linux on s390x or Linux on arm64, but not both on the same VM.
Interesting that z/VM doesn't seem to support spinning up ARM Linux VMs, at least according to this diagram, but it does support bringing up s390x Linux VMs (the LinuxONE Community Cloud creates Linux VMs under z/VM). Also, it looks like z/OS is running directly on the LPAR, which wasn't common the last time I looked (a decade ago, more or less).
I suspect that is not an inherent limitation of the dual-ISA design (the HotChips slides mention some sort of bidirectional thread state mapping between arm and z), but just about there not being z/VM release that supports that (building such a thing is probably SMoP, but another question is whether that makes business sense).
Z’s memory model is much stronger than arm, so running arm on z memory model requires almost no design changes. The inverse is not true.
Which leaves a substantial amount of performance on the table. Which IBM may be fine with, but benchmarks are important to IBM.
In general implementing a weaker memory model (e.g. aarch64) on a stronger memory model (e.g. x86_64 or s390x) is fairly easy, while the reverse is more difficult (see Apple's processors which have a dedicated "stronger" mode to better support execution of translated x86_64 code). It all requires some additional complexity, but starting from a complicated high-performance CISC architecture which already supports a wide range of backwards compatibility modes you are already going to have many of the building blocks on hand to support something new.
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...
David recently announced he was leaving MLCommons, so maybe we'll get him back as an industry analyst.
"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.
Millicode used custom extensions to the ISA but is otherwise regular s390 code. For example there is a separate register file and the "original" registers are available with either (I don't remember exactly) special instructions or special memory addresses.
Intel by the way did the same for SGX, they called it xucode.
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.