Paul Koning <[EMAIL PROTECTED]> writes: > >>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> ----Original Message---- > >> From: Paul Koning Sent: 15 April 2005 17:56 > > >>>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> 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.
