[ih] Confusion in the RFCs

[Clem Cole]

below.. [note this really belongs in COFF, as it's less Internet History
and more reminiscent of us old guys]

On Fri, Sep 5, 2025 at 8:44 AM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

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

>
> 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.
>
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 Remington Rand/Eckert-Mauchly in
North Philly, he is pretty sure they would have shut it down.

 As Bill explained it to us (then UNIX guys in the late 1970s), the
designers of the MCP were very rigorous in their design, but had a
great sense of humor and 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."

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

>
> 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.
>
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.e.,* it had Cobol microcode, Algol microcode, etc.).  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).

>
> Why can’t we build systems like that any more.
>
Sadly, because often simpler is much less costly, and as I have said many
times,* "Simple Economics always beats Sophisticated Architecture."*