07 June 2010, 19:50 | #1 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Converting assembly to C
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).
|
07 June 2010, 20:00 | #2 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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. |
07 June 2010, 20:13 | #3 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
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. |
07 June 2010, 20:29 | #4 |
move.w #$4489,$dff07e
Join Date: Sep 2005
Location: Norfolk, UK
Age: 43
Posts: 2,351
|
And failing that of course you could use a 68000 C emulator core (like Starscream) and feed that native code
|
07 June 2010, 20:45 | #5 |
Posts: n/a
|
What Musashi said is exactly what you're looking for.
|
07 June 2010, 21:12 | #6 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 524
|
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). Last edited by hitchhikr; 07 June 2010 at 21:18. |
07 June 2010, 22:36 | #7 | |||
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Quote:
Code:
asm asm asm asm asm Code:
asm asm C asm asm Code:
spaghetti C spaghetti C spaghetti C spaghetti C spaghetti C Quote:
Quote:
|
|||
08 June 2010, 01:10 | #8 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 524
|
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). |
08 June 2010, 01:36 | #9 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
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.
|
08 June 2010, 03:16 | #10 |
Moderator
Join Date: Jan 2002
Location: Chicago, IL
Posts: 3,392
|
|
08 June 2010, 11:12 | #11 |
Registered User
Join Date: Feb 2008
Location: warrington UK
Posts: 118
|
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. |
08 June 2010, 11:33 | #12 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
|
08 June 2010, 12:16 | #13 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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? |
08 June 2010, 13:43 | #14 | |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Quote:
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. 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). |
|
08 June 2010, 16:39 | #15 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,545
|
Quote:
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. |
|
08 June 2010, 18:21 | #16 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
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.) |
08 June 2010, 18:23 | #17 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
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.
|
08 June 2010, 18:25 | #18 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,307
|
|
08 June 2010, 21:49 | #19 | |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,847
|
Quote:
http://www.microapl.co.uk/asm2c/index.html Kamel |
|
08 June 2010, 22:11 | #20 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,370
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Assembly reference | bobster | Coders. Tutorials | 1 | 20 March 2013 23:16 |
Assembly and bsdsocket_lib.i | fuzzylogic | Coders. General | 2 | 29 February 2012 14:45 |
A1200 and assembly language | aricz | Coders. General | 16 | 08 February 2011 12:31 |
RawDoFmt() in Assembly | redblade | Coders. General | 6 | 02 June 2009 14:25 |
assembly TV | L8-X | Amiga scene | 2 | 04 August 2002 02:36 |
|
|