Dwayne Dietrich

Type of long double on ColdFire

Discussion created by Dwayne Dietrich Employee on Apr 1, 2006
Latest reply on Apr 1, 2006 by Dwayne Dietrich
Dec 8, 2005, 8:19 AM
Post #1 of 14 (373 views)
Copy Shortcut
 [ColdFire] [RFC] Type of long double on ColdFire  Can't Post 
--------------------------------------------------------------------------------
 
We (CodeSourcery) currently working on developing ColdFire targeted GNU
toolchains (gcc, etc).
Currently gcc nominally uses a 12-byte "extended" precision type for the C
"long double" floating point type. This is inherited from the m68k gcc port,
but doesn't really make a whole lot of sense for ColdFire. It's also broken.
The ColdFire FPU only has 64-bit registers, and the current gcc soft-float
routines are just wrappers round the 64-bit "double" routines.
So, we're proposing changing long double to be something more sensible. There
are two options:
1) Make long double == double. This is what Arm does, amongst others. This
pretty much just works and should reduce the amount of support code required.
Anyone wanting more than IEEE double precision has to use a third party
bugnum/MP/quad library of which there are several, but no standard ABI.
2) Choose a sensible format for long double. The obvious candidate is a
128-bit PPC/MIPS stye almost-quad precision type implemented with a pair of
64-bit doubles. This provides a higher precision type for those that want it
at the expense of additional complexity and support code for those that
don't.
This email is a RFC to try and gauge which of the two options is most useful
to the ColdFire community. ie. are there significant users that would benefit
from (2).
Also if there's anyone who really wants to keep the existing long double we'd
like to hear from you, and why you think it should be kept.
Paul
--------------------------------------------------------------------
Dec 8, 2005, 9:15 AM
Post #2 of 14 (373 views)
Copy Shortcut
 Re: [ColdFire] [RFC] Type of long double on ColdFire [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
I can't speak for the rest of the community, but we don't (currently)
require the extra precision of long double. Making long double = double
would be OK with us.
Paul Brook wrote:
>This email is a RFC to try and gauge which of the two options is most useful
>to the ColdFire community. ie. are there significant users that would benefit
>from (2).
>
>Also if there's anyone who really wants to keep the existing long double we'd
>like to hear from you, and why you think it should be kept.
>
>Paul
>--------------------------------------------------------------------
--
Brett Swimley
Sr. Design Engineer
Advanced Electronic Designs
406-585-8892
brett DOT swimley AT aedinc DOT net

--------------------------------------------------------------------
Dec 9, 2005, 12:00 AM
Post #3 of 14 (373 views)
Copy Shortcut
 Re: [ColdFire] [RFC] Type of long double on ColdFire [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
> We (CodeSourcery) currently working on developing ColdFire targeted GNU
> toolchains (gcc, etc).
>
> Currently gcc nominally uses a 12-byte "extended" precision type for the C
> "long double" floating point type. This is inherited from the m68k gcc
port,
> but doesn't really make a whole lot of sense for ColdFire. It's also
broken.
> The ColdFire FPU only has 64-bit registers, and the current gcc soft-float
> routines are just wrappers round the 64-bit "double" routines.
>
> So, we're proposing changing long double to be something more sensible.
There
> are two options:
>
> 1) Make long double == double. This is what Arm does, amongst others. This
> pretty much just works and should reduce the amount of support code
required.
> Anyone wanting more than IEEE double precision has to use a third party
> bugnum/MP/quad library of which there are several, but no standard ABI.
>
That would certainly seem the most sensible solution. It is, I think, rare
for embedded systems to need more than double precision (it's only a
minority that need any kind of floating point at all), and any system that
does is unlikely to be using a ColdFire. 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.
mvh.,
David

> 2) Choose a sensible format for long double. The obvious candidate is a
> 128-bit PPC/MIPS stye almost-quad precision type implemented with a pair
of
> 64-bit doubles. This provides a higher precision type for those that want
it
> at the expense of additional complexity and support code for those that
> don't.
>
> This email is a RFC to try and gauge which of the two options is most
useful
> to the ColdFire community. ie. are there significant users that would
benefit
> from (2).
>
> Also if there's anyone who really wants to keep the existing long double
we'd
> like to hear from you, and why you think it should be kept.
>
> Paul
> --------------------------------------------------------------------
 
--------------------------------------------------------------------
Dec 9, 2005, 2:16 AM
Post #4 of 14 (373 views)
Copy Shortcut
 Re: [ColdFire] [RFC] Type of long double on ColdFire [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
>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.
IMHO such assumptions are most dangerous. a few might require to operate "old mac's", whatever equipment, for whatever reason. subtract the multimedia, and old systems are operational any time.
imagine this: some programs do not do very much, just they require the newest version of OS/ OS ROMS's, ironically to provide "help systems" supporting graphical images etc. not too required if just one little file to create/edit, even to type in a 5 letter file name manually.
guess i am one who notices missing support (though i do not operate old mac's). now i made a 19 year old wordprocessor working (the manual says it is not a wordprocessor), it origins from CP/M and does not have any fonts and such things.
-alex-
know a superstition? (i urgently need a table of lucky numbers, and why)

---------------------------------
Dec 9, 2005, 4:40 AM
Post #5 of 14 (373 views)
Copy Shortcut
 Re: [ColdFire] [RFC] Type of long double on ColdFire [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
 
> >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.
>
> IMHO such assumptions are most dangerous. a few might require to operate
"old mac's", whatever equipment, for whatever reason. subtract the
multimedia, and old systems are operational any time.
>
It is certainly likely that there will be old systems out there that need
12-byte double support. But do they need the latest versions of the
ColdFire compiler? An old system will use an old version of the compiler
and tools - you don't change toolchains in an existing system without good
reason and lots of checking, and one of the big advantages of gcc is that
you can always get hold of old versions when you need them.
The issue is whether there is likely to be the need for 12-byte (or 16-byte)
doubles on ColdFires in the future, and whether there is existing code that
is in active use and likely to be compiled on new versions of the compilers.
mvh.,
David
 
> imagine this: some programs do not do very much, just they require the
newest version of OS/ OS ROMS's, ironically to provide "help systems"
supporting graphical images etc. not too required if just one little file to
create/edit, even to type in a 5 letter file name manually.
>
> guess i am one who notices missing support (though i do not operate old
mac's). now i made a 19 year old wordprocessor working (the manual says it
is not a wordprocessor), it origins from CP/M and does not have any fonts
and such things.
>
> -alex-
> know a superstition? (i urgently need a table of lucky numbers, and why)
>
>
 
--------------------------------------------------------------------
Dec 9, 2005, 4:55 AM
Post #6 of 14 (373 views)
Copy Shortcut
 RE: [ColdFire] [RFC] Type of long double on ColdFire [In reply to]  Can't Post 
--------------------------------------------------------------------------------
 
Hi,
We use doubles extensively, in a 68040, but nothing longer than 64 bit
doubles. I don't see any need for anything longer, either.
Good luck,
Charlie Kupelian
Bldg F-10
Wallops Flight Facility
Wallops Island VA 23337

-----Original Message-----
On Behalf Of David Brown
Sent: Friday, December 09, 2005 3:01 AM
To: Kupelian Charlie
Subject: Re: [ColdFire] [RFC] Type of long double on ColdFire
> We (CodeSourcery) currently working on developing ColdFire targeted
> GNU toolchains (gcc, etc).
>
> Currently gcc nominally uses a 12-byte "extended" precision type for
> the C "long double" floating point type. This is inherited from the
> m68k gcc
port,
> but doesn't really make a whole lot of sense for ColdFire. It's also
broken.
> The ColdFire FPU only has 64-bit registers, and the current gcc
> soft-float routines are just wrappers round the 64-bit "double"
routines.
>
> So, we're proposing changing long double to be something more
sensible.
There
> are two options:
>
> 1) Make long double == double. This is what Arm does, amongst others.
> This pretty much just works and should reduce the amount of support
> code
required.
> Anyone wanting more than IEEE double precision has to use a third
> party bugnum/MP/quad library of which there are several, but no
standard ABI.
>
That would certainly seem the most sensible solution. It is, I think,
rare for embedded systems to need more than double precision (it's only
a minority that need any kind of floating point at all), and any system
that does is unlikely to be using a ColdFire. 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.
mvh.,
David

> 2) Choose a sensible format for long double. The obvious candidate is
> a 128-bit PPC/MIPS stye almost-quad precision type implemented with a
> pair
of
> 64-bit doubles. This provides a higher precision type for those that
> want
it
> at the expense of additional complexity and support code for those
> that don't.
>
> This email is a RFC to try and gauge which of the two options is most
useful
> to the ColdFire community. ie. are there significant users that would
benefit
> from (2).
>
> Also if there's anyone who really wants to keep the existing long
> double
we'd
> like to hear from you, and why you think it should be kept.
>
> Paul
> --------------------------------------------------------------------

 
 
 

Message Edited by Dietrich on 04-04-2006 09:11 PM

Outcomes