30 Jun
2016
30 Jun
'16
7:44 p.m.
From: scj(a)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
30 Jun
30 Jun
8:28 p.m.
New subject: Algol68 vs. C at Bell Labs
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(a)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
11:17 p.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
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.
11:27 p.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
scj(a)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@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
1 Jul
1 Jul
12:52 a.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
On Thu, Jun 30, 2016 at 1:17 PM, <scj(a)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.
1:59 a.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
Dan Cross <crossd(a)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@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
2:06 a.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
On Thu, Jun 30, 2016 at 3:59 PM, Joerg Schilling <schily(a)schily.net> wrote:
Dan Cross <crossd(a)gmail.com> wrote:
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.
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.
2:27 a.m.
New subject: 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)
Dan Cross <crossd(a)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@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'
1:23 a.m.
New subject: Algol68 vs. C at Bell Labs
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(a)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
3096
days inactive
3096
days old
8 comments
6 participants
participants (6)
-
Dan Cross -
jnc＠mercury.lcs.mit.edu -
John Cowan -
schily＠schily.net -
scj＠yaccman.com -
William Cheswick