RE: Processor-specific code

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Fri, 2005-04-15 at 17:49, Dave Korn wrote:
> ----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.

c90 doesn't require anything; it's all new in c99.

C99 has a number of functions and defines a number of macros *iff* the
environment supports rounding switching.  It certainly doesn't require
it.

Code that changes the rounding has to be wrapped with certain pragmas to
inform the compiler that this might happen: on something like ARM+FPA
that might permit dynamic code switching, but I doubt anyone would
really want to pay that price.

R.