Vision native for coldfire

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

JeanMars
Atari maniac
Atari maniac
Posts: 90
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Vision native for coldfire

Postby JeanMars » Sat Dec 15, 2018 11:01 am

Hi all,

In order to improve VISION's speed for firebee, it has to be compiled for coldfire. VISION is now compiled by purec.
2 options:
Port it to gcc: will be pretty tricky because of int/short adaptations and assembly differences
Port it to ahcc: should be easier, but probably some adaptations in assembly code are required as some pure 680x0 instructions maybe missing in coldfire.

Can someone skilled in ahcc have a look at this and at least estimate effort and define a plan? I'm afraid i can't allocate time on my own to work on this.

Thanks, Jean

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1830
Joined: Sun Jul 31, 2011 1:11 pm

Re: Vision native for coldfire

Postby Eero Tamminen » Sun Dec 16, 2018 12:19 am

I think for AHCC one just needs to update Pure-C PRJ project files a bit, to use suitable compile flags ("-7") and libs (ones which have extra "f" or "fi" at end). This is assuming one doesn't bump into any AHCC bugs.

However, if there's also assembly code in addition to C, that can be a lot of extra work. There's PortAsm/68K for ColdFire tool from MicroAPL, but it can't convert everything: http://www.microapl.co.uk/Porting/ColdF ... nload.html

vido
Atari Super Hero
Atari Super Hero
Posts: 631
Joined: Mon Jan 31, 2011 7:39 pm

Re: Vision native for coldfire

Postby vido » Sun Dec 16, 2018 7:58 am

Vision is working on the FireBee but due to emulation of the unsupported commands it is slow. Any improvement would be welcome even if not fully. I gues that could go step by step if it is to much to do it at once.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 493
Joined: Sun Aug 03, 2014 5:54 pm

Re: Vision native for coldfire

Postby ThorstenOtto » Sun Dec 16, 2018 8:03 am

vido wrote:I gues that could go step by step if it is to much to do it at once.


As long as there are parts of the program that are not translated, you would still have to run it in the emulator, so that might work, but you won't notice any speed difference.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 493
Joined: Sun Aug 03, 2014 5:54 pm

Re: Vision native for coldfire

Postby ThorstenOtto » Sun Dec 16, 2018 8:14 am

Eero Tamminen wrote:This is assuming one doesn't bump into any AHCC bugs.


Thats why i would not recommend using AHCC, i would not trust a compiler whos developer thinks he can use the same library for 32bit ints by just changing the header files. Also, AHCC has the problem that it has no (soft-)floating point support for plain 68k targets.

i would suggest to try using gcc. Only drawback there are the assembler sources which have to be converted (~200 K if i didn't miss anything).

vido
Atari Super Hero
Atari Super Hero
Posts: 631
Joined: Mon Jan 31, 2011 7:39 pm

Re: Vision native for coldfire

Postby vido » Sun Dec 16, 2018 8:22 am

ThorstenOtto wrote:
vido wrote:I gues that could go step by step if it is to much to do it at once.


As long as there are parts of the program that are not translated, you would still have to run it in the emulator, so that might work, but you won't notice any speed difference.

Vision is not running in the emulator! Only commands which are not supported by Coldfire are trapped and emulated. So less such commands are the less is to be emulated = code executes faster.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1830
Joined: Sun Jul 31, 2011 1:11 pm

Re: Vision native for coldfire

Postby Eero Tamminen » Sun Dec 16, 2018 12:17 pm

ThorstenOtto wrote:
Eero Tamminen wrote:This is assuming one doesn't bump into any AHCC bugs.


Thats why i would not recommend using AHCC, i would not trust a compiler whos developer thinks he can use the same library for 32bit ints by just changing the header files. Also, AHCC has the problem that it has no (soft-)floating point support for plain 68k targets.

i would suggest to try using gcc. Only drawback there are the assembler sources which have to be converted (~200 K if i didn't miss anything).


While AHCC 32-bit support is bad, and it doesn't support softfloat for 68000, I don't think those issues to be applicable to Pure-C m68k -> CF AHCC port. One anyway needs separate PRJ files for CF, so 68k ones can still be using Pure-C, and AHCC used only for CF.

Converting Pure-C code to GCC can be a *lot* of work (I've done couple of such conversions, and I remember it being mass of work. Admittedly I also did lot of cleanups and 16-bit -> 32-bit support though). AHCC is designed to be Pure-C compatible, so it "should" work fine.

IMHO good reason would be taking advantage of GCC optimizations and much better error checking (which wouldn't be there without those optimization passes). AHCC doesn't really optimize the code, so GCC can provide significant speedup for some parts of the C-code, but one may need to improve the code a bit for that (e.g. use static where appropriate to limit symbol scope).


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests