From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: "Digby R.S. Tarvin" Date: Tue, 9 Oct 2018 14:08:15 +1100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000009f340d0577c30b80" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: e90d7ce6-ead9-11e9-9d60-3106f5b1d025 --0000000000009f340d0577c30b80 Content-Type: text/plain; charset="UTF-8" On Tue, 9 Oct 2018 at 10:07, Dan Cross wrote: > My guess is that there is no reason in principle that it could not fit >> comfortably into the constraints of a PDP11/70, but if the initial >> implementation was done targeting a machine with significantly more >> resources, it would be easy to make design decisions that would be entirely >> incompatible. >> > > I find this unlikely. > > The PDP-11, while a respectable machine for its day, required too many > tradeoffs to make it attractive as a development platform for a > next-generation research operating system in the late 1980s: be it > electrical power consumption vs computational oomph or dollar cost vs > available memory, the -11 had fallen from the attractive position it held a > decade prior. Perhaps slimming a plan9 kernel down sufficiently so that it > COULD run on a PDP-11 was possible in the early days, but I can't see any > reason one would have WANTED to do so: particularly as part of the impetus > behind plan9 was to exploit advances in contemporary hardware: lower-cost, > higher-performance, RISC-based multiprocessors; ubiquitous networking; > common high-resolution bitmapped graphical displays; even magneto-optical > storage (one bet that didn't pan out); etc. > If you mean that you find it unlikely that that development would have been done on a PDP11, then I agree, for the reasons you mentioned. Not sure that I can see why it wouldn't have been feasible, but I can see why it wouldn't have been desirable. I thought there might have been a chance of an early attempt to target the x86 because of its ubiquity and low cost - which could be useful for a networked operating system. And those were 16 bit address constrained in the early days. But its probably not an architecture you would choose to work with if you had a choice.. 68K is what I would have gone for.. > Certainly Richard Millar's comment suggests that might be the case. If it >> is heavily dependent on VM, then the necessary rewrite is likely to be >> substantial. >> > > As a demonstration project, getting a slimmed-down plan9 kernel to boot on > a PDP-11/70-class machine would be a nifty hack, but it would be quite a > tour de force and most likely the result would not be generally useful. I > think that, as has been suggested, the conceptual simplicity of plan9 > paradoxically means that resource utilization is higher than it might > otherwise be on either a more elaborate OR more constrained system (such as > one targeting e.g. the PDP-11). When you can afford not to care about a few > bytes here or a couple of cycles there and you're not obsessed with > scraping out the very last drop of performance, you can employ a simpler > (some might say 'naive') algorithm or data structure. > > I'm not sure how the kernel design has changed since the first release. >> The earliest version I have is the release I bought through Harcourt Brace >> back in 1995. But I won't be home till December so it will be a while >> before I can look at it, and probably won't have time to experiment before >> then in any case. >> > > The kernel evolved substantially over its life; something like doubling in > size. I remember vaguely having a discussion with Sape where he said he > felt it had grown bloated. That was probably close to 20 years ago now. > I guess kernel size wasn't a priority. I did a bit of searching back through the old papers, and whilst there is a lot of talk about lines of code and numbers of system calls, I didn't find any reference to kernel size or memory requirements. > For what it is worth, I don't think the embarrassment of riches presented >> to programmers by current hardware has tended to produce more elegant >> designs. If more resources resulted in elegance, Windows would be a thing >> of beauty. Perhaps Plan9 is an exception. It certainly excels in elegance >> and design simplicity, even if it does turn out to be more resource hungry >> than I imagined. I will admit that the evils of excessively constrained >> environments are generally worse in terms of coding elegance - especially >> when it leads to overlays and self modifying code. >> > > plan9 is breathtakingly elegant, but this is in no small part because as a > research system it had the luxury of simply ignoring many thorny problems > that would have marred that beauty but that the developers chose not to > tackle. Some of these problems have non-trivial domain complexity and, > while "modern" systems are far too complex by far, that doesn't mean that > all solutions can be recast as elegantly simple pearls in the plan9 style. > Whether we like those problems or not, they exist and real-world solutions > have to at least attempt to deal with them (I'm looking at you, web x.0 for > x >= 2...but curse you you aren't alone). > > PDP11's don't support virtual memory, so there doesn't seem any elegant >> way to overcome that fundamental limitation on size of a singe executable. >> > > No, they do: there is paging hardware on the PDP-11 that's used for > address translation and memory protection (recall that PDP-11 kept the > kernel at the top of the address space, the per-process "user" structure is > at a fixed virtual address, and the system could trap a bus error and kill > a misbehaving user-space process). What they may not support is the sort of > trap handling that would let them recover from a page fault (though I > haven't looked) and in any case, the address space is too small to make > demand-paging with reclamation cost-effective. > >>From what I recall, PDP11 hardware memory management was based on segmentation rather than paging (64K divided into 16 variable sized segments), and Unix did swapping rather than paging (a process is either completely in memory or completely on disk). It does relocation and protection, but I think it was limited in its ability to restart trapped instructions. I suppose there was a sort of embryonic virtual memory in the way the process stack was able to expand dynamically. I believe that was handled by generating a trap when an address 'near' the top of the stack was accessed. The instruction could complete, then a trap would allow the operating system to add a bit more memory to the stack before returning to allow the user process to continue. Unix kept the 'per process data area' at the top of the 'process image' in physical memory, but it was not mapped into the process address space. It was, however. mapped into a fixed address in kernel space whenever the corresponding process was the 'current' process. But you are right - even is it could do virtual memory/paging, it wouldn't help much because of limited size of the virtual address space. > So I don't think it i would be worth a substantial rewrite to get it >> going. It is a shame that there don't seem to have been any more powerful >> machines with a comparably elegant architecture and attractive front panel >> :) >> > > An attractive front panel for nearly any machine is just a soldering iron, > LEDs and some logic chips away. As far as elegant architectures, some are > very nice: MIPS is kind of retro but elegant, RISC-V is nice, 680x0 > machines can be had a reasonable prices, and POWER is kind of cool. I know > I shouldn't, but I have a soft spot for ARM. > I have thought about it, but there are a couple of problems (in addition to my lack artistic talent when it comes to building physically attractive enclosures).. One is the sheer number of LEDs required to display all of the address and data lines in a modern architecture. Mainly an issue if I want to use the old PDP11/70 front panel that I had saved for the purpose, I suppose. The other problem is getting access to the all of the machine state that was displayable on a mini computer console. Virtual addresses, User/Kernel mode, register contents etc are all hard to get at. I have toyed with using JTAG etc, but there always seems to be something that I can't get to. So it is hard to do more than resort to a software controlled front panel. I used to have a little box of LEDs and switches that I plugged into the parallel port on PCs, and had my BSDi kernel modified to update it as part of the clock interrupt. But now the parallel ports are becoming rare and you can't update LEDs connected via USB in a single instruction... :-/ Oh, and sure, you can find reasonable architectures. I spent a long time using 680x0 after learning on PDP11s, and found it equally comfortable for those occasions when I had to work in assembly language (I dread having to disassemble Intel binaries). Its just that packaging is so uninteresting now, it gives no indication of what is going on inside. Even lights on the hard drives when they were externally visible gave some signs of what was going on. Especially when there were different lights for read and write.. It is sounding like Inferno is going to be the more practical option. I >> believe gcc can still generate PDP-11 code, so it shouldn't be too hard to >> try. >> > > Sounds like a nifty hack. Fitting Dis into a 64k/64k split I/D space is > the challenge. > Yes indeed. I guess that is something I can try to find the time to test in the short term. It should provide a pretty good indication of viability. Regards, DigbyT --0000000000009f340d0577c30b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , 9 Oct 2018 at 10:07, Dan Cross <cr= ossd@gmail.com> wrote:
My guess is that there is no reason in principle that i= t could not fit comfortably into the constraints of a PDP11/70, but if the = initial implementation was done targeting a machine with significantly more= resources, it would be easy to make design decisions that would be entirel= y incompatible.

I find this unlikely.=

The PDP-11, while a respectable machine for its d= ay, required too many tradeoffs to make it attractive as a development plat= form for a next-generation research operating system in the late 1980s: be = it electrical power consumption vs computational oomph or dollar cost vs av= ailable memory, the -11 had fallen from the attractive position it held a d= ecade prior. Perhaps slimming a plan9 kernel down sufficiently so that it C= OULD run on a PDP-11 was possible in the early days, but I can't see an= y reason one would have WANTED to do so: particularly as part of the impetu= s behind plan9 was to exploit advances in contemporary hardware: lower-cost= , higher-performance, RISC-based multiprocessors; ubiquitous networking; co= mmon high-resolution bitmapped graphical displays; even magneto-optical sto= rage (one bet that didn't pan out); etc.
=

If you=C2=A0 mean that you find it unlikely that that d= evelopment would have been done on a PDP11, then I agree, for the reasons y= ou mentioned.

Not sure that I can see why it would= n't=C2=A0 have been feasible, but I can see why it wouldn't have be= en desirable.

I thought there might have been a ch= ance of an early attempt to target the x86 because of its ubiquity and low = cost - which could be useful for a networked operating system. And those we= re 16 bit address constrained in the early days. But its probably not an ar= chitecture you would choose to work with if you had a choice.. 68K is what = I would have gone for..
=C2=A0
Certainly Richard Millar's comment sugge= sts that might be the case. If it is heavily dependent on VM, then the nece= ssary rewrite is likely to be substantial.

As a demonstration project, getting a slimmed-down plan9 kernel to bo= ot on a PDP-11/70-class machine would be a nifty hack, but it would be quit= e a tour de force and most likely the result would not be generally useful.= I think that, as has been suggested, the conceptual simplicity of plan9 pa= radoxically means that resource utilization is higher than it might otherwi= se be on either a more elaborate OR more constrained system (such as one ta= rgeting e.g. the PDP-11). When you can afford not to care about a few bytes= here or a couple of cycles there and you're not obsessed with scraping= out the very last drop of performance, you can employ a simpler (some migh= t say 'naive') algorithm or data structure.

I'm not sure how the = kernel design has changed since the first release. The earliest version I h= ave is the release I bought through Harcourt Brace back in 1995. But I won&= #39;t be home till December so it will be a while before I can look at it, = and probably won't have time to experiment before then in any case.

The kernel evolved substantially o= ver its life; something like doubling in size. I remember vaguely having a = discussion with Sape where he said he felt it had grown bloated. That was p= robably close to 20 years ago now.

<= /div>
I guess kernel size wasn't a priority. I did a bit of searchi= ng back through the old papers, and whilst there is a lot of talk about lin= es of code and numbers of system calls, I didn't find any reference to = kernel size or memory requirements.
=C2=A0
For what it is worth, I don't think= the embarrassment of riches presented to programmers by current hardware h= as tended to produce more elegant designs. If more resources resulted in el= egance, Windows would be a thing of beauty.=C2=A0 Perhaps Plan9 is an excep= tion. It certainly excels in elegance and design simplicity, even if it doe= s turn out to be more resource hungry than I imagined. I will admit that th= e evils of excessively constrained environments are generally worse in term= s of coding elegance - especially when it leads to overlays and self modify= ing code.=C2=A0

plan9 is breath= takingly elegant, but this is in no small part because as a research system= it had the luxury of simply ignoring many thorny problems that would have = marred that beauty but that the developers chose not to tackle. Some of the= se problems have non-trivial domain complexity and, while "modern"= ; systems are far too complex by far, that doesn't mean that all soluti= ons can be recast as elegantly simple pearls in the plan9 style. Whether we= like those problems or not, they exist and real-world solutions have to at= least attempt to deal with them (I'm looking at you, web x.0 for x >= ;=3D 2...but curse you you aren't alone).

PDP11's don't support v= irtual memory, so there doesn't seem any elegant way to overcome that f= undamental limitation on size of a singe executable.

No, they do: there is paging hardware on the PDP-11 t= hat's used for address translation and memory protection (recall that P= DP-11 kept the kernel at the top of the address space, the per-process &quo= t;user" structure is at a fixed virtual address, and the system could = trap a bus error and kill a misbehaving user-space process). What they may = not support is the sort of trap handling that would let them recover from a= page fault (though I haven't looked) and in any case, the address spac= e is too small to make demand-paging with reclamation cost-effective.
=

From what I recall, PDP11 hard= ware memory management was based on segmentation rather than paging (64K di= vided into 16 variable sized segments), and Unix did swapping rather than p= aging (a process is either completely in memory or completely on disk). It = does relocation and protection, but I think it was limited in its ability t= o restart trapped instructions. I suppose there was a sort of embryonic vir= tual memory in the way the process stack was able to expand dynamically. I = believe that was handled by generating a trap when an address 'near'= ; the top of the stack was accessed. The instruction could complete, then a= trap would allow the operating system to add a bit more memory to the stac= k before returning to allow the user process to continue.

Unix kept the 'per process data area' at the top of the = 9;process image' in physical memory, but it was not mapped into the pro= cess address space. It was, however. mapped into a fixed address in kernel = space whenever the corresponding process was the 'current' process.=

But you are right - even is it could do virtu= al memory/paging, it wouldn't help much because of limited size of the = virtual address space.=C2=A0
=C2=A0
So I don't think it i would be worth a sub= stantial rewrite to get it going. It is a shame that there don't seem t= o have been any more powerful machines with a comparably elegant architectu= re and attractive front panel :)

An attractive front panel for nearly any machine is just a soldering iron= , LEDs and some logic chips away. As far as elegant architectures, some are= very nice: MIPS is kind of retro but elegant, RISC-V is nice, 680x0 machin= es can be had a reasonable prices, and POWER is kind of cool. I know I shou= ldn't, but I have a soft spot for ARM.

I have thought about it, but there are a couple of proble= ms (in addition to my lack artistic talent when it comes to building physic= ally attractive enclosures)..=C2=A0 One is the sheer number of LEDs require= d to display all of the address and data lines in a modern architecture.=C2= =A0 Mainly an issue if I want to use the old PDP11/70 front panel that I ha= d saved for the purpose, I suppose. The other problem is getting access to = the all of the machine state that was displayable on a mini computer consol= e. Virtual addresses, User/Kernel mode, register contents etc are all hard = to get at. I have toyed with using JTAG etc, but there always seems to be s= omething that I can't get to. So it is hard to do more than resort to a= software controlled front panel. I used to have a little box of LEDs and s= witches that I plugged into the parallel port on PCs, and had my BSDi kerne= l modified to update it as part of the clock interrupt. But now the paralle= l ports are becoming rare and you can't update LEDs connected via USB i= n a single instruction... :-/

Oh, and sure, you ca= n find reasonable architectures. I spent a long time using 680x0 after lear= ning on PDP11s, and found it equally comfortable for those occasions when I= had to work in assembly language (I dread having to disassemble Intel bina= ries). Its just that packaging is so uninteresting now, it gives no indicat= ion of what is going on inside. Even lights on the hard drives when they we= re externally visible gave some signs of what was going on. Especially when= there were different lights for read and write..=C2=A0

It is sounding like I= nferno is going to be the more practical option. I believe gcc can still ge= nerate PDP-11 code, so it shouldn't be too hard to try.=C2=A0

Sounds like a nifty hack. Fitting Dis in= to a 64k/64k split I/D space is the challenge.

=C2=A0Yes indeed. I guess that is something I can try= to find the time to test in the short term. It should provide a pretty goo= d indication of viability.

Regards,
Digb= yT
--0000000000009f340d0577c30b80--