Re: Problems with Hardware, Languages, and Compilers

smryan@mail.com (!@?*$%) writes:


>> Factorizing x/y as x*(1/y) is not generally done inside compilers,
>> because compiler people are generally given a quotient hardware
>> operation, rather than an inverse operation. The software that cares
>
> Nope. It is generally not done because customers scream bloody murder
> if the last few bits are different, which can easily happen with this
> transformation.
>
> Personal experience.


Well, if these few bits are really important to the safety of your
customers' projects, then to begin with, they shouldn't use a
development system that won't guarantee them that they will have the
right precision. Else, they might end like the European space agency,
with a rocket that explodes out of a floating point overflow. Note
that floating point underflow might be harder to detect immediately,
so that your customers' device would not only fail, but go wild.


Screaming about a few unneeded bits is stupid. So is not worrying
about precision in mission-critical software. Instead of both running
after ghosts and ignoring real dangers, your customers should first
determine their needs precisely.


      I know people who won't use floating point at all, because they
always count the number of bits they need, and then, they can use
fixed point, which is much cheaper on the embedded hardware they
target.


      To conclude back on the topic of declaring optimizations (whether
that be done by the "system programmer" or the "user", which
distinction is blurred in reflective systems), the problem is of
course that most program transformations are not universally valid, so
that you need a way to specify *and* verify the domain of validity of
transformations. You also need a way to specify and verify the fact
that user code is in this domain.


      It is blatant that current "industry standard" development systems
allow neither software specification, nor software verification, so
that people use contrived red-tape to emulate it, which is inefficient
in all possible points of view.


      I unhappily know no software that currently allows both
specification and verification of arbitrary properties of real-life
(meta)programs, and this is a pity; but building such software is part
of the Tunes project for a semantically clean reflective computing
system.


http://www.eleves.ens.fr:8080/home/rideau/Tunes/


== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
--

Return to the comp.compilers page.
Search the comp.compilers archives again.