On Sun, 01 Apr 2007 18:00:07 -0400, CBFalconer <firstname.lastname@example.org>
>Grant Edwards wrote:
>> On 2007-04-01, Anton Erasmus <email@example.com> wrote:
>... snip ...
>>> Doing a robust floating point implimentation that handles all
>>> the exceptions properly is non-trivial. Typical 8-bit
>>> implimentations takes short cuts.
>> I've been using floating point on 8-bit platforms for 15 years,
>> and I've got no complaints.
>I think Anton is including omission of detection and propagation of
>INF and NAN as "short cuts". The other approach is to trap those
>operations at occurance.
While in-band signalling of special conditions is useful in some
cases, when there are a limited number of special cases, however, with
more complex situations, when the signal is processed at various
stages, getting any meaningful information through the whole chain is
However, when using out-of-band signalling, i.e. there is a status
field is attached to the actual value. This status field can express
much more situations, such as sensor open/short circuit, out of range
etc. For instance, in the Profibus PA fieldbus, each signal is
represented by 5 bytes, four bytes for the actual floating point value
and one byte for the actual status ("quality") of the signal.
So if you are planning to use a floating point value with the sole
purpose of using in-band signalling with NAN, +INF and -INF, it might
make more sense to use a 16 or 24 bit integer value field and an 8 bit
status field, which has the same or smaller memory footprint than the
32 bit float. On an 8 bitter, less memory access is required to check
for the status byte than trying to determine, if the float is a very
large value, INF or NAN, requiring testing up to 4 bytes. This is
significant, since the exception conditions should be checked every
time before using the value.
Reply by Niklas Holsti●April 2, 20072007-04-02
Anton Erasmus wrote:
> A pity that none of the main stream languages has support for fixed point.
Ada supports fixed point. I consider it a "main stream language", but
some perhaps don't...
niklas holsti tidorum fi
. @ .
Reply by Ron Blancarte●April 2, 20072007-04-02
On Fri, 30 Mar 2007 09:28:38 -0600 (while OU was sucking), Not Really
>"Ron Blancarte" <ron@---TAKETHISOUT---.blancarte.com> wrote in message
>> Now, i have googled this some, with not much as far as results, so I
>> though I would ask here to see what kind of luck I would have.
>> I am using the Analog Devices ADuC831 (8052 ISA) part to do data
>> acquisition and transmission. I have some data that is being held as
>> floating point (single precision IEEE 754 format). Some of this data
>> needs to be outputted to serial on request. This is where my request
>> comes in. Currently I am using sprintf() to format this output into
>> my buffer. HOWEVER, the footprint of this code is making it less than
>> desirable to use (over 1100 bytes of code space and nearly 30 bytes of
>> memory). So I am looking to do the output on my own.
>> And to this means, I have succeeded, to an extent. So far I have
>> removed my need for sprintf() in printing HEX format, as well as ints
>> and chars. My problem is with floats. I have not yet attempted
>> standard notation:
>> But I did write an exponent formula.
>> I even got the rounding. HOWEVER, this is using simple multiplies and
>> divides, by 10, to achieve it's goals. And this introduces my
>> problem. Since a few of the numbers go out to 6 digits of precision,
>> I am having problems with these last digits outputting correctly. For
>> Value entered: 6.791775E-08
>> Value displayed: 6.791777E-08
>> Hex value on chip: 0x3391DA2E (6.7917753e-8)
>> Clearly, the entered value is being stored correctly and the displayed
>> value, while close, is just slightly off. So is there a way to do
>> this without this error induced by my multiplications by 10 (and still
>> not using sprintf()?
>> "It is human nature to take shortcuts in thinking"
>I emailed you some sample code that we wrote for the same problem on another
>member of the ADuC8xx family. Let me know if you did not receive the direct
I didn't get it (or my spam filters got to it first). Try sending it
to ron dot blancarte at benchtree dot net. That is my work address
and would be where I was looking for this solution.
>Anton Erasmus wrote:
>> A pity that none of the main stream languages has support for fixed point.
>Ada supports fixed point. I consider it a "main stream language", but
>some perhaps don't...
As far as I am aware there is no main stream language available for
from small 8-bit micros up to 64 bit processors that has support for
fixed point. This is true whether one considers Ada a main stream
language or not. C , and maybe Forth is probably the only languages
which is supported across the full range of micros.
Reply by Simon Clubley●April 4, 20072007-04-04
In article <firstname.lastname@example.org>, Anton Erasmus <email@example.com> writes:
> As far as I am aware there is no main stream language available for
> from small 8-bit micros up to 64 bit processors that has support for
> fixed point. This is true whether one considers Ada a main stream
> language or not. C , and maybe Forth is probably the only languages
> which is supported across the full range of micros.
Ada is now available on the AVR.
What I don't know, because I don't use the AVR, is if Ada's fixed point
packages are also available on the AVR.
See http://avr-ada.sourceforge.net for further details if you are interested.
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world