English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 07 June 2010, 19:50   #1
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
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).
absence is offline  
Old 07 June 2010, 20:00   #2
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
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.
Leffmann is offline  
Old 07 June 2010, 20:13   #3
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
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.
absence is offline  
Old 07 June 2010, 20:29   #4
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 40
Posts: 2,330
And failing that of course you could use a 68000 C emulator core (like Starscream) and feed that native code
musashi5150 is offline  
Old 07 June 2010, 20:45   #5
khu
 
Posts: n/a
What Musashi said is exactly what you're looking for.
 
Old 07 June 2010, 21:12   #6
hitchhikr
Registered User

 
Join Date: Jun 2008
Location: somewhere else
Posts: 437
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.
hitchhikr is offline  
Old 07 June 2010, 22:36   #7
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
Quote:
Originally Posted by musashi5150 View Post
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:

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

Code:
asm
asm
C
asm
asm
But if it was converted into this:

Code:
spaghetti C
spaghetti C
spaghetti C
spaghetti C
spaghetti C
I could easily clean up code anywhere.

Quote:
Originally Posted by hitchhikr View Post
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:

Quote:
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.
absence is offline  
Old 08 June 2010, 01:10   #8
hitchhikr
Registered User

 
Join Date: Jun 2008
Location: somewhere else
Posts: 437
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).
hitchhikr is offline  
Old 08 June 2010, 01:36   #9
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
Quote:
Originally Posted by hitchhikr View Post
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.
absence is offline  
Old 08 June 2010, 03:16   #10
Pyromania
Moderator

Pyromania's Avatar
 
Join Date: Jan 2002
Location: Chicago, IL
Posts: 2,741
If it can be done this project would really benefit from it.

http://www.openvideotoaster.org/
Pyromania is offline  
Old 08 June 2010, 11:12   #11
crabfists
Registered User
 
Join Date: Feb 2008
Location: warrington UK
Posts: 105
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.
crabfists is offline  
Old 08 June 2010, 11:33   #12
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
Quote:
Originally Posted by crabfists View Post
Watch out for self modifying code.
Ouch, that would be a problem. How common is such code?
absence is offline  
Old 08 June 2010, 12:16   #13
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
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?
Leffmann is offline  
Old 08 June 2010, 13:43   #14
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
Quote:
Originally Posted by Leffmann View Post
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.

Quote:
Originally Posted by Leffmann View Post
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).
absence is offline  
Old 08 June 2010, 16:39   #15
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,001
Quote:
Originally Posted by absence View Post
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.
phx is offline  
Old 08 June 2010, 18:21   #16
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 47
Posts: 1,796
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.)
Samurai_Crow is offline  
Old 08 June 2010, 18:23   #17
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 363
Quote:
Originally Posted by phx View Post
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.
absence is offline  
Old 08 June 2010, 18:25   #18
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,933
Quote:
Originally Posted by absence View Post
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.
daxb is offline  
Old 08 June 2010, 21:49   #19
kamelito
Zone Friend

kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,426
Quote:
Originally Posted by Leffmann View Post
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
kamelito is offline  
Old 08 June 2010, 22:11   #20
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 50
Posts: 5,775
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.
jotd is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:28.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.14643 seconds with 14 queries