Porposal: Floating-Point Options

[Marcin Dalecki]

On 2005-06-15, at 13:50, Scott Robert Ladd wrote:
>
> Perhaps my understanding of math isn't as elite as yours, but I do  
> know
> that "worser" isn't a word. ;)

Please bear with me. English is my 3th foreign language.

>> Only the following options would make sense:
>>
>> 1. An option to declare 100% IEEE compatibility if possible at all on
>>  the particular arch, since it's a well known reference.
>>
>> 2. An option to declare 100% FPU architecture exposure.
>>
>> 3. A set of highly target dependent options to control some well
>> defined features of a particular architecture. (Rounding mode,
>> controll, use of MMX or SSE[1234567] for example...)
>>
>
> I would replace 3 above with:
>
> 3. When compiled without either of the above options, adhere  
> strictly to
> the relevant language standard.
>
> Given that Java, Fortran 95, C and C++ all have differences in their
> definitions of floating-point, this will need to be (as it already is,
> to some extent) language-specific.

You should always place Java last in discussions about numerical work.
It's largely irrelevant in this area due to the inherent inefficiency  
it bears.
Fortran first due to tons of well tested legacy code out there,
C and C++ next is indeed fine.

>> Any kind of abstraction between point 1. and 2. and I would see
>> myself analyzing the assembler output to see what the compiler
>> actually did anyway.
>>
>
> On further reflection, I don't see how a middle ground can even be
> defined. The three states above seem to make sense: IEEE, hardware, or
> language standard.
>
>
>> And last but not least: Most of this isn't really interesting at the
>> compilation unit level at all. This is the completely uninteresting
>> scope. If anything one should discuss about the pragma directive
>> level, since this is where fine control of numerical behavior happens
>> in the world out there. The ability to say for example:
>>
>> #pragma unroll 4 sturd 8
>>
>> would be really of "infinite" more value then some fancy -fblah-blah.
>
> GCC seems to have a fancy for options, since that is what most people
> ask for. I agree that a set of "tuning" pragmas would be a good way of
> defining the compilation requirements for a given algorithm.

My understanding is that in the past pragmas where rejected in GCC in  
favor
of the __attribute__((((((()))))))))) syntax due to misguided  
opinions about
esthetics. Thus there are implementation problems with the approach  
outlined
here. However I advise you to read for example the documentation about
Cray C to see how this kind of stuff is handled there. Taking a look  
at Sun's
C compiler will not hurt as well to see how a FPU which is quite  
unique get's
handled.