Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #6484 > unrolled thread
| Started by | Mark Thorson <nospam@sonic.net> |
|---|---|
| First post | 2012-04-10 19:31 -0800 |
| Last post | 2012-04-14 08:02 -0700 |
| Articles | 20 on this page of 133 — 28 participants |
Back to article view | Back to comp.arch
Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-10 19:31 -0800
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 01:29 -0500
Re: Indirect Bit sarr.blumson@alum.dartmouth.org - 2012-04-11 14:48 +0000
Re: Indirect Bit mac <acolvin@efunct.com> - 2012-04-12 14:43 +0000
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:19 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-11 08:32 +0200
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-11 05:49 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:22 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:13 -0700
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-13 20:01 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-14 03:16 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 08:14 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 16:05 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:01 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 13:49 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-13 20:07 -0400
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-14 18:47 +0200
Re: Indirect Bit Morten Reistad <first@last.name> - 2012-04-22 15:26 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-22 23:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 09:18 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-23 19:35 -0400
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 08:37 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 09:42 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 01:58 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 11:26 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 05:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:58 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 10:07 -0700
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-24 04:30 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-24 13:01 +0100
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-11 10:03 -0400
Re: Indirect Bit kenney@cix.compulink.co.uk - 2012-04-11 09:22 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:11 -0700
Re: Indirect Bit Stefan Monnier <monnier@iro.umontreal.ca> - 2012-04-12 18:05 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:13 -0700
Re: Indirect Bit Mark Thorson <nospam@sonic.net> - 2012-04-12 16:55 -0800
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 17:25 -0700
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-12 20:03 -0500
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:33 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-13 15:57 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-13 17:03 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 20:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-11 10:35 -0400
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-11 08:54 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 07:55 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-12 10:16 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-12 11:07 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:34 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-12 11:35 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:41 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-13 14:52 -0700
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 09:24 -0700
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-15 22:45 +0200
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-15 18:04 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-12 21:12 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-12 19:23 +0000
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-13 08:54 +0200
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-14 14:37 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-15 23:42 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:08 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:38 +0000
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:29 -0700
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-16 21:25 -0700
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-12 14:05 -0700
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 10:12 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-14 06:25 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-14 14:50 +0100
Re: Indirect Bit ChrisQ <blackhole@devnull.com> - 2012-04-14 18:01 +0000
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-14 14:00 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-14 20:58 -0400
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 09:57 -0700
Re: Indirect Bit timcaffrey@aol.com (Tim McCaffrey) - 2012-04-20 23:19 +0000
Re: Indirect Bit "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-04-16 08:50 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 18:09 +0100
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-16 23:19 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-17 09:20 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-17 12:49 +0200
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 12:40 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-18 12:01 +0100
Re: Indirect Bit anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 12:34 +0000
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-17 09:10 -0700
Re: Indirect Bit Andrew Reilly <areilly.---@bigpond.net.au> - 2012-04-17 22:05 +0000
Re: Indirect Bit jgk@panix.com (Joe keane) - 2012-04-19 19:37 +0000
Re: Indirect Bit torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-20 11:10 +0200
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-20 11:24 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:01 +0100
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 15:03 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-20 08:01 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-20 16:35 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:10 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:37 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-16 11:21 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-16 19:36 +0100
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-18 11:17 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-18 15:33 -0700
Re: Indirect Bit Andreas Eder <andreas_eder@gmx.net> - 2012-04-19 00:29 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 10:50 +0100
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-19 11:29 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-19 21:39 +0100
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-20 15:14 -0400
Re: Indirect Bit "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-04-20 22:43 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-21 17:14 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-21 19:47 -0500
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 10:45 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 09:57 +0100
Re: Indirect Bit Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-04-22 12:54 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:00 +0100
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 13:28 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 13:04 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-22 23:00 +0200
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-22 18:05 -0400
Re: Indirect Bit glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-22 23:20 +0000
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:22 +0100
Re: Indirect Bit Michael S <already5chosen@yahoo.com> - 2012-04-22 03:56 -0700
Re: Indirect Bit EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-22 12:28 -0400
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 12:56 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:15 -0700
Re: Indirect Bit Nomen Nescio <nobody@dizum.com> - 2012-04-22 22:30 +0200
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-22 21:40 +0100
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-22 17:15 -0500
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 08:26 +0100
Re: Indirect Bit Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-04-23 08:02 -0700
Re: Indirect Bit nmm1@cam.ac.uk - 2012-04-23 17:02 +0100
Re: Indirect Bit Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-23 20:17 +0200
Re: Indirect Bit Robert Wessel <robertwessel2@yahoo.com> - 2012-04-23 13:07 -0500
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-22 13:16 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-23 13:14 -0700
Re: Indirect Bit Anne & Lynn Wheeler <lynn@garlic.com> - 2012-04-23 16:51 -0400
Re: Indirect Bit Quadibloc <jsavard@ecn.ab.ca> - 2012-04-23 14:22 -0700
Re: Indirect Bit MitchAlsup <MitchAlsup@aol.com> - 2012-04-21 11:17 -0700
Re: Indirect Bit jacko <jackokring@gmail.com> - 2012-04-14 08:02 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-19 21:39 +0100 |
| Message-ID | <jmpt5q$6r9$1@needham.csi.cam.ac.uk> |
| In reply to | #6579 |
In article <16603280.18.1334860198726.JavaMail.geo-discussion-forums@ynnf1>,
MitchAlsup <MitchAlsup@aol.com> wrote:
>>
>> >Certain floating-point optimizations are legitimate; others are not,
>> >because they would result in massive loss of precision under some
>> >circumstances. In general, compiler writers do know which is which,
>> >and only perform legitimate optimizations when working with floating-
>> >point.
>>
>> Absolutely NOT! Mitch has pointed out some of the issues, but the
>> problem is well-known to be insoluble in theory and practice; the
>> compiler is almost the worst place to make such decisions.
>
>For todays lesson in FP optimizations: consider the following::
>
> x = 3.0/7.0
> if( x == 3.0/7.0 ) blah();
>
>A) Is it legal for the optimizer to compute the 3.0/7.0 for the
>assignment statement at compile time?
>B) is it legal for the optimizer to compile the 3.0/7.0 for the
>if-statement at compile time?
>C) is it legal for the optimizer to dead-code-eliminate the if-
>statement leaving only the call to blah() ?
>
>{Leaving out the falacy of EVER comparing FP numbers for exactness}
>
>Answers:
>A) yes
>B) no
>C) no
>
>This snippet of code is designed to determine if arithmetic operations
>are carried out with more precision in registers than is store in memory.
>For machines that have more precision in regsiters than in memory, blah
>is never called.
I am afraid not. In both of Fortran and C, the compiler is allowed
to perform those calculations at compile time or not, according to
whim, and whether blah() must be called is unclear. But, in C, it
is a LOT worse than that, because the evaluation rules are wildly
different between C90 and C99, unclear in both, and often not
followed by compilers.
Sorry.
Regards,
Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-04-20 15:14 -0400 |
| Message-ID | <1Bikr.12248$mL3.10431@newsfe23.iad> |
| In reply to | #6579 |
MitchAlsup wrote:
>
> For todays lesson in FP optimizations: consider the following::
>
> x = 3.0/7.0
> if( x == 3.0/7.0 ) blah();
>
> A) Is it legal for the optimizer to compute the 3.0/7.0 for the
> assignment statement at compile time?
> B) is it legal for the optimizer to compile the 3.0/7.0 for the
> if-statement at compile time?
> C) is it legal for the optimizer to dead-code-eliminate the if-
> statement leaving only the call to blah() ?
>
> {Leaving out the falacy of EVER comparing FP numbers for exactness}
>
> Answers:
> A) yes
> B) no
> C) no
>
> This snippet of code is designed to determine if arithmetic operations
> are carried out with more precision in registers than is store in memory.
> For machines that have more precision in regsiters than in memory, blah
> is never called.
>
> Mitch
Isn't this occurring because of silent type conversions,
and perhaps indicative of a compiler bug?
It seems to me that if the compiler supported and
x was declared long double (80 bit float),
and 3.0 and 7.0 were converted to long double type,
and any intermediate values that had to be spilled
from registers were saved as long doubles,
that it would all work as expected (A=yes, B=yes, C=yes).
The weirdness is because there is a silent conversion to
double (64 bits) on save, then back to long double on load.
In other words, its not the extended precision that is the problem,
rather an inappropriate usage of it.
Or is something else afoot?
Eric
[toc] | [prev] | [next] | [standalone]
| From | "Andy (Super) Glew" <andy@SPAM.comp-arch.net> |
|---|---|
| Date | 2012-04-20 22:43 -0700 |
| Message-ID | <4F924908.6040908@SPAM.comp-arch.net> |
| In reply to | #6587 |
On 4/20/2012 12:14 PM, EricP wrote:
> MitchAlsup wrote:
>>
>> For todays lesson in FP optimizations: consider the following::
>>
>> x = 3.0/7.0
>> if( x == 3.0/7.0 ) blah();
>>
>> A) Is it legal for the optimizer to compute the 3.0/7.0 for the
>> assignment statement at compile time?
>> B) is it legal for the optimizer to compile the 3.0/7.0 for the
>> if-statement at compile time?
>> C) is it legal for the optimizer to dead-code-eliminate the if-
>> statement leaving only the call to blah() ?
>>
>> {Leaving out the falacy of EVER comparing FP numbers for exactness}
>>
>> Answers:
>> A) yes
>> B) no
>> C) no
>>
>> This snippet of code is designed to determine if arithmetic operations
>> are carried out with more precision in registers than is store in memory.
>> For machines that have more precision in regsiters than in memory, blah
>> is never called.
>>
>> Mitch
>
> Isn't this occurring because of silent type conversions,
> and perhaps indicative of a compiler bug?
>
> It seems to me that if the compiler supported and
> x was declared long double (80 bit float),
> and 3.0 and 7.0 were converted to long double type,
> and any intermediate values that had to be spilled
> from registers were saved as long doubles,
> that it would all work as expected (A=yes, B=yes, C=yes).
>
> The weirdness is because there is a silent conversion to
> double (64 bits) on save, then back to long double on load.
>
> In other words, its not the extended precision that is the problem,
> rather an inappropriate usage of it.
>
> Or is something else afoot?
>
> Eric
The problem was that on the old x87 floating point, there were always
silent type conversions.
Normally all operations were done in 80 bit precision, and converted
to/from 32 or 64 only when moved to/from memory.
Now, x87 has a precision control, PC, with can be set so that the
register operations were 32 or 64 bit rather than 80 bit. But (1) PC is
slow to change, and (2) PC only affected mantissa bits, not exponent.
So, no matter what, there was a silent type conversion, to a register
type with the same number of mantissa bits, but more exponent bits.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-04-21 17:14 -0400 |
| Message-ID | <QrFkr.8887$M37.580@newsfe01.iad> |
| In reply to | #6589 |
Andy (Super) Glew wrote:
> On 4/20/2012 12:14 PM, EricP wrote:
>> MitchAlsup wrote:
>>>
>>> For todays lesson in FP optimizations: consider the following::
>>>
>>> x = 3.0/7.0
>>> if( x == 3.0/7.0 ) blah();
>>>
>>> A) Is it legal for the optimizer to compute the 3.0/7.0 for the
>>> assignment statement at compile time?
>>> B) is it legal for the optimizer to compile the 3.0/7.0 for the
>>> if-statement at compile time?
>>> C) is it legal for the optimizer to dead-code-eliminate the if-
>>> statement leaving only the call to blah() ?
>>>
>>> {Leaving out the falacy of EVER comparing FP numbers for exactness}
>>>
>>> Answers:
>>> A) yes
>>> B) no
>>> C) no
>>>
>>> This snippet of code is designed to determine if arithmetic operations
>>> are carried out with more precision in registers than is store in
>>> memory.
>>> For machines that have more precision in regsiters than in memory, blah
>>> is never called.
>>>
>>> Mitch
>>
>> Isn't this occurring because of silent type conversions,
>> and perhaps indicative of a compiler bug?
>>
>> It seems to me that if the compiler supported and
>> x was declared long double (80 bit float),
>> and 3.0 and 7.0 were converted to long double type,
>> and any intermediate values that had to be spilled
>> from registers were saved as long doubles,
>> that it would all work as expected (A=yes, B=yes, C=yes).
>>
>> The weirdness is because there is a silent conversion to
>> double (64 bits) on save, then back to long double on load.
>>
>> In other words, its not the extended precision that is the problem,
>> rather an inappropriate usage of it.
>>
>> Or is something else afoot?
>>
>> Eric
>
> The problem was that on the old x87 floating point, there were always
> silent type conversions.
>
> Normally all operations were done in 80 bit precision, and converted
> to/from 32 or 64 only when moved to/from memory.
>
> Now, x87 has a precision control, PC, with can be set so that the
> register operations were 32 or 64 bit rather than 80 bit. But (1) PC is
> slow to change, and (2) PC only affected mantissa bits, not exponent.
> So, no matter what, there was a silent type conversion, to a register
> type with the same number of mantissa bits, but more exponent bits.
>
Just thinking a bit more on this...
There are a few platforms that support multiple incompatible types.
VAX had hardware formats
F (32 bit, 23 bit mantissa)
D (64 bit, 55 bit mantissa)
G (64 bit, 52 bit mantissa)
H (128 bit, 112 bit mantissa)
These type all had separate instructions and
could all be in use at the same time.
Later Alpha dropped hardware support for D and H formats
but added IEEE32 (23 bit mantissa) and IEEE64 (52 bit mantissa)
(same precision but different layouts than F and G).
IBM Z series has their hex normalized 32 bit and 64 bit 370 formats,
and (I assume) IEEE 32 and 64 bit formats, and now decimal hardware.
-----------------------------------------
There is no reason that these cpus could not have multiple
incompatible types in use, in the same routine, at the same time.
Given the above varieties, it seems to me that that there is a proper
method for a compiler to operate on float constants in these environments,
irrespective of language.
It must transport the literal decimal token unchanged to the expression.
Only after the data type at the point of the literal has been determined
can conversion be performed using the appropriate precision, and any
static expression evaluation performed using that types' operators.
So the correct method for evaluating the IF statement is to
use X's data type to bind the literals 3.0 and 7.0 type.
Then perform the division in that type.
The propagation of constants allows the optimization.
That approach would work on all the hardware, except x87 if
the PC bit is missing and the data type was not long double.
As the x87 is only capable of operating on long doubles,
everything must be converted to that data type.
The reason the IF optimization fails on x87 is because the
compiler has erroneously compared incompatible data types.
if (x == 3.0/7.0) blah();
^ ^
type=double type=long double
The compiler should not be comparing mismatched data types.
It should have built-in functions for such conversions,
so the compiler must patch the expression to become
if (CvtFloat64To80(x) == CvtFloatStrTo80(3.0)/CvtFloatStrTo80(7.0)) blah();
It should now be able to statically determine the IF is always FALSE on x87.
Eric
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-04-21 19:47 -0500 |
| Message-ID | <djk6p7h2tb6j3epq6ghncj0nsjqku1rksj@4ax.com> |
| In reply to | #6591 |
On Sat, 21 Apr 2012 17:14:28 -0400, EricP <ThatWouldBeTelling@thevillage.com> wrote: >IBM Z series has their hex normalized 32 bit and 64 bit 370 formats, >and (I assume) IEEE 32 and 64 bit formats, and now decimal hardware. 128 bit formats of each as well. (128 bit hex FP got added as an optional feature on S/370, although 128 division didn't come as a standard item until XA, in the early eighties). IEEE binary got added with the 9672-G5s in 1998, decimal FP on the z9's in 2007. There are now a number of instructions which convert between formats, and things like that.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2012-04-22 10:45 +0200 |
| Message-ID | <5de48b1358f17f5567d4cf5dd4ec3a6f@dizum.com> |
| In reply to | #6591 |
EricP <ThatWouldBeTelling@thevillage.com> wrote: > IBM Z series has their hex normalized 32 bit and 64 bit 370 formats, They also have had 128 bit formats since the S/360 days (late 1960s). It became standard on S/370 but was available as an optional feature at some point in the S/360 lineup. > and (I assume) IEEE 32 and 64 bit formats, Yes, for about 15 or 20 years and that includes 128 bit AFAIK. > and now decimal hardware. Unless you are talking about something new, IBM has had decimal hardware instructions since the first release of S/360 in 1964. They're used heavily in commercial processing as you might imagine. This includes not only arithmetic instructions but also nice features such as instructions to round and format the data for display.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-22 09:57 +0100 |
| Message-ID | <jn0h6k$m92$1@needham.csi.cam.ac.uk> |
| In reply to | #6593 |
In article <5de48b1358f17f5567d4cf5dd4ec3a6f@dizum.com>, Nomen Nescio <nobody@dizum.com> wrote: >EricP <ThatWouldBeTelling@thevillage.com> wrote: > >> IBM Z series has their hex normalized 32 bit and 64 bit 370 formats, > >They also have had 128 bit formats since the S/360 days (late 1960s). It >became standard on S/370 but was available as an optional feature at some >point in the S/360 lineup. I believe that there were System/370s without it. On such systems, and on all for division, the instructions were trapped and emulated. If I recall, the division microcode was enabled only under MVS/XA. The emulation was typically available only for Fortran or if you wrote the handler yourself, though the emulation code was built-in. The format was also damn-near useless for most purposes, because it had the same exponent range as the lower precisions (10^75). Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <"terje.mathisen at tmsw.no"> |
|---|---|
| Date | 2012-04-22 12:54 +0200 |
| Message-ID | <oj4d69-ah92.ln1@ntp6.tmsw.no> |
| In reply to | #6594 |
nmm1@cam.ac.uk wrote: > I believe that there were System/370s without it. On such systems, > and on all for division, the instructions were trapped and emulated. > If I recall, the division microcode was enabled only under MVS/XA. > The emulation was typically available only for Fortran or if you > wrote the handler yourself, though the emulation code was built-in. > > The format was also damn-near useless for most purposes, because it > had the same exponent range as the lower precisions (10^75). Isn't this the same idea as many ~128-bit fp libraries which uses pairs of doubles, i.e. the exponent range is given by the first/top half? If you have FMAC operations without rounding in the middle, you can do operations twice (fused/separate) and get hold of the trailing part. Not nearly as nice as a proper [S][EXP][MANT] format but still a very useful hack. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-22 13:00 +0100 |
| Message-ID | <jn0rsu$n24$1@needham.csi.cam.ac.uk> |
| In reply to | #6596 |
In article <oj4d69-ah92.ln1@ntp6.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >> >> The format was also damn-near useless for most purposes, because it >> had the same exponent range as the lower precisions (10^75). > >Isn't this the same idea as many ~128-bit fp libraries which uses pairs >of doubles, i.e. the exponent range is given by the first/top half? Yes. >If you have FMAC operations without rounding in the middle, you can do >operations twice (fused/separate) and get hold of the trailing part. > >Not nearly as nice as a proper [S][EXP][MANT] format but still a very >useful hack. :-) But not much use except as a hack, because macheps**3 underflows. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2012-04-22 13:28 +0200 |
| Message-ID | <f7ddc15015d93c5e12b27e7b52d8dcf4@dizum.com> |
| In reply to | #6594 |
nmm1@cam.ac.uk wrote: > In article <5de48b1358f17f5567d4cf5dd4ec3a6f@dizum.com>, > Nomen Nescio <nobody@dizum.com> wrote: > >EricP <ThatWouldBeTelling@thevillage.com> wrote: > > > >> IBM Z series has their hex normalized 32 bit and 64 bit 370 formats, > > > >They also have had 128 bit formats since the S/360 days (late 1960s). It > >became standard on S/370 but was available as an optional feature at some > >point in the S/360 lineup. > > I believe that there were System/370s without it. You may well be right. I've only used the high end of the range so I may have missed something. Indeed the Principles of Operation for S/370 mentions an extended floating point facility. > On such systems, and on all for division, the instructions were trapped > and emulated. Now that is curious. If so I wouldn't have expected to see the Divide in the Principles of Operation. > If I recall, the division microcode was enabled only under MVS/XA. > The emulation was typically available only for Fortran or if you > wrote the handler yourself, though the emulation code was built-in. The hardware divide is noted back to 1974, well before XA (1981/82). It had to have been implemented somehow back then. > The format was also damn-near useless for most purposes, because it > had the same exponent range as the lower precisions (10^75). That sounds right but I think the significant digits in the mantissa helped. They couldn't get past their excess 64 notation until they finally implemented IEEE maths.
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-22 13:04 +0100 |
| Message-ID | <jn0s4g$n2p$1@needham.csi.cam.ac.uk> |
| In reply to | #6597 |
In article <f7ddc15015d93c5e12b27e7b52d8dcf4@dizum.com>, Nomen Nescio <nobody@dizum.com> wrote: > >> On such systems, and on all for division, the instructions were trapped >> and emulated. > >Now that is curious. If so I wouldn't have expected to see the Divide in the >Principles of Operation. It wasn't actually an opcode - merely a macro for an extended opcode, and was reserved so that compilers could generate the code and the run-time system trap and emulate it. >> If I recall, the division microcode was enabled only under MVS/XA. >> The emulation was typically available only for Fortran or if you >> wrote the handler yourself, though the emulation code was built-in. > >The hardware divide is noted back to 1974, well before XA (1981/82). It had >to have been implemented somehow back then. By the Fortran run-time system trapping the interrupt. There may have been a machine that implemented it in hardware, but none of the standard ones did. >> The format was also damn-near useless for most purposes, because it >> had the same exponent range as the lower precisions (10^75). > >That sounds right but I think the significant digits in the mantissa >helped. They couldn't get past their excess 64 notation until they finally >implemented IEEE maths. Essentially only for things like inner products, and even then you had to scale. Been there - done that :-) Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-04-22 23:00 +0200 |
| Message-ID | <6dcf5b7a18f279b099fda07eaab07121@msgid.frell.theremailer.net> |
| In reply to | #6599 |
I'm cross posting this to comp.lang.fortran since Glen hangs out there and seems to have good recollection of all things numerical on early IBM boxes. nmm1@cam.ac.uk wrote: > In article <f7ddc15015d93c5e12b27e7b52d8dcf4@dizum.com>, > Nomen Nescio <nobody@dizum.com> wrote: > > > >> On such systems, and on all for division, the instructions were trapped > >> and emulated. > > > >Now that is curious. If so I wouldn't have expected to see the Divide in the > >Principles of Operation. > > It wasn't actually an opcode - merely a macro for an extended opcode, > and was reserved so that compilers could generate the code and the > run-time system trap and emulate it. Four floating point divide opcodes are defined in the Principles of Operation along with descriptions of how they work. I'm referring to GA22-7000-4 dated Sept. 1975 which I believe is available on bitsavers.org. Perhaps you have confused this with the 360? > >> If I recall, the division microcode was enabled only under MVS/XA. > >> The emulation was typically available only for Fortran or if you > >> wrote the handler yourself, though the emulation code was built-in. > > > >The hardware divide is noted back to 1974, well before XA (1981/82). It had > >to have been implemented somehow back then. > > By the Fortran run-time system trapping the interrupt. There may > have been a machine that implemented it in hardware, but none of > the standard ones did. Many 360 & 370 opcodes were microcoded and are to this very day on z/Arch. That does not imply the use of macros or traps, it's transparently supported by the processor. Interrupt handling is very expensive on MVS and I would be very surprised if FORTRAN used this for anything other than the normal SPIE processing of application programming exceptions such as zero-divide, underflow, etc. I would think the Extended Floating Point facility is nothing more than microcode assists but even so 4 flavors of hardware divide seem to be supported in the base architecture. > >> The format was also damn-near useless for most purposes, because it > >> had the same exponent range as the lower precisions (10^75). > > > >That sounds right but I think the significant digits in the mantissa > >helped. They couldn't get past their excess 64 notation until they finally > >implemented IEEE maths. > > Essentially only for things like inner products, and even then > you had to scale. Been there - done that :-)
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2012-04-22 18:05 -0400 |
| Message-ID | <m3r4vfwhge.fsf@garlic.com> |
| In reply to | #6608 |
Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> writes: > Many 360 & 370 opcodes were microcoded and are to this very day on > z/Arch. That does not imply the use of macros or traps, it's transparently > supported by the processor. Interrupt handling is very expensive on MVS and > I would be very surprised if FORTRAN used this for anything other than the > normal SPIE processing of application programming exceptions such as > zero-divide, underflow, etc. I would think the Extended Floating Point > facility is nothing more than microcode assists but even so 4 flavors of > hardware divide seem to be supported in the base architecture. standard 360s up through 360/65 were microcoded ... majority of 370s were microcoded. 370s up thru 145/148 were "vertical" microcode ... would look something like modern day "hercules" that emulates 370 on intel processors. 370 vertical microcode tended to avg. 10 native instructions per 370 emulated instruction. i got roped into "ECPS" ... the followon to 135/145 was 138/148 ... it had faster technology and bigger memories ... it also had extra 6kbytes of space for "microcode". The idea was to find the 6kbytes of highest used instructions in the vm370 virtual machine kernel and recode in native microcode ... which got factor of 10 times performance improvemnt. old post with some of the analysis that went into deciding 6kbytes of vm370 kernel intructions moved to microcode. 155/158 & 165/168 were "horizontal" microcode machines. transition from 155/165 to 158/168 was faster memory technology and various microcode optimization ... aka 165 avg. 2.1 machine cycles per 370 instruction to 1.6 machine cycles per 370 instruction. in the middle of the 370 period ... corporation had the "Future System" effort that was going to completely replace 370 ... with something different ... as a result lots of 370 activity was suspended &/or killed. when "FS" imploded there was mad rush to the get products back into the 370 pipeline. part of this was Q&D 303x in parallel with 370-xa 3081. the 158 had "integrated channels" ... native engine had two sets of microcode ... one for channel operation and the other for 370 emulation sharing the engine. for 303x ... all the machines got external channels with the "channel director". This was actually a separate box with the 158 native engine with only the integrated channel microcode (& w/o the 370 emulation microcode). The 3031 was a 158 native engine with the 370 emulation microcode (and 2nd 158 native engine with integrated channel microcode). The 3032 was a 168-3 with new covers reconfigured to work with 303x channel director (i.e. native 158 engine with integrated channel microcode). The 3033 started out being 168 wiring logic remapped to 20% faster chips. The new faster chips also had approx. ten times the circuits/chip that initially was going unused (3033 would be 20% faster than 168-3). There was then some optimization to make more use of the additional circuits/chip and 3033 eventually shipped approx. 1.5 times 168-3 (long with one or more channel directors ... 158 native engines with integrated channel microcode) ... 3033 getting very close to 1 370 instruction per machine cycle. in the 303x time-frame ... the followon to 138/148 was 4331/4341 (again vertical microcode machines still approx 10:1 ratio of native to 370 instructions). there was various efforts to try and do something analogous for the 3033 ... however since 3033 was already close to one 370 instruction per machine cycle (in horizontal microcode) ... most such activity actually ran slower (on 3033). in parallel with this there was work on 370-xa 3081 using warmed over "FS" technology ... described here http://www.jfsowa.com/computer/memo125.htm I've frequently contended that the significant hardware complexity of "FS" played major role in 801/risc going to the opposite extreme. 1980, there was effort to use 801/risc "iliad" chips to converge/replace the large number of internal "CICS" (vertical) microcode engines ... 370 processors, other processors, large variety of controllers. etc. For a wide variety of reasons all those efforts floundered ... which saw some number of 801/risc engineers leaving and going to work on risc at other vendors. part of this was to have been the 4361/4381 followons to the 4331/4341. I contributed to analysis that shot the 801/risc Iliad for 4361/4381. The argument was that chips were getting big enough that it was starting to be possible to implement a significant part of 370 natively in silicon (rather than all microcode). This showed better price/performance than all microcode 370 on 801/risc. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-04-22 23:20 +0000 |
| Message-ID | <jn23of$8q7$1@speranza.aioe.org> |
| In reply to | #6608 |
In comp.lang.fortran Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> wrote:
> I'm cross posting this to comp.lang.fortran since Glen hangs out
> there and seems to have good recollection of all things numerical
> on early IBM boxes.
Only last week was discussion on the Q format descriptor and the
H Extended compiler that generated code for REAL*16 and COMPLEX*32
data types.
(snip)
>> >> On such systems, and on all for division, the instructions
>> >> were trapped and emulated.
This is a little hard to follow, but somehow regards extended
(quadruple) precision floating point on S/360 and S/370.
It is fairly well documented, including a whole article in the
IBM Systems Journal, and I have the issue that includes it.
>> > Now that is curious. If so I wouldn't have expected to see the
>> > Divide in the Principles of Operation.
Extended precision first appeared in the 360/85. There seems to have
been some system to test out different ideas on different S/360
models. Virtual storage first appeared on the 360/67, fairly close
to the way it was later done on S/370. IBM did studies and found
that extended precision divide was needed rarely enough that it
made more sense to implement it as software emulation.
One of my first disassembly projects, by hand, was IEAXPDXR and
IEAXPALL. The first is the emulation for DXR, the latter for all
extended precsion opcodes. (The DXR emulation in IEAXPALL directly
calls emulation routines for other extended precision instructions.)
>> It wasn't actually an opcode - merely a macro for an extended opcode,
>> and was reserved so that compilers could generate the code and the
>> run-time system trap and emulate it.
Unlike the other RR instructions, which are two bytes long with
a one byte opcode, DXR is X'B22D' and a four byte instruction.
Now, exactly what the rules are on what instructions the assemblers
recognize I don't know, but yes there is a macro DXR to generate
the appropriate code. Note that the diagnose instruction, implemented
in hardware, has no assembler mnemonic. The extended branch
instructions (such as BNE, BGT, etc.) generate B instructions
with the appropriate mask.
MACRO
&LABEL DXR &R1,&R2
.* INSURE LABEL IS ON HALF WORD BOUNDARY
DS 0H
.* GENERATE OPCODE FOR EXTENDED PRECISION DIVIDE
&LABEL DC XL2'B22D'
.* USE EXTENDED PRECISION MULTIPLY INSTRUCTION
.* TO ALLOW THE ASSEMBLER TO DO THE REGISTER
.* ANALYSIS
MXR &R1,&R2
.* MAKE THE THIRD BYTE OF THE INSTRUCTION BINARY
.* ZERO, IE REMOVE MXR OP CODE.
ORG *-2
DC X'00'
ORG *+1
.* THE FINAL FORMAT OF THE EXTENDED PRECISION
.* DIVIDE INSTRUCTION, BYTE BY BYTE, IS
.*
.* B2 2D 00 R1R2
MEND
> Four floating point divide opcodes are defined in the Principles of
> Operation along with descriptions of how they work. I'm referring to
> GA22-7000-4 dated Sept. 1975 which I believe is available on
> bitsavers.org. Perhaps you have confused this with the 360?
It is not in the GA22-7000-3 version. Exactly which machines
did and didn't have it in hardware or microcode, I am not sure.
Many features and instructions described are optional on
different models.
>> >> If I recall, the division microcode was enabled only under MVS/XA.
>> >> The emulation was typically available only for Fortran or if you
>> >> wrote the handler yourself, though the emulation code was built-in.
IEAXPDXR and IEAXPALL are written to be called from an SPIE routine
after decoding an illegal opcode exception.
Now, the 360/91 didn't implement the decimal instructions in
hardware and instead the OS included the emulation routines.
Instead, these require the user to write an SPIE routine and
then call the appropriate routine from there.
>> >The hardware divide is noted back to 1974, well before XA
>> >(1981/82). It had to have been implemented somehow back then.
>> By the Fortran run-time system trapping the interrupt. There may
>> have been a machine that implemented it in hardware, but none of
>> the standard ones did.
> Many 360 & 370 opcodes were microcoded and are to this very
> day on z/Arch. That does not imply the use of macros or traps,
> it's transparently supported by the processor. Interrupt
> handling is very expensive on MVS and I would be very
> surprised if FORTRAN used this for anything other than the
> normal SPIE processing of application programming exceptions
> such as zero-divide, underflow, etc. I would think the
> Extended Floating Point facility is nothing more than
> microcode assists but even so 4 flavors of hardware divide
> seem to be supported in the base architecture.
>> >> The format was also damn-near useless for most purposes, because
>> >> it had the same exponent range as the lower precisions (10^75).
The format is conveniently designed to simplify software emulation.
The significand is 112 bits, with a sign and exponent field in each
half. The instructions generate an exponent 14 less (unless it
wraps) for the low half.
>> > That sounds right but I think the significant digits in the
>> > mantissa helped. They couldn't get past their excess 64
>> > notation until they finally implemented IEEE maths.
>> Essentially only for things like inner products, and even then
>> you had to scale. Been there - done that :-)
-- glen
[toc] | [prev] | [next] | [standalone]
| From | nmm1@cam.ac.uk |
|---|---|
| Date | 2012-04-23 08:22 +0100 |
| Message-ID | <jn2vv1$qvd$1@needham.csi.cam.ac.uk> |
| In reply to | #6608 |
In article <6dcf5b7a18f279b099fda07eaab07121@msgid.frell.theremailer.net>, Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> wrote: >I'm cross posting this to comp.lang.fortran since Glen hangs out there and >seems to have good recollection of all things numerical on early IBM boxes. He does, but we rarely disagree on such matters. >Many 360 & 370 opcodes were microcoded and are to this very day on >z/Arch. That does not imply the use of macros or traps, it's transparently >supported by the processor. Interrupt handling is very expensive on MVS and >I would be very surprised if FORTRAN used this for anything other than the >normal SPIE processing of application programming exceptions such as >zero-divide, underflow, etc. I would think the Extended Floating Point >facility is nothing more than microcode assists but even so 4 flavors of >hardware divide seem to be supported in the base architecture. You would be wrong. Interrupts were used for all floating-point on systems without the floating-point option, for all extended double on ones without that hardware, and for extended division before MVS/XA. I once tried to get IBM to call the code directly, but failed. Regards, Nick Maclaren.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2012-04-22 03:56 -0700 |
| Message-ID | <1c9e3e56-8ed2-4a7f-915b-77ee32aa9bb2@f17g2000yqj.googlegroups.com> |
| In reply to | #6593 |
On Apr 22, 11:45 am, Nomen Nescio <nob...@dizum.com> wrote: > EricP <ThatWouldBeTell...@thevillage.com> wrote: > > IBM Z series has their hex normalized 32 bit and 64 bit 370 formats, > > They also have had 128 bit formats since the S/360 days (late 1960s). It > became standard on S/370 but was available as an optional feature at some > point in the S/360 lineup. > > > and (I assume) IEEE 32 and 64 bit formats, > > Yes, for about 15 or 20 years and that includes 128 bit AFAIK. > > > and now decimal hardware. > > Unless you are talking about something new, IBM has had decimal hardware > instructions since the first release of S/360 in 1964. They're used heavily > in commercial processing as you might imagine. This includes not only > arithmetic instructions but also nice features such as instructions to round > and format the data for display. Yes, he is talking about something relatively new (5 years) - decimal floating point. Despite the name, it is implemented as base 1000 rather than base 10. That helps to achieve almost the same information density as binary floating point.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2012-04-22 12:28 -0400 |
| Message-ID | <clWkr.54050$T5.9029@newsfe13.iad> |
| In reply to | #6595 |
Michael S wrote: > On Apr 22, 11:45 am, Nomen Nescio <nob...@dizum.com> wrote: >> Unless you are talking about something new, IBM has had decimal hardware >> instructions since the first release of S/360 in 1964. They're used heavily >> in commercial processing as you might imagine. This includes not only >> arithmetic instructions but also nice features such as instructions to round >> and format the data for display. > > Yes, he is talking about something relatively new (5 years) - decimal > floating point. > Despite the name, it is implemented as base 1000 rather than base 10. > That helps to achieve almost the same information density as binary > floating point. Yes that is what I meant. I don't know how the 360's decimal instructions were implemented. VAX had "decimal instructions" (of course it did... it had at least one of everything) but these were really just subroutines implemented in microcode so to me that doesn't count as a hardware implementation. VAX also had polynomial and string instructions but again these were just software as microcode. I seem to recall that it turned out to be faster to implement your own 8 packed decimals per 32 bit long than use the instructions. Eric
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-04-22 12:56 -0500 |
| Message-ID | <kuf8p71kcvr42rbiqvkm11cb2r5969g9kj@4ax.com> |
| In reply to | #6602 |
On Sun, 22 Apr 2012 12:28:04 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:
>Michael S wrote:
>> On Apr 22, 11:45 am, Nomen Nescio <nob...@dizum.com> wrote:
>>> Unless you are talking about something new, IBM has had decimal hardware
>>> instructions since the first release of S/360 in 1964. They're used heavily
>>> in commercial processing as you might imagine. This includes not only
>>> arithmetic instructions but also nice features such as instructions to round
>>> and format the data for display.
>>
>> Yes, he is talking about something relatively new (5 years) - decimal
>> floating point.
>> Despite the name, it is implemented as base 1000 rather than base 10.
>> That helps to achieve almost the same information density as binary
>> floating point.
Densely Packed Decimal FP as used in IEEE decimal FP is rather odd.
First, while most of the number is encoded in base 1000 (three decimal
digits per ten bits), it's not a straight mapping to 0x000-0x3e7. For
example, while (decimal) 000-079 map to 0x000-0x079 (a straight
BCD-like mapping), (decimal) 080-099 map to 0x00a, 0x00b, 0x02a,
0x2b, 0x04a, 0x04b, 0x04a, 0x4b, 0x4e, 0x04f, 0x01a, 0x01b, 0x03a,
0x3b, 0x05a, 0x05b, 0x07a, 0x7b, 0x5e and 0x05f.
Second, each format contain an additional decimal digit, which is
encoded in combination with the decimal exponent - for example, on the
short format, an exponent of 0-191 (raw) and a digit of the mantissa
are encoded into 11 ("combination") bits. That plus 20 bits of
"Encoded Trailing Significand" nets 7 digits (the digit encoded with
the exponent, and the two 10 bit base-1000 digits), and leaves room
for a sign bit.
The odd encodings are there to make it easier to decompose the various
bits into pure decimal, mainly by creatively rearranging bits, rather
than applying repeated divisions by 10.
>Yes that is what I meant.
>I don't know how the 360's decimal instructions were implemented.
>VAX had "decimal instructions" (of course it did...
>it had at least one of everything) but these were
>really just subroutines implemented in microcode
>so to me that doesn't count as a hardware implementation.
>VAX also had polynomial and string instructions but again
>these were just software as microcode.
>
>I seem to recall that it turned out to be faster to implement your
>own 8 packed decimals per 32 bit long than use the instructions.
S/360 had fixed point decimal since day one (although it was part of
the "commercial" feature, and thus not installed on all machines of
that era). This supported the usual two operand instructions on
variable length storage operands (1-16 bytes, holding 1-31* BCD digits
plus a sign). Registers were not used to hold operands.
Decimal floating point is new with the z9's, and uses the same FP
registers as the hex and binary FP instructions (and there are
storage-to-register instructions as well for all three formats, but no
storage-to-storage).
*with some weirdness in lengths for multiply and divide
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2012-04-22 13:15 -0700 |
| Message-ID | <44834bf6-d5f3-4551-af29-0fbc9eb91b83@po5g2000pbb.googlegroups.com> |
| In reply to | #6603 |
On Apr 22, 11:56 am, Robert Wessel <robertwess...@yahoo.com> wrote: > Densely Packed Decimal FP as used in IEEE decimal FP is rather odd. > > First, while most of the number is encoded in base 1000 (three decimal > digits per ten bits), it's not a straight mapping to 0x000-0x3e7. No, it isn't. But that's because base-1000 would require time- consuming multiplication to generate from three BCD digits. Instead, it's a coding for three BCD digits that only requires a few layers of logic. The basic principle (but not their actual coding) is: If your three-digit decimal number is composed entirely of digits from 0 to 7, then encode it as something like 0aaabbbccc where aaa, bbb, and ccc are the three digits, and the 0 is a flag to put the number in this category. If one of the digits is, instead, an 8 or a 9, then code it as 101Abbbccc, 110aaaBccc, or 111aaabbbC, where the capital letter is coded as 0=8, 1=9. If two of them are 8 or 9, then go to another level of coding: 10001aaaBC, 10010AbbbC, or 1011ABccc. Finally, if all three are 8 or 9, you only need eight more codes, but you have 32 codes left (since 1024 is 24 more than 1000, this works out right). DPD is more complicated than this to allow truncation of the first three bits to code two digits, and to simplify the logic a bit more. It's a variant of Chen-Ho encoding. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2012-04-22 22:30 +0200 |
| Message-ID | <4d55a2d89ceee7dee6f37bab28e8c924@dizum.com> |
| In reply to | #6602 |
EricP <ThatWouldBeTelling@thevillage.com> wrote: > Michael S wrote: > > On Apr 22, 11:45 am, Nomen Nescio <nob...@dizum.com> wrote: > >> Unless you are talking about something new, IBM has had decimal hardware > >> instructions since the first release of S/360 in 1964. They're used heavily > >> in commercial processing as you might imagine. This includes not only > >> arithmetic instructions but also nice features such as instructions to round > >> and format the data for display. > > > > Yes, he is talking about something relatively new (5 years) - decimal > > floating point. I missed the "floating point" part and just read decimal. > > Despite the name, it is implemented as base 1000 rather than base 10. > > That helps to achieve almost the same information density as binary > > floating point. Interesting, I'll need to check up on that. > Yes that is what I meant. > I don't know how the 360's decimal instructions were implemented. > VAX had "decimal instructions" (of course it did... > it had at least one of everything) but these were > really just subroutines implemented in microcode > so to me that doesn't count as a hardware implementation. > VAX also had polynomial and string instructions but again > these were just software as microcode. > > I seem to recall that it turned out to be faster to implement your > own 8 packed decimals per 32 bit long than use the instructions. On IBM Packed decimal has always been a standard and highly used format. It works great for monetary calcs. It is similar to what people know as BCD, but with a few extras including opcodes that convert back and forth from display (zoned decimal) to packed decimal. It's heavily optimized since it's used so much in commerical programming. COBOL uses it heavily. I believe it's not catered for in FORTRAN at all.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.arch
csiph-web