Is there a such thing as something that could translate the target architecture of a program?

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Is there a such thing as something that could translate the target architecture of a program?

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

dlr posted:

Of course, we have emulators, that work by 'mimicking' the specified program's architecture to another one. Would it be impossible to create a program that translates the opcodes to match another architecture? Has this already been done before automated? How would this work?

In addition to what everyone else has said, there have been tools to do this directly:

The Z-80 and 8088 were "assembly compatible" with the 8080, which I think was similarly compatible with the 8008. The idea being you can just reassemble existing code because they all support the same mnemonics (and then some) just using different opcodes.

There have also been "assembly translators" that take idiomatic assembly for one system and output assembly, C, etc. for another. There was one for 68K to PowerPC conversion on the Mac, I don't recall its name, but WordPerfect was rumored to have been ported to PowerPC this way and still maintained as a 68K assembly app. (Too bad T/Maker didn't do this with WriteNow.)

And OpenGenera from Symbolics was implemented as an emulator for their Ivory CPU in DEC Alpha assembly�which someone was then able to itself treat as a source language, to generate x86_64 code, and bring the emulator from OSF/1 on Alpha workstations to 64-bit Linux on PCs.

# ¿ Apr 24, 2016 05:33

Adbot: ADBOT LOVES YOU

# ¿ May 15, 2024 14:42

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Jabor posted:

Complex instruction sets are basically all emulated today anyway. The instruction set the CPU exposes gets translated down into microinstructions for the actual CPU core to execute.

It turns out this is overall a good thing, because you can make a microinstruction set that executes really fast when you don't have to worry about things like "being just as performant on next year's CPU model" and "being compact enough that you're not saturating your memory bandwidth just by reading the instructions you're trying to execute".

This is how many CPUs have worked for a very long time. The innovation of RISC was to not do that, and instead expose far simpler one-cycle instructions and let the compiler handle things like ordering constraints to avoid pipeline stalls, etc.

What the major CPUs do these days is a lot more like the kind of JIT binary translation (say) HotSpot does than just translation of macroinstructions to microinstructions.

Trivia: Some systems had writable microstore, such as Lisp Machines, and in some cases (LMI) you could even compile a function to microcode if you were able to meet its space, access, etc. constraints and needed the speed.

More trivia: IBM's PC/370, which was an IBM 370 mainframe on a pair of ISA cards for the original IBM PC (intended primarily as a developer workstation) used a Motorola 68000 with custom microcode to implement the 370 CPU.

# ¿ Apr 24, 2016 05:40

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Is there a such thing as something that could translate the target architecture of a program?