Re: [MiNT] Sparemint Coldfire

[Paul Wratt <paul.wratt@gmail.com>]

2010/1/8 Vincent Rivière <vincent.riviere@freesbee.fr>:
> Paul Wratt wrote:
>>
>> this looks like a good way to go, presuming that v4e does not need any
>> patches applied to source, or is that the point of the previous
>> comments, that it still needs minimal patching (compared to other 68k
>> variant output).
>>
>> BTW: why is there still a need to patch is the source is C/C++, wasn't
>> that the point of another discussion re: ASM. I do however understand
>> the need to patch for GCC 4.x "strictness" due to the age of
>> sources...
>
> Here are the facts.
>
> 1) Older sources have *sometimes* to be patched for GCC 4.x "strictness".
> There are usually no GCC problem with up-to-date open-source programs.
> Sometimes the makefiles have to be revised a bit, too.
>
> 2) A C program that compiles well with GCC 4.x for 68000 will compile
> equally well for ColdFire. You just have to have the required libraries for
> ColdFire, and add the option -mcpu=5475 to the gcc command line. It worked
> flawlessly with all the few packages I have compiled an run on ColdFire.
>
> 3) Software fully or partially written in assembly will require manual
> patching to be 100% ColdFire. It is usually quite simple for user programs
> (as I did in the MiNTLib), but it is sometimes a bit tricky in OS software
> (as I did for EmuTOS).
>
> Most Linux open-source software are written in C only, there will be no
> problem to get them work fully optimized on ColdFire.
>
> Due to speed issues, traditional Atari software have often some parts
> written in assembly, if not all. They will require some more or less easy
> patching to be 100 ColdFire optimized. However it is not a big issue, since
> the the Atari ColdFire OS will embed a lightweight 68000 emulation. Thanks
> to the speed of the ColdFire, there will be no performance issue.
>
> So the big problem is not rebuilding the whole SpareMiNT archive for
> ColdFire, it is rebuilding it with GCC 4.x.
> If we fix each package one after each other, there will be no problem. And
> if they are committed.
>
> --
> Vincent Rivière
>
ta, thanks, more good general knowledge, hell I'll be able to write a
compact gcc 5 at this rate :)

on the ASM thing, I have a package I was going to port to help solve
the problem of cross architecture, High Level Assembler, to help in
getting mint to be used as a proto-typing platform

however if this gcc speed and size thing continues on its current
trend not even a clean boot AFROS LiveCD will provide fast enough
native compilation.

However I had not excluded placing cross-compilers with the next
AFROS-update and was going to with any FuDE for AFROS anyway, so some
of these other options, like Eeros SB v1 & v2 post will now be part of
that, to provide more options, but documented, and already setup in
extractable form.

BTW, any patches done on RPM builds, they can work with changes for
Gentoo right? (I used a Gentoo patch to get Zoo to compile on my
Mandriva based distro)

Paul