<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">below.. [note this really belongs in COFF, as it's less Internet History and more reminiscent of us old guys]</font></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Sep 5, 2025 at 8:44 AM John Day via Internet-history <<a href="mailto:internet-history@elists.isoc.org">internet-history@elists.isoc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It inspired everything we did. It was a revelation. That is why our PDP-11 OS language was called PDP-11 Espol, their OS language.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Fascinating - did that survive? Could you tell us more? I did not know that someone had tried to make an ESPOL for the 11. Was it a cross compiler, and what was the native OS?</span> <span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> I grew up on BLISS and C, of course, and knew about other system languages like BCPL and concurrent Pascal that targeted the 11, but I never knew about an implementation of ESPOL for it.</span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I knew there was one around UCLA somewhere and at Stanford. Knuth wrote the early Algol compiler for it. It was the first system to use a stack for procedures, as well as arithmetic. Tagged architecture, descriptor based memory. The system had a coherence I have never seen again.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">No doubt, the B5000 was the first "high-level" system design, incorporating everything you describe, along with some interesting support for its multi-tasking concepts. [I remember trying to wrap my head around the idea of how a cactus stack worked].  One of my old colleagues at Tektronix was Bill Price, who was earlier one of the MCP's designers and implementors, and he took great pride in schooling us youngsters in those days.  He pointed out to us that if Burroughs' management had had any real idea of what they were doing and how far out it was and different from anything else being done at IBM in White Plains or </span>Remington Rand<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">/</span>Eckert-Mauchly</font><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> in North Philly, he is pretty sure they would have shut it down.</span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> As Bill explained it to us (then UNIX guys in the late 1970s), the designers of the MCP </span>were very rigorous in their design<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">, but had a great sense of humor and </span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">used really marvelous names for some of the data structures and kernel tasks.  The MCP was extremely well structured, but when they ended up with something that did not quite fit in their structured design, they gave the special case to Bill to deal with in his "Old Weird Harold" kernel task, which, among other things, maintained "the bed," which was a list of tasks awaiting actions.  One of my favorite actions was when Bill shared the comments from some of the code he still had, which revealed that Old Weird Harold was responsible for "monitoring the bed for something to fork."</span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></font></div><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Also, one minor correction, while I do believe that Burroughs had an LA-based team, I am under the impression that most of the work on both HS and SW for the B5000 and B6000 families was done in Philadelphia (well, Paoli to be more precise).</span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Trivial example: 48-bit word. Floating point format was a 39-bit mantissa (sign bit, 8-bit exponent) but the decimal point was at the right end of the word. Integers were merely unnormalized floating point numbers. No integer to real conversion. It just worked. Also, it was pointed out to me recently that there was a hardware operator that convert an integer to BCD. A 39-bit binary integer would convert within 48 bits.  (The Burros 3500 was a COBOL machine and all decimal including the addressing!) Burros was architecture-agnostic. One could go on and on.<br></blockquote><div><font color="#0000ff"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">Yeah, they got it about language-driven architectures.  My favorite Burroughs machine was their mid-range B1700, which they targeted at small businesses. This machine changed its microcode on the fly depending on the application (<i>i.e.,</i> it had Cobol microcode, Algol microcode, etc.</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">).  We studied this system in great detail in Dan Siewiorek's computer architecture class when I was an undergrad.   It was a very cool machine that really learned a great deal about how microcoding could be used (and some of you have heard my story during my UCB grad qualifiers when I was asked a question about microcoding and used the B1700 to answer it). </span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Why can’t we build systems like that any more.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Sadly, because often simpler is much less costly, and </font></span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">as I have said many times,<i style=""> "Simple Economics always beats Sophisticated Architecture."</i></font></span></div><div><font color="#ff0000"> </font></div></div></div>