From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <1539086308.3134428.1535702480.6E438630@webmail.messagingengine.com> In-Reply-To: <1539086308.3134428.1535702480.6E438630@webmail.messagingengine.com> From: "Digby R.S. Tarvin" Date: Wed, 10 Oct 2018 09:22:55 +1100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000001f2eb0577d32dda" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: ea5661bc-ead9-11e9-9d60-3106f5b1d025 --00000000000001f2eb0577d32dda Content-Type: text/plain; charset="UTF-8" On Tue, 9 Oct 2018 at 23:00, Ethan Gardener wrote: > > Fascinating thread, but I think you're off by a decade with the 16-bit > address bus comment, unless you're not actually talking about Plan 9. The > 8086 and 8088 were introduced with 20-bit addressing in 1978 and 1979 > respectively. The IBM PC, launched in 1982, had its ROM at the top of that > 1MByte space, so it couldn't have been constrained in that way. By the end > of the 80s, all my schoolmates had 68k-powered computers from Commodore and > Atari, showing hardware with a 24-bit address space was very much > affordable and ubiquitous at the time Plan 9 development started. Almost > all of them had 512KB at the time. A few flashy gits had 1MB machines. :) > Not sure I would agree with that. The 20 bit addressing of the 8086 and 8088 did not change their 16 bit nature. They were still 16 bit program counter, with segmentation to provide access to a larger memory - similar in principle to the PDP11 with MMU. The first 32 bit x86 processor was the 386, which I think came out in 1985, very close to when work on Plan9 was rumored to have started. So it seemed not impossible that work might have started on an older 16 bit machine, but at Bell Labs probably a long shot. > I still wish I'd kept the better of the Atari STs which made their way > down to me -- a "1040 STE" -- 1MB with a better keyboard and ROM than the > earlier "STFM" models. I remember wanting to try to run Plan 9 on it. > Let's estimate how tight it would be... > > I think it would be terrible, because I got frustrated enough trying to > run a 4e CPU server with graphics on a 2GB x86. I kept running out of > image memory! The trouble was the draw device in 4th edition stores images > in the same "image memory" the kernel loads programs into, and the 386 CPU > kernel 'only' allocates 64MB of that. :) > > 1 bit per pixel would obviously improve matters by a factor of 16 compared > to my setup, and 640x400 (Atari ST high resolution) would be another 5 > times smaller than my screen. Putting these numbers together with my > experience, you'd have to be careful to use images sparingly on a machine > with 800KB free RAM after the kernel is loaded. That's better than I > thought, probably achievable on that Atari I had, but it couldn't be used > as intensively as I used Plan 9 back then. > > How could it be used? I think it would be a good idea to push the draw > device back to user space and make very sure to have it check for failing > malloc! I certainly wouldn't want a terminal with a filesystem and > graphics all on a single 1MByte 64000-powered computer, because a > filesystem on a terminal runs in user space, and thus requires some free > memory to run the programs to shut it down. Actually, Plan 9's separation > of terminal from filesystem seems quite the obvious choice when I look at > it like this. :) > I went Commodore Amiga at about that time - because it at least supported some form of multi-tasking out out the box, and I spent many happy hours getting OS9 running on it.. An interesting architecture, capable of some impressive graphics, but subject to quite severe limitations which made general purpose graphics difficult. (Commodore later released SVR4 Unix for the A3000, but limited X11 to monochrome when using the inbuilt graphics). But being 32 bit didn't give it a huge advantage over the 16 bit x86 systems for tinkering with operating system, because the 68000 had no MMU. It was easier to get a Unix like system going with 16 bit segmentation than a 32 bit linear space and no hardware support for run time relocation. (OS9 used position independent code throughout to work without an MMU, but didn't try to implement fork() semantics). It wasn't till the 68030 based Amiga 3000 came out in 1990 that it really did everything I wanted. The 68020 with an optional MMU was equivalent, but not so common in consumer machines. Hardware progress seems to have been rather uninteresting since then. Sure, hardware is *much* faster and *much* bigger, but fundamentally the same architecture. Intel had a brief flirtation with a novel architecture with the iAPX 432 in 81, but obviously found that was more profitable making the familiar architecture bigger and faster . --00000000000001f2eb0577d32dda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , 9 Oct 2018 at 23:00, Ethan Gardener <eekee57@fastmail.fm> wrote:

Fascinating thread, but I think you're off by a decade with the 16-bit = address bus comment, unless you're not actually talking about Plan 9.= =C2=A0 The 8086 and 8088 were introduced with 20-bit addressing in 1978 and= 1979 respectively.=C2=A0 The IBM PC, launched in 1982, had its ROM at the = top of that 1MByte space, so it couldn't have been constrained in that = way.=C2=A0 By the end of the 80s, all my schoolmates had 68k-powered comput= ers from Commodore and Atari, showing hardware with a 24-bit address space = was very much affordable and ubiquitous at the time Plan 9 development star= ted.=C2=A0 Almost all of them had 512KB at the time.=C2=A0 A few flashy git= s had 1MB machines. :)

Not sure I would= agree with that. The 20 bit addressing of the 8086 and 8088 did not change= their 16 bit nature. They were still 16 bit program counter, with segmenta= tion to provide access to a larger memory - similar in principle to the PDP= 11 with MMU.=C2=A0

The first 32 bit x86 processor = was the 386, which I think came out in 1985, very close to when work on Pla= n9 was rumored to have=C2=A0 started. So it seemed not impossible that work= might have started on an older 16 bit machine, but=C2=A0 at Bell Labs prob= ably a long shot.
=C2=A0
I still wish I'd kept the better of the Atari STs which made their way = down to me -- a "1040 STE" -- 1MB with a better keyboard and ROM = than the earlier "STFM" models.=C2=A0 I remember wanting to try t= o run Plan 9 on it.=C2=A0 Let's estimate how tight it would be...

I think it would be terrible, because I got frustrated enough trying to run= a 4e CPU server with graphics on a 2GB x86.=C2=A0 I kept running out of im= age memory!=C2=A0 The trouble was the draw device in 4th edition stores ima= ges in the same "image memory" the kernel loads programs into, an= d the 386 CPU kernel 'only' allocates 64MB of that. :)=C2=A0

1 bit per pixel would obviously improve matters by a factor of 16 compared = to my setup, and 640x400 (Atari ST high resolution) would be another 5 time= s smaller than my screen.=C2=A0 Putting these numbers together with my expe= rience, you'd have to be careful to use images sparingly on a machine w= ith 800KB free RAM after the kernel is loaded.=C2=A0 That's better than= I thought, probably achievable on that Atari I had, but it couldn't be= used as intensively as I used Plan 9 back then.=C2=A0

How could it be used?=C2=A0 I think it would be a good idea to push the dra= w device back to user space and make very sure to have it check for failing= malloc!=C2=A0 I certainly wouldn't want a terminal with a filesystem a= nd graphics all on a single 1MByte 64000-powered computer, because a filesy= stem on a terminal runs in user space, and thus requires some free memory t= o run the programs to shut it down.=C2=A0 Actually, Plan 9's separation= of terminal from filesystem seems quite the obvious choice when I look at = it like this. :)=C2=A0

I went Commodor= e Amiga at about that time - because it at least supported some form of mul= ti-tasking out out the box, and I spent many happy hours getting OS9 runnin= g on it.. An interesting architecture, capable of some impressive graphics,= but subject to quite severe limitations which made general purpose graphic= s difficult. (Commodore later released SVR4 Unix for the A3000, but limited= X11 to monochrome when using the inbuilt graphics).

But being 32 bit didn't give it a huge advantage over the 16 bit x86= systems for tinkering with operating system, because the 68000 had no MMU.= =C2=A0 It was easier to get a Unix like system going with 16 bit segmentati= on than a 32 bit linear space and no hardware support for run time relocati= on.
(OS9 used position independent code throughout to work withou= t an MMU, but didn't try to implement fork() semantics).

=
It wasn't till the 68030 based Amiga 3000 came out in 1990 t= hat it really did everything I wanted. The 68020 with an optional MMU was e= quivalent, but not so common in consumer machines.

Hardware progress seems to have been rather uninteresting since then. Sure= , hardware is *much* faster and *much* bigger, but fundamentally the same a= rchitecture. Intel had a brief flirtation with a novel architecture with th= e iAPX 432 in 81, but obviously found that was more profitable making the f= amiliar architecture bigger and faster .
--00000000000001f2eb0577d32dda--