On Monday 12 December 2005 19:22, Aaron J. Grier wrote:
> 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.
>...
> 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.

Ok, let me ask a different question.
Do you think m68k and Coldfire are the same architecture?
Do you expect the be able to link together (and run) a mixture of ColdFire and 
m68k code in a single binary?

It was my impression that while there are many similarities, the two 
instruction sets are sufficiently different (especially when you include the 
FPU) that they are not interchangeable.

If they are effectively different architectures (ie. mixing the two never 
happens) then whats the point having ABI compatibility?

As an example x86-64 and i386 are very similar instruction sets. However you 
can't mix the two in the same application, so there's no point having a 
common ABI.

Paul