Re: Ada front-end depends on signed overflow

[Paul Schlie <schlie at comcast dot net>]

> From: Joe Buck <Joe.Buck@synopsys.COM>
>> On Wed, Jun 08, 2005 at 10:53:04AM -0400, Paul Schlie wrote:
>>> From: Robert Dewar <dewar@adacore.com>
>>> There is nothing imprecise about IEEE floating-point operations
>> 
>> - agreed, however nor is it mandated by most language specifications,
>>   so seemingly irrelevant.
> 
> In real life, there are no longer any significant non-embedded
> architectures out there that don't use IEEE floating point, so
> it is a widely used practice to assume it and document the requirement.
> The resulting programs might not work on a Vax, Cray, or IBM 370.
> C'est la vie.

- With the not so minor exception that IEEE strict semantics are basically
  counter productive for most real-time fp signal processing tasks, as
  simple saturation and consistent reciprocal semantics tend to be preferred
  as they lose precision gracefully, not catastrophically as sticky inf and
  nan semantics do at the limits of it's representation bounds; which is why
  fp signal processor architectures tend not to implement IEEE semantics,
  and arguably rely on it's "imprecision" in lieu of failure at it's bounds.
  (also most "embedded" processors do not have any FP support, and often
  typically benefit from looser soft implementations of IEEE, as strict
  bit-exact behavior is typically of less significance when all that may
  be occasionally required is just a bit more dynamic range than an fixed
  point representation my reasonably provide, and often gladly trade a few
  bits of precision for a less bulky implementations and never need to fool
  with nan or inf semantics).