30 Aug
2019
30 Aug
'19
8:21 p.m.
John Reiser did do his own paging system for UNIX 32/V.
I heard about it from friends at Bell Labs ca. 1982-83,
when I was still running systems for physicists at Caltech.
It sounded very interesting, and I would love to have had
my hands on it--page cache unified with buffer cache,
copy-on-write from the start.
The trouble is that Reiser worked in a different group
from the original UNIX crowd, and his management didn't
think his time well spent on that work, so it never got
released.
I remember asking, either during my interview at the Labs
or after I started work there, why the 4.1 kernel had been
chosen instead of Reiser's. It had to do with maintainability:
there were already people who could come in and hack on the
Berkeley system, as well as more using it and maintaining it,
whereas Reiser's system had become a unicorn. Nobody in
1127 wanted to maintain a VM system or anything much close
to the VAX hardware. So the decision was to stick with a
kernel for which someone else would do those things.
Once I'd been there for a year or so and settled in, I found
that I was actually looking after all that stuff, because I
was really interested in it. (Which seemed to delight a lot
of people.) Would we have ended up using Reiser's kernel had
I been there a couple of years earlier? I don't know.
It is in any case a shame that jfr's code never saw the light
of day. I really hope someone can find it on an old tape
somewhere and we can get it into the archive, if only because
I'd love to look at it.
Norman Wilson
Toronto ON
30 Aug
30 Aug
8:28 p.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Fri, Aug 30, 2019 at 04:21:47PM -0400, Norman Wilson wrote:
John Reiser did do his own paging system for UNIX
32/V.
I heard about it from friends at Bell Labs ca. 1982-83,
when I was still running systems for physicists at Caltech.
It sounded very interesting, and I would love to have had
my hands on it--page cache unified with buffer cache,
copy-on-write from the start.
Huh, Moran published his SunOS VM system paper in 1988, my guess is he
was working on the code for a year or two before that. So Reiser's work
predates that. Super interesting. I too would love for someone to find
a copy of that code.
8:39 p.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Fri, Aug 30, 2019 at 4:22 PM Norman Wilson <norman(a)oclsc.org> wrote:
It had to do with maintainability:
there were already people who could come in and hack on the
Berkeley system, as well as more using it and maintaining it,
whereas Reiser's system had become a unicorn. Nobody in
1127 wanted to maintain a VM system or anything much close
to the VAX hardware. So the decision was to stick with a
kernel for which someone else would do those things.
Norman, I suspect the folks in 1127 was really not different the CS-Dept at
UCB in fact. The whole reason CSRG wound down (and that was before wnj
left BTW) is the project stopped being research and started to have a
maintainence flavor which a lot of people found distasteful.
Funny, one of the things that I think made BSD the most useful, and *really
where wnj made his contribution IMO,* was the all the 'completors' between
things like the #ifdef FAST_VAX work and autoconfiguration, all the new
device support, *etc*. That was a huge amount of work not very sexy work
that made 4.1BSD in particular, 'just work' I had had the out-of-box
experience with all of V5 in RK05s, V6 and V7 on 9-track tape, earlier.
4.1BSD was a dream, really not much to do but role the tape and answer
questions.
I can see why people liked that. I remember a lot of people complaining
about the BSD VM system, but it worked 'good enough.' I can tell you when
we did the Masscomp system (and the first thing I worked on was the VM
system with tjt), even thought we had started with a System III kernel
(that was our license), we pulled Joy's code in for the VM pretty early.
The first thing Tom and I did is made it 'MP-safe' (big lock scheme to be
honest) but we were interested in debugging the locking code, not the VM
system. It's true when we did Stellar and had V.3, we used the AT&T VM
base by that point and started over, used a fine grain locking model
etc...., but by we knew how to make a MP UNIX box by then (remember the
MC-500/DP was the first MP Unix >>product<< -- predates our friends in on
the West coast by 2 years).
9:52 p.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole wrote:
MC-500/DP was the first MP Unix
>>product<< -- predates our friends in on
the West coast by 2 years).
And as I recall you had to do 2 68000's in lockstep to get the VM system
to do page fault restarts. That was neat, was that a Masscomp invention
or was it a commonly known trick?
--lm
31 Aug
31 Aug
12:58 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
Actually not in lock step. They were independent. One was called the
executor and the other the fixer. When a fault was detected the executor
was sent wait stated while the fixer handled the fault and refilled the
TLB. Once the TLB was set to instruction was allowed to complete. Btw
when the 68010 was released the pals on the board were changed to allow the
executor to actually take the fault and do something else while the fixer
replaced the TLB entry
The idea was proposed by Forest Baskett at an early Asilomar conference but
never built by him - I want to say 1980 or 81. I have lost that paper
and would love to find a copy again BTW. To be fair both Apollo and
Masscomp’s hw teams reduced the idea to practice independently but I know
of no other folks that tried it.
On Fri, Aug 30, 2019 at 5:52 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Fri, Aug 30, 2019 at 04:39:09PM -0400, Clem Cole
wrote:
--
Sent from a handheld expect more typos than usual
MC-500/DP was the first MP Unix
>>product<< -- predates our friends in on
the West coast by 2 years).
And as I recall you had to do 2 68000's in lockstep to get the VM system
to do page fault restarts. That was neat, was that a Masscomp invention
or was it a commonly known trick?
--lm
1:13 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com> wrote:
Actually not in lock step. They were independent. One was called the
executor and the other the fixer. When a fault was detected the executor
was sent wait stated while the fixer handled the fault and refilled the
TLB. Once the TLB was set to instruction was allowed to complete. Btw
when the 68010 was released the pals on the board were changed to allow the
executor to actually take the fault and do something else while the fixer
replaced the TLB entry
As I remember, the issue with 68000 was that instructions were
not restartable so in case of accessing memory that didn't
exist, you couldn't take a segfault and do anything useful.
This is why you needed a second processor to deal with an
external MMU. There would have been no TLB unless you actually
added an external TLB -- but an external CAM would've been
very expensive. May be a direct map?
What we did at Fortune was to utilize a 4 entry external map:
text, data, extra and stack. When a new function was invoked
it would do a 'probe'. If the probe caused a segfault, stack
was extended in the handler. The probe didn't have to be
restartable. So we didn't need a second 68k. This logic may
have been in the V7 port we started from.
2:46 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI
before he left dec. He was a bus and memory specialist
*** west coast VS east coast training - calling it a TB vs a TLB.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Aug 30, 2019, at 9:13 PM, Bakul Shah
<bakul(a)bitblocks.com> wrote:
On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole
<clemc(a)ccc.com> wrote:
Actually not in lock step. They were independent. One was called the
executor and the other the fixer. When a fault was detected the executor
was sent wait stated while the fixer handled the fault and refilled the
TLB. Once the TLB was set to instruction was allowed to complete. Btw
when the 68010 was released the pals on the board were changed to allow the
executor to actually take the fault and do something else while the fixer
replaced the TLB entry
As I remember, the issue with 68000 was that instructions were
not restartable so in case of accessing memory that didn't
exist, you couldn't take a segfault and do anything useful.
This is why you needed a second processor to deal with an
external MMU. There would have been no TLB unless you actually
added an external TLB -- but an external CAM would've been
very expensive. May be a direct map?
What we did at Fortune was to utilize a 4 entry external map:
text, data, extra and stack. When a new function was invoked
it would do a 'probe'. If the probe caused a segfault, stack
was extended in the handler. The probe didn't have to be
restartable. So we didn't need a second 68k. This logic may
have been in the V7 port we started from.
2:57 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough
information during some of the faults. Les Crudele once told me, that it turns out he had
tried to fix it but there were a series of errors and some short cuts they used to fit it
in the store. They gave up trying to fix it as the part was purely skunkworks and they
could not respin it at the time. After it succeeded and were a real project, the
difference between the original and the 10 was Nick redid the microcode but they had made
a larger microstore - otherwise basically the same Si.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Aug 30, 2019, at 10:46 PM, Clem cole
<clemc(a)ccc.com> wrote:
There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the
BI before he left dec. He was a bus and memory specialist
*** west coast VS east coast training - calling it a TB vs a TLB.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
>>
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com> wrote:
>>
>> Actually not in lock step. They were independent. One was called the
>> executor and the other the fixer. When a fault was detected the executor
>> was sent wait stated while the fixer handled the fault and refilled the
>> TLB. Once the TLB was set to instruction was allowed to complete. Btw
>> when the 68010 was released the pals on the board were changed to allow the
>> executor to actually take the fault and do something else while the fixer
>> replaced the TLB entry
>
> As I remember, the issue with 68000 was that instructions were
> not restartable so in case of accessing memory that didn't
> exist, you couldn't take a segfault and do anything useful.
> This is why you needed a second processor to deal with an
> external MMU. There would have been no TLB unless you actually
> added an external TLB -- but an external CAM would've been
> very expensive. May be a direct map?
>
> What we did at Fortune was to utilize a 4 entry external map:
> text, data, extra and stack. When a new function was invoked
> it would do a 'probe'. If the probe caused a segfault, stack
> was extended in the handler. The probe didn't have to be
> restartable. So we didn't need a second 68k. This logic may
> have been in the V7 port we started from.
3:14 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
Hello!
That definitely groks with a decidedly thirty year old memory. I
remember going to BUSCON, and getting into an interesting discussion
with the folks behind the M68K just how difficult it could be to run
more modern code (or operating systems). Let's just say it was
peculiar. They wanted to stick with a proprietary OS, and one odd man
there wanted to expand CPM-68K. And still another was looking into
bringing up UNIX on it.
It was fun.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc(a)ccc.com> wrote:
Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough
information during some of the faults. Les Crudele once told me, that it turns out he had
tried to fix it but there were a series of errors and some short cuts they used to fit it
in the store. They gave up trying to fix it as the part was purely skunkworks and they
could not respin it at the time. After it succeeded and were a real project, the
difference between the original and the 10 was Nick redid the microcode but they had made
a larger microstore - otherwise basically the same Si.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc(a)ccc.com> wrote:
>
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed
the BI before he left dec. He was a bus and memory specialist
>
>
> *** west coast VS east coast training - calling it a TB vs a TLB.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
>>>
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com> wrote:
>>>
>>> Actually not in lock step. They were independent. One was called the
>>> executor and the other the fixer. When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB. Once the TLB was set to instruction was allowed to complete. Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>>
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>>
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack. When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.
3:19 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
It would be interesting to see its MMU details.
On Aug 30, 2019, at 7:46 PM, Clem cole
<clemc(a)ccc.com> wrote:
There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the
BI before he left dec. He was a bus and memory specialist
*** west coast VS east coast training - calling it a TB vs a TLB.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
>
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com> wrote:
>>
>> Actually not in lock step. They were independent. One was called the
>> executor and the other the fixer. When a fault was detected the executor
>> was sent wait stated while the fixer handled the fault and refilled the
>> TLB. Once the TLB was set to instruction was allowed to complete. Btw
>> when the 68010 was released the pals on the board were changed to allow the
>> executor to actually take the fault and do something else while the fixer
>> replaced the TLB entry
>
> As I remember, the issue with 68000 was that instructions were
> not restartable so in case of accessing memory that didn't
> exist, you couldn't take a segfault and do anything useful.
> This is why you needed a second processor to deal with an
> external MMU. There would have been no TLB unless you actually
> added an external TLB -- but an external CAM would've been
> very expensive. May be a direct map?
>
> What we did at Fortune was to utilize a 4 entry external map:
> text, data, extra and stack. When a new function was invoked
> it would do a 'probe'. If the probe caused a segfault, stack
> was extended in the handler. The probe didn't have to be
> restartable. So we didn't need a second 68k. This logic may
> have been in the V7 port we started from.
3:38 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
One thing I can think of is something like this:
IIRC 68k had 24 address bits. So with a 4K page size, you can have one level
pagetable. If the pagetable is in fast SRAM, may be 1 or 2 clock cyles would
be added. If you allow 2^N processes, you need 2^(12+N) entry page table. The
width of the table would depend on the number of 4K pages in the physical
memory. Context switch would be to simply set the 2^N bit process "base"
register. Going beyond 2^N you'd have to swap out a process. Each process can
then grow up to 16MB. I don't think a real translation lookaside buffer would
help much.
It would be interesting to see the actual details.
On Aug 30, 2019, at 7:57 PM, Clem cole
<clemc(a)ccc.com> wrote:
Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough
information during some of the faults. Les Crudele once told me, that it turns out he had
tried to fix it but there were a series of errors and some short cuts they used to fit it
in the store. They gave up trying to fix it as the part was purely skunkworks and they
could not respin it at the time. After it succeeded and were a real project, the
difference between the original and the 10 was Nick redid the microcode but they had made
a larger microstore - otherwise basically the same Si.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc(a)ccc.com> wrote:
>
> There was most definitely a TLB or as Dave called it ‘The TB’ ***
> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed
the BI before he left dec. He was a bus and memory specialist
>
>
> *** west coast VS east coast training - calling it a TB vs a TLB.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
>>>
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com> wrote:
>>>
>>> Actually not in lock step. They were independent. One was called the
>>> executor and the other the fixer. When a fault was detected the executor
>>> was sent wait stated while the fixer handled the fault and refilled the
>>> TLB. Once the TLB was set to instruction was allowed to complete. Btw
>>> when the 68010 was released the pals on the board were changed to allow the
>>> executor to actually take the fault and do something else while the fixer
>>> replaced the TLB entry
>>
>> As I remember, the issue with 68000 was that instructions were
>> not restartable so in case of accessing memory that didn't
>> exist, you couldn't take a segfault and do anything useful.
>> This is why you needed a second processor to deal with an
>> external MMU. There would have been no TLB unless you actually
>> added an external TLB -- but an external CAM would've been
>> very expensive. May be a direct map?
>>
>> What we did at Fortune was to utilize a 4 entry external map:
>> text, data, extra and stack. When a new function was invoked
>> it would do a 'probe'. If the probe caused a segfault, stack
>> was extended in the handler. The probe didn't have to be
>> restartable. So we didn't need a second 68k. This logic may
>> have been in the V7 port we started from.
3:47 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
Fwiw. the 68k design team used a 11/70 running an ISC based Unix and with Rand Editor
running in Perkin Elmer Fox terminals with special microcode in the 6800 in the terminals
roms. Basically Les, Nick and Tom were all Unix folks.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Aug 30, 2019, at 11:14 PM, Gregg Levine
<gregg.drwho8(a)gmail.com> wrote:
Hello!
That definitely groks with a decidedly thirty year old memory. I
remember going to BUSCON, and getting into an interesting discussion
with the folks behind the M68K just how difficult it could be to run
more modern code (or operating systems). Let's just say it was
peculiar. They wanted to stick with a proprietary OS, and one odd man
there wanted to expand CPM-68K. And still another was looking into
bringing up UNIX on it.
It was fun.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
> On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc(a)ccc.com> wrote:
>
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save
enough information during some of the faults. Les Crudele once told me, that it turns out
he had tried to fix it but there were a series of errors and some short cuts they used to
fit it in the store. They gave up trying to fix it as the part was purely skunkworks and
they could not respin it at the time. After it succeeded and were a real project, the
difference between the original and the 10 was Nick redid the microcode but they had made
a larger microstore - otherwise basically the same Si.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc(a)ccc.com> wrote:
>>
>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>> Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and
designed the BI before he left dec. He was a bus and memory specialist
>>
>>
>> *** west coast VS east coast training - calling it a TB vs a TLB.
>>
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>>
>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul(a)bitblocks.com>
wrote:
>>>>
>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc(a)ccc.com>
wrote:
>>>>
>>>> Actually not in lock step. They were independent. One was called the
>>>> executor and the other the fixer. When a fault was detected the
executor
>>>> was sent wait stated while the fixer handled the fault and refilled the
>>>> TLB. Once the TLB was set to instruction was allowed to complete.
Btw
>>>> when the 68010 was released the pals on the board were changed to allow
the
>>>> executor to actually take the fault and do something else while the
fixer
>>>> replaced the TLB entry
>>>
>>> As I remember, the issue with 68000 was that instructions were
>>> not restartable so in case of accessing memory that didn't
>>> exist, you couldn't take a segfault and do anything useful.
>>> This is why you needed a second processor to deal with an
>>> external MMU. There would have been no TLB unless you actually
>>> added an external TLB -- but an external CAM would've been
>>> very expensive. May be a direct map?
>>>
>>> What we did at Fortune was to utilize a 4 entry external map:
>>> text, data, extra and stack. When a new function was invoked
>>> it would do a 'probe'. If the probe caused a segfault, stack
>>> was extended in the handler. The probe didn't have to be
>>> restartable. So we didn't need a second 68k. This logic may
>>> have been in the V7 port we started from.
5:37 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Fri, 30 Aug 2019, Clem cole wrote:
Btw. The issue with the 68k was Nick Tredenick’s
original Microcode did
not save enough information during some of the faults. Les Crudele once
told me, that it turns out he had tried to fix it but there were a
series of errors and some short cuts they used to fit it in the store.
They gave up trying to fix it as the part was purely skunkworks and they
could not respin it at the time. After it succeeded and were a real
project, the difference between the original and the 10 was Nick redid
the microcode but they had made a larger microstore - otherwise
basically the same Si.
Yep, that certainly rings a bell. ISTR that Sun had a board with the two
CPUs, one keeping an eye on the other.
Ah, those were the days :-) Now, we just have to put up with Intel,
although I believe the ARM is much better.
-- Dave
7:03 p.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Sat, Aug 31, 2019 at 1:38 AM Dave Horsfall <dave(a)horsfall.org> wrote:
Yep, that certainly rings a bell. ISTR that Sun had a
board with the two
CPUs, one keeping an eye on the other.
Interesting, I was under the belief that Sun never even tried the trick (at
least as a product). The original Stanford University Network (SUN) CPU
was built for an Intel Multibus (electrically and mechanically) but using a
single 68000 instead of an Intel processor. The 'SUN' was designed by one
of Forest's graduate students (Andy Bechtolsheim
<https://en.wikipedia.org/wiki/Andy_Bechtolsheim>); and the University licensed
the design extremely cheaply throughout the valley (VLSI Tech, *a.k.a.* Sun
Microsystems, was only one of the licensees. But for instance the original
Cisco AGS and the Imagen Laser printers both used CPU's licensed from the
Unversity).
FWIW: I knew Andy at CMU previously, he had designed a similar board for
the CMU front-end as I was leaving for Tektronix - when I was there we used
LSI-11s and Andy replaced that with an 8085 (then 8086) based Multibus
[IIRC, Phil Karn may have mixed up in all that too - he was hacking on what
would become KA9Q TCP on his Z80 and then the 8085. We had all taken the
graduate realtime course from Steely Dan as lab partners and our big
project was based on hacks to that hardware].
That said, it was Forest that proposed the executor/fixer trick (as I say
he gave a paper at an Asilomar Microprocessor Conference which I have sadly
misplaced). It is certainly possible that Andy tried building it, but the
only two firms that I know of that built processors using the idea were
Apollo and Masscomp (neither who used or licensed the SUN CPU design from
Stanford) although all of them used a flavor of the Multibus as their first
bus.
I don't know what Apollo did. The multibus mechanically had two connectors,
but the Intel-defined I/O bus was on the lower (larger connector). At,
Masscomp the MC-500 a private (synchronous) memory bus, that was very
similar to the BI in its protocol (because Dave designed both of course).
It was built on the unused/undefined header and ran much faster than the
I/O bus since memory fetches occurred. Also, the Masscomp >>card cage<<
was larger than Multibus (I think Apollo was also). The shorter boards
fit into the backplane, the larger size allowed for more 'chips to fit.'
IIRC, with the original memory chips being used at the time, one reason why
the Masscomp was so much faster than the Sun-1 (and 2) was it had larger
memory capacity on its boards and the memory transaction were quicker.
2 Sep
2 Sep
8:28 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On 2019-Aug-31 15:37:32 +1000, Dave Horsfall <dave(a)horsfall.org> wrote:
Ah, those were the days :-) Now, we just have to put
up with Intel,
although I believe the ARM is much better.
Well, https://www.youtube.com/watch?v=_6sh097Dk5k paints a less rosy
picture of ARM. Maybe RISC-V will succeed.
It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
makes interesting reading.
--
Peter Jeremy
11:26 p.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On Mon, 2 Sep 2019, Peter Jeremy wrote:
Well, https://www.youtube.com/watch?v=_6sh097Dk5k
paints a less rosy
picture of ARM. Maybe RISC-V will succeed.
It's a bit dated and very off topic but http://www.cpushack.com/CPU/cpu.html
makes interesting reading.
Most interesting; thanks.
-- Dave
5 Sep
5 Sep
5:11 a.m.
New subject: dmr streams & networking [was: Re: If not Linux, then what?]
On 8/31/19 12:03 PM, Clem Cole wrote:
I was under the belief that Sun never even tried the trick
Correct.
The original pre-BSD Sun-1 used the Stanford CPU,
ran Unisoft and used the stack probe hack in the compiler.
SunOS 1 required a 68010 'brain transplant'
1689
days inactive
1695
days old
16 comments
9 participants
participants (9)
-
Al Kossow -
Bakul Shah -
Clem Cole -
Clem cole
-
Dave Horsfall -
Gregg Levine -
Larry McVoy -
Norman Wilson -
Peter Jeremy