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.
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
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!
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.
Not the OP, but you can find quite a good collection of info at https://www.multicians.org/, specially interesting is the B2 Security Evaluation (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.
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.)
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.
Yes, when I was at IBM's Watson lab working in KnowledgeTool, a PL/I pre-processor (using some of Deremer's work, our software did fully parse the KnowledgeTool source and, thus, also PL/I), I got to chat with George Radin, essentially the father of PL/I.
For a while I was teaching computer science in the business school at Georgetown and taught a start on PL/I, e.g., enough to do quicksort.
