> I find it hard to believe what you remember Dennis saying. The point of > dmr's streams was to support networking research in the lab and avoid the > myriad bugs of the mpx interface by stepping around them completely. > > Perhaps it's out of context. > > -rob > I could be wrong but that's my memory. What he told me was streams was > for line disciplines for tty drivers. That's what I know but you were > there, I was not. I'm pretty confused because what Dennis said to me > was that he did not think streams would work for networking, he thought > they made sense for a stream but not for a networking connection because > that had multiple connections coming up through a stream. There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views. [1] The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed. [2] However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph. If the post by dmr does not immediately appear, click on the 8-10-85 post by 'd...@dutoit.uucp’ to make it fold out. For ease of reference, I’m including the message text below. <quote> Steven J. Langdon claimed that without multiplexing one couldn't do a proper kernel-resident version of TCP/IP in the V8 stream context. Here's how it's done. It is still true in our system that stream multiplexing does not occur, in the sense that every stream connection has (from the point of view of the formal data structures) exactly two ends, one at a user process, and the other at a device or another process. However, this has, in practice, not turned out to be a problem. Say you have a hardware device that hands you packets with a channel (or socket) number buried inside in some complicated format. The general scheme to handle the situation uses both a line discipline (stream filter module) and associated code that, to the system, looks like a stream device driver with several minor devices; these have entries in /dev. A watchdog process opens the underlying real device, and pushes the stream module. Arriving packets from the real device are passed to this module, where they are analyzed, and then given to the appropriate associated pseudo-device. Likewise, messages written on the pseudo-device are shunted over to the line discipline, where they are encoded appropriately and sent to the real device. This is where the multiplexing-demultiplexing occurs; formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules. For example, IP works this way: The IP line discipline looks at the type field of data arriving from the device, and determines whether the packet is TCP or UDP or ARP or whatever, and shunts it off to the stream associated with /dev/ip6 or /dev/ip17 or whatever the numbers are. TCP, of course, is multiplexed as well. So there is a TCP line discipline, and a bunch of TCP devices; a watchdog process opens /dev/ip6, and pushes the TCP line discipline; then the TCP packets it gets are parcelled out to the appropriate /dev/tcpXX device. Each TCP device looks like the end of a stream, and may, of course, have other modules (e.g. tty processor) inserted in this stream. UDP sits on top of IP in the same way. This example is complicated, because (TCP,UDP)/IP is. However, it works well. In particular, the underlying real device can be either an ethernet or our own Datakit network; the software doesn't care. For example, from my machine, I can type "rlogin purdy" and connect to a Sequent machine running 4.2; the TCP connection goes over Datakit to machine "research" where it is gatewayed to a local ethernet that purdy is connected to. A further generalization (that we haven't made) is in principle easy: there can be protocol suites other than IP on an Ethernet cable. So there could be another layer to separate IP from XNS from Chaosnet, etc. Dennis Ritchie </quote> Maybe the subtle notion expressed as "formally, it is outside of the stream structure, because the data-passing doesn't follow the forward and backward links of the stream modules. However, the interfaces of the combined larger module obey stream rules” explains how dmr could talk about streams as being just suitable for line disciplines without meaning to say that they did not have good use in networking. Paul
On 28/08/19, Paul Ruizendaal wrote:
>
> There is some contemporary material that gives a bit of context. The quotes are a bit contradictory and perhaps reflect evolving views.
>
> [1]
>
> The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seems to support the no networking view, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seems to exclude usage for networking, which is typically multiplexed.
>
> [2]
>
> However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3Astreams/net.unix-wizards/b7W_j_0qASU
> The config files in the surviving TUHS V8 source tree actually match with the setup that dmr described in the penultimate paragraph.
>
Something else I found interesting is in v8's blit/Road.map:
"Next, operating systems. We run under Berkeley 4.1bsd or Dennis Ritchie's
stacked line-discipline system."
That sounds to me like an early v8. If not, what was it? I'm really
interested in the timeline here. How long was research running on a
PDP-11 and when did they move to a VAX?
aap
> How long was research running on a PDP-11 and when did they move to a VAX?
London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
Doug
[-- Attachment #1: Type: text/plain, Size: 845 bytes --] Interesting. In my head, v7 is kind of the pinnacle of what you should run on a PDP-11 (yes, I know 2.11BSD is still maintained), but that once you add a networking stack, the 16-bit address limitations really start to hurt, no matter how clever you are with your overlays. But when I think of v7, in my mind it's running on an 11/70. I also find the multilayer switching described in the streams networking implementation a lot like "inetd, all the way down." That's kinda nifty. Adam On Wed, Aug 28, 2019 at 10:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > > Doug > [-- Attachment #2: Type: text/html, Size: 1234 bytes --]
Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>
> > How long was research running on a PDP-11 and when did they move to a VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>
> Doug
So, what's the story on why the London/Reiser port didn't get adapted
back by Research, and they ended up starting from 4.1 BSD?
Thanks,
Arnold
[-- Attachment #1: Type: text/plain, Size: 386 bytes --] On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > Is there a paper on this work? Warner > [-- Attachment #2: Type: text/html, Size: 959 bytes --]
[-- Attachment #1: Type: text/plain, Size: 724 bytes --] On Wed, Aug 28, 2019, 12:27 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Wed, Aug 28, 2019, 11:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > >> >> > How long was research running on a PDP-11 and when did they move to a >> VAX? >> >> London and Reiser had ported Unix to the VAX, replete with virtual >> memory, in 1978. By the time v7 was released (1979), Vaxen had become the >> workhorse machines in Research. >> > > > Is there a paper on this work? > Found the 32V paper, but this was still a swapping implementation if I'm reading correctly. I thought that the virtual memory was added by BSD / Bill Joy. That would explain why V8 was BSD 4.1 based, since it was the first usable Vax port with VM. Warner > [-- Attachment #2: Type: text/html, Size: 1809 bytes --]
> Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>
>>
>>> How long was research running on a PDP-11 and when did they move to a VAX?
>>
>> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>>
>> Doug
>
> So, what's the story on why the London/Reiser port didn't get adapted
> back by Research, and they ended up starting from 4.1 BSD?
>
> Thanks,
>
> Arnold
Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.
Doug
Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> > Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> >
> >>
> >>> How long was research running on a PDP-11 and when did they move to a VAX?
> >>
> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> >>
> >> Doug
> >
> > So, what's the story on why the London/Reiser port didn't get adapted
> > back by Research, and they ended up starting from 4.1 BSD?
> >
> > Thanks,
> >
> > Arnold
>
> Sorry, what I said about London/Reiser is true, but not the whole
> story. L/R didn't have demand paging; BSD did.
But my question still stands. Why didn't Research keep going from L/R
and add demand paging? Wouldn't that have been "cleaner" than starting
from BSD?
Thanks,
Arnold
On 8/28/19 2:49 PM, arnold@skeeve.com wrote: >> Sorry, what I said about London/Reiser is true, but not the whole >> story. L/R didn't have demand paging; BSD did. > > But my question still stands. Why didn't Research keep going from L/R > and add demand paging? Wouldn't that have been "cleaner" than starting > from BSD? It's my impression that BSD had done other work that Research didn't want to duplicate, like autoconfiguration, device support, and so on. Joy got a lot out of the VAX hardware. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> On 8/28/19 2:49 PM, arnold@skeeve.com wrote:
>
> >> Sorry, what I said about London/Reiser is true, but not the whole
> >> story. L/R didn't have demand paging; BSD did.
> >
> > But my question still stands. Why didn't Research keep going from L/R
> > and add demand paging? Wouldn't that have been "cleaner" than starting
> > from BSD?
>
> It's my impression that BSD had done other work that Research didn't want
> to duplicate, like autoconfiguration, device support, and so on. Joy got
> a lot out of the VAX hardware.
He was a coding machine back then. Quite the legacy.
[-- Attachment #1: Type: text/plain, Size: 780 bytes --] I think it was slightly later. I joined mid-1980 and VAXes to replace the 11/70 were being discussed but had not arrived. We needed to convert a lab into a VAX machine room and decide between BSD and Reiser, all of which happened in the second half of 1980. Reiser Unix got demand paging a little later, and it was spectacularly fast. I remember being gobsmacked when I saw a demo in early 1981. Dead ends everywhere. -rob On Thu, Aug 29, 2019 at 3:57 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > > How long was research running on a PDP-11 and when did they move to a > VAX? > > London and Reiser had ported Unix to the VAX, replete with virtual memory, > in 1978. By the time v7 was released (1979), Vaxen had become the workhorse > machines in Research. > > Doug > [-- Attachment #2: Type: text/html, Size: 1156 bytes --]
[-- Attachment #1: Type: text/plain, Size: 792 bytes --] Reiser added paging and it was working well by early 1981. -rob On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > > >> > >>> How long was research running on a PDP-11 and when did they move to a > VAX? > >> > >> London and Reiser had ported Unix to the VAX, replete with virtual > memory, in 1978. By the time v7 was released (1979), Vaxen had become the > workhorse machines in Research. > >> > >> Doug > > > > So, what's the story on why the London/Reiser port didn't get adapted > > back by Research, and they ended up starting from 4.1 BSD? > > > > Thanks, > > > > Arnold > > > Sorry, what I said about London/Reiser is true, but not the whole story. > L/R didn't have demand paging; BSD did. > > Doug > > [-- Attachment #2: Type: text/html, Size: 1316 bytes --]
This is an object lesson in not making assumptions about things. I had
always assumed the V in UNIX 32V stood for something which went to
demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
One other note about sockets: The original 4.2 port had to be used by
a lot of people without the ethernet, because we didn't have the DEC
ethernet card it was written to. This made unix domain sockets very
interesting because you could test in them. Except: the very first
test program somebody wrote at Leeds university to create and write to
a unix domain socket in /tmp crashed the vax. ... (this was around
1982/3) -We were warned off using sockets until the first patch tape
came in the post.
The Berkeley lawyers were amazing. I like to think 'shakespear
witches' or 'evil gnomes' -We had changed staff in some functional
role, and when we came to do licence renewal for the upgrade from 4.1
They insisted we find the mouldering body of the ex appointee and get
them to countersign (press the dead flesh in a pot of ink and put on
the paper?) before they'd re-issue. I'd never seen documents (a)
printed on this bizarre page size called 'legal and (b) actually
*embossed* by the university seal.. This was some serious magic going
down. In my nightmares, somebody in mid-western nondescript university
of somewhereville is screaming "I CANT GET THE ORIGINAL SIGNATURE" and
the Berkeley lawyers just shrug and walk away from the deal.
This was also the release which brought T/Roff drivers for xerographic
process printers. They emitted wet, shiny, even slimy pages in some
process I don't want to understand, all of which bore cut marks on the
side (roll feed, before A4 printers existed) marking this US legal
thing. Cut at the mark? Won't fit a ring-binder we own in the entire
University... Mike Lesk told me the code had 'witticisms' such as an
extra emitted char on \r to ensure the specific printer it was written
for didn't stuff up TBL output.
-G
On Thu, Aug 29, 2019 at 7:55 AM Rob Pike <robpike@gmail.com> wrote:
>
> Reiser added paging and it was working well by early 1981.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:41 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>>
>> > Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>> >
>> >>
>> >>> How long was research running on a PDP-11 and when did they move to a VAX?
>> >>
>> >> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>> >>
>> >> Doug
>> >
>> > So, what's the story on why the London/Reiser port didn't get adapted
>> > back by Research, and they ended up starting from 4.1 BSD?
>> >
>> > Thanks,
>> >
>> > Arnold
>>
>>
>> Sorry, what I said about London/Reiser is true, but not the whole story. L/R didn't have demand paging; BSD did.
>>
>> Doug
>>
I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
ethernet like 3com as well as the DEC boards.
Anyone have the 4.1 or 4.2 BSD docs handy. Mine are boxed away for safe
keeping.
On 8/28/2019 6:29 PM, George Michaelson wrote:
> This is an object lesson in not making assumptions about things. I had
> always assumed the V in UNIX 32V stood for something which went to
> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>
> One other note about sockets: The original 4.2 port had to be used by
> a lot of people without the ethernet, because we didn't have the DEC
> ethernet card it was written to. This made unix domain sockets very
> interesting because you could test in them. Except: the very first
> test program somebody wrote at Leeds university to create and write to
> a unix domain socket in /tmp crashed the vax. ... (this was around
> 1982/3) -We were warned off using sockets until the first patch tape
> came in the post.
>
>
On 8/28/2019 6:36 PM, William Pechter wrote:
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other
> early
> ethernet like 3com as well as the DEC boards.
I know some VAX-11/750's running BSD 4.2 were running NI1010's - I don't
know if that was because someone had made/found a driver and installed
it, or it was native. Maybe backported from 4.3.
I think I might actually have one of those 1010's and I'm pretty sure I
have the driver development guide for it (tech specs).
Looking at the 4.3 sources I got from the place that had these VAXs,
there's this.
./src/nfsdist/32_43.FCS/sys/vaxif/if_il.c
/* @(#)if_il.c 1.4 87/07/22 3.2/4.3NFSSRC */
/*
* Copyright (c) 1982, 1986 Regents of the University of California.
* All rights reserved. The Berkeley software License Agreement
* specifies the terms and conditions for redistribution.
*
* @(#)if_il.c 7.1 (Berkeley) 6/5/86
*/
#include "il.h"
#if NIL > 0
/*
* Interlan Ethernet Communications Controller interface
*/
<SNIP>
William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc. We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point. The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system. UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall.
The Xerox cards were used with the BBN tcp before 4.1a. Eric cooper brought all that up with Sam and Bob Kriddle Iirc.
That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Aug 28, 2019, at 6:36 PM, William Pechter <pechter@gmail.com> wrote:
>
> I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> ethernet like 3com as well as the DEC boards.
>
> Anyone have the 4.1 or 4.2 BSD docs handy. Mine are boxed away for safe keeping.
>
>> On 8/28/2019 6:29 PM, George Michaelson wrote:
>> This is an object lesson in not making assumptions about things. I had
>> always assumed the V in UNIX 32V stood for something which went to
>> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
>>
>> One other note about sockets: The original 4.2 port had to be used by
>> a lot of people without the ethernet, because we didn't have the DEC
>> ethernet card it was written to. This made unix domain sockets very
>> interesting because you could test in them. Except: the very first
>> test program somebody wrote at Leeds university to create and write to
>> a unix domain socket in /tmp crashed the vax. ... (this was around
>> 1982/3) -We were warned off using sockets until the first patch tape
>> came in the post.
>>
>>
>
I should add that in the UK the vaxes we run included "systime"
equipment: They got done for photocopying DEC boards and reselling
without licence fee, and for selling kit to the USSR. They'd started
as a Vt100 seller. nice terminals.
Shame about the bad business practices. The headquarters was a
modernist building used for the BBC tv series "edge of darkness" and
did have the CEO's helicopter parked outside: he flew it when they
could afford the avgas.
-G
On Thu, Aug 29, 2019 at 10:12 AM Clem cole <clemc@ccc.com> wrote:
>
> William That’s right. 4.1a supported at least these plus the original Xerox 3m card and I think a card MIT made for chaos and the protean card. iirc. We had one of each of the production 10M Ethernet cards in the cad lab at UCB at some point. The machine dec gave us had a dec card and that was the only dec card on campus so Sam would come over to my lab to test new OSses on that system. UCB originally bought 3com cards (eventually in the cad group I got some early interlan cards from their ceo to test and I remember we liked them better for some reason I don’t remember). Before we had the 3COM based 10M link, we had couple of 3M Xerox cards on the original link back to Evans hall.
>
> The Xerox cards were used with the BBN tcp before 4.1a. Eric cooper brought all that up with Sam and Bob Kriddle Iirc.
>
> That was all switched to the 3com cards pretty early to get 10M and Early after 4.1a and I do remember sam and I had used all that to debug Routed as we had the CAD Ethernet in Cory Hall, the back link to Evans and another Ethernet in the Evans machine room.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Aug 28, 2019, at 6:36 PM, William Pechter <pechter@gmail.com> wrote:
> >
> > I could've sworn 4.x BSD supported Micom Internan NI1010 or some other early
> > ethernet like 3com as well as the DEC boards.
> >
> > Anyone have the 4.1 or 4.2 BSD docs handy. Mine are boxed away for safe keeping.
> >
> >> On 8/28/2019 6:29 PM, George Michaelson wrote:
> >> This is an object lesson in not making assumptions about things. I had
> >> always assumed the V in UNIX 32V stood for something which went to
> >> demand paging, from 'Virtual Addressing'. Turns out: I was wrong.
> >>
> >> One other note about sockets: The original 4.2 port had to be used by
> >> a lot of people without the ethernet, because we didn't have the DEC
> >> ethernet card it was written to. This made unix domain sockets very
> >> interesting because you could test in them. Except: the very first
> >> test program somebody wrote at Leeds university to create and write to
> >> a unix domain socket in /tmp crashed the vax. ... (this was around
> >> 1982/3) -We were warned off using sockets until the first patch tape
> >> came in the post.
> >>
> >>
> >
> On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>
>
>> How long was research running on a PDP-11 and when did they move to a VAX?
>
> London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
>
> Doug
I’ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix. I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators. He finished at Stanford in 1977 and in 1978 he was porting Unix? How did that happen?
-L
On Wed, Aug 28, 2019 at 11:29:02PM -0400, Lawrence Stewart wrote:
> > On 2019, Aug 28, at 1:57 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> >> How long was research running on a PDP-11 and when did they move to a VAX?
> >
> > London and Reiser had ported Unix to the VAX, replete with virtual memory, in 1978. By the time v7 was released (1979), Vaxen had become the workhorse machines in Research.
> >
> > Doug
>
> I???ve always been a little curious about how Reiser (John Reiser, not Hans!) came to port Unix. I had heard of him from his PhD Dissertation which was something like 35 pages long for Knuth (!) on random number generators. He finished at Stanford in 1977 and in 1978 he was porting Unix? How did that happen?
I'm with Lawrence, I'd love to hear this. This thread is the first I've
heard about John Reiser and London. I don't remember anything about them
in the Bell Labs journals.
I can say it is not a stretch to go from school to porting, I did that.
School is amazing at making you feel like you can do anything. I took
the grad compiler class, you could take one of them or two of them at
a time, my buddy Rob Netzer and I took two together and we wrote a
big subset of the ADA language in a semester.
You slow down when you have to make a product that works in the face
of people doing silly (aka stupid) things. Error checking is a thing,
compiler error messages that point to the exact problem are a much,
much bigger thing. Gcc is very good at that, I've got a lot of respect
for gcc, I know how hard that is.
Clem cole wrote:
> William That’s right. 4.1a supported at least these plus the original
> Xerox 3m card and I think a card MIT made for chaos
I would love to see 4.1a with Chaosnet support. I have 4.1 patched with
MIT's Chaosnet software.
Rob Pike <robpike@gmail.com> wrote: > Reiser Unix got demand paging a little later, and it was spectacularly > fast. I remember being gobsmacked when I saw a demo in early 1981. So, once again, *W*H*Y* did Research choose BSD instead of Reiser's version on the vax? > Dead ends everywhere. Explain please? Thanks, Arnold
[-- Attachment #1: Type: text/plain, Size: 493 bytes --] It had paging already and there was affection by some towards Berkeley. -rob On Thu, Aug 29, 2019 at 4:45 PM <arnold@skeeve.com> wrote: > Rob Pike <robpike@gmail.com> wrote: > > > Reiser Unix got demand paging a little later, and it was spectacularly > > fast. I remember being gobsmacked when I saw a demo in early 1981. > > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's > version on the vax? > > > Dead ends everywhere. > > Explain please? > > Thanks, > > Arnold > [-- Attachment #2: Type: text/html, Size: 931 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --] Yeah sockets, FFS, VM, autoconfiguration. It almost seems a shame he went to SUN. Although at the same time it’s no wonder why they grabbed him ASAP. I guess it’s like Avie working for NeXT. From: Larry McVoy Sent: Thursday, August 29, 2019 3:06 AM To: Chet Ramey Cc: tuhs@tuhs.org; doug@cs.dartmouth.edu Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote: > On 8/28/19 2:49 PM, arnold@skeeve.com wrote: > > >> Sorry, what I said about London/Reiser is true, but not the whole > >> story. L/R didn't have demand paging; BSD did. > > > > But my question still stands. Why didn't Research keep going from L/R > > and add demand paging? Wouldn't that have been "cleaner" than starting > > from BSD? > > It's my impression that BSD had done other work that Research didn't want > to duplicate, like autoconfiguration, device support, and so on. Joy got > a lot out of the VAX hardware. He was a coding machine back then. Quite the legacy. [-- Attachment #2: Type: text/html, Size: 3030 bytes --]
Let's get it straight. I think Kirk McKusick did the FFS. VM was done
by Somebody Babaglu (a greek? name - I know I'm not remembering it correctly.)
I guess Joy did sockets, but I don't know. I do know that he did the
csh and ex/vi. I gather he was also in the kernel, but it wasn't all him.
BSD was not a one man show.
Arnold
Jason Stevens <jsteve@superglobalmegacorp.com> wrote:
> Yeah sockets, FFS, VM, autoconfiguration. It almost seems a shame he
> went to SUN. Although at the same time it’s no wonder why they grabbed
> him ASAP. I guess it’s like Avie working for NeXT.
>
> From: Larry McVoy
> Sent: Thursday, August 29, 2019 3:06 AM
> To: Chet Ramey
> Cc: tuhs@tuhs.org; doug@cs.dartmouth.edu
> Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?]
>
> On Wed, Aug 28, 2019 at 03:03:34PM -0400, Chet Ramey wrote:
> > On 8/28/19 2:49 PM, arnold@skeeve.com wrote:
> >
> > >> Sorry, what I said about London/Reiser is true, but not the whole
> > >> story. L/R didn't have demand paging; BSD did.
> > >
> > > But my question still stands. Why didn't Research keep going from L/R
> > > and add demand paging? Wouldn't that have been "cleaner" than starting
> > > from BSD?
> >
> > It's my impression that BSD had done other work that Research didn't want
> > to duplicate, like autoconfiguration, device support, and so on. Joy got
> > a lot out of the VAX hardware.
>
> He was a coding machine back then. Quite the legacy.
>
Ah, OK. Expedience + other considerations.
I don't suppose the Reiser 32V+paging survived anywhere?
Much thanks,
Arnold
Rob Pike <robpike@gmail.com> wrote:
> It had paging already and there was affection by some towards Berkeley.
>
> -rob
>
>
> On Thu, Aug 29, 2019 at 4:45 PM <arnold@skeeve.com> wrote:
>
> > Rob Pike <robpike@gmail.com> wrote:
> >
> > > Reiser Unix got demand paging a little later, and it was spectacularly
> > > fast. I remember being gobsmacked when I saw a demo in early 1981.
> >
> > So, once again, *W*H*Y* did Research choose BSD instead of Reiser's
> > version on the vax?
> >
> > > Dead ends everywhere.
> >
> > Explain please?
> >
> > Thanks,
> >
> > Arnold
> >
Hi Arnold, > VM was done by Somebody Babaglu (a greek? name - I know I'm not > remembering it correctly.) Özalp Babaoğlu, a Turkish name. https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu -- Cheers, Ralph.
Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> Hi Arnold,
>
> > VM was done by Somebody Babaglu (a greek? name - I know I'm not
> > remembering it correctly.)
>
> Özalp Babaoğlu, a Turkish name.
> https://en.wikipedia.org/wiki/%C3%96zalp_Babao%C4%9Flu
>
> --
> Cheers, Ralph.
Much thanks. I knew I didn't have it right. :-)
Arnold
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
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.
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --] On Fri, Aug 30, 2019 at 4:22 PM Norman Wilson <norman@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). [-- Attachment #2: Type: text/html, Size: 3555 bytes --]
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
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --] 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@mcvoy.com> wrote: > 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 > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 1752 bytes --]
On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
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@bitblocks.com> wrote:
>
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
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@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@bitblocks.com> wrote:
>>>
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
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@gmail.com
"This signature fought the Time Wars, time and again."
On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc@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@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@bitblocks.com> wrote:
> >>>
> >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
It would be interesting to see its MMU details.
> On Aug 30, 2019, at 7:46 PM, Clem cole <clemc@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@bitblocks.com> wrote:
>>
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
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@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@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@bitblocks.com> wrote:
>>>>
>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
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@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@gmail.com
> "This signature fought the Time Wars, time and again."
>
>> On Fri, Aug 30, 2019 at 10:58 PM Clem cole <clemc@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@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@bitblocks.com> wrote:
>>>>>
>>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@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.
[-- Attachment #1: Type: text/plain, Size: 887 bytes --] 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
[-- Attachment #1: Type: text/plain, Size: 161 bytes --] Whenever I hear UNIX, networking and streams I have to think about this scheme. Still using this, even on HP-UX 11.31 on Itanium rx-servers Cheers, uncle rubl [-- Attachment #2: Transport Interface.gif --] [-- Type: image/gif, Size: 8969 bytes --]
[-- Attachment #1: Type: text/plain, Size: 490 bytes --] It's the Mentant implementation that HP originally bought. At LCC we had to hacked on it a bit when we put Transparent Network Computing (TNC) stuff in HP-UX [we had full process migration working BTW -- A real shame that never shipped]. On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom@gmail.com> wrote: > Whenever I hear UNIX, networking and streams I have to think about this > scheme. > > Still using this, even on HP-UX 11.31 on Itanium rx-servers > > Cheers, > uncle rubl > [-- Attachment #2: Type: text/html, Size: 873 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --] On Sat, Aug 31, 2019 at 1:38 AM Dave Horsfall <dave@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. [-- Attachment #2: Type: text/html, Size: 5010 bytes --]
I don't remember from where I got the scheme, so it might be general, DigitalUnix, or HP-UX related. Checking the "HP 9000 networking XTI programmer's guide" from 1995 there's no diagram. The application which was initially developed on a SystemV derived UNIX the Computer division of Philips Electronics had bought, used TLI. Taken over by DEC we moved to SCO UNIX still using TLI, moving to XLI on Alpha/Digital Unix. The nice thing of TLI/XLI is the poll(). A multi-client server can check a list of file descriptors AND indicate a timeout value for the poll(). Like in ret_cd = poll(tep->CEPlist, tep->CEPnumb, timeout); BTW putting in a bit of OSI, on SCO UNIX I use a DEC package which offers a TLI interface to an OSI TP4/IP stack. Even worked using X.25 as WAN. OSI TP4 and NetBIOS originally bought from Retix. >Date: Sat, 31 Aug 2019 11:41:40 -0400 >From: Clem Cole <clemc@ccc.com> >To: Rudi Blom <rudi.j.blom@gmail.com> >Cc: tuhs <tuhs@minnie.tuhs.org> >Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux,then what?] >Message-ID: > <CAC20D2MJPFoU6r73U9GDaqG+Q7vpH3T7CiDNjgN3D2uyuAJgLQ@mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >It's the Mentant implementation that HP originally bought. At LCC we had >to hacked on it a bit when we put Transparent Network Computing (TNC) stuff >in HP-UX [we had full process migration working BTW -- A real shame that >never shipped]. >On Sat, Aug 31, 2019 at 5:44 AM Rudi Blom <rudi.j.blom@gmail.com> wrote: >> Whenever I hear UNIX, networking and streams I have to think about this >> scheme. >> >> Still using this, even on HP-UX 11.31 on Itanium rx-servers >> >> Cheers, >> uncle rubl
Just to be precise and because I dislike loose ends :-) Found the XTI to TCP/IP diagram. It's even online! https://www.cs.auckland.ac.nz/references/unix/digital/APS2WDTE/TITLE.HTM Network Programmer's Guide © Digital Equipment Corporation 1994, 1995, 1996 All Rights Reserved. Product Version: Digital UNIX Version 4.0 or higher March 1996
[-- Attachment #1: Type: text/plain, Size: 436 bytes --] On 2019-Aug-31 15:37:32 +1000, Dave Horsfall <dave@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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 963 bytes --]
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
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'