Attempts to translate x86 assembly into mos6502 assembly

[legacy]

found here, impressed 

[westfw]

I've wondered, occasionally, why there aren't more "compilers" for obsolete assembly languages.  Or for machine languages, for that matter - figuring out which parts are code and which parts are data ought to be comparatively easy, compared to what real compilers do these days.

[orin]

I've wondered, occasionally, why there aren't more "compilers" for obsolete assembly languages.  Or for machine languages, for that matter - figuring out which parts are code and which parts are data ought to be comparatively easy, compared to what real compilers do these days.

Not much need to compile obsolete assembly language.  Often the source is lost and only the binary remains.  If you have the binary, then IDA Pro will handle binary code for many obsolete CPUs.  You won't like the price though.  https://www.hex-rays.com/products/ida/  Fortunately my employer paid for the copy I sometimes use at work.

[Moshly]

There is a talk on youtube about using it to make a pong game ->

[legacy]

IDA Pro

I am going to buy my copy for MIPS and 68k

[rstofer]

I wonder how these gadgets work when the original source used a DB to insert an opcode without the following operands.  The effect of this is to throw the disassember out of sync with the instruction stream.

In CP/M there is a DB that defines an LXI instruction which is normally 3 bytes.  But it isn't an instruction at all and would never be executed because control never get there.  The following 2 bytes are not the address field for the LXI but the first two bytes of another 3 byte instruction.  From this point on, the disassembly is trash.

[Bruce Abbott]

I wonder how these gadgets work when the original source used a DB to insert an opcode without the following operands.  The effect of this is to throw the disassember out of sync with the instruction stream.

The fix is to make the translator aware of that OS function and how to process it.

But the real problem isn't getting an accurate disassembly. Disassembling a program doesn't recreate the OS and the hardware it runs on. You could translate a Windows program into the equivalent 6502 machine code, but it wouldn't run on a C64.

The truth is, these 'gadgets' only work for a limited set of instruction sequences that might be produced by a particular compiler. That's a million miles away from being able to take any random executable and translate it to another platform.

[ale500]

I wonder how these gadgets work when the original source used a DB to insert an opcode without the following operands.  The effect of this is to throw the disassembler out of sync with the instruction stream.

In CP/M there is a DB that defines an LXI instruction which is normally 3 bytes.  But it isn't an instruction at all and would never be executed because control never get there.  The following 2 bytes are not the address field for the LXI but the first two bytes of another 3 byte instruction.  From this point on, the disassembly is trash.

With data mixed with the instruction stream you have the same effect. What I did (no idea how IDA works) was to analyze the flow to discover the execution paths. You have  to construct a table of starting points, if not, you don't get that far. Jump tables is something I never recognized, but are almost always present.

[legacy]

The truth is, these 'gadgets' only work for a limited set of instruction sequences that might be produced by a particular compiler. That's a million miles away from being able to take any random executable and translate it to another platform.

no doubt about it

my TiniJava platfrom comes with a "jump51" meta-assembler
it converts from java-byte-code into 8051 machine code
and ... even Dallas Semiconductors admited that it's a million
light year away from being able to take any random executable
and translate it to another (8051?) platform 

anyhow, with some (heavy) restrictions ... it works

[legacy]

IDA Pro

Mips@Irix is supported: excellent 

[C]

Think of what happens with this z80 code in a dissembler.

Call a function
a lot of inline data here
function return is to here
more code

the simple function
pops the return address from stack
uses return address as a data pointer
when done push data pointer on stack
return

A common use was to output a pomp or string.

The second problem is a program that relocates some of it's code.

[vodka]

Think of what happens with this z80 code in a dissembler.

Call a function
a lot of inline data here
function return is to here
more code

the simple function
pops the return address from stack
uses return address as a data pointer
when done push data pointer on stack
return

A common use was to output a pomp or string.

The second problem is a program that relocates some of it's code.

But if you get old sources from  80s  it is more optimized  than today sources. Therefore , it is more easiest to reverse.
Now if you get today source as the TL866A bootloader source , the half-code is crap and like you said you can pass all the time circling the source as waterwheels.

[Bruce Abbott]

What I did (no idea how IDA works) was to analyze the flow to discover the execution paths. You have  to construct a table of starting points, if not, you don't get that far. Jump tables is something I never recognized, but are almost always present.

I wrote a disassembler for the Amiga that followed every jump to determine what was code and data. It also knew about all the operating system calls, and recognized typical 'c' constructs used by popular compilers. With a bit of manual prodding to ensure that no code got missed, the regenerated assembler source would produce an identical executable file (including all segments, relocation tables etc.).

I used it to update and improve an accounting program which had been abandoned by its developer (who gave me permission to modify the Amiga version).     

[timb]

The truth is, these 'gadgets' only work for a limited set of instruction sequences that might be produced by a particular compiler. That's a million miles away from being able to take any random executable and translate it to another platform.

That's not entirely true... In practice, binary translation can be very effective. For example, there's Rosetta, which Apple included in Tiger (Mac OS X 10.4.4) after the PPC to Intel switch.

Rosetta dynamically translated the code of PowerPC (G3 and G4 plus AltiVec) executables to run on Intel (x86 and x64) systems. It worked for most of the existing software and ran it a lot of it close to native speed.

That's pretty damn impressive. (That said, it did only transmute userland code, but that was more of an implementation decision than anything.)

Edit: There's also the M68k to PPC translator that Apple implemented when they switched from the 68000 to PPC. That performed dynamic recompilation on blocks of code as it ran! M68k software running on a PPC of the time could actually run *faster* through this method than on native hardware!

[orin]

I wonder how these gadgets work when the original source used a DB to insert an opcode without the following operands.  The effect of this is to throw the disassembler out of sync with the instruction stream.

In CP/M there is a DB that defines an LXI instruction which is normally 3 bytes.  But it isn't an instruction at all and would never be executed because control never get there.  The following 2 bytes are not the address field for the LXI but the first two bytes of another 3 byte instruction.  From this point on, the disassembly is trash.

With data mixed with the instruction stream you have the same effect. What I did (no idea how IDA works) was to analyze the flow to discover the execution paths. You have  to construct a table of starting points, if not, you don't get that far. Jump tables is something I never recognized, but are almost always present.

IDA analyzes probable execution flow.  But it does need to know a starting point.  Not a problem with a known exe format.  For a binary image, you have to define the address of the image and a starting point.  You can easily turn areas it's treated as code back to data or turn areas of data into code.

It sure beats the alternatives if you can afford it (and I would much like the version that can disassemble 64bit, but can't justify the cost).

[Bruce Abbott]

That's not entirely true... In practice, binary translation can be very effective. For example, there's Rosetta, which Apple included in Tiger (Mac OS X 10.4.4) after the PPC to Intel switch.

But this is not the same as translating an executable compiled for one CPU/OS to run on another as a stand-alone application.

Rosetta

Apple released Rosetta in 2006 when it changed the instruction set architecture of the Macintosh platform from the PowerPC to the Intel processor...

According to Apple, applications with heavy user interaction but low computational needs (such as word processors) are well suited to translation via Rosetta, while applications with high computational needs (such as AutoCAD, games, or Adobe Photoshop) are not...

Rosetta does not support the following:[6]

    The Classic environment, and thus any non-Carbon application built for Mac OS 9 or earlier
    Code that inserts preferences into the System Preferences pane
    Applications that require a G5 processor
    Applications that require precise exception handling
    Screen savers
    Kernel extensions and applications that depend on them
    Bundled Java applications or Java applications with JNI libraries that can’t be translated
    Java applets in Rosetta-translated applications, meaning that a native Intel web browser application, rather than a legacy PowerPC version, must be used to load Java applets

So Rosetta translates code from one CPU to another on basically the same platform, and only works with some applications (not 'any random executable'). The main reasons it works so well are that PowerPC and modern Intel CPUs are both RISC so the code can be translated fairly efficiently, and applications with 'heavy user interaction but low computational needs' spend most of their time in the OS which is native code.

Rosetta is effectively part of the Mac OS, which is where much of its effectiveness comes from. I suppose it would be possible to tack a Rosetta-like translator onto the executable, but adding Megabytes of OS-specific code and describing it as 'translating CPUx assembly into CPUy assembly' is a stretch...         
 

There's also the M68k to PPC translator that Apple implemented when they switched from the 68000 to PPC. That performed dynamic recompilation on blocks of code as it ran! M68k software running on a PPC of the time could actually run *faster* through this method than on native hardware!

That was an emulator, which is not quite the same as a translator. Yes, software could run faster through the emulator than on an original M68k Mac, but only because the PPC is so much faster than a 68000. The emulator also implemented OS functions in native PPC code, and took full advantage of similarities between PPC and M68K Macs.

Any machine can emulate any other if it has enough resources. Want to see something really impressive? Here's an 8 bit ATmega1284 running ARM5 Linux.

How fast is it?

uARM is certainly no speed demon. It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu ("exec init" and then login). Starting X takes a lot longer. The effective emulated CPU speed is about 6.5KHz, which is on par with what you'd expect emulating a 32-bit CPU & MMU on a measly 8-bit micro. Curiously enough, once booted, the system is somewhat usable. You can type a command and get a reply within a minute. That is to say that you can, in fact, use it. I used it today to format an SD card

[timb]

There's also the M68k to PPC translator that Apple implemented when they switched from the 68000 to PPC. That performed dynamic recompilation on blocks of code as it ran! M68k software running on a PPC of the time could actually run *faster* through this method than on native hardware!

That was an emulator, which is not quite the same as a translator. Yes, software could run faster through the emulator than on an original M68k Mac, but only because the PPC is so much faster than a 68000. The emulator also implemented OS functions in native PPC code, and took full advantage of similarities between PPC and M68K Macs.

Well, it was an emulator in the sense that it emulated the functions of an M68k Mac, yes. However, the second version for PCI systems performed dynamic recompilation on chunks of code as it ran.

DRC is defined as: Reading machine code from a source platform and emitting it for the target platform.

That's what both Rosetta *and* the M68k Emulator did for their respective platforms. Hence, they both used forms of binary translation.

Yes, the M68k system was called an emulator, mainly because it emulated parts of an M68k Mac *other* than the processor. However, an emulator can still use binary translation as one method of emulating a CPU (other methods include CPU emulatiom entirely in software, virtualization, etc).

Edit: In the video this thread is based on, the guy uses a form of static translation. That is, all the work in converting from one architecture to another is done before the program is run and only needs to be done once.

Dynamic translation does this on the fly, on the target architecture as the code is run.

Those are both considered forms of emulation, even though it's not what we traditionally think of as emulation (which in a lot of cases is creating a soft CPU that emulates all the registers and features of the source CPU.