Re: Specifying precision

glen herrmannsfeldt wrote in message ...
>Richard Maine wrote:
>> Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
>
>>>Could someone explain to me the cumbersomeness of
>
>> SELECTED_REAL(INT)_KIND() ??
>
>>>I agree the syntax is a bit wordy,
>
>Not so wordy as
>
> INTEGER (SELECTED_INT_KIND(9)) :: I
>
>compare to C's
>
> int i;
>
>> Yes, that's one thing - one that I think is more important than you make
>> it out to be. Another is that it just doesn't match the way most people
>> want/need to specify things. Decimal digits of precision might seem fine
>> in theory, but that just isn't a good match the reality of programming.
>> When what you want to do is select between the 32-, 84- and 128-bit
>> options for real, it is cumbersome to translate that into numbers of
>> decimal digits.
>
>PL/I only has specifiers in terms of either binary or decimal
>digits. In most case, people specify the values for their
>favorite system. PL/I uses 3.32 as the conversion between
>the two. (Except that IBM compilers, given a request for
>FLOAT DECIMAL(16), which comes out 53.12 bits, uses 53
>instead of rounding up to 54.)

For non IEEE and double words, IBM hardware allowed
for hex float with 53 maximum guaranteed binary bits, hence
it could not "round up" to 54 because the hardware
could not support it.

But in any case PL/I compilers use whatever hardware
is available. And if decimal float is available, the compiler
uses decimal hardware when FLOAT DECIMAL (16) is
specified, and binary hardware (if available) when FLOAT BINARY
is specified.

robin wrote:
(snip)

> For non IEEE and double words, IBM hardware allowed
> for hex float with 53 maximum guaranteed binary bits, hence
> it could not "round up" to 54 because the hardware
> could not support it.

Extended precision hardware has existed since the
360/85, and all 370 and later processors.
Software emulation is used for other S/360 processors.

> But in any case PL/I compilers use whatever hardware
> is available. And if decimal float is available, the compiler
> uses decimal hardware when FLOAT DECIMAL (16) is
> specified, and binary hardware (if available) when FLOAT BINARY
> is specified.

See:

http://publibfp.boulder.ibm.com/cgi-...ibmol004/4.1.5

http://publibfp.boulder.ibm.com/cgi-...ibmol004/4.1.6

http://publibfp.boulder.ibm.com/cgi-...S/ibmol004/A.0

-- glen

glen herrmannsfeldt wrote:
> robin wrote:
> (snip)
>
>> For non IEEE and double words, IBM hardware allowed
>> for hex float with 53 maximum guaranteed binary bits, hence
>> it could not "round up" to 54 because the hardware
>> could not support it.
>
> Extended precision hardware has existed since the
> 360/85, and all 370 and later processors.
> Software emulation is used for other S/360 processors.

There was also a different extended-precision offering for the 67. It
may have been an RPQ, and it may have been withdrawn without being
shipped, but it did appear in at least one manual ca. 1967 (TSS/360
Assembler Language Reference, I think).
--
John W. Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"

glen herrmannsfeldt wrote in message ...
>robin wrote:
>(snip)
>
>> For non IEEE and double words, IBM hardware allowed
>> for hex float with 53 maximum guaranteed binary bits, hence
>> it could not "round up" to 54 because the hardware
>> could not support it.
>
>Extended precision hardware has existed since the
>360/85,

But not on the S/360 series generally.

> and all 370 and later processors.

Not for division.
That was implemented in software.

>Software emulation is used for other S/360 processors.


That's not so. And how many S/360 processors are still running?

>> But in any case PL/I compilers use whatever hardware
>> is available. And if decimal float is available, the compiler
>> uses decimal hardware when FLOAT DECIMAL (16) is
>> specified, and binary hardware (if available) when FLOAT BINARY
>> is specified.

robin wrote:
> glen herrmannsfeldt wrote in message ...

>>robin wrote:
>>(snip)

>>>For non IEEE and double words, IBM hardware allowed
>>>for hex float with 53 maximum guaranteed binary bits, hence
>>>it could not "round up" to 54 because the hardware
>>>could not support it.

>>Extended precision hardware has existed since the
>>360/85,

> But not on the S/360 series generally.

No, but they supplied an emulator.

The original comment applies to the Optimizing compiler
and later ones. (F) didn't support extended precision.

The rule for precision is supposed to be CEIL(3.32*p) but
in the case I mentioned, they modified it slightly.

>>and all 370 and later processors.

> Not for division.
> That was implemented in software.

There is an IBM Systems Journal article on extended
precision. IBM did the study showing that the demand
for DXR was low enough that software was the best way.

Somewhat late in ESA/390 it was finally added.

>>Software emulation is used for other S/360 processors.

> That's not so. And how many S/360 processors are still running?

Are you complaining about my use of the present tense?

I usually use present tense describing an architecture, which
exists whether or not any implementations of it exist. Support
for instructions exist even when the machine isn't running.

>>>But in any case PL/I compilers use whatever hardware
>>>is available. And if decimal float is available, the compiler
>>>uses decimal hardware when FLOAT DECIMAL (16) is
>>>specified, and binary hardware (if available) when FLOAT BINARY
>>>is specified.

It seems to me that, especially for floating point, the
DECIMAL attribute is meant more to indicate specifying
precision in decimal digits than to specify float decimal
hardware. That is less true in fixed point, where scaling may
require multiply or divide by powers of ten, which is easier
in decimal arithmetic. I do know at least one IBM compiler
that implements FIXED DECIMAL in binary.

-- glen

glen herrmannsfeldt wrote:
> robin wrote:
>> glen herrmannsfeldt wrote in message ...
>
>>> robin wrote:
>>> (snip)
>
>>>> For non IEEE and double words, IBM hardware allowed
>>>> for hex float with 53 maximum guaranteed binary bits, hence
>>>> it could not "round up" to 54 because the hardware
>>>> could not support it.
>
>>> Extended precision hardware has existed since the
>>> 360/85,
>
>> But not on the S/360 series generally.
>
> No, but they supplied an emulator.
>
> The original comment applies to the Optimizing compiler
> and later ones. (F) didn't support extended precision.
>
> The rule for precision is supposed to be CEIL(3.32*p) but
> in the case I mentioned, they modified it slightly.
>
>>> and all 370 and later processors.
>
>> Not for division.
>> That was implemented in software.
>
> There is an IBM Systems Journal article on extended
> precision. IBM did the study showing that the demand
> for DXR was low enough that software was the best way.
>
> Somewhat late in ESA/390 it was finally added.
>
>>> Software emulation is used for other S/360 processors.
>
>> That's not so. And how many S/360 processors are still running?
>
> Are you complaining about my use of the present tense?
>
> I usually use present tense describing an architecture, which
> exists whether or not any implementations of it exist. Support
> for instructions exist even when the machine isn't running.
>
>>>> But in any case PL/I compilers use whatever hardware
>>>> is available. And if decimal float is available, the compiler
>>>> uses decimal hardware when FLOAT DECIMAL (16) is
>>>> specified, and binary hardware (if available) when FLOAT BINARY
>>>> is specified.
>
> It seems to me that, especially for floating point, the
> DECIMAL attribute is meant more to indicate specifying
> precision in decimal digits than to specify float decimal
> hardware. That is less true in fixed point, where scaling may
> require multiply or divide by powers of ten, which is easier
> in decimal arithmetic. I do know at least one IBM compiler
> that implements FIXED DECIMAL in binary.

But it is only very recently that hardware implementing both float
binary and float decimal came into existence. It's putting pressure on
/all/ languages, although it will probably not become critical until
Intel does it, which they seem disinclined to do at present. In the
meantime, in what is probably the most important hardware that does both
and that also has an important PL/I compiler, IBM /is/ implementing
FLOAT DECIMAL and FLOAT BINARY as separate hardware types.

--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson

John W Kennedy wrote:
(snip)

> But it is only very recently that hardware implementing both float
> binary and float decimal came into existence. It's putting pressure on
> /all/ languages, although it will probably not become critical until
> Intel does it, which they seem disinclined to do at present. In the
> meantime, in what is probably the most important hardware that does both
> and that also has an important PL/I compiler, IBM /is/ implementing
> FLOAT DECIMAL and FLOAT BINARY as separate hardware types.

Yes, it is very convenient of PL/I to have this distinction.

It might be that IBM was planning 40 years ahead for z/Architecture
and float decimal hardware. I have old versions of the language
reference. (The one that is supposed to be compiler independent.)

Around 1977 I was told that the CDC STAR-100 had float decimal, but
that turned out to be wrong.

-- glen

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
>
>> But it is only very recently that hardware implementing both float
>> binary and float decimal came into existence. It's putting pressure on
>> /all/ languages, although it will probably not become critical until
>> Intel does it, which they seem disinclined to do at present. In the
>> meantime, in what is probably the most important hardware that does
>> both and that also has an important PL/I compiler, IBM /is/
>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
>
>
> Yes, it is very convenient of PL/I to have this distinction.
>
> It might be that IBM was planning 40 years ahead for z/Architecture
> and float decimal hardware. I have old versions of the language
> reference. (The one that is supposed to be compiler independent.)
>
> Around 1977 I was told that the CDC STAR-100 had float decimal, but
> that turned out to be wrong.
>

Or looking back at the 70xx systems that had float decimal.
--
prf

** Posted from http://www.teranews.com **

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
>
>> But it is only very recently that hardware implementing both float
>> binary and float decimal came into existence. It's putting pressure on
>> /all/ languages, although it will probably not become critical until
>> Intel does it, which they seem disinclined to do at present. In the
>> meantime, in what is probably the most important hardware that does
>> both and that also has an important PL/I compiler, IBM /is/
>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
>
> Yes, it is very convenient of PL/I to have this distinction.
>
> It might be that IBM was planning 40 years ahead for z/Architecture
> and float decimal hardware. I have old versions of the language
> reference. (The one that is supposed to be compiler independent.)

Yeah, but they were sloppy about the definition of ROUND, which assumed
that all floating-point was binary (or approximately binary, as the
S/360 was); to literally implement it on some hardware (like the old
707x family) would have caused the equivalent of a parity check.

Allen-Babcock's RUSH PL/I-based time-sharing system had hardware float
decimal (it ran on 360/50s with massively altered microcode), and I seem
to remember that CALL/360 PL/I may have used software float decimal, as
BASIC/370 (not at all compatible with VS BASIC) did.

I hear that Mike Cowlishaw was of great importance in the creation of
IEEE-754R -- it certainly makes sense that the creator of REXX would
have an interest. But I see that he joined IBM in 1974, too late to have
had any significant involvement in PL/I.
--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

Peter Flass wrote:
> glen herrmannsfeldt wrote:
>> John W Kennedy wrote:
>> (snip)
>>
>>> But it is only very recently that hardware implementing both float
>>> binary and float decimal came into existence. It's putting pressure
>>> on /all/ languages, although it will probably not become critical
>>> until Intel does it, which they seem disinclined to do at present. In
>>> the meantime, in what is probably the most important hardware that
>>> does both and that also has an important PL/I compiler, IBM /is/
>>> implementing FLOAT DECIMAL and FLOAT BINARY as separate hardware types.
>>
>>
>> Yes, it is very convenient of PL/I to have this distinction.
>>
>> It might be that IBM was planning 40 years ahead for z/Architecture
>> and float decimal hardware. I have old versions of the language
>> reference. (The one that is supposed to be compiler independent.)
>>
>> Around 1977 I was told that the CDC STAR-100 had float decimal, but
>> that turned out to be wrong.
>>
>
> Or looking back at the 70xx systems that had float decimal.

And the 1620.


--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich
have always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"