Attempts to translate x86 assembly into mos6502 assembly - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2016, 07:19:14 pm
content: foundhere, impressed

author: westfw
author_rank: Super Contributor
timestamp: October 24, 2016, 01:30:02 am
content: 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.

author: orin
author_rank: Frequent Contributor
timestamp: October 24, 2016, 07:02:32 am
content: Quote from: westfw on October 24, 2016, 01:30:02 amNot 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.

author: Moshly
author_rank: Regular Contributor
timestamp: October 24, 2016, 07:21:04 am
content: There is a talk on youtube about using it to make a pong game ->

author: legacy
author_rank: Super Contributor
timestamp: October 24, 2016, 11:27:38 am
content: Quote from: orin on October 24, 2016, 07:02:32 amI am going to buy my copy for MIPS and 68k

author: rstofer
author_rank: Super Contributor
timestamp: October 24, 2016, 06:11:25 pm
content: 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 24, 2016, 11:57:17 pm
content: Quote from: rstofer on October 24, 2016, 06:11:25 pmThe 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.

author: ale500
author_rank: Frequent Contributor
timestamp: October 25, 2016, 05:35:30 am
content: QuoteWith 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.

author: legacy
author_rank: Super Contributor
timestamp: October 25, 2016, 07:26:34 am
content: Quote from: Bruce Abbott on October 24, 2016, 11:57:17 pmno doubt about itmy TiniJava platfrom comes with a "jump51" meta-assemblerit converts from java-byte-code into 8051 machine codeand ... even Dallas Semiconductors admited that it's a millionlight year away from being able to take any random executableand translate it to another (8051?) platformanyhow, with some (heavy) restrictions ... it works

author: legacy
author_rank: Super Contributor
timestamp: October 25, 2016, 07:43:32 am
content: Quote from: orin on October 24, 2016, 07:02:32 amMips@Irix is supported: excellent

author: C
author_rank: Super Contributor
timestamp: October 25, 2016, 05:05:17 pm
content: Think of what happens with this z80 code in a dissembler.Call a functiona lot of inline data herefunction return is to heremore codethe simple functionpops the return address from stackuses return address as a data pointerwhen done push data pointer on stackreturnA common use was to output a pomp or string.The second problem is a program that relocates some of it's code.

author: vodka
author_rank: Frequent Contributor
timestamp: October 25, 2016, 06:08:40 pm
content: Quote from: C on October 25, 2016, 05:05:17 pmBut 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 25, 2016, 07:40:32 pm
content: Quote from: ale500 on October 25, 2016, 05:35:30 amI 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 anidenticalexecutable 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).

author: timb
author_rank: Super Contributor
timestamp: October 25, 2016, 08:34:21 pm
content: Quote from: Bruce Abbott on October 24, 2016, 11:57:17 pm

author: orin
author_rank: Frequent Contributor
timestamp: October 25, 2016, 09:12:51 pm
content: Quote from: ale500 on October 25, 2016, 05:35:30 amIDA 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).

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 26, 2016, 04:16:39 pm
content: Quote from: timb on October 25, 2016, 08:34:21 pmBut this is not the same as translating an executable compiled for one CPU/OS to run on another as a stand-alone application.RosettaQuoteSo Rosetta translates code from one CPU to another on basically thesameplatform, and only works withsomeapplications (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...QuoteThat 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 somethingreallyimpressive?Here's an 8 bit ATmega1284 running ARM5 Linux.How fast is it?Quote

author: timb
author_rank: Super Contributor
timestamp: October 26, 2016, 08:31:24 pm
content: Quote from: Bruce Abbott on October 26, 2016, 04:16:39 pmWell, 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.