| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398927 is a reply to message #398874] |
Mon, 31 August 2020 13:17   |
|
|
Originally posted by: Thomas Koenig
John Levine <johnl@taugh.com> schrieb:
> In article <36ca64c0-91b8-4120-9976-6bd580ce7d41o@googlegroups.com>,
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Sunday, August 30, 2020 at 5:09:19 AM UTC-6, Thomas Koenig wrote:
>>
>>> Of course, once the 7094 arrived, they had more index registers to play
>>> with, because they removed that weird "or" mode. (Not sure if the
>>> compiler ever used that).
>>
>> That's not _strictly_ accurate. The 7094 allowed the programmer to turn off that
>> "weird OR mode", but it wasn't removed from the machine, which was perfectly
>> capable of running in compatibility mode.
>
> I have asked a few times whether anyone actually used weird OR mode,
> or whether it was just an artifact of the wiring of the 704 that IBM,
> being IBM, documented just in case. Nobody ever said that they did.
I certainly didn't, the 704 is older than me :-)
There could be a use, though, but it would be narrow. Assuming you
had a Fortran program fragment like
DIMENSION A(4,11)
DO 10 J=1,9
DO 10 I=1,4
10 A(I,J) = 2.0
you could have one index register for I running from 0 to 3 and
another index register for J running from 0 to 32 in increments
of four, and then just or them together.
That sounds like something that a clever assembler (or machine
code) programmer would try, and probably spend hours debugging.
I have no clue if the Fortran compiler did anything like that.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398932 is a reply to message #398927] |
Mon, 31 August 2020 15:58 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <rijbaq$nb6$1@newsreader4.netcologne.de>,
Thomas Koenig <tkoenig@netcologne.de> wrote:
> There could be a use, though, but it would be narrow. Assuming you
> had a Fortran program fragment like
>
> DIMENSION A(4,11)
> DO 10 J=1,9
> DO 10 I=1,4
> 10 A(I,J) = 2.0
>
> you could have one index register for I running from 0 to 3 and
> another index register for J running from 0 to 32 in increments
> of four, and then just or them together.
That's the only thing I've been able to think of, and only in the
special case that the first subscript is a power of two.
Seems pretty obscure to be worth implementing in a compiler.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398939 is a reply to message #398874] |
Mon, 31 August 2020 18:50 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, August 30, 2020 at 11:58:32 AM UTC-6, John Levine wrote:
> In article <36ca64c0-91b8-4120-9976-6bd580ce7d41o@googlegroups.com>,
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Sunday, August 30, 2020 at 5:09:19 AM UTC-6, Thomas Koenig wrote:
>>> Of course, once the 7094 arrived, they had more index registers to play
>>> with, because they removed that weird "or" mode. (Not sure if the
>>> compiler ever used that).
>> That's not _strictly_ accurate. The 7094 allowed the programmer to turn off that
>> "weird OR mode", but it wasn't removed from the machine, which was perfectly
>> capable of running in compatibility mode.
> I have asked a few times whether anyone actually used weird OR mode,
> or whether it was just an artifact of the wiring of the 704 that IBM,
> being IBM, documented just in case. Nobody ever said that they did.
> Given that the 704 was sign-magnitude but indexing did two's
> complement subtraction, it would have needed some seriously funky
> programming to do anything useful with it.
> I suppose someone must have sometime if it was worth keeping it as the
> default in the 7094.
One possibility is that IBM simply found it easier to include strictly
compatible operation in the 7094 than to go out and check if this mode was ever
used. (Later on, they did drop the ASCII bit in the PSW going from the 360 to
the 370, on the basis that it was never used, but here the sample size was
smaller, as they really only had to check the operating systems they wrote
themselves.)
It is also _possible_ that it was actually used simply on the basis that the set
of IBM 704 programmers surviving today is a subset of the total set of people
who programmed the IBM 704. Too much time has passed to be really sure about
things like this.
John Savard
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398944 is a reply to message #398939] |
Mon, 31 August 2020 20:24 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Sunday, August 30, 2020 at 11:58:32 AM UTC-6, John Levine wrote:
>> In article <36ca64c0-91b8-4120-9976-6bd580ce7d41o@googlegroups.com>,
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>> On Sunday, August 30, 2020 at 5:09:19 AM UTC-6, Thomas Koenig wrote:
>
>>>> Of course, once the 7094 arrived, they had more index registers to play
>>>> with, because they removed that weird "or" mode. (Not sure if the
>>>> compiler ever used that).
>
>>> That's not _strictly_ accurate. The 7094 allowed the programmer to turn off that
>>> "weird OR mode", but it wasn't removed from the machine, which was perfectly
>>> capable of running in compatibility mode.
>
>> I have asked a few times whether anyone actually used weird OR mode,
>> or whether it was just an artifact of the wiring of the 704 that IBM,
>> being IBM, documented just in case. Nobody ever said that they did.
>
>> Given that the 704 was sign-magnitude but indexing did two's
>> complement subtraction, it would have needed some seriously funky
>> programming to do anything useful with it.
>
>> I suppose someone must have sometime if it was worth keeping it as the
>> default in the 7094.
>
> One possibility is that IBM simply found it easier to include strictly
> compatible operation in the 7094 than to go out and check if this mode was ever
> used. (Later on, they did drop the ASCII bit in the PSW going from the 360 to
> the 370, on the basis that it was never used, but here the sample size was
> smaller, as they really only had to check the operating systems they wrote
> themselves.)
>
> It is also _possible_ that it was actually used simply on the basis that the set
> of IBM 704 programmers surviving today is a subset of the total set of people
> who programmed the IBM 704. Too much time has passed to be really sure about
> things like this.
If they’d asked, people probably would have said “yes” on the principle
that “I don’t know, but if I am using it somewhere I don’t want to find out
later.”
>
> John Savard
>
--
Pete
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #398950 is a reply to message #398875] |
Mon, 31 August 2020 23:32 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-08-30, Dan Espen <dan1espen@gmail.com> wrote:
> John Levine <johnl@taugh.com> writes:
>
>> One thing that might have made it reasonable to write PL/I programs is
>> that it did support the faux ISAM that the 20's DPS provided on its
>> fixed block disks. I presume that DPS RPG could handle them too, but
>> RPG only handled ISAM files in a few stylized ways.
>
> I'm guessing you mean MR? Memory sort of fails but I remember it was
> difficult.
No, MR was part of the matching mechanism that worked with ordinary
sequential files as well.
> Later on in RPG II they came up with the CHAIN op code for the CALC
> section. A pleasure to use.
That's the way I remember accessing ISAM files on Univac systems.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #398951 is a reply to message #398903] |
Tue, 01 September 2020 00:21 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, August 31, 2020 at 1:34:51 PM UTC+10, Peter Flass wrote:
> Robin Vowels <r........@gmail.com> wrote:
>> On Monday, August 31, 2020 at 11:06:20 AM UTC+10, John Levine wrote:
>>> In article <f......@googlegroups.com>,
>>> Robin Vowels <r.......@gmail.com> wrote:
>>>> >> Except for data held in picture format.
>>>> >
>>>> > Which was zoned decimal (see page 22 of the manual)
>>>> >
>>>> which is picture format, namely EBCDIC.
>>>
>>> You haven't looked at page 22 of the manual, have you?
>>>
>> You don't know that the zone of the decimal digits is "F" is EBCDIC,
>> aka picture format?
>>>
>>>> >>> by calling internal routines (see the appendix
>>>> >>> about assembler interfaces) so for anything but the tiniest programs,
>>>> >>> it'd have been extremely slow,
>>>> >>
>>>> >> Another guess. [ etc etc etc ]
>>>> >
>>>> > You really should look at the manual,
>>>> > starting around page 200. The PL/I compiler was pretty impressive in a
>>>> > dancing pig sort of way, but I would not want to try array indexing
>>>> > where the index was stored in decimal and the machine had no CVB or
>>>> > CVD instruction.
>>
>>> Assuming you mean the manual with document number A26-5687, on page 11
>>>
>> No, A26-5847-3. This is the manual for the 360/20, not some other machine.
>>>
>>> and 12, it describes PACK, UNPK, MVO, ZAP, AP, SP, CP, MP, and DP.
>>
>>>> > One thing that might have made it reasonable to write PL/I programs
>>>> >
>>>> Don't talk rot. PL/I on the model 20 was all you'd need to write
>>>> decent data processing programs and scientific programs.
>>>
>>> An integral decimal multiply or divide took a millisecond or more.
>> .
>> Are timings published anywhere?
>> .
>>> PL/I had decimal floating point simulated in software, very, very
>>> slowly.
>> .
>> The model 20 did not have floating-point hardware.
>> However, it did have the decimal instruction set.
>> Inline code for floating-point could have been generated.
>> .
>> The speed of decimal floating-point was limited
>> by the speed of packed decimal instructions generally.
>> So it would not have been "very very slowly".
>>
> Too bad we don’t have a copy of the compiler. Of course Hercules doesn’t do
> Model 20. so we’d have nothing to run it on anyway.
Well, a group in the UK has recently purchased two IBM 360/20's
that had been unused for many years, still cabled up.
So, you might have an opportunity to run programs on the real thing.
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #398958 is a reply to message #398923] |
Tue, 01 September 2020 01:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, September 1, 2020 at 2:34:51 AM UTC+10, John Levine wrote:
> In article <5......@googlegroups.com>,
> Robin Vowels <r.......@gmail.com> wrote:
>>>> > where the index was stored in decimal and the machine had no CVB or
>>>> > CVD instruction.
>>
>>> Assuming you mean the manual with document number A26-5687, on page 11
>
>> No, A26-5847-3. This is the manual for the 360/20, not some other machine.
..
> Sorry, I can't type, that's the one. I presume we both found it on bitsavers.
..
No, Bitsavers is not accessible from this country.
..
>>>> Don't talk rot. PL/I on the model 20 was all you'd need to write
>>>> decent data processing programs and scientific programs.
>>>
>>> An integral decimal multiply or divide took a millisecond or more.
>> .
>> Are timings published anywhere?
> Sigh. They're in Appendix H of A26-5847-3. Really, you should read the manual.
..
Thanks.
As I said, Bitsavers is inaccessible, but I found a site where the individual
pages are stored. I had downloaded the first 29 pages (out of the 140 total
number of pages), one by one. Slow and tedious.
..
>>> PL/I had decimal floating point simulated in software, very, very
>>> slowly.
>> .
>> The model 20 did not have floating-point hardware.
>> However, it did have the decimal instruction set.
>> Inline code for floating-point could have been generated.
>> .
>> The speed of decimal floating-point was limited
>> by the speed of packed decimal instructions generally.
>> So it would not have been "very very slowly".
..
> To do a floating point add or subtract, you have to check the relative
> sizes of the operands, scale one of them to match the other, checking
> for over- or under-flow,
Overflow cannot occur, because only the smaller value may
be shifted.
..
> then do the add or subtract, check again for
> overflow, then normalize the result and adjust the exponent, and
> checking for underflow.
I know how to do floating-point, as I have written float
simulators using integer arithmetic, and multi-precision
floating-point, using bit strings.
> That's pretty slow even when you have a
> typical binary instruction set.
It isn't. Floating-point on the DEUCE (1955) took only
2 to 3 times longer than integer multiply and divide.
[DEUCE did not have float hardware.]
> Doing it with the /20's limited
> instruction set, with slow decimal instructions, would happen very,
> very, slowly.
..
Compared with a model 70.
..
> Like I said, an impressive dancing pig, but still a dancing pig.
I have seen a dancing elephant, and it did it very well.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398960 is a reply to message #398939] |
Tue, 01 September 2020 01:19 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, September 1, 2020 at 8:50:40 AM UTC+10, Quadibloc wrote:
> On Sunday, August 30, 2020 at 11:58:32 AM UTC-6, John Levine wrote:
>> In article <3.......@googlegroups.com>,
>> Quadibloc <j.....@ecn.ab.ca> wrote:
>> I suppose someone must have sometime if it was worth keeping it as the
>> default in the 7094.
> One possibility is that IBM simply found it easier to include strictly
> compatible operation in the 7094 than to go out and check if this mode was ever
> used. (Later on, they did drop the ASCII bit in the PSW going from the 360 to
> the 370, on the basis that it was never used,
..
But we have seen that the ASCII feature was not recognized, so no-one could use it.
..
> but here the sample size was
> smaller, as they really only had to check the operating systems they wrote
> themselves.)
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398961 is a reply to message #398939] |
Tue, 01 September 2020 01:23 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, September 1, 2020 at 8:50:40 AM UTC+10, Quadibloc wrote:
> On Sunday, August 30, 2020 at 11:58:32 AM UTC-6, John Levine wrote:
>> In article <3.......@googlegroups.com>,
>> Quadibloc <j.....@ecn.ab.ca> wrote:
>> I suppose someone must have sometime if it was worth keeping it as the
>> default in the 7094.
> One possibility is that IBM simply found it easier to include strictly
> compatible operation in the 7094 than to go out and check if this mode was ever
> used. (Later on, they did drop the ASCII bit in the PSW going from the 360 to
> the 370, on the basis that it was never used,
..
But we have seen that the ASCII feature was not recognized by the OS,
so no-one could use it.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398968 is a reply to message #398932] |
Tue, 01 September 2020 05:39 |
|
|
Originally posted by: Thomas Koenig
John Levine <johnl@taugh.com> schrieb:
> In article <rijbaq$nb6$1@newsreader4.netcologne.de>,
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> There could be a use, though, but it would be narrow. Assuming you
>> had a Fortran program fragment like
>>
>> DIMENSION A(4,11)
>> DO 10 J=1,9
>> DO 10 I=1,4
>> 10 A(I,J) = 2.0
>>
>> you could have one index register for I running from 0 to 3 and
>> another index register for J running from 0 to 32 in increments
>> of four, and then just or them together.
>
> That's the only thing I've been able to think of, and only in the
> special case that the first subscript is a power of two.
Maybe this was something C.A.R. Hoare alluded to, in his "Hints
on Programming Language Design":
# In the early days of hardware design, some very ingenious but
# arbitrary features turned up in order codes as a result of
# orthogonal combinations of the function bits of an instruction,
# on the grounds that some clever programmer would find a use for
# them, -- and some clever programmer always did.
Of course, he then goes on to write
# Hardware designers have now learned more sense
:-)
> Seems pretty obscure to be worth implementing in a compiler.
I don't think we will find out without somebody actually trying.
Does anybody have an up-and-running IBM 704 emulator with the
Fortran compiler and could compile a test program and examine
the output? I don't, unfortunately.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398970 is a reply to message #398927] |
Tue, 01 September 2020 07:10 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
> There could be a use, though, but it would be narrow. Assuming you
> had a Fortran program fragment like
>
> DIMENSION A(4,11)
> DO 10 J=1,9
> DO 10 I=1,4
> 10 A(I,J) = 2.0
>
> you could have one index register for I running from 0 to 3 and
> another index register for J running from 0 to 32 in increments
> of four, and then just or them together.
That's an interesting optimisation.
In PL/I, one might write
A = 2.0;
and that would be optimised to
MVC A,B(4)
MVC A+4,A(44*4-4)
where B is the constant 2.0.
> That sounds like something that a clever assembler (or machine
> code) programmer would try, and probably spend hours debugging.
>
> I have no clue if the Fortran compiler did anything like that.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398973 is a reply to message #398970] |
Tue, 01 September 2020 08:19 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>
>> There could be a use, though, but it would be narrow. Assuming you
>> had a Fortran program fragment like
>>
>> DIMENSION A(4,11)
>> DO 10 J=1,9
>> DO 10 I=1,4
>> 10 A(I,J) = 2.0
>>
>> you could have one index register for I running from 0 to 3 and
>> another index register for J running from 0 to 32 in increments
>> of four, and then just or them together.
>
> That's an interesting optimisation.
>
> In PL/I, one might write
> A = 2.0;
> and that would be optimised to
> MVC A,B(4)
> MVC A+4,A(44*4-4)
>
> where B is the constant 2.0.
Those length specifications belong on the first operand.
Those move character instructions with data overlap
are all specified by POP to be treated as if one byte at a time is being
moved:
For MOVE (MVC), each operand is processed left to
right. When the operands overlap, the result is
obtained as if the operands were processed one byte
at a time and each result byte were stored immedi-
ately after fetching the necessary operand byte.
I don't know if the hardware has an optimization to recognize the
overlap offset is 4 bytes and it can fetch/store 4 bytes at a time.
The hardware would need another optimization to realize it can
parallelize the whole operation and not wait to see what's in
the next 4 bytes.
Anyway, that's a common way to clear a print area, except it's done:
MVI PRINT,X'40'
MVC PRINT+1(131),PRINT
I was always suspicious that this would cause a performance hit
so I preferred to define an area of 132 spaces and move that to
areas that needed clearing.
--
Dan Espen
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #398979 is a reply to message #398958] |
Tue, 01 September 2020 09:34 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> wrote:
> On Tuesday, September 1, 2020 at 2:34:51 AM UTC+10, John Levine wrote:
>> In article <5......@googlegroups.com>,
>> Robin Vowels <r.......@gmail.com> wrote:
>>>> >> where the index was stored in decimal and the machine had no CVB or
>>>> >> CVD instruction.
>>>
>>>> Assuming you mean the manual with document number A26-5687, on page 11
>>
>>> No, A26-5847-3. This is the manual for the 360/20, not some other machine.
> .
>> Sorry, I can't type, that's the one. I presume we both found it on bitsavers.
> .
> No, Bitsavers is not accessible from this country.
That’s odd. Get VPN. I use “Hide Me” VPN, it works well and is inexpensive,
plus a free trial is available, although there are plenty of others. I got
tired of not being able to watch the shows I wanted on German TV, but, of
course, it looks like Charité is no longer available, after I watched a
couple of episodes.
--
Pete
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #398990 is a reply to message #398837] |
Tue, 01 September 2020 14:07 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, August 29, 2020 at 10:52:41 PM UTC-4, Robin Vowels wrote:
> IBM doesn't go about writing compilers for fun,
> with no expectation for significant sales.
Actually, IBM did screw up and waste time.
IBM intended 360-OS would be a universal operating system.
Try as they did, it was simply too big to run effectively
on the low-end machines. IBM then had to rush out a bunch of
low-end operating systems--DOS, TOS, BOS, and BPS. This
delayed delivery of S/360. It was very tough on IBM's
system programmers. The effort is described in the S/360 history
and in Watson's memoir.
As part of the "universal" intent of System/360, IBM developed
a new programming language, PL/I, intended to replace COBOL
and FORTRAN. But while it did gain a few ardent fans, most data
centers stuck with Assembler, COBOL, and FORTRAN. PL/I
was basically a boondoggle. Maybe well intentioned, but
with the benefit of hindsight, a waste of their time.
>
>> Looking at
>> the manual, all numeric data was decimal,
>
> Except for data held in picture format.
>
>> and a lot of the work was
>> done interpretively
>
> Really now!
> Model 20 PL/I was a compiler, and produced executable code.
>
>> by calling internal routines (see the appendix
>> about assembler interfaces) so for anything but the tiniest programs,
>> it'd have been extremely slow,
>
> Another guess.
>
> Decimal arithmetic was carried out using decimal
> hardware instructions. What's slow about that?
>
>> which doesn't impress me
>
> Another guess.
>
>> as a good use
>> of a /20 configured with 16K and a disk.
>
> 16K is not a large memory. The S360/20 could have up to 32K.
>
>> I believe
>
> Another guess.
>
>> that most /20 users programmed in a combination of RPG and
>> assembler, and only had card and printer I/O, no disk.
>
> Again, you have not produced a single fact about the model 20
> PL/I, and those few "facts" you produced are wrong.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #398991 is a reply to message #398973] |
Tue, 01 September 2020 14:08 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <rile83$dlm$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
> Robin Vowels <robin.vowels@gmail.com> writes:
>
>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>
>>> There could be a use, though, but it would be narrow. Assuming you
>>> had a Fortran program fragment like
>>>
>>> DIMENSION A(4,11)
>>> DO 10 J=1,9
>>> DO 10 I=1,4
>>> 10 A(I,J) = 2.0
>>> ...
>> In PL/I, one might write
>> A = 2.0;
Sure, you can do that in modern Fortran, too.
> Anyway, that's a common way to clear a print area, except it's done:
>
> MVI PRINT,X'40'
> MVC PRINT+1(131),PRINT
>
> I was always suspicious that this would cause a performance hit
> so I preferred to define an area of 132 spaces and move that to
> areas that needed clearing.
Since the 370 came along in the early 1970s you could write something like
LA 2,PRINT target area
LA 3,132 target length
LA 5,x'40'
SLL 5,24 padding byte in high byte, length zero
MVCL 2,4
this is probably too clever for a 132 byte field but the POO says it's the fastest
way to clear a block bigger than 256 bytes
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: KDF9, not IBM system/360 ad [message #398992 is a reply to message #398829] |
Tue, 01 September 2020 14:10 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, August 29, 2020 at 7:59:31 PM UTC-4, Charlie Gibbs wrote:
> On 2020-08-29, Niklas Karlsson <anksil@yahoo.se> wrote:
>
>> On 2020-08-29, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> However, where's the problem with Hydrogen? People are advocating
>>> it as an alternative for hydrocarbons for energy. It must be
>>> absolutely safe to handle, or they would not be doing that, right?
>>
>> Silly people. Not only is it dangerously flammable and explosive, it's
>> such a tiny molecule that it leaks through most anything, and it tends
>> to embrittle any metal it's contained within.
>
> Nevertheless, I once toured a nearby electrical generating plant where
> it was explained that those 180MW generators were cooled by circulating
> hydrogen gas through the housings. Apparently its thermal conductivity
> is high enough to make it worth working out the other problems.
Likewise. Sure surprised me, given it was a power plant
with freakin' very high power. But apparently it worked
just fine for them. I presume no leaking.
As an aside, early computation writeups on bitsavers
talk about turbine engineering on the CPC.
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #398993 is a reply to message #398725] |
Tue, 01 September 2020 14:13 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Friday, August 28, 2020 at 4:21:51 PM UTC-4, John Levine wrote:
> In article <705decfc-4a3d-419b-ae42-66e79e5962d7o@googlegroups.com>,
> <hancock4@bbs.cpcn.com> wrote:
>>> They aren't, they're racks full of POWER chips.
>>
>> Here's a question: Certain calculations have to be
>> done sequentially, that is, the elements of one equation
>> is dependent on the result of the equation done before
>> it. How do those massive parallel processors handle
>> situations like that?
>
> Not very fast. People have put a great deal of work into trying to
> restructure problems so they can run in parallel.
>
>> Also, is there a typically used programming
>> language for these high powered numeric
>> applications? I guess Fortran fell by the
>> wayside.
>
> Not at all. Since Fortran 90 it has had array operations and since
> Fortran 2008 specific support for concurrent operations. It's not your
> grandmother's FORTRAN any more.
>
> People use all sorts of languages for high performance computers as
> well as frameworks like Hadoop that can distribute the work and
> combine the results.
Interesting, thanks for the explanation.
But it remains puzzling why IBM ceased support of Fortran
for the Z series. They have increased the math
capabilities of the Z series--note the following
excerpts from the Principles of Opearation for
floating point and vectors. There's also a
square root instruction, separate instructions
for normalized/unnormalized numbers, and 128
bit numbers. (SA22-7832-12, Thirteenth Edition September, 2019).
If I counted correctly, there are 65 ADD instructions.
That's a lot!
Lots of vector instructions, like
VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION
or VECTOR PACK LOGICAL SATURATE
I suspect a modern Fortran, exploiting all of these
enhancements to arithmetic instructions on the Z
series, would be both powerful and fast. I presume
a serious mathematician could find use for the
"borrow indication" or the "vector saturate".
(Don't ask me to explain it.)
Floating-point operands have formats based on three
radixes: 2, 10, or 16. These radix values lead to the
terminology “binary,” “decimal,” and “hexadecimal”
floating point (BFP, DFP, and HFP), respectively. The
formats are also based on three operand lengths:
short (32 bits), long (64 bits), and extended (128
bits). Short operands require less storage than long
or extended operands. On the other hand, long and
extended operands permit greater precision in computation.
The vector facility provided in the z/Architecture
architectural mode provides fixed-sized vectors ranging
from one to sixteen elements. For most instructions,
all of the data contained in a vector is operated
on by the instructions defined in this facility.
As an aside, Z COBOL added various trig and math functions.
Not sure who would want to do trig in COBOL, but the
functions are there.
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #398999 is a reply to message #398993] |
Tue, 01 September 2020 15:17 |
Niklas Karlsson
Messages: 265
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-09-01, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
[Fortran, massively parallel computing]
> But it remains puzzling why IBM ceased support of Fortran
> for the Z series. They have increased the math
> capabilities of the Z series [...]
I could be wrong - I don't really know that much about the market, but I
get the impression that scientific shops, usually the ones to use
massively parallel/high performance computing gear, aren't much in the
market for the Z series.
I've been in contact with a high performance computing center recently,
and their main machine is a Cray XC40, which uses Intel Haswell Xeon
processors with optional GPUs. (Not sure if theirs has those or not.)
They communicate via a proprietary Cray interconnect.
Cray (there've been bankruptcies, buyouts, resurrections, but the Cray
trademark still survives) was recently bought by HP Enterprise, so it's
now "HPE Cray".
Niklas
--
IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF
-- Norman deForest explains the joys of PL/1
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #399000 is a reply to message #398993] |
Tue, 01 September 2020 15:20 |
|
|
Originally posted by: Thomas Koenig
[x-post and follow-up to comp.lang.fortran]
hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> schrieb:
> But it remains puzzling why IBM ceased support of Fortran
> for the Z series.
VS Fortran is still available, I think, but it is stuck in F77-mode.
It was a nice compiler at the time, though.
[...]
> Lots of vector instructions, like
> VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION
> or VECTOR PACK LOGICAL SATURATE
Wow.
> I suspect a modern Fortran, exploiting all of these
> enhancements to arithmetic instructions on the Z
> series, would be both powerful and fast.
I suspect that these instructions are not there for number
crunching. For that, the price/performance ratio of a zSystem is
simply not suitable - number crunching does not need the special
high availability etc of the maniframes.
For that kind of application, you would probably buy AMD,
Intel or IBM's own POWER.
> I presume
> a serious mathematician could find use for the
> "borrow indication" or the "vector saturate".
> (Don't ask me to explain it.)
First, a compiler write would have to understand what it
means :-) and if it fits into the language.
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #399001 is a reply to message #398990] |
Tue, 01 September 2020 15:38 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-09-01, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> As part of the "universal" intent of System/360, IBM developed
> a new programming language, PL/I, intended to replace COBOL
> and FORTRAN. But while it did gain a few ardent fans, most
> data centers stuck with Assembler, COBOL, and FORTRAN. PL/I
> was basically a boondoggle. Maybe well intentioned, but
> with the benefit of hindsight, a waste of their time.
My only contact with PL/I was in a university computer science
class. I observed that compared to any other language processor,
the PL/I compiler was bloated and slow (a big factor when you're
being charged funny money for CPU time for one-shot assignments,
as opposed to repeatedly running production code). And this was
on a 360/67; I was surprised to read (in this thread) that IBM
actually got it running on a /20.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399003 is a reply to message #398991] |
Tue, 01 September 2020 16:04 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <rile83$dlm$1@dont-email.me>,
> Dan Espen <dan1espen@gmail.com> wrote:
>> Robin Vowels <robin.vowels@gmail.com> writes:
>>
>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>
>>>> There could be a use, though, but it would be narrow. Assuming you
>>>> had a Fortran program fragment like
>>>>
>>>> DIMENSION A(4,11)
>>>> DO 10 J=1,9
>>>> DO 10 I=1,4
>>>> 10 A(I,J) = 2.0
>>>> ...
>>> In PL/I, one might write
>>> A = 2.0;
>
> Sure, you can do that in modern Fortran, too.
>
>> Anyway, that's a common way to clear a print area, except it's done:
>>
>> MVI PRINT,X'40'
>> MVC PRINT+1(131),PRINT
>>
>> I was always suspicious that this would cause a performance hit
>> so I preferred to define an area of 132 spaces and move that to
>> areas that needed clearing.
>
> Since the 370 came along in the early 1970s you could write something like
>
> LA 2,PRINT target area
> LA 3,132 target length
> LA 5,x'40'
> SLL 5,24 padding byte in high byte, length zero
> MVCL 2,4
>
> this is probably too clever for a 132 byte field but the POO says it's the fastest
> way to clear a block bigger than 256 bytes
Getting to the Z/Series you can get that blank
in the high order of the low part of the 64 bit register with:
IILF Rx,X'40000000' Insert Immediate Low Full
--
Dan Espen
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #399004 is a reply to message #399001] |
Tue, 01 September 2020 16:08 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2020-09-01, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>> As part of the "universal" intent of System/360, IBM developed
>> a new programming language, PL/I, intended to replace COBOL
>> and FORTRAN. But while it did gain a few ardent fans, most
>> data centers stuck with Assembler, COBOL, and FORTRAN. PL/I
>> was basically a boondoggle. Maybe well intentioned, but
>> with the benefit of hindsight, a waste of their time.
>
> My only contact with PL/I was in a university computer science
> class. I observed that compared to any other language processor,
> the PL/I compiler was bloated and slow (a big factor when you're
> being charged funny money for CPU time for one-shot assignments,
> as opposed to repeatedly running production code). And this was
> on a 360/67; I was surprised to read (in this thread) that IBM
> actually got it running on a /20.
There is a variation on PL/I called PL/S.
IBM supposedly used it to write large parts of the OS.
To this day, they haven't released it for customer use.
Perhaps they also used it on the 20 and that's why
there was a PL/I compiler for the 20.
--
Dan Espen
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #399011 is a reply to message #398993] |
Tue, 01 September 2020 19:06 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<hancock4@bbs.cpcn.com> wrote:
> On Friday, August 28, 2020 at 4:21:51 PM UTC-4, John Levine wrote:
>> In article <705decfc-4a3d-419b-ae42-66e79e5962d7o@googlegroups.com>,
>> <hancock4@bbs.cpcn.com> wrote:
>>>> They aren't, they're racks full of POWER chips.
>>>
>>> Here's a question: Certain calculations have to be
>>> done sequentially, that is, the elements of one equation
>>> is dependent on the result of the equation done before
>>> it. How do those massive parallel processors handle
>>> situations like that?
>>
>> Not very fast. People have put a great deal of work into trying to
>> restructure problems so they can run in parallel.
>>
>>> Also, is there a typically used programming
>>> language for these high powered numeric
>>> applications? I guess Fortran fell by the
>>> wayside.
>>
>> Not at all. Since Fortran 90 it has had array operations and since
>> Fortran 2008 specific support for concurrent operations. It's not your
>> grandmother's FORTRAN any more.
>>
>> People use all sorts of languages for high performance computers as
>> well as frameworks like Hadoop that can distribute the work and
>> combine the results.
>
>
> Interesting, thanks for the explanation.
>
> But it remains puzzling why IBM ceased support of Fortran
> for the Z series. They have increased the math
> capabilities of the Z series--note the following
> excerpts from the Principles of Opearation for
> floating point and vectors. There's also a
> square root instruction, separate instructions
> for normalized/unnormalized numbers, and 128
> bit numbers. (SA22-7832-12, Thirteenth Edition September, 2019).
>
> If I counted correctly, there are 65 ADD instructions.
> That's a lot!
>
> Lots of vector instructions, like
> VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION
> or VECTOR PACK LOGICAL SATURATE
>
> I suspect a modern Fortran, exploiting all of these
> enhancements to arithmetic instructions on the Z
> series, would be both powerful and fast. I presume
> a serious mathematician could find use for the
> "borrow indication" or the "vector saturate".
> (Don't ask me to explain it.)
>
How about Gnu Fortran?
--
Pete
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #399012 is a reply to message #399011] |
Tue, 01 September 2020 19:12 |
|
|
Originally posted by: J. Clarke
On Tue, 1 Sep 2020 16:06:08 -0700, Peter Flass <peter_flass@yahoo.com>
wrote:
> <hancock4@bbs.cpcn.com> wrote:
>> On Friday, August 28, 2020 at 4:21:51 PM UTC-4, John Levine wrote:
>>> In article <705decfc-4a3d-419b-ae42-66e79e5962d7o@googlegroups.com>,
>>> <hancock4@bbs.cpcn.com> wrote:
>>>> > They aren't, they're racks full of POWER chips.
>>>>
>>>> Here's a question: Certain calculations have to be
>>>> done sequentially, that is, the elements of one equation
>>>> is dependent on the result of the equation done before
>>>> it. How do those massive parallel processors handle
>>>> situations like that?
>>>
>>> Not very fast. People have put a great deal of work into trying to
>>> restructure problems so they can run in parallel.
>>>
>>>> Also, is there a typically used programming
>>>> language for these high powered numeric
>>>> applications? I guess Fortran fell by the
>>>> wayside.
>>>
>>> Not at all. Since Fortran 90 it has had array operations and since
>>> Fortran 2008 specific support for concurrent operations. It's not your
>>> grandmother's FORTRAN any more.
>>>
>>> People use all sorts of languages for high performance computers as
>>> well as frameworks like Hadoop that can distribute the work and
>>> combine the results.
>>
>>
>> Interesting, thanks for the explanation.
>>
>> But it remains puzzling why IBM ceased support of Fortran
>> for the Z series. They have increased the math
>> capabilities of the Z series--note the following
>> excerpts from the Principles of Opearation for
>> floating point and vectors. There's also a
>> square root instruction, separate instructions
>> for normalized/unnormalized numbers, and 128
>> bit numbers. (SA22-7832-12, Thirteenth Edition September, 2019).
>>
>> If I counted correctly, there are 65 ADD instructions.
>> That's a lot!
>>
>> Lots of vector instructions, like
>> VECTOR SUBTRACT WITH BORROW COMPUTE BORROW INDICATION
>> or VECTOR PACK LOGICAL SATURATE
>>
>> I suspect a modern Fortran, exploiting all of these
>> enhancements to arithmetic instructions on the Z
>> series, would be both powerful and fast. I presume
>> a serious mathematician could find use for the
>> "borrow indication" or the "vector saturate".
>> (Don't ask me to explain it.)
>>
>
> How about Gnu Fortran?
If you want to port Gnu Fortran to MVS go right ahead. And there's no
point to running it under Linux, that just turns the mainframe into
hideously expensive PC.
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #399013 is a reply to message #398958] |
Tue, 01 September 2020 19:52 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Monday, August 31, 2020 at 11:13:14 PM UTC-6, Robin Vowels wrote:
> No, Bitsavers is not accessible from this country.
Condolences. I suppose the Internet Archive is also not accessible. Or Bitsavers'
mirror sites.
John Savard
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399021 is a reply to message #398973] |
Tue, 01 September 2020 21:05 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, September 1, 2020 at 10:19:17 PM UTC+10, Dan Espen wrote:
> Robin Vowels <r........@gmail.com> writes:
>
>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>
>>> There could be a use, though, but it would be narrow. Assuming you
>>> had a Fortran program fragment like
>>>
>>> DIMENSION A(4,11)
>>> DO 10 J=1,9
>>> DO 10 I=1,4
>>> 10 A(I,J) = 2.0
>>>
>>> you could have one index register for I running from 0 to 3 and
>>> another index register for J running from 0 to 32 in increments
>>> of four, and then just or them together.
>>
>> That's an interesting optimisation.
>>
>> In PL/I, one might write
>> A = 2.0;
>> and that would be optimised to
>> MVC A,B(4)
>> MVC A+4,A(44*4-4)
>>
>> where B is the constant 2.0.
> Those length specifications belong on the first operand.
It's stylised assembler. I figured that it would be easier to follow.
>
> Those move character instructions with data overlap
> are all specified by POP to be treated as if one byte at a time is being
> moved:
..
That's the way it works. MVC on the IBM series never does a block transfer.
..
> For MOVE (MVC), each operand is processed left to
> right. When the operands overlap, the result is
> obtained as if the operands were processed one byte
> at a time and each result byte were stored immedi-
> ately after fetching the necessary operand byte.
..
The CPU must do it that way, otherwise the overlapped
fields would not work.
..
> I don't know if the hardware has an optimization to recognize the
> overlap offset is 4 bytes and it can fetch/store 4 bytes at a time.
..
It doesn't.
..
> The hardware would need another optimization to realize it can
> parallelize the whole operation and not wait to see what's in
> the next 4 bytes.
>
> Anyway, that's a common way to clear a print area, except it's done:
>
> MVI PRINT,X'40'
> MVC PRINT+1(131),PRINT
It's done that way because the set-up is simpler (a move of one byte)
> I was always suspicious that this would cause a performance hit
> so I preferred to define an area of 132 spaces and move that to
> areas that needed clearing.
What a waste !
The MVC still moves the 132 bytes a byte at a time, storing one
byte before fetching the next and storing that, etc.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399022 is a reply to message #398991] |
Tue, 01 September 2020 21:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 4:08:37 AM UTC+10, John Levine wrote:
> In article <r.......@dont-email.me>,
> Dan Espen <d......@gmail.com> wrote:
>> Robin Vowels <r........@gmail.com> writes:
>>
>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>
>>>> There could be a use, though, but it would be narrow. Assuming you
>>>> had a Fortran program fragment like
>>>>
>>>> DIMENSION A(4,11)
>>>> DO 10 J=1,9
>>>> DO 10 I=1,4
>>>> 10 A(I,J) = 2.0
>>>> ...
>>> In PL/I, one might write
>>> A = 2.0;
> Sure, you can do that in modern Fortran, too.
..
True, but the OP was referring to earlier verstions of FORTRAN
up to FORTRAN 77.
The difference is that in PL/I, its been possible to write that
since 1966.
..
>> Anyway, that's a common way to clear a print area, except it's done:
>>
>> MVI PRINT,X'40'
>> MVC PRINT+1(131),PRINT
>>
>> I was always suspicious that this would cause a performance hit
>> so I preferred to define an area of 132 spaces and move that to
>> areas that needed clearing.
>
> Since the 370 came along in the early 1970s you could write something like
>
> LA 2,PRINT target area
> LA 3,132 target length
> LA 5,x'40'
> SLL 5,24 padding byte in high byte, length zero
..
I think that SR 5,5 and IC 5,=X'40' would be better than the previous
two instructions, or even one straight L.
..
> MVCL 2,4
>
> this is probably too clever for a 132 byte field but the POO says it's the fastest
> way to clear a block bigger than 256 bytes.
|
|
|
|
| Re: IBM system/360, whiz or dog? [message #399023 is a reply to message #398999] |
Tue, 01 September 2020 21:22 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 5:17:40 AM UTC+10, Niklas Karlsson wrote:
> On 2020-09-01, h......@bbs.cpcn.com <h......@bbs.cpcn.com> wrote:
> [Fortran, massively parallel computing]
>> But it remains puzzling why IBM ceased support of Fortran
>> for the Z series. They have increased the math
>> capabilities of the Z series [...]
>
> I could be wrong - I don't really know that much about the market, but I
> get the impression that scientific shops, usually the ones to use
> massively parallel/high performance computing gear, aren't much in the
> market for the Z series.
>
> I've been in contact with a high performance computing center recently,
> and their main machine is a Cray XC40, which uses Intel Haswell Xeon
> processors with optional GPUs. (Not sure if theirs has those or not.)
> They communicate via a proprietary Cray interconnect.
>
> Cray (there've been bankruptcies, buyouts, resurrections, but the Cray
> trademark still survives) was recently bought by HP Enterprise, so it's
> now "HPE Cray".
> IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF
It's not even correct PL/I.
Correct is:
IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF ;
This sort of thing is possible in any programming language
(includug FORTRAN) in which keywords are not reserved words.
The reason for having no reserved words is to anticipate
additions to the language, whereby a new keyword does
not invalidate any existing programs.
> -- Norman deForest explains the joys of PL/1
The language is PL/I.
|
|
|
|
| Re: IBM system/360, model 20 PL/I [message #399024 is a reply to message #399001] |
Tue, 01 September 2020 21:41 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 5:39:26 AM UTC+10, Charlie Gibbs wrote:
> On 2020-09-01, <h......@bbs.cpcn.com> wrote:
>> As part of the "universal" intent of System/360, IBM developed
>> a new programming language, PL/I, intended to replace COBOL
>> and FORTRAN. But while it did gain a few ardent fans, most
>> data centers stuck with Assembler, COBOL, and FORTRAN. PL/I
>> was basically a boondoggle. Maybe well intentioned, but
>> with the benefit of hindsight, a waste of their time.
> My only contact with PL/I was in a university computer science
> class. I observed that compared to any other language processor,
> the PL/I compiler was bloated and slow
..
Depends on what compiler you used.
Certainly the language had/has more data types and built-in functions
and facilities than FORTRAN or COBOL.
For student jobs, various compilers were available for processing
those faster than IBM's PL/I-F compiler. The most notable of those
was PL/C, which was very fast; as well, it implemented most of PL/I.
(The comparable FORTRAN compiler for student jobs was WATFOR.)
..
> (a big factor when you're
> being charged funny money for CPU time for one-shot assignments,
> as opposed to repeatedly running production code).
..
For developing programs, PL/I was far more economical than either
FORTRAN or COBOL on the S/360 in that it used far less computer
time, because of its built-in debugging facilities, including telling
you the statement number where an error occurred.
Those facilities meant that fewer runs were required to get a program
running.
..
> And this was
> on a 360/67; I was surprised to read (in this thread) that IBM
> actually got it running on a /20.
..
There's nothing unusual about that. Just because the CPU was not as
fast as a /67, and did not have as much core store as a /67,
does not mean that it cannot run on the /20.
|
|
|
|
|
|
| Re: block moves, 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399026 is a reply to message #399022] |
Tue, 01 September 2020 22:14 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <742c4c80-bc40-492f-b648-6a72a0b64f73n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
>> Since the 370 came along in the early 1970s you could write something like
>>
>> LA 2,PRINT target area
>> LA 3,132 target length
>> LA 5,X'40'
>> SLL 5,24 padding byte in high byte, length zero
> .
> I think that SR 5,5 and IC 5,=X'40' would be better than the previous
> two instructions, or even one straight L.
The fill character has to be in the high byte of the register, not the low
byte. I suppose you could do ICM 5,8,=X'40' but I don't see why that would
be better than LA and SLL which don't have the extra memory reference.
>> MVCL 2,4
>>
>> this is probably too clever for a 132 byte field but the POO says it's the fastest
>> way to clear a block bigger than 256 bytes.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399027 is a reply to message #399021] |
Tue, 01 September 2020 22:32 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> On Tuesday, September 1, 2020 at 10:19:17 PM UTC+10, Dan Espen wrote:
>> Robin Vowels <r........@gmail.com> writes:
>>
>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>
>>>> There could be a use, though, but it would be narrow. Assuming you
>>>> had a Fortran program fragment like
>>>>
>>>> DIMENSION A(4,11)
>>>> DO 10 J=1,9
>>>> DO 10 I=1,4
>>>> 10 A(I,J) = 2.0
>>>>
>>>> you could have one index register for I running from 0 to 3 and
>>>> another index register for J running from 0 to 32 in increments
>>>> of four, and then just or them together.
>>>
>>> That's an interesting optimisation.
>>>
>>> In PL/I, one might write
>>> A = 2.0;
>>> and that would be optimised to
>>> MVC A,B(4)
>>> MVC A+4,A(44*4-4)
>>>
>>> where B is the constant 2.0.
>> Those length specifications belong on the first operand.
>
> It's stylised assembler. I figured that it would be easier to follow.
Stylized?
I guess wrong is always easier to follow.
>> Those move character instructions with data overlap
>> are all specified by POP to be treated as if one byte at a time is being
>> moved:
> .
> That's the way it works. MVC on the IBM series never does a block transfer.
So, the internal data path on S/360 is always a byte at a time.
The things I learn on the internet.
>> For MOVE (MVC), each operand is processed left to
>> right. When the operands overlap, the result is
>> obtained as if the operands were processed one byte
>> at a time and each result byte were stored immedi-
>> ately after fetching the necessary operand byte.
> .
> The CPU must do it that way, otherwise the overlapped
> fields would not work.
> .
>> I don't know if the hardware has an optimization to recognize the
>> overlap offset is 4 bytes and it can fetch/store 4 bytes at a time.
> .
> It doesn't.
> .
>> The hardware would need another optimization to realize it can
>> parallelize the whole operation and not wait to see what's in
>> the next 4 bytes.
>>
>> Anyway, that's a common way to clear a print area, except it's done:
>>
>> MVI PRINT,X'40'
>> MVC PRINT+1(131),PRINT
>
> It's done that way because the set-up is simpler (a move of one byte)
Yep, 2 instructions are always simpler than one.
Got it.
>> I was always suspicious that this would cause a performance hit
>> so I preferred to define an area of 132 spaces and move that to
>> areas that needed clearing.
>
> What a waste !
> The MVC still moves the 132 bytes a byte at a time, storing one
> byte before fetching the next and storing that, etc.
I'm not a hardware engineer so I'm glad you could clear that up for me.
--
Dan Espen
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399033 is a reply to message #399027] |
Tue, 01 September 2020 22:51 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <rin086$utf$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
>>> Those move character instructions with data overlap
>>> are all specified by POP to be treated as if one byte at a time is being moved:
>> .
>> That's the way it works. MVC on the IBM series never does a block transfer.
>
> So, the internal data path on S/360 is always a byte at a time.
> The things I learn on the internet.
Not really, it's an "as if" rule:
When the operands overlap, the result is obtained as if the
operands were processed one byte at a time and each result byte were
stored immediately after fetching the necessary operand byte.
Given how common that idiom is, I expect modern CPUs recognize it and
do a block fill rather than load and store one byte at a time.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399034 is a reply to message #398991] |
Tue, 01 September 2020 23:34 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 4:08:37 AM UTC+10, John Levine wrote:
> In article <r.......@dont-email.me>,
> Dan Espen <d......@gmail.com> wrote:
>> Robin Vowels <r........@gmail.com> writes:
>>
>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>
>>>> There could be a use, though, but it would be narrow. Assuming you
>>>> had a Fortran program fragment like
>>>>
>>>> DIMENSION A(4,11)
>>>> DO 10 J=1,9
>>>> DO 10 I=1,4
>>>> 10 A(I,J) = 2.0
>>>> ...
>>> In PL/I, one might write
>>> A = 2.0;
> Sure, you can do that in modern Fortran, too.
..
True, but the OP was referring to earlier verstions of FORTRAN
up to FORTRAN 77.
The difference is that in PL/I, its been possible to write that
since 1966.
..
>> Anyway, that's a common way to clear a print area, except it's done:
>>
>> MVI PRINT,X'40'
>> MVC PRINT+1(131),PRINT
>>
>> I was always suspicious that this would cause a performance hit
>> so I preferred to define an area of 132 spaces and move that to
>> areas that needed clearing.
>
> Since the 370 came along in the early 1970s you could write something like
>
> LA 2,PRINT target area
> LA 3,132 target length
> LA 5,x'40'
> SLL 5,24 padding byte in high byte, length zero
..
I think that SR 5,5 and ICM 5,...=X'40' specifying the upper byte
would be better than the previous two instructions, or even one straight L.
..
> MVCL 2,4
>
> this is probably too clever for a 132 byte field but the POO says it's the fastest
> way to clear a block bigger than 256 bytes.
|
|
|
|
| Re: block moves, 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399035 is a reply to message #399026] |
Tue, 01 September 2020 23:52 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 12:14:30 PM UTC+10, John Levine wrote:
> In article <7.......@googlegroups.com>,
> Robin Vowels <r........@gmail.com> wrote:
>>> Since the 370 came along in the early 1970s you could write something like
>>>
>>> LA 2,PRINT target area
>>> LA 3,132 target length
>>> LA 5,X'40'
>>> SLL 5,24 padding byte in high byte, length zero
>> .
>> I think that SR 5,5 and IC 5,=X'40' would be better than the previous
>> two instructions, or even one straight L.
>
> The fill character has to be in the high byte of the register, not the low
> byte. I suppose you could do ICM 5,8,=X'40'
I meant to write ICM, of course. I also said that a plain L would do.
Anyway I corrected the post.
> but I don't see why that would
> be better than LA and SLL which don't have the extra memory reference.
SLL is slow for a large number of shifts.
>>> MVCL 2,4
>>>
>>> this is probably too clever for a 132 byte field but the POO says it's the fastest
>>> way to clear a block bigger than 256 bytes.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399036 is a reply to message #399033] |
Tue, 01 September 2020 23:52 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> In article <rin086$utf$1@dont-email.me>,
> Dan Espen <dan1espen@gmail.com> wrote:
>>>> Those move character instructions with data overlap are all
>>>> specified by POP to be treated as if one byte at a time is being
>>>> moved:
>>> . That's the way it works. MVC on the IBM series never does a block
>>> transfer.
>>
>> So, the internal data path on S/360 is always a byte at a time. The
>> things I learn on the internet.
>
> Not really, it's an "as if" rule:
>
> When the operands overlap, the result is obtained as if the operands
> were processed one byte at a time and each result byte were stored
> immediately after fetching the necessary operand byte.
>
> Given how common that idiom is, I expect modern CPUs recognize it and
> do a block fill rather than load and store one byte at a time.
Yes, I guess so too. The original speculation on my part was whether a
S/360 (or it's modern equivalents) would be smart enough to use the same
optimization when there was a 4 byte overlap.
--
Dan Espen
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399037 is a reply to message #399027] |
Tue, 01 September 2020 23:58 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, September 2, 2020 at 12:32:40 PM UTC+10, Dan Espen wrote:
> Robin Vowels <r........@gmail.com> writes:
>
>> On Tuesday, September 1, 2020 at 10:19:17 PM UTC+10, Dan Espen wrote:
>>> Robin Vowels <r........@gmail.com> writes:
>>>
>>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>>
>>>> > There could be a use, though, but it would be narrow. Assuming you
>>>> > had a Fortran program fragment like
>>>> >
>>>> > DIMENSION A(4,11)
>>>> > DO 10 J=1,9
>>>> > DO 10 I=1,4
>>>> > 10 A(I,J) = 2.0
>>>> >
>>>> > you could have one index register for I running from 0 to 3 and
>>>> > another index register for J running from 0 to 32 in increments
>>>> > of four, and then just or them together.
>>>>
>>>> That's an interesting optimisation.
>>>>
>>>> In PL/I, one might write
>>>> A = 2.0;
>>>> and that would be optimised to
>>>> MVC A,B(4)
>>>> MVC A+4,A(44*4-4)
>>>>
>>>> where B is the constant 2.0.
>>> Those length specifications belong on the first operand.
>>
>> It's stylised assembler. I figured that it would be easier to follow.
> Stylized?
>
> I guess wrong is always easier to follow.
..
It isn't wrong for my purpose.
..
>>> Those move character instructions with data overlap
>>> are all specified by POP to be treated as if one byte at a time is being
>>> moved:
>> .
>> That's the way it works. MVC on the IBM series never does a block transfer.
> So, the internal data path on S/360 is always a byte at a time.
> The things I learn on the internet.
>>> For MOVE (MVC), each operand is processed left to
>>> right. When the operands overlap, the result is
>>> obtained as if the operands were processed one byte
>>> at a time and each result byte were stored immedi-
>>> ately after fetching the necessary operand byte.
>> .
>> The CPU must do it that way, otherwise the overlapped
>> fields would not work.
>> .
>>> I don't know if the hardware has an optimization to recognize the
>>> overlap offset is 4 bytes and it can fetch/store 4 bytes at a time.
>> .
>> It doesn't.
>> .
>>> The hardware would need another optimization to realize it can
>>> parallelize the whole operation and not wait to see what's in
>>> the next 4 bytes.
>>>
>>> Anyway, that's a common way to clear a print area, except it's done:
>>>
>>> MVI PRINT,X'40'
>>> MVC PRINT+1(131),PRINT
>>
>> It's done that way because the set-up is simpler (a move of one byte)
> Yep, 2 instructions are always simpler than one.
If you want one instruction, define a byte containing a blank.
amd immediately follow it with the definition of the print area.
Then you can use MVC PRINT(132),PRINT-1
..
> Got it.
>>> I was always suspicious that this would cause a performance hit
>>> so I preferred to define an area of 132 spaces and move that to
>>> areas that needed clearing.
>>
>> What a waste !
>> The MVC still moves the 132 bytes a byte at a time, storing one
>> byte before fetching the next and storing that, etc.
..
> I'm not a hardware engineer so I'm glad you could clear that up for me.
..
It's in the manual.
|
|
|
|
| Re: 70X index OR mode, Fortran, not KDF9, not IBM system/360 ad [message #399038 is a reply to message #399034] |
Wed, 02 September 2020 00:06 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> On Wednesday, September 2, 2020 at 4:08:37 AM UTC+10, John Levine wrote:
>> In article <r.......@dont-email.me>,
>> Dan Espen <d......@gmail.com> wrote:
>>> Robin Vowels <r........@gmail.com> writes:
>>>
>>>> On Tuesday, September 1, 2020 at 3:17:16 AM UTC+10, Thomas Koenig wrote:
>>>>
>>>> > There could be a use, though, but it would be narrow. Assuming you
>>>> > had a Fortran program fragment like
>>>> >
>>>> > DIMENSION A(4,11)
>>>> > DO 10 J=1,9
>>>> > DO 10 I=1,4
>>>> > 10 A(I,J) = 2.0
>>>> > ...
>>>> In PL/I, one might write
>>>> A = 2.0;
>> Sure, you can do that in modern Fortran, too.
> .
> True, but the OP was referring to earlier verstions of FORTRAN
> up to FORTRAN 77.
> The difference is that in PL/I, its been possible to write that
> since 1966.
> .
>>> Anyway, that's a common way to clear a print area, except it's done:
>>>
>>> MVI PRINT,X'40'
>>> MVC PRINT+1(131),PRINT
>>>
>>> I was always suspicious that this would cause a performance hit
>>> so I preferred to define an area of 132 spaces and move that to
>>> areas that needed clearing.
>>
>> Since the 370 came along in the early 1970s you could write something like
>>
>> LA 2,PRINT target area
>> LA 3,132 target length
>> LA 5,x'40'
>> SLL 5,24 padding byte in high byte, length zero
> .
> I think that SR 5,5 and ICM 5,...=X'40' specifying the upper byte
> would be better than the previous two instructions, or even one straight L.
So, 2 instructions with one memory reference is better than 2
instructions with no memory reference.
I always thought it was odd that IBM never got around to optimizing it's
literal pool.
If you do:
ICM R1,8,=X'40'
MVC CARDIN,=CL80' '
MVC PRINTAREA,=CL132' '
You end up with 132+80+1 spaces in the literal pool.
Another reason for a smart programmer to define an area of blanks
as large as the codes largest use and use that instead of literals.
That's not only true for HLASM but for all the high level languages I
ever looked at code generation for.
--
Dan Espen
|
|
|
|
| Re: KDF9, not IBM system/360 ad [message #399039 is a reply to message #398829] |
Wed, 02 September 2020 00:21 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 29 Aug 2020 23:58:28 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> Nevertheless, I once toured a nearby electrical generating plant where
> it was explained that those 180MW generators were cooled by circulating
> hydrogen gas through the housings. Apparently its thermal conductivity
> is high enough to make it worth working out the other problems.
The most alarming sounding cooling system I have come across is the
one used in some nuclear reactors with molten sodium running round the core
with water/steam on the other side of the heat exchange. I'm sure none of
those have ever failed, but the system design must surely allow for the
obvious and hair raising failure mode somehow - boiling radioactive caustic
soda YOUCH!
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
