Remix.run Logo
christkv 2 days ago

Is this like the Transmeta processors doing code translation in hardware?

bryanlarsen 2 days ago | parent | next [-]

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.

christkv 2 days ago | parent [-]

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?

rbanffy 2 days ago | parent | next [-]

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.

pezezin a day ago | parent [-]

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.

rbanffy a day ago | parent [-]

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).

dfox a day ago | parent [-]

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).

rbanffy 17 hours ago | parent [-]

Building is easy. Supporting it for the next 50 years might be another story.

cpgxiii a day ago | parent | prev | next [-]

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.

trwei a day ago | parent | prev | next [-]

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.

bryanlarsen a day ago | parent [-]

Which leaves a substantial amount of performance on the table. Which IBM may be fine with, but benchmarks are important to IBM.

bryanlarsen 2 days ago | parent | prev | next [-]

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.

2 days ago | parent | prev [-]
[deleted]
stonogo 2 days ago | parent | prev | next [-]

They were pretty clear at Hot Chips that it's native

to11mtm 2 days ago | parent | next [-]

.... I -so- miss RealWorldTech write-ups, I'd love to see what David Kanter would have to say about this thing...

ccgreg a day ago | parent [-]

David recently announced he was leaving MLCommons, so maybe we'll get him back as an industry analyst.

pulse7 2 days ago | parent | prev [-]

"code translation in hardware" microcode is called "native"

wahern 2 days ago | parent | next [-]

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.

to11mtm 2 days ago | parent [-]

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.

rbanffy 2 days ago | parent | prev [-]

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.

bonzini a day ago | parent [-]

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.

LoganDark 2 days ago | parent | prev [-]

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.