This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Processor-specific code
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Richard Earnshaw'" <rearnsha at gcc dot gnu dot org>,"'Robert Dewar'" <dewar at adacore dot com>
- Cc: "'Richard Henderson'" <rth at redhat dot com>,'François-Xavier Coudert' <Francois-Xavier dot Coudert at lcp dot u-psud dot fr>,"'Steve Kargl'" <sgk at troutmask dot apl dot washington dot edu>,<fortran at gcc dot gnu dot org>,<gcc at gcc dot gnu dot org>
- Date: Fri, 15 Apr 2005 17:49:07 +0100
- Subject: RE: Processor-specific code
----Original Message----
>From: Richard Earnshaw
>Sent: 15 April 2005 17:42
> On Fri, 2005-04-15 at 15:50, Robert Dewar wrote:
>> Richard Earnshaw wrote:
>>
>>> Not all environments can change the rounding mode dynamically. For
>>> example, on the FPA co-processor for ARM, rounding is set by the
>>> instruction selected -- so the concept of having an environment variable
>>> to control this is meaningless.
>>
>> Right, such a feature obviously does not apply to hardware that is this
>> far from the IEEE standard (which requires dynamic control). The Alpha
>> architecture has similar problems.
>
> Precisely which statement in IEEE 754-1985 states this? As far as I can
> tell this standard is a mathematical abstraction for mapping floating
> point onto machine types. Chapter 4 describes the required rounding
> modes but definitely makes no statement saying that this has to be
> selectable in a dynamic manner.
>
> R.
Doesn't the C language spec require the mode to be switchable at runtime?
In any case, the ARM or Alpha isn't prevented from working in such a
fashion just because the rounding mode is encoded in the instruction; it
just means that fp primitives have to be compiled as intrinsics that test
whatever flag controls the rounding mode and then branch to an fp insn of
the appropriate form.
cheers,
DaveK
--
Can't think of a witty .sigline today....