Converting assembly to C

[absence]

Are there any tools that will convert 68000 assembly to C? It doesn't necessarily have to be a fancy decompiler that produces well-written readable code. I'd be happy with a "goto hell" spaghetti conversion as long as the code works (i.e. can be compiled and do exactly the same as the assembly code).

[Leffmann]

Never seen one, but please post if you do find one.

If it's not a lot of code you can convert it to C by hand, otherwise you can assemble it into a separate object file and just link it with the rest of your object files.

[absence]

Assembling to a separate object won't work for me, as the target is cross-platform and not necessarily 68k. Converting by hand is error-prone, and I won't know whether it works or not until I'm done (and if it doesn't, the error could be anywhere). It would be nicer to have some already working, but dirty, C code, which I can clean up step by step while periodically running it to make sure I'm not breaking anything.

It will obviously only work for the "business logic" code, and the part that writes to the hardware registers will have to be hand converted to some other API. But it would be SOME help at least.

[musashi5150]

And failing that of course you could use a 68000 C emulator core (like Starscream) and feed that native code

What Musashi said is exactly what you're looking for.

[hitchhikr]

A better solution: using a custom assembler to convert 68k mnemonics into commands for a small virtual machine:

http://www.atien.net/?static2/frontier
http://tom.noflag.org.uk/glfrontier.html

The best solution would be to have an assembler directly converting into target machine native opcodes (from a fully working asm source code, of course).

[absence]

Originally Posted by musashi5150

And failing that of course you could use a 68000 C emulator core (like Starscream) and feed that native code

Would I be able to clean up the code piece by piece that way? For example, if I have:

asm
asm
asm
asm
asm

I can't imagine it's easy to clean up a section in the middle like this:

asm
asm
C
asm
asm

But if it was converted into this:

spaghetti C
spaghetti C
spaghetti C
spaghetti C
spaghetti C

I could easily clean up code anywhere.

Originally Posted by hitchhikr

A better solution: using a custom assembler to convert 68k mnemonics into commands for a small virtual machine:

http://www.atien.net/?static2/frontier
http://tom.noflag.org.uk/glfrontier.html

The best solution would be to have an assembler directly converting into target machine native opcodes (from a fully working asm source code, of course).

That is not the best solution, as one would have to implement back-ends for all the wanted target platforms. If the custom assembler converts to C instead, the code can be compiled for any platform using the appropriate compiler. Interestingly, this is indeed what the code you linked to does, according to README:

FrontVM2 has discarded the uae cpu core of hatari and instead compiles the
frontier 68k crap to native assembly language. This is done either by generating
a grotesquely huge C source file, or generating i386 asm directly.

I'll have a closer look, thanks for the heads-up.

[hitchhikr]

I only checked frontier1337, a virtual machine is used for this one.

Using a converter to Asm or C is better of course. But depending on the target processor: outputting to (ugly) C may not be the best solution for speed considerations as the code will probably be much smaller when recompiled (in that case output functions specific for the target processor would be best & a backend (like a SDL one) would need to be rewritten anyway) of course it shouldn't matter that much if the output of the conversion is for x86 processors.

The only semi decent asm to C i've seen is HexRays' one which only convert 32 bit x86 to C (and it's a heavy process).

[absence]

Originally Posted by hitchhikr

outputting to (ugly) C may not be the best solution for speed considerations

Speed is not important, as the ugly generated C is only to help me rewrite the code to pretty C++ without (hopefully) introducing bugs in the process, due to the ability to test everything as I progress. When I'm done, there will be none of the ugly generated C left.

[Pyromania]

If it can be done this project would really benefit from it.

http://www.openvideotoaster.org/

[crabfists]

I was thinking about doing something like this at one point for Z80 and 68000 but I never got anywhere with it.

Watch out for self modifying code.

[absence]

Originally Posted by crabfists

Watch out for self modifying code.

Ouch, that would be a problem. How common is such code?

[Leffmann]

What crabfists pointed out got me thinking that at some point one might have to either emulate the entire environment the code is supposed to be run in, or reverse engineer it to catch things like SMC and less obvious hardware accesses in order to fully understand what the code does, and reimplement it from scratch in another language.

It depends on how much the code deviates from a sort of ideal case where it takes two pointers to input data and where the output is supposed to go. In the case of reimplementing the code I'm not even sure it's easier to work from a messy C translation than the original 68K code.

Out of curiosity, what game/app are you looking to convert and how much code is it?

[absence]

Originally Posted by Leffmann

In the case of reimplementing the code I'm not even sure it's easier to work from a messy C translation than the original 68K code.

Disassembling code you don't quite understand what does can be daunting, and the idea is that reimplementing a small piece here and a small piece there will make it easier to grasp the bigger picture. It may not be easier to work from the messy C translation, but at least it will run alongside the partially reimplemented code and make it easier to see when something breaks because the reimplementation deviates from the original code.

Another possibility could be to use an old Amiga C compiler, insert all the code as inline assembler, and work on it that way. Could a non-DOS game run that way without major changes by just calling the inline asm from main()? Non-DOS games would be harder, but maybe a WHDLoad slave could help. What would be the best compiler for this? I just remember some names from back in the days, like SAS, DICE, Lattice, but I have no experience with writing C on Amiga. I seem to recall there's an abandoned GCC port as well, but its different syntax could be a problem unless Resource supports it.

Originally Posted by Leffmann

Out of curiosity, what game/app are you looking to convert and how much code is it?

I worked on Turboraketti a while ago, but haven't had time to finnish it. As I have gotten quite far it's probably not worth it to start over with a new method, but once/if I finnish it, I'll probably have a look at Gravity Force 2 (or Gravity Power as the later coverdisk version was called).

[phx]

Originally Posted by absence

Another possibility could be to use an old Amiga C compiler, insert all the code as inline assembler, and work on it that way.

Hmm... if I understand you correctly, then there is an even better approach, called linker!

Just reassemble the whole program which you want to port to C. Then you can start to rewrite parts from it in C, remove this part from the 68k source and link the remaining assembler object with your C object. This way you can easily control whether your new code works as it should.

[Samurai_Crow]

I wish the LibCPU.org team could hurry up with their optimizing cross-assembler. Then you could use the LLVM C backend or C++ backend to produce your code. If you need something for a processor that exists as a backend already, just use that backend instead.

I'd like to see something like LibCPU happen in the future so that we could use the slow and currently experimental PBQP register scheduler to produce more efficient code than what was put into it. (A PBQP scheduler can stuff things into partial registers and switch between them when it is efficient to do so.)

[absence]

Originally Posted by phx

Hmm... if I understand you correctly, then there is an even better approach, called linker!

I thought about that, and it would be quite appropriate for rewriting entire subroutines at once. For code that isn't well-organised, however, I would have to move every chunk of assembly I want to reimplement into a separate subroutine. It's doable, but a lot of extra work that can get messy real fast if there's lots of data to pass around. I'd rather go with inline assembler as long as it's easy to mix assembly and C the way I want to.

[daxb]

Originally Posted by absence

I worked on Turboraketti a while ago, but haven't had time to finnish it.

Yeah, Turboraketti! One of my favourite games ever. At least it needs an WDHLoad slave.

[kamelito]

Originally Posted by Leffmann

Never seen one, but please post if you do find one.

If it's not a lot of code you can convert it to C by hand, otherwise you can assemble it into a separate object file and just link it with the rest of your object files.

This tools does it but its a commercial product.

http://www.microapl.co.uk/asm2c/index.html
Kamel

[jotd]

relogix looks interesting.
There's no simple way to simply port assembler to C because of the bra/jmp and bsr/jsr. C goto can only jump in the current procedure. You'd have to sort out local bra's and global bra's. Even harder: if there are internal bsr's you're screwed.

That's a reality for all assemblers not only 68000.

I have done some asm 2 C conversion (using awk ) to create a portable version of fimp (ATN!/Imploder) cruncher from 68000 Code I did not understand a bit:

http://pagesperso-orange.fr/jotd/misc/fimp_c.zip

Here's a short example of my macro-based C code (full source available in the .zip file above):

void do_implode()
{
// implode:

// In: a0.l=*buffer
// d0.l=data length
// d1.l=crunch mode

// Out: d0.l=<0:user break

A[7] -= 44; // pre
MOVEM_D_IND(252,124,A[7],4);
MOVEQ_IMM_D(0x57,D[2],4);
IM01:
A[7] -= 2; // pre
CLR_IND(A[7],2);
DBF(D[2],IM01);
MOVEA_D_D(A[7],A[6],4);
// move.l a5,2(a6)
CMP_IMM_D(0x40,D[0],4);
BLO(IM23);
LSR_IMM_D(8,D[1],4);
SCS_IND(A[6]); // size 1
LSR_IMM_D(8,D[1],4);
CMP_IMM_D(12,D[1],1);
BLO(IM02);
MOVEQ_IMM_D(0,D[1],4);
...

The code was then embedded in a dll and used in Superfrog custom editor by Exl.
Well this cannot be applied to big asm sources. I wonder how relogix would behave if we feeded it the asm file from Chaos Engine

I also converted whole 6502 games to C (Oric games). But most of the time you have to move/rearrange code so far branches become function_call() + return when out of the current procedure or when there was some spaghetti code with lots of bsr without any procedural logic
Well, it took a few hours to sort this out, and compilation errors help you all the way.

However if the code was originally C or C++, it is possible to recognise the compiler patterns and recreate the original program structure (and there are less bra/bsr problems!). Relogix should work optimally in that case.