Re: 80386 support

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 12 Sep 2012 13:46:41 -0700
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1TBtpZ-004lScC%more.weird.com@localhost>

  | At Wed, 12 Sep 2012 11:14:49 +0700, Robert Elz 
<kre%munnari.OZ.AU@localhost> wrote:
  | Subject: Re: 80386 support
  | >
  | >     Date:        Tue, 11 Sep 2012 19:14:42 -0700
  | >     From:        "Greg A. Woods" <woods%planix.ca@localhost>
  | >     Message-ID:  <m1TBcTS-004lScC%more.weird.com@localhost>
  | >
  | >   | However I don't think I ever ran any kind of unix on any 32-bit
  | >   | machine with just 2MB of main memory, or if I did it was just to
  | >   | see if it could  boot.

  | The Sun-1 at the time still only ran a V7 port, 

Yes, sun-1's are best forgotten...  (but they were 32bit).

  | not a true 32-bit VM unix (more about my distinction below).

Not VM sure, but certainly 32 bit, it was a 68K processor.

  | Anyway, my comment was mostly aimed at i386 systems of course.  :-)

OK...

  | The 3/60 that was my main workstation at the time was full of SIMMs,

My home 3/60 was the same, and with 24MB worked just fine (don't recall
ever being particularly memory limited for anything).   And I certainly
did compiles on it (though it had pretty much fallen into disuse before
I started using NetBSD).   I doubt it would work now, even if I pulled
it out of its storage locker somewhere in Melbourne...

  | I guess either could have self-hosted with a full NetBSD build, but what
  | was the point?  With little or no disk on them there had to be a bigger
  | NFS server somewhere else anyway,

Hmm ... the first Sun Network I used had 3/50 workstations (many diskless)
all served by a giant (wait for it) 3/50 server (with plenty of disc
added to its scsi chain, but still the regulation 3/50 4MB of ram).
That was it...   Compile locally, or compile on the server, you still
get the same processor, same speed, same ram (the server just probably
wasn't running much in the way of gui applications).

This was not fast by today's standards (or even really by standards of
the time) but it was a better user environment than a typical rs323
connected terminal, and better response times than sharing a 780 with
a hundred other people (which was the main alternative).

  | even old SCSI disks were a heck of a lot faster on
  | the server where they were directly connected than via NFS over good old
  | "slow" 10Mbit/s Ethernet.

That's true.

  | > The first 32 bit system I ran unix on had 384KB of RAM, that also ran

  | So it wasn't really running a true 32-bit Unix, was it. :-)

Of course it was.   I have no idea what you think it takes to be 32 bit
but in any rational definition, it is 32 bit integers, and a 32 bit address
space, and it had both of those.

VM is a separate issue entirely - that actually shrinks the amount of ram
required over the more primitive swap only systems, as only useful pages
need ram space (it adds a few 10's of KB in kernel code complexity but more
than makes up for that in application usage savings).

  | It probably wasn't even running as much code per process on average
  | as Unix 32V.

Atually, probably more, it was a much less effecient instruction set
than the vax had.

  | For all intents and purposes even 32V was just running a 16-bit unix in
  | 32-bit mode.

As a statement, that is simply nonsense.   It was possible to run 16
bit mode on early vaxen, but that isn't what 32V did, it ran true 32
bit binaries.

The next thing that you'll tell me is that a pdp-11 (or other 16 bit
processor) running with paging enabled is really a 32 bit system?

  | The purpose of my original reply to Mouse was to point out
  | that a modern 32-bit system inherently requires more memory (and more
  | patience too as there's more code to run overall).

Fine, but all I was commenting on was the statement (still included above)

=== However I don't think I ever ran any kind of unix on any 32-bit machine
=== with just 2MB of main memory

Note the "any kind of unix" and "any 32-bit machine" (no limit to VM
unixes, no limit to intel architecture).

Also note that I'm not saying you were incorrect, I have no idea what
systems you might have used in the past (certainly many younger users
here might have never seen a computer with less than hundreds of MB's
of ram) I was just pointing out that the implication that unix could
never fit (satisfactorily) on such a machine was incorrect.

Even early BSD ran on vaxes with 1MB or so (and they were used as
servers and to compile systems - much UCB develepment in the early days
was done on 750s with that kind of configuration) - and that's complete
with VM (though I'm not sure if 4.2, with all the networking added, would
still have fit on systems that small, I don't remember ever trying).

  | The VAX ran 3BSD briefly at the beginning of the next
  | term and then 4BSD after that, but I seem to remember it needed more
  | memory after the 4BSD upgrade, even before any new terminals were added,
  | and the compiler ran noticeably slower after the upgrade as well.

The compiler in 4BSD was no different than in 3BSD (in any way anyone
would notice) - but 4BSD was slower overall (it was one of the "add
new features" releases - 4.1 got a lot faster again.

  | The last time I used that VAX I think it had 16MB of RAM

Not if it was around in the 32V/3BSD days it didn't, 750s & 730s (not
that you probably meant either of those anyway) couldn't handle nearly
that much, and while a 780 could in theory, it was only in theory.
In practice, the nexus backplane got too long if you tried to add a
4th memory controller (each could handle just 4MB) and it just didn't
work.   12MB was possible, but I think there were only ever a couple
of 780s in the world that ever had that much (ghg might have done it,
and we had that in the old munnari.oz.au in its final years).  I don't
think (hearsay evidence only) that VMS supported more than 8MB (in a 780).
8MB was a typical "big" 11/780 ram size .

Later generation systems (the ones that were no longer 11/xxx) could
support more of course, but they never ran 3BSD or 32V.

  | Now modern systems such as NetBSD have things like SSL libraries, locale
  | support, wide-char support, GCC!, etc., etc., all adding megabytes more
  | code.

It you're just trying to say that using a system with tiny memory in
it today is futile, then I agree - it is also pointless.  For embedded
systems running dedicated code, fine, but for general purpose computing
these days there's little point.

But you uwant to be more careful what you say (and imply).

kre