John Levine <johnl@taugh.com> schrieb:
> According to MitchAlsup <MitchAlsup@aol.com>:
>>On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
>>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
>><
>>7090 was pipelined.............
>
> "IBM's Early Computers" says the 7090 was a reimplemented 709 using
> technology from the STRETCH. While STRETCH had a lookahead feature to
> try to start memory accesses early which I suppose was a kind of
> pipeline, it doesn't seem to have made it into the 7090. The
> instruction timings in the 7090 manual at bitsavers don't say anything
> that suggests there might be pipelining.

The IBM 7094 II had "extended sequence overlap operations". What they
describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
certainly souncs like pipelining.

According to Thomas Koenig <tkoenig@netcologne.de>:
>The IBM 7094 II had "extended sequence overlap operations". What they
>describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
>certainly souncs like pipelining.

It does, but if you look at the discussion and the table on the next
page, it looks pretty vestigial. The 7090 and 7094 used the 72 bit
STRETCH memory so it could fetch an even/odd pair of words in one
operation. The overlap was mostly decoding the second instruction
while executing the first, and in a few cases starting the second
instruction's memory fetch if the first didn't reference memory. The
7094 POO says that in a typical instruction mix about 40% of
instructions could be overlapped, the rest not. So I suppose it's a
little bitty part time pipeline.

FWIW, the 709x machines had an XEC instruction, didn't do any bit
fiddling like on the 360, didn't overlap.

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

On 7/3/2021 1:34 PM, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>> According to MitchAlsup <MitchAlsup@aol.com>:
>>> On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
>>>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
>>> <
>>> 7090 was pipelined.............
>>
>> "IBM's Early Computers" says the 7090 was a reimplemented 709 using
>> technology from the STRETCH. While STRETCH had a lookahead feature to
>> try to start memory accesses early which I suppose was a kind of
>> pipeline, it doesn't seem to have made it into the 7090. The
>> instruction timings in the 7090 manual at bitsavers don't say anything
>> that suggests there might be pipelining.
>
> The IBM 7094 II had "extended sequence overlap operations". What they
> describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
> certainly souncs like pipelining.
>

I saw but did not use a 7094 doing useful work. It was at
Write-Patterson and I was around 12 years old. Has anyone here actually
used one? When and where?

On Saturday, July 3, 2021 at 2:10:06 PM UTC-6, John Levine wrote:

> "IBM's Early Computers" says the 7090 was a reimplemented 709 using
> technology from the STRETCH. While STRETCH had a lookahead feature to
> try to start memory accesses early which I suppose was a kind of
> pipeline, it doesn't seem to have made it into the 7090. The
> instruction timings in the 7090 manual at bitsavers don't say anything
> that suggests there might be pipelining.

The IBM 7094 II, at least, still in the early '60s, was 'pipelined', but only in
the primitive sense that the pipeline stages were fetch, decode, and
execute.

So because there was no overlap between the _execute_ stages of successive
instructions, the issues we associate with pipelined operation today still do
not exist; the computer was equivalent to a non-pipelined computer in basic
design.

John Savard

On 7/3/2021 2:58 PM, Ivan Godard wrote:
> On 7/3/2021 1:34 PM, Thomas Koenig wrote:
>> John Levine <johnl@taugh.com> schrieb:
>>> According to MitchAlsup  <MitchAlsup@aol.com>:
>>>> On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
>>>>> As I keep pointing out, the 360 was designed in the 1960s. There
>>>>> were no pipelines,
>>>> <
>>>> 7090 was pipelined.............
>>>
>>> "IBM's Early Computers" says the 7090 was a reimplemented 709 using
>>> technology from the STRETCH. While STRETCH had a lookahead feature to
>>> try to start memory accesses early which I suppose was a kind of
>>> pipeline, it doesn't seem to have made it into the 7090. The
>>> instruction timings in the 7090 manual at bitsavers don't say anything
>>> that suggests there might be pipelining.
>>
>> The IBM 7094 II had "extended sequence overlap operations".  What they
>> describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
>> certainly souncs like pipelining.
>>
>
> I saw but did not use a 7094 doing useful work. It was at
> Write-Patterson

Wright-Patterson, right? :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/4/2021 2:15 PM, Stephen Fuld wrote:
> On 7/3/2021 2:58 PM, Ivan Godard wrote:
>> On 7/3/2021 1:34 PM, Thomas Koenig wrote:
>>> John Levine <johnl@taugh.com> schrieb:
>>>> According to MitchAlsup  <MitchAlsup@aol.com>:
>>>>> On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
>>>>>> As I keep pointing out, the 360 was designed in the 1960s. There
>>>>>> were no pipelines,
>>>>> <
>>>>> 7090 was pipelined.............
>>>>
>>>> "IBM's Early Computers" says the 7090 was a reimplemented 709 using
>>>> technology from the STRETCH. While STRETCH had a lookahead feature to
>>>> try to start memory accesses early which I suppose was a kind of
>>>> pipeline, it doesn't seem to have made it into the 7090. The
>>>> instruction timings in the 7090 manual at bitsavers don't say anything
>>>> that suggests there might be pipelining.
>>>
>>> The IBM 7094 II had "extended sequence overlap operations".  What they
>>> describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
>>> certainly souncs like pipelining.
>>>
>>
>> I saw but did not use a 7094 doing useful work. It was at Write-Patterson
>
> Wright-Patterson, right?  :-)
>
>

@!@#$% spell-check

According to Ivan Godard <ivan@millcomputing.com>:
>> The IBM 7094 II had "extended sequence overlap operations". What they
>> describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
>> certainly souncs like pipelining.
>
>I saw but did not use a 7094 doing useful work. It was at
>Write-Patterson and I was around 12 years old. Has anyone here actually
>used one? When and where?

I just missed it, started using the computers at Princeton in 1967
when they had just turned off the 7094 in favor of a 360/67 running TSS
and a 360/91. Lots of people I know used 7094 and earlier.

My thesis advisor wrote compilers for the 650.

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

On Saturday, July 3, 2021 at 3:01:44 PM UTC-6, John Levine wrote:

> It does, but if you look at the discussion and the table on the next
> page, it looks pretty vestigial. The 7090 and 7094 used the 72 bit
> STRETCH memory so it could fetch an even/odd pair of words in one
> operation. The overlap was mostly decoding the second instruction
> while executing the first, and in a few cases starting the second
> instruction's memory fetch if the first didn't reference memory.

Yes, that was what the 7090 and 7094 had, but the 7094 II improved
matters and went to a true fetch-decode-execute pipeline.

John Savard

On Sunday, July 4, 2021 at 4:37:11 PM UTC-6, Ivan Godard wrote:

> @!@#$% spell-check

Never trust spell check! I've turned off auto-correct on my desktop;
I need it on my phone, because of the manual difficulty of entering
text, but I still check its results carefully before hitting send.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Sunday, July 4, 2021 at 4:37:11 PM UTC-6, Ivan Godard wrote:
>
>> @!@#$% spell-check
>
> Never trust spell check! I've turned off auto-correct on my desktop;
> I need it on my phone, because of the manual difficulty of entering
> text, but I still check its results carefully before hitting send.

I once was in the unenviable situation of urgently having to send
a few text messages in English. The spelling checker / autocorrect
was set to German and the phone was unfamiliar.

What came out of that one would have been completely unintelligible.

On 7/4/21 5:53 PM, John Levine wrote:
> According to Ivan Godard <ivan@millcomputing.com>:
>>> The IBM 7094 II had "extended sequence overlap operations". What they
>>> describe in http://bitsavers.org/pdf/ibm/7094/A22-6760_7094model2.pdf
>>> certainly souncs like pipelining.
>>
>> I saw but did not use a 7094 doing useful work. It was at
>> Write-Patterson and I was around 12 years old. Has anyone here actually
>> used one? When and where?
>
> I just missed it, started using the computers at Princeton in 1967
> when they had just turned off the 7094 in favor of a 360/67 running TSS
> and a 360/91. Lots of people I know used 7094 and earlier.
>
> My thesis advisor wrote compilers for the 650.
>
>
I got to Princeton in 1966 and used the 7094 (in Algol 60). Previously at
Johns Hopkins I used a 7090 (maybe 94) which was at the Applied Physics Lab.
There was a microwave link between the Hopkins campus and APL. Apparently the
link was not well error-corrected and often you would get duplicate or missing
card images. This increased the batch processing turn around substantially.

On 7/2/2021 7:01 PM, John Levine wrote:
> According to Quadibloc <jsavard@ecn.ab.ca>:
>>> Now, though, one doesn't _have_ to put the state in an elarged PSW. What Mitch
>>> Alsup was probably envisaging is that the preceding instruction plus at least the
>>> decode of the following instlruction would be *atomic* - if it can't be interrupted,
>>> then nothing needs to be saved.
>>
>> There is, of course, an even simpler solution. Just change the definition of the
>> instruction so that if the length field contains zero, then, since that's absurd, that
>> means the instruction is variable-length, and the length is found in register zero.
>
> What the 360 actually did was to make the length in the instruction one less than
> the actual length so values 0-255 meant lengths 1-256. I suppose you could have reserved
> a value and made it 1-255, but when processing long strings of data, handling it as
> 256 byte chunks was a lot more efficient than 255 byte chunks since shifting and masking
> was a lot faster than dividing by 255.
>
> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
> no caches, and computers were built out of individual transistors.

I am not sure what you consider pipelining, but if it includes fetching
the instruction N+1 simultaneously with executing instruction N, then
the 1108, also mid 1960s and made from individual transistors, was
pipelined.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
>> no caches, and computers were built out of individual transistors.
>
>I am not sure what you consider pipelining, but if it includes fetching
>the instruction N+1 simultaneously with executing instruction N, then
>the 1108, also mid 1960s and made from individual transistors, was
>pipelined.

What I had in mind was a pipeline deep enough that there'd be a significant penalty
for the out of order fetch of the Execute target, and the 1960s machines were a long
way from that.

The 360 POO says that instructions are conceptually executed in strict sequence, so an
instruction can modify the following instruction. The z/Series manual still says that,
(give or take some waffling if there are multiple virtual addresses mapped to the same
real address.) It looks like they didn't expect pipelining to be important, or I suppose
they figured they could add enough interlocks to make self-modifying code work anyway.

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

On Tuesday, July 6, 2021 at 8:17:11 PM UTC-6, John Levine wrote:

> The 360 POO says that instructions are conceptually executed in strict sequence, so an
> instruction can modify the following instruction. The z/Series manual still says that,
> (give or take some waffling if there are multiple virtual addresses mapped to the same
> real address.) It looks like they didn't expect pipelining to be important, or I suppose
> they figured they could add enough interlocks to make self-modifying code work anyway.

Well, when the System/360 was announced on April 7, 1964, the lineup consisted of
the models 30, 40, 50, 60 and 70. The 60 and 70, as originally announced, were not
shipped; instead, their performance was improved with faster memory, and so they were
re-designated the models 65 and 75. And of course, later there came along the Model 67,
a Model 65 modified to include "Dynamic Address Translation" which enabled the use
of a swap file, making timesharing easier to implement.

Models 30, 40, 50 and 65 were all microcoded. Model 75 was the hardwired member of
the bunch. The Model 75 overlapped fetch, decode, and execute, but did not break up
instruction execution into multiple steps that could be overlapped with execute steps
from other instructions, so it only had the original kind of pipeline which is not really
considered one these days.

It was only later that the Model 90 was concieved, which later became the Model 91
when offered for sale. That was the one with a pipeline - for which IBM invented
out-of-order execution, used only for floating-point, like on the Pentium II.

And the history of the Model 91 - and its modified and improved successors, the
Model 95, with thin-film memory, made specifically for NASA, and the Model 195,
with a cache, after the Model 85, microcoded and with cache memory, provided
performance comparable to the 91 at lower cost. Basically, the drama concerns the
inclusion of janitors...

The Model 195, with both cache and out-of-order execution, provided excellent and
impressive performance.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:

> And the history of the Model 91 - and its modified and improved successors, the
> Model 95, with thin-film memory, made specifically for NASA, and the Model 195,
> with a cache, after the Model 85, microcoded and with cache memory, provided
> performance comparable to the 91 at lower cost. Basically, the drama concerns the
> inclusion of janitors...

The inclusion of janitors?

Dark is the meaning of your speach (with apologies to Schiller).

On Wednesday, July 7, 2021 at 12:30:30 AM UTC-5, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > And the history of the Model 91 - and its modified and improved successors, the
> > Model 95, with thin-film memory, made specifically for NASA, and the Model 195,
> > with a cache, after the Model 85, microcoded and with cache memory, provided
> > performance comparable to the 91 at lower cost. Basically, the drama concerns the
> > inclusion of janitors...
<
> The inclusion of janitors?
<
The 360/91 was made from discrete transistors that were water cooled for performance
reasons. There was a '/91 that "blew up" when a water pipe broke, and afterwards they
kept little red mechanics towels under the frame so that if any water leak occurred, they
had a visual indication that things were amiss. "Even the Janitor could see there was a
problem".........
<
>
> Dark is the meaning of your speach (with apologies to Schiller).

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Tuesday, July 6, 2021 at 8:17:11 PM UTC-6, John Levine wrote:
>
>> The 360 POO says that instructions are conceptually executed in strict sequence, so an
>> instruction can modify the following instruction. The z/Series manual still says that,
>> (give or take some waffling if there are multiple virtual addresses mapped to the same
>> real address.) It looks like they didn't expect pipelining to be important, or I suppose
>> they figured they could add enough interlocks to make self-modifying code work anyway.
>
>Well, when the System/360 was announced on April 7, 1964, the lineup consisted of
>the models 30, 40, 50, 60 and 70. The 60 and 70, as originally announced, were not
>shipped; instead, their performance was improved with faster memory, and so they were
>re-designated the models 65 and 75. And of course, later there came along the Model 67,
>a Model 65 modified to include "Dynamic Address Translation" which enabled the use
>of a swap file, making timesharing easier to implement.

Swap file? Any 360 could swap -- they called it rollout/rollin, swap
an entire running application program out, then swap it back in to the
same place in memory later.

The /67 had 32 bit addressing (not 31 as in later 370s) and DAT which
enabled paged virtual memory, in which the system could mark
individual pages not present and it would suppress an instruction that
referenced such a page, and interrupt so the system could page the
missing page in and continue. I used TSS, which did a lousy job of
paging, and CP/67 which did a lot better.

One thing that made paging on the /67 fairly complex is that you could
have an EX instruction that crossed a page boundary that exectuted an
SS format instruction that crossed a page boundary, that referenced
two storage operands each of which crossed a page boundary so a single
instruction could touch 8 different pages, and it couldn't store any
results until it knew all 8 pages were resident. I believe in some
cases they ran the instuctions twice, once to see if the pages were
all there, again to do the actual work and store the results.

>It was only later that the Model 90 was concieved, which later became the Model 91
>when offered for sale. That was the one with a pipeline - for which IBM invented
>out-of-order execution, used only for floating-point, like on the Pentium II.

I used a /91 also. It had a 64 byte instruction buffer and could do
arithmetic operations out of order using Tomasulo's algorithm, which I
guess counts as pipelining. The instruction buffer was great, since if
your loop fit in the buffer, the CPU didn't have to do any instruction
fetches. The out of order execution was a mixed blessing. It let your
arithetic run faster, but it didn't keep enough context info to unwind
after an overflow or zero divide. Instead it caused an imprecise
interrupt, an OS/360 S0C0 termination code (pronounced "socko" of course)
and a core dump. It was sort of fun looking at the core dump and figuring
out which instructions had completed and which hadn't for a rather wide range
around the failing instruction.

The /91 manual does mention that thare were interlocks so storing into the
next instruction would work.
--
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

On Tuesday, July 6, 2021 at 11:30:30 PM UTC-6, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > Basically, the drama concerns the
> > inclusion of janitors...

> The inclusion of janitors?

> Dark is the meaning of your speach (with apologies to Schiller).

Apparently it _was_ dark, as even Mitch Alsup did not get my reference.
Despite the fact that he's a fan of the Control Data 6600.

MEMORANDUM
August 25, 1963

Memorandum To:
Messrs.
A. L. Williams
T. V. Learson
H. W. Miller, Jr.
E. R. Piore
O. M. Scott
M. B. Smith
A. K. Watson

Last week CDC had a press conference during which they
officially announced their 6600 lsystem. I understand that in the
laboratory developing this system there are only 34 people, "including
the janitor." Of these, 14 are engineers and 4 are programmers, and
only one person has a Ph. D., a relatively junior programmer. To the
outsider, the laboratory appeared to be cost conscious, hard working
and highly motivated.

Contrasting this modest effort with our own vast development
activities, I fail to understand why we have lost our industry leadership
position by letting someone else offer the world's most powerful computer.
At Jenny Lake, I think top priority should be given to a discussion as to
what we are doing wrong and how we should go about changing it immediately.

T. J. Watson, Jr.
TJW, Jr:jmc

cc: Mr. W. B. McWhirter

https://www.computerhistory.org/revolution/supercomputers/10/33/62

John Savard

On 7/7/2021 12:16 PM, John Levine wrote:
> According to Quadibloc <jsavard@ecn.ab.ca>:
>> On Tuesday, July 6, 2021 at 8:17:11 PM UTC-6, John Levine wrote:
>>
>>> The 360 POO says that instructions are conceptually executed in strict sequence, so an
>>> instruction can modify the following instruction. The z/Series manual still says that,
>>> (give or take some waffling if there are multiple virtual addresses mapped to the same
>>> real address.) It looks like they didn't expect pipelining to be important, or I suppose
>>> they figured they could add enough interlocks to make self-modifying code work anyway.
>>
>> Well, when the System/360 was announced on April 7, 1964, the lineup consisted of
>> the models 30, 40, 50, 60 and 70. The 60 and 70, as originally announced, were not
>> shipped; instead, their performance was improved with faster memory, and so they were
>> re-designated the models 65 and 75. And of course, later there came along the Model 67,
>> a Model 65 modified to include "Dynamic Address Translation" which enabled the use
>> of a swap file, making timesharing easier to implement.
>
> Swap file? Any 360 could swap -- they called it rollout/rollin, swap
> an entire running application program out, then swap it back in to the
> same place in memory later.

I take your point, but I don't consider Rollout/Rollin to be swapping.
To me swapping implies the ability to reload the swapped out program to
a different physical location. This is part and parcel of one of my
criticisms of the S/360 architecture. The reliance on using at least
one of the GPRs as a "base register", that ended up containing a
physical address caused a lot of problems. At our site, Rollout/Rollin
was basically useless. The only thing you could do was to rollout one
program if you had a higher priority program to run in that partition.
But even if a job in another partition finished, you couldn't rollin the
rolledout job into that partition. This was what led TSS/360 to be such
a total disaster. Having one HW base register that was set by the OS
when a job was first initiated or "rolled in" or switched to would have
been a much better decision. Of course, this was "fixed" in S360/67 and
later S/370s by the DAT mechanism.

snip

> I used a /91 also. It had a 64 byte instruction buffer and could do
> arithmetic operations out of order using Tomasulo's algorithm, which I
> guess counts as pipelining. The instruction buffer was great, since if
> your loop fit in the buffer, the CPU didn't have to do any instruction
> fetches. The out of order execution was a mixed blessing. It let your
> arithetic run faster, but it didn't keep enough context info to unwind
> after an overflow or zero divide. Instead it caused an imprecise
> interrupt, an OS/360 S0C0 termination code (pronounced "socko" of course)

Bravo! That is much more imaginative than what we called it, "sock
zero", as it went along with what, in our shop, was the most common
error S0C7 (pronounced "sock seven"), which was a data protection
violation (usually a subscript run amuck).

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/7/2021 1:15 PM, Quadibloc wrote:
> On Tuesday, July 6, 2021 at 11:30:30 PM UTC-6, Thomas Koenig wrote:
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>>> Basically, the drama concerns the
>>> inclusion of janitors...
>
>> The inclusion of janitors?
>
>> Dark is the meaning of your speach (with apologies to Schiller).
>
> Apparently it _was_ dark, as even Mitch Alsup did not get my reference.
> Despite the fact that he's a fan of the Control Data 6600.
>
> MEMORANDUM
> August 25, 1963
>
> Memorandum To:
> Messrs.
> A. L. Williams
> T. V. Learson
> H. W. Miller, Jr.
> E. R. Piore
> O. M. Scott
> M. B. Smith
> A. K. Watson
>
> Last week CDC had a press conference during which they
> officially announced their 6600 lsystem. I understand that in the
> laboratory developing this system there are only 34 people, "including
> the janitor." Of these, 14 are engineers and 4 are programmers, and
> only one person has a Ph. D., a relatively junior programmer. To the
> outsider, the laboratory appeared to be cost conscious, hard working
> and highly motivated.
>
> Contrasting this modest effort with our own vast development
> activities, I fail to understand why we have lost our industry leadership
> position by letting someone else offer the world's most powerful computer.
> At Jenny Lake, I think top priority should be given to a discussion as to
> what we are doing wrong and how we should go about changing it immediately.
>
> T. J. Watson, Jr.
> TJW, Jr:jmc
>
> cc: Mr. W. B. McWhirter
>
> https://www.computerhistory.org/revolution/supercomputers/10/33/62
>
> John Savard
>

The Burroughs B6500 software team did from scratch a new OS, five new
compilers, all documentation, and all the ancillary stuff with 23 people
in three years, for a new architecture and new hardware. We didn't get
actual hardware until the end of the second year. Led by Ben Dent, the
best manager I have ever worked for. Don't know what difference this
made, but rare for the industry then and now: Ben was Black.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
> I take your point, but I don't consider Rollout/Rollin to be
> swapping. To me swapping implies the ability to reload the swapped out
> program to a different physical location. This is part and parcel of
> one of my criticisms of the S/360 architecture. The reliance on using
> at least one of the GPRs as a "base register", that ended up
> containing a physical address caused a lot of problems. At our site,
> Rollout/Rollin was basically useless. The only thing you could do was
> to rollout one program if you had a higher priority program to run in
> that partition. But even if a job in another partition finished, you
> couldn't rollin the rolledout job into that partition. This was what
> led TSS/360 to be such a total disaster. Having one HW base register
> that was set by the OS when a job was first initiated or "rolled in"
> or switched to would have been a much better decision. Of course,
> this was "fixed" in S360/67 and later S/370s by the DAT mechanism.

OS/360 heavily dependent on embedded fixed addresses between program
modules. Each CSECTs had table of location (RLD) of these fixed
addresses. Program load would run each CSECT table adjusting the
addresses. This fixed the location of that program for duration of
execution.

trivia: a decade ago, I was asked to track down decision to move all
370s to virtual memory and found guy was staff to one of the execs.
Basically MVT storage management was so bad that "region" sizes had to
be four times larger than actually used ... as a result typical one
mbyte, 370/165 could only run four concurrent regions. Going to virtual
memory would allow number of concurrent regions to be increased by a
factor of four times with little or no paging. old archived post
http://www.garlic.com/~lynn/2011d.html#73

VS2 Release 1 (SVS) was essentailly very much like running MVT in a CP67
16mbyte virtual machine ... except the build of the address table was
done by MVT and a little bit paging code added. The biggest effort was
CP67 CCWTRANS was hacked into EXCP/SVC0 to do the copy of passed (I/O)
channel programs, substituting the virtual address with real address.
However, the CSECT/RLD convention still continued ... which then had the
downside of all the program pages still had to be preloaded by the
program loader and all pages with address pointers where now
modified/changed (and would have to be paged out). It was not possible
to just page map the virtual memory to the program image on disk.

TSS/360 (official virtual memory operating system for 360/67) had solved
that problem by moving the RLD equivalents to a separate system table
.... and program invokation just required prebuilding that table ... and
then mapping virtual memory to program image on disk (w/o preloading)
and invoking the program. This also had the advantage in that several
application address spaces could have concurrent shared image of the
same program ... concurrently (even located at different virtual
addresses, in different address spaces).

Some of the MIT CTSS people went the 5th flr to Project MAC to do
MULTICS, others went to the ibm science center on the 4th flr and did
CP40/CMS (CP40 ran on 360/40 that had been modified with virtual memory
hardware). CP40/CMS morphs into CP67/CMS (precursor to VM370/CMS) when
360/67 standard with virtual memory becomes available.

I had done a virtual paged mapped filesystem for CP67/CMS (and later
moved to VM370/CMS) ... and would comment that I learned what not to do
by observing TSS/360 implementation. One of the TSS/360 performance
issues was that it just paged mapped the programs (everthing 4k page
fault at a time, no read-ahead or multiple 4k transfers in single
operation) ... so loading required multiple (potentially large number)
individual 4k synchronous page faults. I did a lot of work on being able
to schedule preload & read-ahead as much as possible (given amount and
contention for real storage). This met much of the program could be
loaded with single I/O operation (rather than 4k at a time with separate
I/O operations) ... and program execution could be started before the
whole program was available in memory.

The downside was CMS used a lot of OS/360 compilers that generated
CSECTS with the RLD convention. I had to go through a lot of effort to
create program images on disk that could be page mapped and be shared
concurrently in multiple different addresses spaces ... even at
different virtual address locations (like in TSS/360).

--
virtualization experience starting Jan1968, online at home since Mar1970

On 7/8/2021 11:15 AM, Anne & Lynn Wheeler wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> I take your point, but I don't consider Rollout/Rollin to be
>> swapping. To me swapping implies the ability to reload the swapped out
>> program to a different physical location. This is part and parcel of
>> one of my criticisms of the S/360 architecture. The reliance on using
>> at least one of the GPRs as a "base register", that ended up
>> containing a physical address caused a lot of problems. At our site,
>> Rollout/Rollin was basically useless. The only thing you could do was
>> to rollout one program if you had a higher priority program to run in
>> that partition. But even if a job in another partition finished, you
>> couldn't rollin the rolledout job into that partition. This was what
>> led TSS/360 to be such a total disaster. Having one HW base register
>> that was set by the OS when a job was first initiated or "rolled in"
>> or switched to would have been a much better decision. Of course,
>> this was "fixed" in S360/67 and later S/370s by the DAT mechanism.
>
> OS/360 heavily dependent on embedded fixed addresses between program
> modules. Each CSECTs had table of location (RLD) of these fixed
> addresses. Program load would run each CSECT table adjusting the
> addresses. This fixed the location of that program for duration of
> execution.

I certainly defer to your knowledge of OS/360 internals. However, I
think this could be worked out by having those "fixed" addresses
actually be relative to the system controlled base register. Perhaps
not, but I know that the basic idea works, as systems competing with
S/360 did it.

snip interesting story

> TSS/360 (official virtual memory operating system for 360/67)

I apologize for sending you down a wrong path. I meant TSO/360 (Time
Sharing Option), not TSS/360. For those not familiar with this beast,
it was a program that ran under the OS in a partition. It ran the
terminals and "swapped" user programs in and out of its own memory,
using whatever memory management system it used. I don't know the
details, but it had the TSO/360 overhead on top of the OS/360 overhead,
and was generally ridiculously slow. We ran it on a 360/65 under MVT,
and beyond about 4 users it was almost unusable. On the good side, you
didn't have to key in JCL into the terminal. :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/6/2021 7:17 PM, John Levine wrote:
> According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
>>> no caches, and computers were built out of individual transistors.
>>
>> I am not sure what you consider pipelining, but if it includes fetching
>> the instruction N+1 simultaneously with executing instruction N, then
>> the 1108, also mid 1960s and made from individual transistors, was
>> pipelined.
>
> What I had in mind was a pipeline deep enough that there'd be a significant penalty
> for the out of order fetch of the Execute target, and the 1960s machines were a long
> way from that.

Fair enough. I looked at the 1108 Processor and Storage manual
(available on Bit Savers),and it says the execute instruction takes
..75uS, the same as most other "simple" instructions. Though looking at
the timing information provided in the manual, it seems it should take
some extra time to fetch the instruction. But since there was no cache,
and the memory was multi-banked, the penalty should be less than 1 uS.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, July 8, 2021 at 6:18:21 PM UTC-6, Stephen Fuld wrote:

> Fair enough. I looked at the 1108 Processor and Storage manual
> (available on Bit Savers),and it says the execute instruction takes
> .75uS, the same as most other "simple" instructions. Though looking at
> the timing information provided in the manual, it seems it should take
> some extra time to fetch the instruction.

But if the instruction being executed also takes its usual time, that time
includes the time taken to fetch it, since instructions always have to
be fetched.

John Savard

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> Swap file? Any 360 could swap -- they called it rollout/rollin, swap
>> an entire running application program out, then swap it back in to the
>> same place in memory later.
>
>I take your point, but I don't consider Rollout/Rollin to be swapping.
>To me swapping implies the ability to reload the swapped out program to
>a different physical location.

I agree it wasn't very good swapping.

> This is part and parcel of one of my
>criticisms of the S/360 architecture. The reliance on using at least
>one of the GPRs as a "base register", that ended up containing a
>physical address caused a lot of problems.

The IBMSJ article on the 360 architecture says that the point of base+displacement
addressing was to made the addresses in the instructions small enough to let code
fit on small systems (remember that DOS originally ran in 16K) while enabling linear
addressing in large systems. I think they also wrongly believed that forcing all
addresses to use base registers would make hardware relocation unnecessary, which was
of course completely wrong.

I gather that the code in APL\360 was sufficiently disciplined that it
could swap out a user's data block and swap it back in somewhere else
and fix up the data base register and it would work, but that was
quite unusual.

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