Subject: Re: [RFC] Type of long double on ColdFire
To: ColdFire Mailing List <ColdFire@lists.wildrice.com>
From: Aaron J. Grier <email@example.com>
Date: 12/09/2005 16:52:07
On Fri, Dec 09, 2005 at 07:32:38PM +0000, Paul Brook wrote:
> On Friday 09 December 2005 18:07, Aaron J. Grier wrote:
> > On Fri, Dec 09, 2005 at 09:00:32AM +0100, David Brown wrote:
> > > The only reason I can think of for having longer doubles in the
> > > m68k gcc port is for older Macs, and I'd be doubtful if removing
> > > support would be noticed by anyone.
> > I'm sure the m68k hackers running NetBSD would...
> I'm not suggesting changing the m68k definition of long double, only
ahh. OK after doing some reading things are a little clearer.
could it be switchable? i386 has -m96bit-long-double and
> AFAIK NetBSD doesn't support ColdFire, and even if it did, it would be
> separate from the existing m68k port. Am I missing something?
NetBSD has separate kernel ports for the various 68k machines, but they
are binary compatible at the application level. if I had a v4 eval
board with FPU at home, I'd certainly be attempting a port, if for no
other reason than to do bulkbuilds of 68k binaries at 200+MHz rather
in general I'm a bit grumpy about the current orthagonal-ness of
coldfire support being added to gcc without updating support for
existing 68k processors. I'd like to see a common 68k target that would
be least-common-denominator compatible across all 68k and coldfire
variants, not for any particular application, but as a proof-of-concept
that the changes being made to gcc are portable across the various 68k
implementations, and that necessary flexibility to handle the variants
is being built-in rather than bolted-on.
I realize I'm in the minority in this. I've heard a lot of whining from
Bernie and Peter on this point, but I still see it as an issue that
needs a better answer than "nobody uses the old stuff, just ignore it"
which leaves gcc support for older (still shipping!) 68k processors
stagnant, and I'd hate to see the same thing being repeated in the
future. (oh, nobody uses v2 cores anymore...)
for better or worse, Motorola didn't provide full backwards
compatibility in the 68k line, and while the coldfire series seems to
have improved in that respect, we now have MMU, eMAC, and FPU extentions
on newer coldfire cores... if these variants can be handled surely these
mechanisms can be integrated with the older CPUs too. who's to say that
freescale doesn't decide to add 96-bit extended precision floating point
into the FPU at a future date?
Aaron J. Grier | Frye Electronics, Tigard, OR | firstname.lastname@example.org