Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27759 > unrolled thread

Use of soft float?

Back to article view | Back to comp.arch.embedded

Contents

  Use of soft float? Philipp Klaus Krause <pkk@spth.de> - 2018-05-20 11:56 +0200
    Re: Use of soft float? Dimiter_Popoff <dp@tgi-sci.com> - 2018-05-20 14:24 +0300
      Re: Use of soft float? Clifford Heath <no.spam@please.net> - 2018-05-21 09:24 +1000
        Re: Use of soft float? Dimiter_Popoff <dp@tgi-sci.com> - 2018-05-21 10:35 +0300
          Re: Use of soft float? Clifford Heath <no.spam@please.net> - 2018-05-22 09:33 +1000
    Re: Use of soft float? Grant Edwards <invalid@invalid.invalid> - 2018-05-20 23:39 +0000
    Re: Use of soft float? David Brown <david.brown@hesbynett.no> - 2018-05-21 12:12 +0200
      Re: Use of soft float? upsidedown@downunder.com - 2018-05-22 00:36 +0300
        Re: Use of soft float? Grant Edwards <invalid@invalid.invalid> - 2018-05-21 21:49 +0000
          Re: Use of soft float? upsidedown@downunder.com - 2018-05-22 01:41 +0300
        Re: Use of soft float? Clifford Heath <no.spam@please.net> - 2018-05-22 09:39 +1000
        Re: Use of soft float? David Brown <david.brown@hesbynett.no> - 2018-05-22 11:23 +0200
    Re: Use of soft float? Luke A. Guest <laguest@archeia.com> - 2018-06-06 04:37 +0100
      Re: Use of soft float? Reinhardt Behm <rbehm@hushmail.com> - 2018-06-06 12:54 +0800

#27759 — Use of soft float?

While those who make heavy use of floating-point computations in
embedded sytems probably go for systems with hardware support for
floating-point calculations, there are plenty of systems without such
support out there.
And the existence of soft float implementations indicates that there is
a real need for doing floating-point computations on systems without
hardware floating-point support. I'd like to know a bit more about that.

* What kind of computations do people use soft float for? Any real-world
examples?
* Which types of soft float do they use? IEEE 32- or 64-bit? Some other
C standard-compliant type? 16-bit IEEE? Other 16-bit?

Philipp

[toc] | [next] | [standalone]

#27760

On 20.5.2018 г. 12:56, Philipp Klaus Krause wrote:
> While those who make heavy use of floating-point computations in
> embedded sytems probably go for systems with hardware support for
> floating-point calculations, there are plenty of systems without such
> support out there.
> And the existence of soft float implementations indicates that there is
> a real need for doing floating-point computations on systems without
> hardware floating-point support. I'd like to know a bit more about that.
>
> * What kind of computations do people use soft float for? Any real-world
> examples?
> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>
> Philipp
>

I can only speak for myself of course, here it goes.

Some 20 years ago on our first Nukeman
( http://tgi-sci.com/tgi/nmtb.htm ) I needed floating point.
The need came late in the project, during spectrum evaluation
one has to calculate isotope decay during the time acquisition
has taken place (some isotopes have short half lives so this
matters a lot). This took e^x or something like that, and the
processor was an MC68340 - a CPU32 core (sort of a downgraded 68020)
which had no FPU.
So I wrote the FPU functions I needed - just those I needed, basic
arithmetic plus the exponential thing I believe, may be something
else I don't remember at the moment. The format was that the 68K
series used, called "extended precision", 96 bit. However the
precision was far far from it - the 68340 had 32*32->64 bit
multiplication so I left the mantissa precision at just 32 bits,
was plenty.
Later when our spectrometers (multichannel analyzers) moved to
power architecture I had again to deal with FP emulation as power
has a very nice and fast FPU but it only does the fundamentals,
i.e. mul, div, add, sub etc. Well, and FMAD (multiply/add) of
course, this was crucial (could do what a 5420 DSP used to
do formerly). I had to do square root again, e^x etc. (so the
old 68340 code would run when compiled with vpa); I also had to
handle the .x (extended precision, 96 bit) format, the FPU on
the PPC core does 64 bit standard FP (again the precision I
did was that of a 64 bit IEEE number, just format conversion
without extending the mantissa precision).
Another few years later I did a sort of complete FP library,
was not in a dire need of it but I thought a respectable OS
like DPS - and the entire environment - would be less respectable
if there was not one I suppose.
I did plenty, sin, sinh, log etc., don't remember it all now.
It comes handy though, often used also in shell scripts...

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#27762

On 20/05/18 21:24, Dimiter_Popoff wrote:
> On 20.5.2018 г. 12:56, Philipp Klaus Krause wrote:
>> While those who make heavy use of floating-point computations in
>> embedded sytems probably go for systems with hardware support for
>> floating-point calculations, there are plenty of systems without such
>> support out there.
>> And the existence of soft float implementations indicates that there is
>> a real need for doing floating-point computations on systems without
>> hardware floating-point support. I'd like to know a bit more about that.
>>
>> * What kind of computations do people use soft float for? Any real-world
>> examples?
>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>>
>> Philipp
>>
> 
> I can only speak for myself of course, here it goes.
> 
> Some 20 years ago on our first Nukeman
> ( http://tgi-sci.com/tgi/nmtb.htm ) I needed floating point.
> The need came late in the project, during spectrum evaluation
> one has to calculate isotope decay during the time acquisition
> has taken place (some isotopes have short half lives so this
> matters a lot). This took e^x or something like that, and the
> processor was an MC68340 - a CPU32 core (sort of a downgraded 68020)
> which had no FPU.
> So I wrote the FPU functions I needed - just those I needed, basic
> arithmetic plus the exponential thing I believe, may be something
> else I don't remember at the moment. The format was that the 68K
> series used, called "extended precision", 96 bit. However the
> precision was far far from it - the 68340 had 32*32->64 bit
> multiplication so I left the mantissa precision at just 32 bits,
> was plenty.

How much precision did you even need? If you have a regular clock
tick and not to many decays in parallel you can do exponential
decay just by subtracting some fraction (shift and subtract)
on each cycle.

Most recently, I used division by fractional multiplication
to speed up calculation of DDS delta words. The master clock
is fixed, and so is the calibration factor to use, so you
can calculate how many bits of headroom you have and do the
division by a multiplication plus a shift back by the headroom
amount. That's a kind of floating point:

<https://github.com/cjheath/AD9959/blob/master/AD9959.h#L220-L230>
<https://github.com/cjheath/AD9959/blob/master/AD9959.h#L220-L230>

Even a crappy little Arduino UNO can do that in 100usec, which
isn't bad for effectively a 64-bit divide. The precision averages
better than 1/10 LSB compared to the full divide.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#27765

On 21.5.2018 г. 02:24, Clifford Heath wrote:
> On 20/05/18 21:24, Dimiter_Popoff wrote:
>> On 20.5.2018 г. 12:56, Philipp Klaus Krause wrote:
>>> While those who make heavy use of floating-point computations in
>>> embedded sytems probably go for systems with hardware support for
>>> floating-point calculations, there are plenty of systems without such
>>> support out there.
>>> And the existence of soft float implementations indicates that there is
>>> a real need for doing floating-point computations on systems without
>>> hardware floating-point support. I'd like to know a bit more about that.
>>>
>>> * What kind of computations do people use soft float for? Any real-world
>>> examples?
>>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>>>
>>> Philipp
>>>
>>
>> I can only speak for myself of course, here it goes.
>>
>> Some 20 years ago on our first Nukeman
>> ( http://tgi-sci.com/tgi/nmtb.htm ) I needed floating point.
>> The need came late in the project, during spectrum evaluation
>> one has to calculate isotope decay during the time acquisition
>> has taken place (some isotopes have short half lives so this
>> matters a lot). This took e^x or something like that, and the
>> processor was an MC68340 - a CPU32 core (sort of a downgraded 68020)
>> which had no FPU.
>> So I wrote the FPU functions I needed - just those I needed, basic
>> arithmetic plus the exponential thing I believe, may be something
>> else I don't remember at the moment. The format was that the 68K
>> series used, called "extended precision", 96 bit. However the
>> precision was far far from it - the 68340 had 32*32->64 bit
>> multiplication so I left the mantissa precision at just 32 bits,
>> was plenty.
>
> How much precision did you even need? If you have a regular clock
> tick and not to many decays in parallel you can do exponential
> decay just by subtracting some fraction (shift and subtract)
> on each cycle.

It is not so simple, far from it really. During spectrum acquisition,
when you have a "clock tick" you don't know what is in the spectrum,
acquisition times of many hours - or days - are normal.
So all you have the acquisition time and the half lives after you
have identified the isotopes. Then the operator needs to be able
to calculate activities referenced to any particular moment, not the
moment of acquisition. Etc etc.
Steering away from FP makes sense as long as you don't have an FPU
on chip of course, but sometimes using FP - even emulated - is just
the easiest way to go. I had managed back then - prior to writing the
evaluation mentioned - to do curve fit to spectrum peaks using
fixed point, works quite well to this day - although I have migrated
some (not sure how much) of the arithmetic to FP since I have one
anyway.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#27773

On 21/05/18 17:35, Dimiter_Popoff wrote:
> On 21.5.2018 г. 02:24, Clifford Heath wrote:
>> On 20/05/18 21:24, Dimiter_Popoff wrote:
>>> On 20.5.2018 г. 12:56, Philipp Klaus Krause wrote:
>>>> While those who make heavy use of floating-point computations in
>>>> embedded sytems probably go for systems with hardware support for
>>>> floating-point calculations, there are plenty of systems without such
>>>> support out there.
>>>> And the existence of soft float implementations indicates that there is
>>>> a real need for doing floating-point computations on systems without
>>>> hardware floating-point support. I'd like to know a bit more about 
>>>> that.
>>>>
>>>> * What kind of computations do people use soft float for? Any 
>>>> real-world
>>>> examples?
>>>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>>>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>>>>
>>>> Philipp
>>>>
>>>
>>> I can only speak for myself of course, here it goes.
>>>
>>> Some 20 years ago on our first Nukeman
>>> ( http://tgi-sci.com/tgi/nmtb.htm ) I needed floating point.
>>> The need came late in the project, during spectrum evaluation
>>> one has to calculate isotope decay during the time acquisition
>>> has taken place (some isotopes have short half lives so this
>>> matters a lot). This took e^x or something like that, and the
>>> processor was an MC68340 - a CPU32 core (sort of a downgraded 68020)
>>> which had no FPU.
>>> So I wrote the FPU functions I needed - just those I needed, basic
>>> arithmetic plus the exponential thing I believe, may be something
>>> else I don't remember at the moment. The format was that the 68K
>>> series used, called "extended precision", 96 bit. However the
>>> precision was far far from it - the 68340 had 32*32->64 bit
>>> multiplication so I left the mantissa precision at just 32 bits,
>>> was plenty.
>>
>> How much precision did you even need? If you have a regular clock
>> tick and not to many decays in parallel you can do exponential
>> decay just by subtracting some fraction (shift and subtract)
>> on each cycle.
> 
> It is not so simple, far from it really. During spectrum acquisition,
> when you have a "clock tick" you don't know what is in the spectrum,
> acquisition times of many hours - or days - are normal.
> So all you have the acquisition time and the half lives after you
> have identified the isotopes. Then the operator needs to be able
> to calculate activities referenced to any particular moment, not the
> moment of acquisition. Etc etc.
> Steering away from FP makes sense as long as you don't have an FPU
> on chip of course, but sometimes using FP - even emulated - is just
> the easiest way to go.

All true. Soft FP isn't as bad as some may think.
But in the specific situation I mentioned, the
integer-based approach is still many times faster.
And I've made good use of exponential decay (IIR
filters) done with integers too. It's just another
tool in the math toolbox.

[toc] | [prev] | [next] | [standalone]

#27763

On 2018-05-20, Philipp Klaus Krause <pkk@spth.de> wrote:
> While those who make heavy use of floating-point computations in
> embedded sytems probably go for systems with hardware support for
> floating-point calculations, there are plenty of systems without such
> support out there.
> And the existence of soft float implementations indicates that there is
> a real need for doing floating-point computations on systems without
> hardware floating-point support. I'd like to know a bit more about that.
>
> * What kind of computations do people use soft float for? Any real-world
>   examples?

In my personal experience, all sorts of real-time process-measurement
calculations (pressure, temperature, flow, etc.).

> * Which types of soft float do they use? IEEE 32- or 64-bit?

Low end systems often use 32-bit only.

> Some other C standard-compliant type?

Not that I've ever seen.

> 16-bit IEEE?

No.

> Other 16-bit?

IIRC, I've seen some custom 24-bit FP types.

--
Grant

[toc] | [prev] | [next] | [standalone]

#27766

On 20/05/18 11:56, Philipp Klaus Krause wrote:
> While those who make heavy use of floating-point computations in
> embedded sytems probably go for systems with hardware support for
> floating-point calculations, there are plenty of systems without such
> support out there.
> And the existence of soft float implementations indicates that there is
> a real need for doing floating-point computations on systems without
> hardware floating-point support. I'd like to know a bit more about that.
> 
> * What kind of computations do people use soft float for? Any real-world
> examples?
> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
> C standard-compliant type? 16-bit IEEE? Other 16-bit?
> 

Any C compiler will provide software floating point for IEEE 32-bit 
"float".  Most also provide 64-bit "double" support, but for 8-bit 
targets it is not unusual to have non-standard 32-bit "double".

I would expect the vast majority of software floating point usage to be 
directly from a C compiler.  Some few people write their own functions 
optimised to their particular needs (such as unusual accuracy 
requirements), but that is rare.  For the basic arithmetic, you are 
unlikely to make significantly better general-purpose floating point 
functions than the ones provided by the compiler, and you have the huge 
advantage of convenience of use.

Maths functions (like trig functions) are a different matter.  In 
embedded systems, even those with floating point hardware, it is not 
uncommon to have your own functions with a more appropriate balance 
between speed and accuracy than the slow but IEEE bit-perfect standard 
functions.

[toc] | [prev] | [next] | [standalone]

#27770

On Mon, 21 May 2018 12:12:26 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 20/05/18 11:56, Philipp Klaus Krause wrote:
>> While those who make heavy use of floating-point computations in
>> embedded sytems probably go for systems with hardware support for
>> floating-point calculations, there are plenty of systems without such
>> support out there.
>> And the existence of soft float implementations indicates that there is
>> a real need for doing floating-point computations on systems without
>> hardware floating-point support. I'd like to know a bit more about that.
>> 
>> * What kind of computations do people use soft float for? Any real-world
>> examples?
>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>> 
>
>Any C compiler will provide software floating point for IEEE 32-bit 
>"float".  Most also provide 64-bit "double" support, but for 8-bit 
>targets it is not unusual to have non-standard 32-bit "double".
>
>I would expect the vast majority of software floating point usage to be 
>directly from a C compiler.  Some few people write their own functions 
>optimised to their particular needs (such as unusual accuracy 
>requirements), but that is rare.  For the basic arithmetic, you are 
>unlikely to make significantly better general-purpose floating point 
>functions than the ones provided by the compiler, and you have the huge 
>advantage of convenience of use.
>
>Maths functions (like trig functions) are a different matter.  In 
>embedded systems, even those with floating point hardware, it is not 
>uncommon to have your own functions with a more appropriate balance 
>between speed and accuracy than the slow but IEEE bit-perfect standard 
>functions.

What is so "bit perfect" about IEEE floats ? The only thing that I can
think of  is handling of infinity and denorms and other special
values. t seems that the IEEE standard committee thought that is
completely OK to have INF intermediate results and still continue
doing further calculations with such sick values.

Some "IEEE" soft libraries handle ordinary values quite well, but
might not handle these special cases properly.

In an embedded system you usually try to clean the mathematics before
coding in order to avoid divide by zero or having extremely small
(less than 1E-38) intermediate results. 

Before IEEE floats, each computer manufacturer had their own floating
point representation, some used sign/magnitude significand, while
other 2's complement, some used biased exponent while other 2's
complement or sign/magnitude exponent, some used base 2 float
with/without hidden bit normalization while others used base 16. Some
had one more bit in the significand or other used an extra bit to
exponent to extend the range from 1E38. Converting computer tapes
containing binary floats was a mess, usually the data on the sending
machine was converted to printable ADCII (or EBCDIC) characters like
the character string "1234.56" and on the receiving side it was
converted to binary in the other system format. Of course, this meant
loss of 1-3 least significant bits. 

If you could do this directly in binary, one could receive a wizard
status :-). But still a special conversion was required for each pair
of computer manufacturer.

When the IEEE format was adopted by most manufacturers, much of these
conversion problems were solved. If some still used some proprietary
float format, the manufacturer provided conversion from/to their
private format to IEEE. Conversion between two private formats was now
done via IEEE, only loosing about 1 bit of accuracy, compared to 1-3
bit losses via printable decimals. This century, I have only needed
to do one such to/from binary conversion for an ancient hardware.

In practice, it is not a big issue using any proprietary (non IEEE)
float library internally, unless you need to handle INF or other
special values or need to communicate binary floats to/from  the
external world.

[toc] | [prev] | [next] | [standalone]

#27771

On 2018-05-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote:

> What is so "bit perfect" about IEEE floats? The only thing that I
> can think of is handling of infinity and denorms and other special
> values.

Exactly how rounding and intermediate values interact is a sticky
issue.  For example, the old Intel 8087 had 80-bit internal FP
registers.  If you do a series of floating point operations in the
most obvious/efficient way (with 80-bit intermediate values), the
result you get might not be IEEE "bit-perfect" correct.

-- 
Grant Edwards               grant.b.edwards        Yow! My polyvinyl cowboy
                                  at               wallet was made in Hong
                              gmail.com            Kong by Montgomery Clift!

[toc] | [prev] | [next] | [standalone]

#27772

On Mon, 21 May 2018 21:49:47 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2018-05-21, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>
>> What is so "bit perfect" about IEEE floats? The only thing that I
>> can think of is handling of infinity and denorms and other special
>> values.
>
>Exactly how rounding and intermediate values interact is a sticky
>issue.  For example, the old Intel 8087 had 80-bit internal FP
>registers.  If you do a series of floating point operations in the
>most obvious/efficient way (with 80-bit intermediate values), the
>result you get might not be IEEE "bit-perfect" correct.

Not only that, but the x87 has  a very limited 8 level stack, which
can overflow on very complex expressions.

Consider a situation, in which some FP calculations are done in main
program, which expression calls a function, which also does some
complex FP calculations on the parameters.

If the function is declared in the same module before the main
program, the compiler _might_ (or might not depending on optimizer
settings) inline the function and do all the calculation on the 80 bit
hardware  stack. However, if the function is in an external module,
the compiler can't in-line so some 32 bit parameters will be passed.

Of course, the same problem exists if 64 bit IEEE are used internally
and some intermediate 32 bit IEEE values  may be passed.

However, for typical embedded applications, this might not be so much
an issue, since both ADC and DACs are typically 8, 12 or 16 bits. I
practice, only when cumulating long series of values, the intermediate
procession becomes critical. Even in such cases knowing in which order
values are cumulated, such as cumulating every millisecond to one hour
and then cumulating hours into months instead of cumulating
millisecond values directly into monthly sums, will solve the problem.

[toc] | [prev] | [next] | [standalone]

#27774

On 22/05/18 07:36, upsidedown@downunder.com wrote:
> On Mon, 21 May 2018 12:12:26 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 20/05/18 11:56, Philipp Klaus Krause wrote:
>>> While those who make heavy use of floating-point computations in
>>> embedded sytems probably go for systems with hardware support for
>>> floating-point calculations, there are plenty of systems without such
>>> support out there.
>>> And the existence of soft float implementations indicates that there is
>>> a real need for doing floating-point computations on systems without
>>> hardware floating-point support. I'd like to know a bit more about that.
>>>
>>> * What kind of computations do people use soft float for? Any real-world
>>> examples?
>>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>>>
>>
>> Any C compiler will provide software floating point for IEEE 32-bit
>> "float".  Most also provide 64-bit "double" support, but for 8-bit
>> targets it is not unusual to have non-standard 32-bit "double".
>>
>> I would expect the vast majority of software floating point usage to be
>> directly from a C compiler.  Some few people write their own functions
>> optimised to their particular needs (such as unusual accuracy
>> requirements), but that is rare.  For the basic arithmetic, you are
>> unlikely to make significantly better general-purpose floating point
>> functions than the ones provided by the compiler, and you have the huge
>> advantage of convenience of use.
>>
>> Maths functions (like trig functions) are a different matter.  In
>> embedded systems, even those with floating point hardware, it is not
>> uncommon to have your own functions with a more appropriate balance
>> between speed and accuracy than the slow but IEEE bit-perfect standard
>> functions.
> 
> What is so "bit perfect" about IEEE floats ?

It's not that they're perfect. It's that they're
predictably imperfect, so the same program yields
the same results on different implementations.

> In practice, it is not a big issue using any proprietary (non IEEE)
> float library internally, unless you need to handle INF or other
> special values or need to communicate binary floats to/from  the
> external world.

Or you want to develop & test the program on a
different computer than it will run on.

My AD9969 Arduino code runs its tests on Intel
just fine. Much easier to diagnose issues there
before moving to target hardware.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#27777

On 21/05/18 23:36, upsidedown@downunder.com wrote:
> On Mon, 21 May 2018 12:12:26 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 20/05/18 11:56, Philipp Klaus Krause wrote:
>>> While those who make heavy use of floating-point computations in
>>> embedded sytems probably go for systems with hardware support for
>>> floating-point calculations, there are plenty of systems without such
>>> support out there.
>>> And the existence of soft float implementations indicates that there is
>>> a real need for doing floating-point computations on systems without
>>> hardware floating-point support. I'd like to know a bit more about that.
>>>
>>> * What kind of computations do people use soft float for? Any real-world
>>> examples?
>>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>>>
>>
>> Any C compiler will provide software floating point for IEEE 32-bit 
>> "float".  Most also provide 64-bit "double" support, but for 8-bit 
>> targets it is not unusual to have non-standard 32-bit "double".
>>
>> I would expect the vast majority of software floating point usage to be 
>> directly from a C compiler.  Some few people write their own functions 
>> optimised to their particular needs (such as unusual accuracy 
>> requirements), but that is rare.  For the basic arithmetic, you are 
>> unlikely to make significantly better general-purpose floating point 
>> functions than the ones provided by the compiler, and you have the huge 
>> advantage of convenience of use.
>>
>> Maths functions (like trig functions) are a different matter.  In 
>> embedded systems, even those with floating point hardware, it is not 
>> uncommon to have your own functions with a more appropriate balance 
>> between speed and accuracy than the slow but IEEE bit-perfect standard 
>> functions.
> 
> What is so "bit perfect" about IEEE floats ? The only thing that I can
> think of  is handling of infinity and denorms and other special
> values. t seems that the IEEE standard committee thought that is
> completely OK to have INF intermediate results and still continue
> doing further calculations with such sick values.

IEEE specifies rounding, errors and limits for all sorts of operations.
 The idea is that if you have two IEEE compatible implementations
(hardware, software, doesn't matter) and pick the same settings for
roundings, you will get exactly the same (or perhaps a LSB out) results
for many operations.

In particular, if you have a maths library that is IEEE compliant and
use a function like "sin", you will get an accuracy to within a bit or
two.  Following C standards, IEEE standards, and common practice, the
"sin" function is typically done at 64-bit double resolution - thus your
"sin" function will be bit-perfect to 52 bits.  This is, of course,
utterly pointless if you are using that function for driving a motor and
have a 10-bit PWM resolution.

> 
> Some "IEEE" soft libraries handle ordinary values quite well, but
> might not handle these special cases properly.
> 
> In an embedded system you usually try to clean the mathematics before
> coding in order to avoid divide by zero or having extremely small
> (less than 1E-38) intermediate results. 

Absolutely agreed.

<snip>

> 
> In practice, it is not a big issue using any proprietary (non IEEE)
> float library internally, unless you need to handle INF or other
> special values or need to communicate binary floats to/from  the
> external world.
> 

Using IEEE makes it far simpler to work with tools, because they all
give the same results.  In particular, it means your compiler (if it is
smart enough, and the right optimisations are enabled) can often do
calculations at compile time, knowing the results will be the same as at
run time.

Very often you only actually need /approximate/ IEEE compatibility.  For
gcc (and clang), the flag "-ffast-math" is very useful - it tells the
compiler that you don't care about infinities, denormals, and other such
awkwardness, and you are happy to assume the floating point maths is
associative, commutative, etc.  This can make results vary marginally
depending on the optimisation details, but can give you much smaller and
faster code.

You still need to write your own transcendental functions if you need
speed, however.

[toc] | [prev] | [next] | [standalone]

#27791

Philipp Klaus Krause <e> wrote:

> 
> * What kind of computations do people use soft float for? Any real-world
> examples?
> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
> C standard-compliant type? 16-bit IEEE? Other 16-bit?
> 

Probably not what you’re asking, but... Ada has always, AFAIK, had fixed
point types as well as floating point types. Fixed point is implemented
with integers.

[toc] | [prev] | [next] | [standalone]

#27792

AT Wednesday 06 June 2018 11:37, Luke A.  Guest wrote:

> Philipp Klaus Krause <e> wrote:
> 
>> 
>> * What kind of computations do people use soft float for? Any real-world
>> examples?
>> * Which types of soft float do they use? IEEE 32- or 64-bit? Some other
>> C standard-compliant type? 16-bit IEEE? Other 16-bit?
>> 
> 
> Probably not what you’re asking, but... Ada has always, AFAIK, had fixed
> point types as well as floating point types. Fixed point is implemented
> with integers.

Nothing new. It was there in PL/I since the 1960'ties. binary fixed(p,q)

-- 
Reinhardt

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web