[TUHS] Algol68 vs. C at Bell Labs

[TUHS] Algol68 vs. C at Bell Labs

[Noel Chiappa]

    > From: scj at yaccman.com

    > I think one fatal mistake that A68 made

One of many, apparently, given Hoare's incredible classic "The Emperor's Old
Clothes":

   http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf

(which should be required reading for every CS student).

       Noel

[TUHS] Algol68 vs. C at Bell Labs

[William Cheswick]

I assumed by 1980 that Rule 1 (program security) was an obvious given. Alas, no.

> On 30Jun 2016, at 9:44 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> One of many, apparently, given Hoare's incredible classic "The Emperor's Old
> Clothes":
> 
>   http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf
> 
> (which should be required reading for every CS student).
> 
>       Noel

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[scj]

My memory was that the 68000 gave the 8086 a pretty good run for its
money, but when Moto came out with a memory management chip it had some
severe flaws that made paging and fault recovery impossible, while the
equivalent features available on the 8086 line were tolerable.  There were
some bizarre attempts to page with the 68000 (I remember one product that
had two 68000 chips, one of which was solely to sit on the shoulder of the
other and remember enough information to respond to faults!).  By the time
Moto fixed it, the 8086 had taken the field...

I got a lot more respect for the 8086 architecture when working at
Transmeta.  The instruction set encoding means that programs are small,
and that means that, for a given icache size, the cache hit rate was much
better than for our (wide word) machine.  By the time we had upped the
size of our caches, the increased area and cost made our chip much less
competitive.

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

scj at yaccman.com wrote:

> My memory was that the 68000 gave the 8086 a pretty good run for its
> money, but when Moto came out with a memory management chip it had some
> severe flaws that made paging and fault recovery impossible, while the
> equivalent features available on the 8086 line were tolerable.  There were
> some bizarre attempts to page with the 68000 (I remember one product that
> had two 68000 chips, one of which was solely to sit on the shoulder of the
> other and remember enough information to respond to faults!).  By the time
> Moto fixed it, the 8086 had taken the field...

The 68451 did exist early. We had a "ExorMax" development system with the MMU 
that we used to develop our UNOS derivate "VBERTOS" before we had our own 
hardware.

The design bug in the mc68000 was that the execption stack did not contain the 
complete microcode state for things like "*p++" and thus was not restartable at 
the same state.

The ideas using two 68000 did put the main CPU into halt (from wehre it could 
be restarted) and did only run the exception handling code on the second CPU.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Dan Cross]

On Thu, Jun 30, 2016 at 1:17 PM, <scj at yaccman.com> wrote:

> My memory was that the 68000 gave the 8086 a pretty good run for its
> money, but when Moto came out with a memory management chip it had some
> severe flaws that made paging and fault recovery impossible, while the
> equivalent features available on the 8086 line were tolerable.  There were
> some bizarre attempts to page with the 68000 (I remember one product that
> had two 68000 chips, one of which was solely to sit on the shoulder of the
> other and remember enough information to respond to faults!).  By the time
> Moto fixed it, the 8086 had taken the field...
>

Brantley Coile mentioned this here a couple of years ago: M68k couldn't
restart auto-inc/dec style instructions after a fault (there wasn't enough
information in the trap frame to ensure the side-effects were correct),
which made e.g. dynamic paging hard. He did a Unix port in which he simply
loaded the process completely before switching to it (e.g., like <= 32V).
But if I understand correctly, this was fixed by the time the 68010 came
out (1982). And it wouldn't have mattered for a non-paging system. So in
principle the 68000 could support a 7th-Edition style Unix and indeed, did
so. Surely it could have supported another similar operating system for a
hypothetical IBM PC based around the 68k.

Still, the point that the 68451 MMU was pretty lame is well taken. The
segment table was too small (96 entries?) and it was clearly designed to
support segmented memory rather than paging. It is inadequate to the latter
task. The 68851 available for the 68020 got it right; supposedly this could
be used with the 68010 as well, but I don't know that anyone ever tried
that in a real product.

I got a lot more respect for the 8086 architecture when working at
> Transmeta.  The instruction set encoding means that programs are small,
> and that means that, for a given icache size, the cache hit rate was much
> better than for our (wide word) machine.  By the time we had upped the
> size of our caches, the increased area and cost made our chip much less
> competitive.
>

I've heard that this is still one of the selling points of the x86
instruction set. As someone put it to me not too long ago, "think of it as
a dense bytecoding over the underlying RISC core." We're back to a P-code.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/0912ba80/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

Noel Chiappa scripsit:

> One of many, apparently, given Hoare's incredible classic "The Emperor's
> Old Clothes":

I agree with 90% of what he says, but not about Algol 68.  He obviously
has a strong preference for small languages: it would be interesting
to see his uncensored opinions of C++, the Godzilla of our day as Ada
and PL/I and Algol 68 were the Godzillas of theirs.  But from where we
stand now, A68 looks like a minizilla indeed, and has many interesting
ideas (notably structural equivalence).  It would need a few upgrades
to provide for subtyping and functional programming.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Dan Cross <crossd at gmail.com> wrote:

> Still, the point that the 68451 MMU was pretty lame is well taken. The
> segment table was too small (96 entries?) and it was clearly designed to
> support segmented memory rather than paging. It is inadequate to the latter
> task. The 68851 available for the 68020 got it right; supposedly this could
> be used with the 68010 as well, but I don't know that anyone ever tried
> that in a real product.

We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for our 
virtual UNOS variant.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Dan Cross]

On Thu, Jun 30, 2016 at 3:59 PM, Joerg Schilling <schily at schily.net> wrote:

> Dan Cross <crossd at gmail.com> wrote:
>
> > Still, the point that the 68451 MMU was pretty lame is well taken. The
> > segment table was too small (96 entries?) and it was clearly designed to
> > support segmented memory rather than paging. It is inadequate to the
> latter
> > task. The 68851 available for the 68020 got it right; supposedly this
> could
> > be used with the 68010 as well, but I don't know that anyone ever tried
> > that in a real product.
>
> We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for
> our
> virtual UNOS variant.


Sorry, I was referring to using a 68851 with a 68010; I'd imagine that by
the time the 68851 was appearing in new designs, it was paired with the
68020.

Wow. *12* 68451s? That's pretty wild.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/144e7bad/attachment.html>

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Dan Cross <crossd at gmail.com> wrote:

> > We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for
> > our
> > virtual UNOS variant.

> Wow. *12* 68451s? That's pretty wild.

3 have been officially supported.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]

Steve almost right....mixing a few memories...see below..

On Thu, Jun 30, 2016 at 1:17 PM, <scj at yaccman.com> wrote:

> My memory was that the 68000 gave the 8086 a pretty good run for its
> money,

​Indeed - most of the UNIX workstations folks picked it because of the
linear addressing.​


but when Moto came out with a memory management chip it had some
> severe flaws that made paging and fault recovery impossible, while the
> equivalent features available on the 8086 line were tolerable.

​Different issues...​

​When the 68000 came out there was a base/limit register chip available,​
who's number I forget (Moto offered to Apple for no additional cost if they
would use it in the Mac but sadly they did not).    This chip was similar
to the 11/70 MMU, as that's what Les and Nick were used to using (they used
a 11/70 running Unix V6 has the development box and had been before the
what would become the 68000 -- another set of great stories from Les, Nick
and Tom Gunter).

The problem with running a 68000 with VM was not the MMU, it was the
microcode.   Nick did not store all of the needed information needed by the
microcode to recover from a faulted instruction, so if a instruction could
not complete, it could not be restarted without data loss.


> There were
> ​ ​
> some bizarre attempts to page with the 68000 (I remember one product that
> had two 68000 chips, one of which was solely to sit on the shoulder of the
> other and remember enough information to respond to faults!).

​This was referred to as Forest Baskett mode -- he did a early paper that
described it.  I just did a quick look but did not see a copy in my shelf
of Moto stuff.​   At least two commercial systems were built this way -
Apollo and Masscomp.

The two processors are called the "executor" and "fixer."  The trick is
that when the MMU detects an fault will occur, the executor is sent "wait
state" cycles telling it that the required memory location is just taking
longer to read or write.   The fixer is then given the faulting address,
which handles the fault.    When the page is finally filled, on the
Masscomp system the cache is then loaded and the executor is allowed to
complete the memory cycle.

When Nick fixed the microcode for the processor, the updated chip was
rebranded as the 68010.   In the case of the Masscomp MC-500 CPU board, we
popped the new chip in as the executor and changed the PAL's so the fault
was allowed to occur (creating the MPU board).   This allowed the executor
to go do other work while the fixer was dealing with the fault.    We
picked up a small amount of performance, but in fact it was not much.   I
still have a system on my home network BTW (although I have not turned it
on in a while -- it was working last time I tried it).

Note the 68010 still needed an external MMU.  Apollo and Masscomp built
their own, although fairly soon after they did the '10 Moto created a chip
to replace the base/limit register scheme with one that handled 2-level
pages.

In Masscomp's case when we did the 5000 series which was based on the
68020, use their MMU for their low end (300 series)  and our custom MMU on
the larger systems (700 series).



> By the time
> ​ ​
> Moto fixed it, the 8086 had taken the field...
>
​Well sort of.   The 68K definitely won the UNIX wars, at least until the
386 and linear addressing would show up in the Intel line.​  There were
some alternatives like the Z8000, NS32032, and AT&T did the 32100 which was
used in the 3B2/3B5 et al. but 68K was the lion share.


​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/8cf1c389/attachment.html>