From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20181008081253.GB812@ananda.local> In-Reply-To: <20181008081253.GB812@ananda.local> From: "Digby R.S. Tarvin" Date: Mon, 8 Oct 2018 20:12:52 +1100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000d836e10577b405ac" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: e8b320ca-ead9-11e9-9d60-3106f5b1d025 --000000000000d836e10577b405ac Content-Type: text/plain; charset="UTF-8" I quite agree - the PDP 11/70 was quite a high end 16 bit machine, but it was the machine that I was talking about and the one I would most like to revisit (although I wouldn't turn down an 11/40 if somebody offered me a working one). I don't think I would contemplate putting Plan9 on a machine with no MMU or a 64K physical memory limit. My first reasonable multi-user, multi-tasking computer system (back in the early 80s) was home made 6809 machine with 6829 MMU and eventually 1MB of ram, running OS-9/6809. It initially ran with 64K for programs and and the rest of memory was a big ram disk - because what else could you do with such a ridiculous amount of memory. It did pretty well at providing a personal Unix like environment, although counldn't reproduce the fork() semantics and there was no memory protection, and the memory contraints meant always running the C compiler one pass at a time.. But we eventually ported 'Level 2' OS-9 which could use a mapping ram/MMU, and with that I had a quite robust multi-user system, with up to 64K available per process, and 64K available for the kernel. I was able to get most Unix programs running on it (except for a few with big tables that compiled to larger than 64K) and no longer had to worry about exiting the editor before doing a compile. Most of the core system utilities were written in assembly language - so the equivalent of 'ls' for example, required no more than a 256 byte memory allocation. And all executables were loaded read-only and re-entrant (shared text) which helped. The only real Achilles heal was the 6809 had no illegal instruction trapping, so executing data could occasionally result in an unrecoverable freeze.. I never liked the 68K version os OS-9 quite as much. Because of the larger address space it used the MMU for protection only, with no address translation - so the kernel was mapped into the same address space as the user programs but just not accessible in user mode. It just didn't seem as elegant. Anyway, thats why I don't see 64K per process as necessarily being inadequate for a lean operating system, although it would be easy enough to write extravagant code that would not run in 64K, or a design that relied on a large virtual address space - especially if you were used to relying on virtual memory. I just don't know if how small Plan9 can go, and unless someone has already explored those limits, I suppose rather than speculating i'll just have to plan on a little experimentation when I get a bit of spare time. Regards, Digby On Mon, 8 Oct 2018 at 19:13, Nils M Holm wrote: > On 2018-10-08T15:29:02+1100, Digby R.S. Tarvin wrote: > > A native Inferno port would certainly be a lot easier, but I think you > > might be a bit pessimistic about would can fit into a 64K address space > > machine. The 11/70 certainly managed to run a very respectable V7 Unix > > supporting 20-30 simultaneous active users in its day, [...] > > The 11/70 was a completely different beast than, say, an 11/03. > The 70 had a backplane with 22 address lines, a MMU, and up to > 4M bytes of memory. So while its processes were limited to > 64K+64K bytes, I would not consider it to be a typical 16-bit > machine. > > -- > Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org > > --000000000000d836e10577b405ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I quite agree - the PDP 11/70 was quite a high end 16 bit = machine, but it was the machine that I was talking about and the one I woul= d most like to revisit (although I wouldn't turn down an 11/40 if someb= ody offered me a working one). I don't think I would contemplate puttin= g Plan9 on a machine with no MMU or a 64K physical memory limit.

My first reasonable multi-user, multi-tasking computer system (bac= k in the early 80s)=C2=A0 was home made 6809 machine with 6829 MMU and even= tually 1MB of ram, running OS-9/6809. It initially ran with 64K for program= s and and the rest of memory was a big ram disk - because what else could y= ou do with such a ridiculous amount of memory. It did pretty well at provid= ing a personal Unix like environment, although counldn't reproduce the = fork() semantics and there was no memory protection, and the memory contrai= nts meant always running the C compiler one pass at a time.. But we eventua= lly ported 'Level 2' OS-9 which could use a mapping ram/MMU, and wi= th that I had a quite robust multi-user system, with up to 64K available pe= r process, and 64K available for the kernel. I was able to get most Unix pr= ograms running on it (except for a few with big tables that compiled to lar= ger than 64K) and no longer had to worry about exiting the editor before do= ing a compile. Most of the core system utilities were written in assembly l= anguage - so the equivalent of 'ls' for example, required no more t= han a 256 byte memory allocation. And all executables were loaded read-only= and re-entrant (shared text) which helped. The only real Achilles heal was= the 6809 had no illegal instruction trapping, so executing data could occa= sionally=C2=A0 result in an unrecoverable freeze..

I never liked the 68K version os OS-9 quite as much. Because of the larger= address space it used the MMU for protection only, with no address transla= tion - so the kernel was mapped into the same address space as the user pro= grams but just not accessible in user mode. It just didn't seem as eleg= ant.

Anyway, thats why I don't see 64K per pro= cess as necessarily being inadequate for a lean operating system, although = it would be easy enough to write extravagant code that would not run in 64K= , or a design that relied on a large virtual address space - especially if = you were used to relying on virtual memory. I just don't know if how sm= all Plan9 can go, and unless someone has already explored those limits, I s= uppose rather than speculating i'll just have to plan on a little exper= imentation when I get a bit of spare time.=C2=A0

R= egards,
Digby=C2=A0


=

On Mon, 8= Oct 2018 at 19:13, Nils M Holm <nmh@t3x.= org> wrote:
On 2018-10-08T15= :29:02+1100, Digby R.S. Tarvin wrote:
> A native Inferno port would certainly be a lot easier, but I think you=
> might be a bit pessimistic about would can fit into a 64K address spac= e
> machine. The 11/70 certainly managed to run a very respectable V7 Unix=
> supporting 20-30 simultaneous active users in its day, [...]

The 11/70 was a completely different beast than, say, an 11/03.
The 70 had a backplane with 22 address lines, a MMU, and up to
4M bytes of memory. So while its processes were limited to
64K+64K bytes, I would not consider it to be a typical 16-bit
machine.

--
Nils M Holm=C2=A0 < n m h @ t 3 x . o r g >=C2=A0 www.t3x.org

--000000000000d836e10577b405ac--