From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: gcc@gcc.gnu.org
Subject: Re: Supporting decimal float on additional platforms
Date: Fri, 20 Nov 2009 21:53:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.0911202131340.4910@digraph.polyomino.org.uk> (raw)
In-Reply-To: <yddbpiwubsk.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
On Fri, 20 Nov 2009, Rainer Orth wrote:
> > Much the same applies if anyone wishes to add fixed point (TR 18037)
> > support for more targets.
>
> I'll have a look at the last draft (N1169) for now. Right now, only
> MIPS support is in GCC, so there seems to be less traction so far.
Each of these extensions is aimed at a specific class of programs, and
users of such programs are much more likely to use some processors than
others - various embedded processors have fixed point instructions of one
form or another (not necessarily all mapping neatly to the TR 18037
types), while some Power and S390 processors have hardware support for
decimal floating point.
The TRs may eventually result in those classes of programs becoming more
portable, in which case people might eventually want to include free
software using these extensions in general-purpose operating system
distributions - which may drive porting the feature as people wish to
build those distributions for many different processors - but the limited
application domains for these features seem likely to exacerbate the
chicken-and-egg effect that applies to any new language feature (no demand
for the feature in compilers without applications using it, no
applications using it without compilers implementing it). Implementing a
feature without having any applications for it is of course one way of
addressing that effect, as is implementing a feature you'd like to use
yourself in programs you write in future; it seems a fine improvement to
the compiler to contribute as long as you work with any ABI maintainers to
avoid it causing future compatibility problems.
(Though I made decimal floating point work on e500 processors - to
eliminate the test failures seen in such configurations given that it's
enabled by default for Power GNU/Linux and already worked for other Power
processors - it's quite possible that no-one has ever used that
functionality other than for testcases. There were no ABI compatibility
issues there since e500 uses the same ABI as soft-float Power processors.)
Note that the fixed point implementation for MIPS substantially slows down
the build of libgcc for MIPS targets because of a huge number of libgcc
functions for fixed point that need to be built, so people may not care
for their libgcc builds being slowed down for other targets without any
applications for the new feature.
--
Joseph S. Myers
joseph@codesourcery.com
prev parent reply other threads:[~2009-11-20 21:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 18:20 Rainer Orth
2009-11-18 19:20 ` Janis Johnson
2009-11-20 21:12 ` Rainer Orth
2009-11-18 20:08 ` Joseph S. Myers
2009-11-20 21:28 ` Rainer Orth
2009-11-20 21:53 ` Joseph S. Myers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0911202131340.4910@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).