Re: Processor-specific code

[Geoffrey Keating <geoffk at geoffk dot org>]

Paul Koning <pkoning@equallogic.com> writes:

> >>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes:
> 
>  Dave> ----Original Message----
>  >> From: Paul Koning Sent: 15 April 2005 17:56
> 
>  >>>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes:
>  >>
>  Dave> Doesn't the C language spec require the mode to be switchable
>  Dave> at runtime?
>  >>
>  Dave> In any case, the ARM or Alpha isn't prevented from working in
>  Dave> such a fashion just because the rounding mode is encoded in the
>  Dave> instruction; it just means that fp primitives have to be
>  Dave> compiled as intrinsics that test whatever flag controls the
>  Dave> rounding mode and then branch to an fp insn of the appropriate
>  Dave> form.
>  >> That only works if the notion of switchable rounding mode exists.
> 
>  Dave> I'm not sure.  Either you don't get me, or I don't get you, but
>  Dave> what I thought I was describing was a way of working around the
>  Dave> lack of a switchable mode by compiling the code both ways with
>  Dave> a runtime test of a flag.
> 
> Sorry, poor wording.  
> 
> What I meant is that those architectures do floating point in exactly
> one way.  You have NO way to say what kind of rounding you want, not
> by a settable state, not by a different opcode -- not at all.

Those architectures simply don't support other rounding modes; they
would define only FE_TONEAREST (or whatever rounding mode is suitable)
and compile fesetround() into a no-op.