Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
fpu why?
52 views
Skip to first unread message
Rosario1903
Feb 9, 2013, 6:45:18 AM2/9/13
to
why x86 has fpu?
why not use fixed point instructions on integers?
other cpu have fpu?
why the math of fixed point is less good than fpu math?
why not use fixed point instructions on integers?
other cpu have fpu?
why the math of fixed point is less good than fpu math?
Robert Wessel
Feb 9, 2013, 7:09:20 AM2/9/13
to
several advantages, not least managing a considerable range in
magnitude in a commonly useful way. You can certainly do the same
work with fixed point, but you commonly end up spending a lot of time
watching your magnitudes and carefully managing the scaling. It's
particularly popular in scientific-type calculations, as those are
normally done in a floating point format anyway.
As to other CPUs with FPUs, almost all of the large ones in some
fashion. From ARM to zSeries. In some architectures it's optional
(ARM), in some it's always been an integral part of the ISA (IPF,
Cray-1, CDC-6600), and in some it was originally optional but is now
integral (zSeries, x86).
Small CPU often don't have defined FP ISAs, so don't expect native FP
on your 6502 or 8051.
And while you don't see it much these days, there used to be
semi-generic FP coprocessor chips that you could attach to small CPUs
if your application needed that (these days it usually makes more
sense to just upgrade to a CPU with FP support rather than adding an
external device).
Rosario1903
Feb 9, 2013, 10:02:45 AM2/9/13
to
On Sat, 09 Feb 2013 06:09:20 -0600, Robert Wessel
<robert...@yahoo.com> wrote:
>On Sat, 09 Feb 2013 12:45:18 +0100, Rosario1903
><Ros...@invalid.invalid> wrote:
>
>>why x86 has fpu?
<robert...@yahoo.com> wrote:
>On Sat, 09 Feb 2013 12:45:18 +0100, Rosario1903
><Ros...@invalid.invalid> wrote:
>
>>why x86 has fpu?
>In addition to certain disadvantages, floating point numbers have
>several advantages, not least managing a considerable range in
>magnitude in a commonly useful way. You can certainly do the same
>work with fixed point, but you commonly end up spending a lot of time
>watching your magnitudes and carefully managing the scaling. It's
>particularly popular in scientific-type calculations, as those are
>normally done in a floating point format anyway.
>
>As to other CPUs with FPUs, almost all of the large ones in some
>fashion. From ARM to zSeries. In some architectures it's optional
>(ARM), in some it's always been an integral part of the ISA (IPF,
>Cray-1, CDC-6600), and in some it was originally optional but is now
>integral (zSeries, x86).
>
>Small CPU often don't have defined FP ISAs, so don't expect native FP
>on your 6502 or 8051.
>
>And while you don't see it much these days, there used to be
>semi-generic FP coprocessor chips that you could attach to small CPUs
>if your application needed that (these days it usually makes more
>sense to just upgrade to a CPU with FP support rather than adding an
>external device).
ok thank you, grazie
>several advantages, not least managing a considerable range in
>magnitude in a commonly useful way. You can certainly do the same
>work with fixed point, but you commonly end up spending a lot of time
>watching your magnitudes and carefully managing the scaling. It's
>particularly popular in scientific-type calculations, as those are
>normally done in a floating point format anyway.
>
>As to other CPUs with FPUs, almost all of the large ones in some
>fashion. From ARM to zSeries. In some architectures it's optional
>(ARM), in some it's always been an integral part of the ISA (IPF,
>Cray-1, CDC-6600), and in some it was originally optional but is now
>integral (zSeries, x86).
>
>Small CPU often don't have defined FP ISAs, so don't expect native FP
>on your 6502 or 8051.
>
>And while you don't see it much these days, there used to be
>semi-generic FP coprocessor chips that you could attach to small CPUs
>if your application needed that (these days it usually makes more
>sense to just upgrade to a CPU with FP support rather than adding an
>external device).
Buon Giorno
M. Strobel
Feb 14, 2013, 5:11:48 AM2/14/13
to
Floating point: 10 / 3 = 3.3333333
Integer calculation is only exact if you take care of the rest.
Floating point is not exact, because you have a periodic .3 (when using the decimal
system). But for many uses it is exact enough.
BTW FPU floating point formats are based on the binary system, so fractions are
represented as 1/2 + 1/4 + 1/8 + 1/16 ... which has it's own problems when converting
to and from decimal.
Bottom line: with floating point you get an approximation to the mathematical result,
that is good enough for many uses, and is very fast with FPUs.
/Str.
Bill Leary
Feb 14, 2013, 6:04:47 AM2/14/13
to
"M. Strobel" wrote in message news:ao3rj4...@mid.uni-berlin.de...
example:
Fixed point: 10 / 3 = 3.3333
For a lot of applications, that'll be fine. For others, of course, it's
not.
The potential problem with fixed point is range limitations. For example,
using four decimal place fixed point on a thirty-two bit integer gets you a
range of -214,748.3648 to +214,748.3647. If you need to handle 0.00002 or
220,000.00 you've got a problem.
I've used this approach a few times in embedded work, usually where I needed
to express something as a percentage, and the processor didn't support
floating point and I couldn't afford the several kilobytes required to
include a floating point package in the ROM to do just a couple of
calculations.
- Bill
> Am 09.02.2013 12:45, schrieb Rosario1903:
>> why x86 has fpu?
>> why not use fixed point instructions on integers?
>> other cpu have fpu?
>> why the math of fixed point is less good than fpu math?
>
> Integer calculation: 10 / 3 = 3 rest 1
> Floating point: 10 / 3 = 3.3333333
He said fixed point on integers. Assuming fixed point, four places, for
>> why x86 has fpu?
>> why not use fixed point instructions on integers?
>> other cpu have fpu?
>> why the math of fixed point is less good than fpu math?
>
> Integer calculation: 10 / 3 = 3 rest 1
> Floating point: 10 / 3 = 3.3333333
example:
Fixed point: 10 / 3 = 3.3333
For a lot of applications, that'll be fine. For others, of course, it's
not.
The potential problem with fixed point is range limitations. For example,
using four decimal place fixed point on a thirty-two bit integer gets you a
range of -214,748.3648 to +214,748.3647. If you need to handle 0.00002 or
220,000.00 you've got a problem.
I've used this approach a few times in embedded work, usually where I needed
to express something as a percentage, and the processor didn't support
floating point and I couldn't afford the several kilobytes required to
include a floating point package in the ROM to do just a couple of
calculations.
- Bill
Robert Wessel
Feb 14, 2013, 7:13:53 AM2/14/13
to
called scaled, arithmetic is part of a number of languages, going back
to Cobol. In assembler, or in languages without specific features to
support it, you'd need to manage the scaling manually, which is
tedious, but not hard.
In any event, while x86 hardware floating point may be exclusively
binary, that's not a requirement, and systems have implemented hex and
decimal FP.
Bill Leary
Feb 14, 2013, 5:20:12 PM2/14/13
to
"Robert Wessel" wrote in message
news:q0lph85dfq1qqq94n...@4ax.com...
> ((..omitted..))
on a 8086 machine in the 70's that had a BCD data type. For BCD variables
you could specify the overall number of digits and how many were to the
right of the decimal point. There was a caution in the manual about using
only the precision you needed for performance reasons.
- Bill
news:q0lph85dfq1qqq94n...@4ax.com...
> ((..omitted..))
> In any event, while x86 hardware floating point may be exclusively
> binary, that's not a requirement, and systems have implemented hex
> and decimal FP.
The X86 has BCD instructions. Two digits per byte. I worked with a BASIC
> binary, that's not a requirement, and systems have implemented hex
> and decimal FP.
on a 8086 machine in the 70's that had a BCD data type. For BCD variables
you could specify the overall number of digits and how many were to the
right of the decimal point. There was a caution in the manual about using
only the precision you needed for performance reasons.
- Bill
Bill Leary
Feb 14, 2013, 8:41:56 PM2/14/13
to
"Bill Leary" wrote in message
news:yMOdncVVir-C_oDM...@giganews.com...
actually meant to say 8080.
- Bill
news:yMOdncVVir-C_oDM...@giganews.com...
> "Robert Wessel" wrote in message
>> ((..omitted..))
>> In any event, while x86 hardware floating point may be exclusively
>> binary, that's not a requirement, and systems have implemented hex
>> and decimal FP.
>
> The X86 has BCD instructions. Two digits per byte. I worked with a BASIC
> on a 8086 machine in the 70's that had a BCD data type. For BCD variables
> you could specify the overall number of digits and how many were to the
> right of the decimal point. There was a caution in the manual about using
> only the precision you needed for performance reasons.
The X86 did/does have BCD instructions, but in the paragraph above I
>> In any event, while x86 hardware floating point may be exclusively
>> binary, that's not a requirement, and systems have implemented hex
>> and decimal FP.
>
> The X86 has BCD instructions. Two digits per byte. I worked with a BASIC
> on a 8086 machine in the 70's that had a BCD data type. For BCD variables
> you could specify the overall number of digits and how many were to the
> right of the decimal point. There was a caution in the manual about using
> only the precision you needed for performance reasons.
actually meant to say 8080.
- Bill
wolfgang kern
Feb 15, 2013, 3:56:57 PM2/15/13
to
Bill Leary mentioned:
>> ((..omitted..))
>> In any event, while x86 hardware floating point may be exclusively
>> binary, that's not a requirement, and systems have implemented hex
>> and decimal FP.
> The X86 has BCD instructions. Two digits per byte. I worked with a BASIC
> on a 8086 machine in the 70's that had a BCD data type. For BCD variables
> you could specify the overall number of digits and how many were to the
> right of the decimal point. There was a caution in the manual about using
> only the precision you needed for performance reasons.
and avoid this 'new' features at all and just use the logical parts of it.
This limited to 18 digits translation made me think about opportunities
beyond... and I'm still stuck to the idea of using more bits in here.
So I finally find myself in using FPU (sin-cos/Atan) just once on
startup in my OS to create a few LUTs for graphical representation
and/or for translate and feed GPUs with vector-oriented Info.
BCD conversion to and from Integer is a really huge time-eater today.
SO we better avoid this (quite olde) FPU-instructions because they may
be still supported (back-wards compatible issues) but their timing
would end up in astonishing long terms ...
We can assume today: FPU-BCD-support is much too slow (death horse).
OTOH, C-lib users may find no other way to convert float to usable
figures at all (tell/pray if you know any better!)
__
wolfgang
(the one who laugh aloud when HLL-users talk about opportunities ..)
Robert Wessel
Feb 15, 2013, 5:35:30 PM2/15/13
to
On Thu, 14 Feb 2013 17:20:12 -0500, "Bill Leary" <Bill_...@msn.com>
wrote:
The BCD and ASCII instructions go away in 64-bit mode, although the
FPU's ability to load and store 80-bit BCD numbers remains.
wrote:
FPU's ability to load and store 80-bit BCD numbers remains.
Bill Leary
Feb 15, 2013, 10:14:58 PM2/15/13
to
"wolfgang kern" wrote in message news:kfm7hk$3k2$1...@newsreader2.utanet.at...
Processing Unit itself, not those of the x87 (seven) Floating Point Unit.
- Bill
> Bill Leary mentioned:
>>> ((..omitted..))
>>> In any event, while x86 hardware floating point may be exclusively
>>> binary, that's not a requirement, and systems have implemented hex
>>> and decimal FP.
>
>> The X86 has BCD instructions. Two digits per byte. I worked with a
>> BASIC on a 8086 machine in the 70's that had a BCD data type. For BCD
>> variables you could specify the overall number of digits and how many
>> were to the right of the decimal point. There was a caution in the
>> manual about using only the precision you needed for performance reasons.
>
>
> this two BCD-variants of xn87 processors may have maid me once to desire
> and avoid this 'new' features at all and just use the logical parts of it.
Sorry, no. I'm talking about the BCD capabilities of the x86 (six) Central
>>> ((..omitted..))
>>> In any event, while x86 hardware floating point may be exclusively
>>> binary, that's not a requirement, and systems have implemented hex
>>> and decimal FP.
>
>> The X86 has BCD instructions. Two digits per byte. I worked with a
>> BASIC on a 8086 machine in the 70's that had a BCD data type. For BCD
>> variables you could specify the overall number of digits and how many
>> were to the right of the decimal point. There was a caution in the
>> manual about using only the precision you needed for performance reasons.
>
>
> this two BCD-variants of xn87 processors may have maid me once to desire
> and avoid this 'new' features at all and just use the logical parts of it.
Processing Unit itself, not those of the x87 (seven) Floating Point Unit.
- Bill
M. Strobel
Feb 16, 2013, 7:32:34 AM2/16/13
to
integer scaling factor).
If talking about bcd one should say so. But BCD is just integer, the only advantage
for the assembler programmer is that he can imagine the decimal point at the nibble
boundaries.
/Str.
Bill Leary
Feb 16, 2013, 11:30:13 AM2/16/13
to
"M. Strobel" wrote in message news:ao9cj2...@mid.uni-berlin.de...
scaled integer.
Some few languages support fixed point in the language, but the low level
implementation is usually an integer. But I was really mostly thinking of
the traditional approach in FORTH of using scaled integers for fixed point
math, or the cases where I'd done the same thing in C.
> If talking about bcd one should say so. But BCD is just integer, the only
> advantage
> for the assembler programmer is that he can imagine the decimal point at
> the nibble
> boundaries.
I talked about BCD in another article. In the one you replied to here, and
those leading up to it, I was only talking about fixed point based on an
integer, as was the original poster.
- Bill
/Str.
> equated fixed point to integer, because fixed point is just scaled integer
> (with
> integer scaling factor).
Yes, I was / we were talking about fixed point which is usually based on a
> (with
> integer scaling factor).
scaled integer.
Some few languages support fixed point in the language, but the low level
implementation is usually an integer. But I was really mostly thinking of
the traditional approach in FORTH of using scaled integers for fixed point
math, or the cases where I'd done the same thing in C.
> If talking about bcd one should say so. But BCD is just integer, the only
> advantage
> for the assembler programmer is that he can imagine the decimal point at
> the nibble
> boundaries.
those leading up to it, I was only talking about fixed point based on an
integer, as was the original poster.
- Bill
/Str.
Rosario1903
Mar 15, 2013, 3:40:37 AM3/15/13
to
On Thu, 14 Feb 2013 11:11:48 +0100, "M. Strobel"
<sorry_no_...@nowhere.dee> wrote:
<sorry_no_...@nowhere.dee> wrote:
>Am 09.02.2013 12:45, schrieb Rosario1903:
>> why x86 has fpu?
>> why not use fixed point instructions on integers?
>> other cpu have fpu?
>> why the math of fixed point is less good than fpu math?
>>
>
>Integer calculation: 10 / 3 = 3 rest 1
>Floating point: 10 / 3 = 3.3333333
>
>Integer calculation is only exact if you take care of the rest.
>Floating point is not exact, because you have a periodic .3 (when using the decimal
>system). But for many uses it is exact enough.
>
>BTW FPU floating point formats are based on the binary system, so fractions are
>represented as 1/2 + 1/4 + 1/8 + 1/16 ... which has it's own problems when converting
>to and from decimal.
fixed point float format is as above, but withoug fpu... all
>> why x86 has fpu?
>> why not use fixed point instructions on integers?
>> other cpu have fpu?
>> why the math of fixed point is less good than fpu math?
>>
>
>Integer calculation: 10 / 3 = 3 rest 1
>Floating point: 10 / 3 = 3.3333333
>
>Integer calculation is only exact if you take care of the rest.
>Floating point is not exact, because you have a periodic .3 (when using the decimal
>system). But for many uses it is exact enough.
>
>BTW FPU floating point formats are based on the binary system, so fractions are
>represented as 1/2 + 1/4 + 1/8 + 1/16 ... which has it's own problems when converting
>to and from decimal.
calculations on array of integers
the only seriuous calculation i can think is done by unsigned integer
and fixed point float
Rosario1903
Mar 15, 2013, 3:45:00 AM3/15/13
to
On Fri, 15 Mar 2013 08:40:37 +0100, Rosario1903
<Ros...@invalid.invalid> wrote:
>On Thu, 14 Feb 2013 11:11:48 +0100, "M. Strobel"
><sorry_no_...@nowhere.dee> wrote:
>
>>Am 09.02.2013 12:45, schrieb Rosario1903:
>>> why x86 has fpu?
>>> why not use fixed point instructions on integers?
>>> other cpu have fpu?
>>> why the math of fixed point is less good than fpu math?
>>>
>>
>>Integer calculation: 10 / 3 = 3 rest 1
>>Floating point: 10 / 3 = 3.3333333
>>
>>Integer calculation is only exact if you take care of the rest.
>>Floating point is not exact, because you have a periodic .3 (when using the decimal
>>system). But for many uses it is exact enough.
>>
>>BTW FPU floating point formats are based on the binary system, so fractions are
>>represented as 1/2 + 1/4 + 1/8 + 1/16 ... which has it's own problems when converting
>>to and from decimal.
>
>fixed point float format is as above, but withoug fpu... all
>calculations on array of integers
>
>the only seriuous calculation i can think is done by unsigned integer
>and fixed point float
one can miss calcs as
<Ros...@invalid.invalid> wrote:
>On Thu, 14 Feb 2013 11:11:48 +0100, "M. Strobel"
><sorry_no_...@nowhere.dee> wrote:
>
>>Am 09.02.2013 12:45, schrieb Rosario1903:
>>> why x86 has fpu?
>>> why not use fixed point instructions on integers?
>>> other cpu have fpu?
>>> why the math of fixed point is less good than fpu math?
>>>
>>
>>Integer calculation: 10 / 3 = 3 rest 1
>>Floating point: 10 / 3 = 3.3333333
>>
>>Integer calculation is only exact if you take care of the rest.
>>Floating point is not exact, because you have a periodic .3 (when using the decimal
>>system). But for many uses it is exact enough.
>>
>>BTW FPU floating point formats are based on the binary system, so fractions are
>>represented as 1/2 + 1/4 + 1/8 + 1/16 ... which has it's own problems when converting
>>to and from decimal.
>
>fixed point float format is as above, but withoug fpu... all
>calculations on array of integers
>
>the only seriuous calculation i can think is done by unsigned integer
>and fixed point float
12,233e300* 12,45e200
for doing above in fixed point float it would need array of integers
that can hold 300 digits or more...
i don't know but above numbers it seems to me too much long for usual
fpu too
wolfgang kern
Mar 16, 2013, 6:42:31 AM3/16/13
to
Rosario1903 wrote:
....
> one can miss calcs as
> 12,233e300* 12,45e200
> for doing above in fixed point float it would need array of integers
> that can hold 300 digits or more...
Not neccessarily that much, "Fix-point-Float" isn't that new to me :)
> 12,233e300* 12,45e200
> for doing above in fixed point float it would need array of integers
> that can hold 300 digits or more...
My workaround are variable-types which hold an integer mantissa of
any desired size that will always represent all decimal digits for
a wanted precision, but stored as a binary integer (signed or not).
And this types are accompanied by an decimal valued exponent, ie:
one type is defined as 24+8 bits: FF FF 7F 81 mean +8388607e-129
while others might go up to 512+32 bits.
This formats aren't best for heavy calulations, but help for pretty
fast output conversion and got minimal rounding issues.
> i don't know but above numbers it seems to me too much long for usual
> fpu too
24+8, 53+11 and 63+15 bits, and as this exponents are binary valued
and biased too, the exponent limits are
-125..+126, -1022..+1023 and -16382..+16383
__
wolfgang
Rosario1903
Mar 17, 2013, 3:10:30 AM3/17/13
to
On Sat, 16 Mar 2013 11:42:31 +0100, "wolfgang kern" wrote:
>Rosario1903 wrote:
>....
>> one can miss calcs as
>> 12,233e300* 12,45e200
>> for doing above in fixed point float it would need array of integers
>> that can hold 300 digits or more...
>
>Not neccessarily that much, "Fix-point-Float" isn't that new to me :)
>
>My workaround are variable-types which hold an integer mantissa of
>any desired size that will always represent all decimal digits for
>a wanted precision, but stored as a binary integer (signed or not).
>And this types are accompanied by an decimal valued exponent, ie:
>one type is defined as 24+8 bits: FF FF 7F 81 mean +8388607e-129
>while others might go up to 512+32 bits.
>
>This formats aren't best for heavy calulations, but help for pretty
>fast output conversion and got minimal rounding issues.
>Rosario1903 wrote:
>....
>> one can miss calcs as
>> 12,233e300* 12,45e200
>> for doing above in fixed point float it would need array of integers
>> that can hold 300 digits or more...
>
>Not neccessarily that much, "Fix-point-Float" isn't that new to me :)
>
>My workaround are variable-types which hold an integer mantissa of
>any desired size that will always represent all decimal digits for
>a wanted precision, but stored as a binary integer (signed or not).
>And this types are accompanied by an decimal valued exponent, ie:
>one type is defined as 24+8 bits: FF FF 7F 81 mean +8388607e-129
>while others might go up to 512+32 bits.
>
>This formats aren't best for heavy calulations, but help for pretty
>fast output conversion and got minimal rounding issues.
>The main three FPU-float forms use:
>24+8, 53+11 and 63+15 bits, and as this exponents are binary valued
>and biased too, the exponent limits are
>-125..+126, -1022..+1023 and -16382..+16383
the problem with fpu your representation with exponent, is the error
>24+8, 53+11 and 63+15 bits, and as this exponents are binary valued
>and biased too, the exponent limits are
>-125..+126, -1022..+1023 and -16382..+16383
depend from the operation and numbers and *never is constant* [in the
fixed point float representation instead in what i see it is constant
in one operation]
eg c=a*b c has one error if a and b are in one range
c has one error more big if a and b are in one other
range...
this make calculation in fpu + exponent useless in what i see
because it is not easy calculate the error
possibly i remember wrong
Robert Wessel
Mar 17, 2013, 4:37:12 AM3/17/13
to
(under an ULP), so long as you stay away from overflows and underflows
(including denormals). Addition and subtraction have significant
issues with accumulated errors, though.
You should consider reading Goldberg's "What Every Computer Scientist
Should Know About Floating-Point Arithmetic":
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
Rosario1903
Mar 18, 2013, 4:20:13 AM3/18/13
to
On Sun, 17 Mar 2013 03:37:12 -0500, Robert Wessel wrote:
>Rounding error for multiplication and division is fairly constant
>(under an ULP), so long as you stay away from overflows and underflows
i'm not agree
>Rounding error for multiplication and division is fairly constant
>(under an ULP), so long as you stay away from overflows and underflows
1.123 * 1.129
has one error
1.123e50 * 1.129e50
has let say x50 times the error above
in the few i remember
the error dipend not only by operation but the range are the numbers.
if someone has need the operation has error < number
it is difficult calculate error
Robert Wessel
Mar 19, 2013, 12:09:56 AM3/19/13
to
On Mon, 18 Mar 2013 09:20:13 +0100, Rosario1903
<Ros...@invalid.invalid> wrote:
>On Sun, 17 Mar 2013 03:37:12 -0500, Robert Wessel wrote:
>>Rounding error for multiplication and division is fairly constant
>>(under an ULP), so long as you stay away from overflows and underflows
>
>i'm not agree
>1.123 * 1.129
>has one error
>1.123e50 * 1.129e50
>has let say x50 times the error above
>in the few i remember
>
>the error dipend not only by operation but the range are the numbers.
>if someone has need the operation has error < number
>it is difficult calculate error
For good reason we always almost measure error in relative terms. If
<Ros...@invalid.invalid> wrote:
>On Sun, 17 Mar 2013 03:37:12 -0500, Robert Wessel wrote:
>>Rounding error for multiplication and division is fairly constant
>>(under an ULP), so long as you stay away from overflows and underflows
>
>i'm not agree
>1.123 * 1.129
>has one error
>1.123e50 * 1.129e50
>has let say x50 times the error above
>in the few i remember
>
>the error dipend not only by operation but the range are the numbers.
>if someone has need the operation has error < number
>it is difficult calculate error
not, just changing the units would change the error. IOW, if I
present a measurement in kilometers, with a accuracy of 1%, and then
presented the same measurement in millimeters, the accuracy is still
1%, and not a million times bigger, despite the presented number being
a million times larger.
So assuming 32 IEEE floats, in both of your example multiplications
the error would be about 1 part in 2**24.
0 new messages