
Case Study: IBM's System/360-370 Architecture (1987) [pdf] - eternalban
https://www.cs.tufts.edu/~nr/cs257/archive/alfred-spector/spector87ibm.pdf
======
mrbill
The book "IBM's 360 and Early 370 systems" by IBM Press goes DEEP into the
development of these systems, and is one of my very favorite technical books.
I paid $50 for a used copy more than a decade ago and it's well worth it.
(also: "IBM's Early Computers" from some of the same authors, covers pre-360
stuff).

[https://books.google.com/books/about/IBM_s_360_and_Early_370...](https://books.google.com/books/about/IBM_s_360_and_Early_370_Systems.html)

------
andrewf
> Q: What sorts of radical changes can you foresee that would cause the 360
> architecture to be supplanted by a new architecture?

> A: That’s hard to say. If there is ever a breakthrough in harnessing
> thousands of micros into an effective array for a wide-enough spectrum of
> big jobs, then it might be time to rethink the major computer product lines.

~~~
msla
A Beowulf Cluster, in case you weren't on Slashdot in the 1990s:

[https://en.m.wikipedia.org/wiki/Beowulf_cluster](https://en.m.wikipedia.org/wiki/Beowulf_cluster)

~~~
itomato
Yes, but can you imagine a Beowulf Cluster of 360 boxes?

------
Cactus2018
Fred Brooks is mentioned in the case study.

The book "The Mythical Man Month" is about software engineering and project
management based on Fred Brooks experiences at IBM while managing the
development of OS/360.

> assigning more programmers to a project running behind schedule will make it
> even later.

> while it takes one woman nine months to make one baby, "nine women can't
> make a baby in one month".

[https://en.wikipedia.org/wiki/The_Mythical_Man-
Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)

~~~
wglb
The book is essentially an apologia for finishing one year late.

~~~
graycat
And he ended up with JCL, one of the worst pieces of work in computing. There
were already much better user interfaces then.

~~~
edward-h
You might be pleased to hear Fred Brooks apologised for JCL in 2015:[1]

> If we had been smart, we would also have done a schedule-time mode of PL/I
> instead of doing JCL, the Job Control Language. But we weren’t smart. The
> worst mistake we made was JCL. Its existence was a mistake. Building it on a
> card format was a mistake. Building it on assembly language was a mistake.
> Thinking of it as only six little control cards instead of a language was a
> mistake, because it had no proper subroutine facilities, no proper branching
> facilities. That we did not see it as a language was the fundamental
> problem; we saw it as a set of control cards.

[1] [https://cacm.acm.org/magazines/2015/11/193333-an-
interview-w...](https://cacm.acm.org/magazines/2015/11/193333-an-interview-
with-fred-brooks/abstract)

~~~
gwern
The full interview is at
[https://archive.computerhistory.org/resources/access/text/20...](https://archive.computerhistory.org/resources/access/text/2012/11/102658255-05-01-acc.pdf)
; I've mirrored the ACM excerpts at
[https://www.gwern.net/docs/cs/2015-brooks.pdf](https://www.gwern.net/docs/cs/2015-brooks.pdf)

------
drfuchs
I appreciate the shout-out to the “Imprecise Interrupt” found only in the
360/91: “You divided by zero somewhere in there, but we’re not going to tell
you where, and if you’ve done a Branch/Jump by the time we detected it, the
current Instruction Pointer won’t give you much of a clue, either.” Fun times.

~~~
monocasa
The 360/91's FPU was the first full on Tomasulo's algorithm OoO pipeline.
Recovering from exceptions and unwinding state is one of the most difficult
parts of those cores, so I don't really blame them for punting on that part

~~~
graycat
I learned PL/I on the 360/91 at the JHU/APL.

Later I used PL/I on CP67/CMS in Stamford to save FedEx the first time, to
schedule the full planned 33 planes to cover the planned 90 cities. Founder,
COB, CEO Smith's remark at the staff meeting was 'An amazing document, solves
the most important problem facing Federal Express." Our two guys from BoD
Member General Dynamics looked over the schedule and said "It's a little tight
in a few places, but it's flyable." The BoD doubts were defeated; the BoD was
pleased; crucial funding was enabled; and FedEx was saved.

PL/I is a nice language. When I got a phone interview from Google and they
asked me what my favorite language was, of course I said PL/I. Apparently way
wrong answer and they were looking for at least C and hopefully C++. I was
later in the IBM Watson lab research group that did KnowledgeTool, a rule
based pre-processor to PL/I. Some of my knowledge of PL/I internals let me do
a trick that saved much of the language -- I got an award for that.

PL/I based structures are nearly as nice as C# objects and for addressing use
essentially only generalized array addressing so are really fast. If want
_methods_ , then have some entry variables in the structure. For a light
version of inheritance, use the attribute Like. For something like
polymorphism, use Generics, or whatever it was called then, that is, the right
version of the code is called depending on the types of what is passed. The
scope of names support is terrific stuff. Similarly for the exception
condition handling via On conditions and how they work with scope of names and
the stack of dynamic descendancy.

There's a lot of good stuff in PL/I. Sorry people at Google didn't know about
PL/I!

~~~
pjmlp
And from all the papers I have read, a much safer option to write systems
software on than C ever was.

~~~
msla
Much harder to write compilers for, though.

~~~
pjmlp
Sure, but that was already a solved problem outside Bell Labs, at least by
reading IBM papers and interviews with well known compiler implementers from
the 60 - 80's.

~~~
walshemj
And PR1ME used pl1 as its system programming language

~~~
graycat
Okay, okay, I give up; you win! I used to be a Prime customer and was going to
post that! Gotta type fast at HN or get _scooped_!

And what was the role of PL/I in Multics?

~~~
pjmlp
Not the OP, but you can find quite a good collection of info at
[https://www.multicians.org/](https://www.multicians.org/), specially
interesting is the B2 Security Evaluation
([https://www.multicians.org/b2.html](https://www.multicians.org/b2.html))
with the pearl that none of the UNIX known exploits, possible due to C's lack
of safety where possible to take advantage of on Multics, thanks PL/I.

~~~
unused0
Sadly, a buffer overflow attack has been found; it is possible to write bad
PL/I. (The defective code is a user-space tool, so at best, a remote code
exploit. No privilege escalation.)

~~~
pjmlp
Any public info about it?

~~~
unused0
A writeup is on my round tuit list; some day soon.

PL/I does bounds checking on arrays, but not on pointers.

The Kermit server allocated an insufficiently large buffer to decompress
packets into, and used ptrs to write to the buffer. (Errors 1 and 2:
allocation and ptrs)

Later in the code, there is a 'goto state(idx)' construct, with a declaration
like 'dcl state (0:6) label init (state0, state1, ....);'.

Which label is jumped to depends on the value of idx.

The 'state' variable was not declared to be state (error 3), so the table is
in writable memory, and due to whatever circumstances, is above the decompress
buffer.

A correctly crafted packet, when decompressed, will write over the end of the
buffer and onto the state array. Later, when the goto is executed, the address
transferred has been changed. It is not the case that a transfer can be made
into the decompress buffer, as it is not in an executable segment, there are
lots of places that could be transferred to, leaving open the possibility of
an exploit.

The error was discovered when a particular file transfer would reliably crash
the kermit server, and analysis of the crash uncovered the coding errors.

~~~
pjmlp
Thanks for sharing.

I always find such stories interesting.

------
glhaynes
I found this line interesting: “All of the reasonable designs that have been
developed have been a lot closer to each other than people expected.”

It feels (to me, who is admittedly not a hardware person) as though
instruction sets haven’t really been that important aside from a brief moment
when RISC seemed revolutionary.

~~~
nabla9
Intel, Alpha, ARM, SPARC, have clever legacy quirks and hacks. VLIW's, stack
machines, tagged architectures etc. never took off.

RISC-V is the newest and coolest completely new instruction set. It's also one
of the the most reasonable, practical and boring instruction sets you can
imagine. It's basically updated and cleaned MIPS-style ISA with minimal
surprises.

~~~
rbanffy
For modern high performance CPUs the benefit of RISC in terms of
simpler/faster decoding fade a bit in relation to the memory bandwidth benefit
of more concise instructions. Still, a lot of die space is dedicated to
interpret x86 instructions and issue operations for the backend. I wouldn't
mind having that silicon dedicated to more threads (which mean fewer context
switches) or a larger cache (which somewhat negates the advantages of a more
concise code)

~~~
nabla9
RISC-V has compressed instruction subset that reduces code size 25-30%.

~~~
rbanffy
Having a compressed ISA AND a smaller decoder is a win-win.

There are, sadly, non-intrinsic reasons why x86 holds the position it does -
nobody has the kind of money Intel has to invest in high-performance desktop
CPUs. The few companies that do either go after the x86 market or ignore the
desktop and low/mid-range server niche.

------
enricotal
My dad's factory in the 80s was managed by s360. I do not understand why, but
1 out of 4 companies in Italy I talk to, are still running AS400... This must
be something like Maya architecture :)

------
saagarjha
> we wanted to emphasize that the architecture is, in fact, defined; the
> definition, however, specifies the operation to be unpredictable. That is,
> the operation may vary among models, and on any one model may differ among
> instances. Otherwise someone could ask when we are going to complete the
> definition.

This is quite an interesting way of combating Hyrum's Law!

------
jejones3141
Interesting. I wish they'd discussed why they went for base 16 floating point.

~~~
wglb
If I recall correctly, knuth’s volume two about semi numerical algorithms
talks abou that in adequate detail.

