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>
- Cc: "'Robert Dewar'" <dewar at adacore dot com>,"'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 18:21:07 +0100
- Subject: RE: Processor-specific code
----Original Message----
>From: Richard Earnshaw
>Sent: 15 April 2005 18:08
>> 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.
> 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.
It's a very arch-dependent price, though. On an arch where you have
conditional execution per-instruction, it could be a very low overhead
indeed.
cheers,
DaveK
--
Can't think of a witty .sigline today....