Subject: Re: [RFC] Type of long double on ColdFire
To: ColdFire Mailing List <ColdFire@lists.wildrice.com>
From: Aaron J. Grier <aaron@frye.com>
List: port-m68k
Date: 12/12/2005 11:22:53
On Sat, Dec 10, 2005 at 02:46:01AM +0000, Paul Brook wrote:

> On Saturday 10 December 2005 00:52, Aaron J. Grier wrote:
> > ahh. OK after doing some reading things are a little clearer.
> > could it be switchable?  i386 has -m96bit-long-double and
> > -m128bit-long-double.
> 
> I'm not keen on this idea. IMHO ABI breaking options tend to be of
> very little practical use, especially on targets like Linux and *BSD
> where binaries are expected to be portable between different
> configs/machines. The conversation usually goes something like:
> "I compiled with -mfoo and my program broke"
> "Yes. You also need to recompile the rest of your system/libc with -mfoo"
> "Meh. maybe I'll not bother".

yet changing the size of long double breaks potential ABI compatibility
between coldfire and m68k.

> Well, to be honest m68k and ColdFire are fairly different
> architectures.  The basic instruction format is the same, but the
> supported addressing modes, FPU, MAC, MMU and exception model are all
> different.
>
> There have been suggestions (though AFAIK no actual patches) that 68k
> and ColdFire should actually be two separate gcc ports, rather than
> trying to support them both in the same port.

isn't the MIPS family at a greater level of complexity?  in the ia32
architecture there are similiar issues with SSE/3dnow/etc.

> Running 68k code on ColdFire may be theoretically possible (I haven't
> checked all the details), but it would require trapping and emulating
> a *lot* of instructions.  I wouldn't be surprised if your 200MHz
> ColdFire ends up going slower than your 50MHz 68k. I don't know if
> it's even possible to run ColdFire binaries on a 68k machine.

trapping unsupported instructions is a separate issue from a common 68k
ABI, which issue already exists both in the m68k and coldfire worlds.
v4 with FPU (no matter the long double representation) will have to be
emulated on v3 without FPU.

> The only way to avoid that is to provide the resources (ie.
> programmers or money to hire programmers) to maintain support for the
> "older stuff". whining just irritates the people you want to help you
> :-)

I thought the whole point of the original post was a request for
comments.  I'm commenting.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com