On Wed, 10 Jul 2024, Lars Brinkhoff wrote: I believe there's hardware to make it work better, but there's plenty of examples of object code translation without special hardware. The last time Apple switched processors they compiled POWER code to x86 which was harder since the byte orders were different. Still would be interested to hear when it was invented. 1967 seems early but not that early. Regards, John Levine, johnl(a)taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly

Well, a computer scientist named Cathy May at IBM Research did this for the S370 / Power PC architecture pair back in the mid-1980s. The work was novel to me at the time ... she and her long-term partner were close friends of mine, so I heard about her work over shared dinners across several years. The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. It turned out to be remarkably easy to do the translation. And in practice the resulting Power PC code was only about 10% bigger than the original 370 code. AND, since tons of code is never touched (corner cases on corner cases) the result is quite efficient. I don't know if IBM ever built a product based on her research, but it seemed remarkably clever to me. Marc ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Tue, Jul 9, 2024 at 10:37 PM John Levine &lt;johnl(a)taugh.com&gt; wrote:

On Wed, Jul 10, 2024 at 12:58 PM segaloco via TUHS &lt;tuhs(a)tuhs.org&gt; wrote: Surely things like this have some limitations. Self-modifying code, for example, would be more challenging (though not impossible) to implement. But for _most_ programs, where text and data are mapped separately, it wouldn't be that bad; if data formats are common across ISAs and the instruction sets are similar-ish, it wouldn't be that bad. For the mainframe to PowerPC, I imagine floating point would be the sticky wicket. In some sense, this is one of the easiest cases to support. The system call mechanism necessarily needs some method to trap into the kernel; the kernel, in turn, needs to look at the state of the user program to see what it should do in response to that trap. In the case of going across an ISA, the kernel's job is marginally harder in that it has to respond to having multiple ways to end up at the system call handler, but that's not so much different than supporting multiple system call conventions on a single system. For example, on x86, we have the SYSCALL instruction, but also SYSENTER and older software might initiate a syscall by means of the INT instruction (e.g., INT 0x80 or INT 0x40). Across ISAs, one might enter the kernel on an illegal instruction trap, in which case the trap handler will have access to the faulting address and can examine what's there; if it's e.g. a 370 instruction, one could interpret it and figure out what to do from there. Usually system calls are made by calling a stub function in, say, the C library. That stub then sets up state in whatever manner the system expects, such as poking the system call number and arguments into registers or putting them on the stack in a specific order or whatever; the stub then traps, at which point the kernel takes over, services the syscall, and (usually) returns control to userspace, the return value will be examined, errno might be set, and the stub "returns" to calling code. Of course, the process might have invoked `exit` or something, in which case control won't be returned to userspace. Or the call can block, context switches might happen, the arguments might be bad, the thing can be killed, etc, etc. Anyway, in the context of this kind of ISA translation, presumably the stubs would be interpreted and the interpreter would be smart enough to recognize the trap, in which case it might rewrite to a native trap of some kind, instead of relying on the illegal instruction trick. These techniques are rather old, and I think go back much further than we're suggesting. Knuth mentions nested translations in TAOCP (Volume 1, I believe), suggesting the technique was well-known as early as the mid-1960s. - Dan C.

On Wed, Jul 10, 2024 at 3:23 PM Marc Donner &lt;marc.donner(a)gmail.com&gt; wrote: Marc, you are better than that - proof by lack of imagination is not very effective😘 Seriously, the "VAX Compiler" that Paul describes made a great deal of sense to the VMS team when it was developed. It's all about *economics*, not technical purity. And solution actually worked really well; as Paul points out, it lived for many different ISAs that followed VAX at DEC and now VSi. What I always was amazed by was the Cutler use assembler in the first place since DEC had production quality BLISS compilers. But as Dave Cane [VAX750 lead] once put it, it was the world's greatest assembler machine. Dave (famously) hated BLISS but was one heck of an assembly programmer. VMS both at the kernel and systems level, was (is) in assembler, so treating the VAX as a HLL and "compiling" to a new ISA was solid economics. ᐧ

The Cathy May paper can be found at: https://dl.acm.org/doi/pdf/10.1145/29650.29651 And it's quite interesting; the first time I was aware of work like this was six or seven years later, when ARDI's Mac emulator "Executor" was the new hotness. Adam