Re: Specifying precision

John W Kennedy wrote:
(snip)

> 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.

CALL/OS PL/I uses binary arithmetic for FIXED DECIMAL, such
that FIXED DEC(9,9) will overflow at 2.147483647. (I tried
it once to be sure.) I think CALL/OS is related to CALL/360,
but I am not sure exactly how. (I used it in high school,
after using PL/I (F). I only had (F) manuals, and tried to
figure out what it could and couldn't do from them.)

I did find an interesting bug in CALL/OS Fortran, in that
there is one character that, if printed, will crash the
whole system. I was trying to figure out all the punch
tape combinations on an ASR-33 terminal by printing all
256 EBCDIC characters, and the system crashed. When it
came back up, I tried again with the same result.

-- glen

In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:

>But it is only very recently that hardware implementing both float
>binary and float decimal came into existence.

If you consider 4 decades to be recent.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:
> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
> at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:
>
>> But it is only very recently that hardware implementing both float
>> binary and float decimal came into existence.
>
> If you consider 4 decades to be recent.

Both hardware binary floating point and hardware decimal floating point
in one machine?

--
John W. Kennedy
"Sweet, was Christ crucified to create this chat?"
-- Charles Williams. "Judgement at Chelmsford"

John W Kennedy wrote:
> Shmuel (Seymour J.) Metz wrote:
>> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
>> at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:
>>
>>> But it is only very recently that hardware implementing both float
>>> binary and float decimal came into existence.
>>
>> If you consider 4 decades to be recent.
>
> Both hardware binary floating point and hardware decimal floating point
> in one machine?

And, of course, I'm talking about both being simultaneously available in
the same program -- not, for example, a 1620 or 7070 emulator on a 360.


--
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naïve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)

Shmuel (Seymour J.) Metz wrote:

> In <4880ce70$0$5011$607ed4bc@cv.net>, on 07/18/2008
> at 01:10 PM, John W Kennedy <jwkenne@attglobal.net> said:

>>But it is only very recently that hardware implementing both float
>>binary and float decimal came into existence.

> If you consider 4 decades to be recent.

I think we have had this discussion before, though I may
not be convinced. By floating point hardware, I would mean
hardware that can do floating point addition, subtraction,
multiplication, or division of floating point numbers.

That would include microcoded implementations that take
relatively few machine cycles, but not ones that take
hundreds of thousands of cycles. (The distinction
being between microcode as a systematic form of hardware
design, as opposed to software emulation.)

-- glen

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:A_ydnYBptMkY-R3VnZ2dnUVZ_uGdnZ2d@comcast.com...
> 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.

Not on any of the other 360 systems of which I am aware.
It was not introduced until the /370, and then only
as A, S, and M.

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

Of course not, because it wasn't available on the hardware.

> 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.

As I said, it wasn't for division.

> 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'm saying that it wasn't available on the /360 period.
I'm also saying that unless you can cite a working S/360,
you are incorrect.

> I usually use present tense describing an architecture, which
> exists whether or not any implementations of it exist.

If it does not exist, it doesn't exist.

> >>>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.

Some machines actually provided float decimal hardware.
The Univac was one of those.

> 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.

And I know of many PL/I compilers that implement
FIXED DECIMAL using DECIMAL hardware,
and FIXED BINARY in BINARY hardware.

On those computers that did not have decimal instructions,
decimal arithmetic was implemented using binary integer
instructions. There is nothing unusual or rare about that.

IBM's PL/I compiler for OS/2 implemented floating-point
in software.

In <4884dc08$0$7363$607ed4bc@cv.net>, on 07/21/2008
at 02:56 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Both hardware binary floating point and hardware decimal floating point
>in one machine?

Yes.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:A_ydnYBptMkY-R3VnZ2dnUVZ_uGdnZ2d@comcast.com...
>> 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.
>
> Not on any of the other 360 systems of which I am aware.
> It was not introduced until the /370, and then only
> as A, S, and M.

No, 128-bit hex floating point was introduced on the 85, was also found
on the 195, and was provided by software emulation on all other models
running OS/360 -- emulation was necessary for the DXR instruction,
anyway, which didn't appear in hardware until much later, although it
was architected and generated as compiler output for compilers that
supported it.


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

> Of course not, because it wasn't available on the hardware.

It was not implemented as hardware in the 360, except for the 85 and
195, but it was available via software emulation. However, it was not
supported by any free OS/360 compiler; you had to get the Optimizer or
the Checker for PL/I, and H Extended, or, later, VS FORTRAN, for FORTRAN.

> If it does not exist, it doesn't exist.

That amounts to a claim that every S/360 Principles of Operation manual
has been burnt.

> IBM's PL/I compiler for OS/2 implemented floating-point
> in software.

If it did, then it was years behind the state of the art; normal OS/2
compilers used 80387 code that could be resolved by an emulator if the
chip were not present.

--
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see
why it was her."
-- "Alias"

In <BqmdnZnAiLSZmBjVnZ2dnUVZ_ozinZ2d@comcast.com>, on 07/21/2008
at 02:52 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>I think we have had this discussion before, though I may
>not be convinced. By floating point hardware, I would mean
>hardware that can do floating point addition, subtraction,
>multiplication, or division of floating point numbers.

Il va sans dire. It existed in the 1950's. It existed on a non-IBM machine
in the 1960's, at least one of which had both floating binary and floating
decimal.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

In <4884dc08$0$7363$607ed4bc@cv.net>, on 07/21/2008
at 02:56 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Both hardware binary floating point and hardware decimal floating point
>in one machine?

Yes.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org