> This is a much broader problem -- many other aspects of compilation might
> also require proper choice of compiler flags -- and it is unclear that a
> language standard should attempt to solve it.  Surely the "code" for a
> complex system includes its makefile (or equivalent), and there is little
> hope that a language standard can solve the problems of attempting to
> build software from an incomplete or mangled distribution.

That brings up another thing...

Why has the committee not done something to standardize precompiled
headers or some other kind of separate compilation mechanism? The
current mechanism is just a big hack.

Java has a better setup for this kind of thing. So does Extended Pascal.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[This article is crossposted to both comp.std.c and comp.std.c++.]

In article <4s5m4l$dfs@tribune.mayo.edu>, stan@chirpa.Mayo.EDU (Andrew Staniszewski) writes:
>I feel it would be incredibly usefull to be able to turn on and off IEEE
>math behavior in code thru a standardized set of preprocessor dirrectives.

It is incredibly useful to turn on and off all kinds of features, but
doesn't mean that all should be standardized.  The standards impose on
implementations to support integer multiplication and division even on
hardware that doesn't, but they do not impose that the result of integer
division be rounded downwards if hardware rounds closest to zero.  The
standards impose on implementations to support floating point arithmetic
even on hardware that doesn't, but the do not impose support for IEEE
arithmetic if hardware supports different floating point arithmetic.

Now admitted, if a programmer has to control a machine then the programmer
has to use assembly language because neither C nor C++ is intended to be
a substitute, but I still think it would be going too far to require
abandoning hardware capabilities and running slower software replacements.

>Most modern C and C++ compilers support the IEEE math standards using
>compiler switchs,

And most "modern" ones support 64-bit longs, but we don't force it on all.

>The justification for creating special directives is that:

I agree with your justifications (deleted to save bandwidth).

>a suggested set of directives would be:
>#ieee_math on
>#ieee_math off

A better suggested set of directives would be:
#pragma ieee_math on
#pragma ieee_math off

Of course, those would have to be pursued in other newsgroups.

Norman Diamond
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4s5m4l$dfs@tribune.mayo.edu> "Staniszewski, Andrew J." <staniszewski.andrew@mayo.edu> writes:
>I feel it would be incredibly usefull to be able to turn on and off
>IEEE math behavior in code thru a standardized set of preprocessor
>dirrectives.

There is a fundamental problem here:  turning IEEE math behavior on and
off at run time can be quite expensive, depending on the machine.  The
problem is changing processor mode bits.  It is fairly common for at least
some aspects of the IEEE trapping behavior to be controlled by mode bits
rather than by instruction choice.  Mode-bit changes are often very costly
on high-performance machines, because parallel and overlapped activities
must come to a screeching halt to ensure that the change happens exactly
when it should -- that all pre-change operations behave in the pre-change
way and all post-change operations behave in the post-change way.

Using preprocessor directives is also a rather awkward way of requesting
such a change, because they are not well-integrated with the flow of
control.  In practice, they would probably have to be turned into function
calls (or some conceptually-similar construct) which would then be
compiled suitably.  It would be better to just use function calls to begin
with, putting the functions in one of the reserved areas of the C name
space or in a new header.

> 1) the extra instructions cause the code to be slower, being able
> to selectivly turn on and off the generation of instructions
> would allow the developer to write efficient code that uses the
> IEEE behavior only when it is appropriate.

As mentioned above, switching back and forth can be extremely expensive,
so any efficiency advantage is system-specific anyway, which rather
reduces the benefit of standardizing the syntax.

Also, various aspects of IEEE behavior might need to be controlled
independently.  For example, full support for denormalized numbers can be
quite costly if the hardware does not help, and might not be desired if
the only motive is to get, say, IEEE handling of NaNs.  In other words,
"IEEE math behavior" is not Boolean -- it is potentially a complex set
of options, and if the motive is efficiency, selection of the minimal
necessary set may be important.

> 2) The person writing the code can not be assured that the
> code will be properly compiled to obtain the IEEE behavior.
> As the code gets maintained, ported, moved around, etc. The
> required flag for generating code with IEEE behavior may
> be forgotten.

This is a much broader problem -- many other aspects of compilation might
also require proper choice of compiler flags -- and it is unclear that a
language standard should attempt to solve it.  Surely the "code" for a
complex system includes its makefile (or equivalent), and there is little
hope that a language standard can solve the problems of attempting to
build software from an incomplete or mangled distribution.
--
...the truly fundamental discoveries seldom        |       Henry Spencer
occur where we have decided to look.  --B. Forman  |   henry@zoo.toronto.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[Moderator's note: this article is crossposted to both
comp.std.c and comp.std.c++.  -fjh.]

I feel it would be incredibly usefull to be able to turn on and off
IEEE math behavior in code thru a standardized set of preprocessor
dirrectives.

Most modern C and C++ compilers support the IEEE math standards using
compiler switchs, which tell the compiler to generate extra instructions to
allow trapping of floating point exceptions, and to define the IEEE
standard default trapping behavior.

The justification for creating special directives is that:
 1) the extra instructions cause the code to be slower, being able
 to selectivly turn on and off the generation of instructions
 would allow the developer to write efficient code that uses the
 IEEE behavior only when it is appropriate.

 2) The person writing the code can not be assured that the
 code will be properly compiled to obtain the IEEE behavior.
 As the code gets maintained, ported, moved around, etc. The
 required flag for generating code with IEEE behavior may
 be forgotten.

a suggested set of directives would be:

 #ieee_math on
 #ieee_math off

This would allow a programmer to turn on IEEE behavior when it
is really wanted, such as:

 ...
 #ieee_math on
 c = a/b;
 if (!finite(c))
  goto recover:

 #ieee_math off
 ..




--
------------------------------------------------------------------------------
Andrew Staniszewski
Sr. Software Engineer
Special Purpose Processing Group
Mayo Foundation
staniszewski.andrew@mayo.edu

Please Note: Unless otherwise specified, I speak only for myself, NOT as
a representative of the Special Purpose Processor Group or Mayo Foundation

------------------------------------------------------------------------------
------------------------------------------------------------------------------
           A diamond is a lump of coal that stuck with the job
------------------------------------------------------------------------------
------------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]