Hi -
> From: Warren Toomey <wkt(a)minnie.tuhs.org>
> In article by Greg 'groggy' Lehey:
> > The big issue is address space. It's difficult enough shoehorning
> > 2.11BSD onto the PDP-11. It's well-nigh impossible to retrofit 32 bit
> > operating systems. But Steven M. Schulz will doubtless give you a
> More specifically, the issue is data space. Using overlays, you can
> have a process with more than 64Kbytes of instruction space on a PDP-11,
> but the maximum data space that a process can have is 64Kbytes.
>
> The kernel is in a similar situation, but with some PDP-11 models
> there is kernel mode and supervisor mode, giving you two separate
> 64Kbytes instruction + 64Kbytes data address spaces (and overlays
> to increase the I space).
>
> I can't see Linux fitting into 128K of data space, and GCC is definitely
> out of the question. Besides, 2.11BSD already looks pretty close to 4BSD :-)
Well said Warren.
The D (data) space is the most severe constraint on adding any new
feature to 2.11BSD. Besides, as Warren mentioned, most of 4.3BSD
as well as a few bits&pieces of 4.4 are already present.
A couple years ago I toyed with the idea of porting over the 4.4BSD
tty subsystem (it'd be real nice to have termios and 8bit clean
serial line handling). The 'struct tty' almost tripled in size! Even
doing major surgery and leaving out a couple less useful capabilities
the growth in 'struct tty' exceeded what is left available in 2.11's
kernel D space.
Oh, I should point out the limit for the kernel's D space is even lower
than the 64KB mentioned. Of that 64KB the I/O page has to, of course,
be mapped in at all times or the kernel wouldn't have access to the
memory management registers, device registers, and so on. Then
the kernel has to have access to 'struct u' (the per process context
area - part of the address space is also where the kernel stack is
kept). So, 64 - 8 - 8 = 48. The kernel has a total of 48KB of
data space to use.
There are a few "tricks" that are played. Some data structures are
allocated external to the kernel's D space. That data is mapped in
as needed. Slows things down of course since it does take a number
of instructions to save the current memory manangement status, change it
to access the external data, fetch the data, restore the mmu registers.
Things such as the 4.3BSD disc quota system were implemented this way.
There is at the present time an absolute maximum on the size of the
I (instruction/text) space of 56K + (15*8)KB or 176KB (base segment of
56KB and 15 overlays of 8KB each. At present, depending on how many
drivers and so on are configured, about 9 or 10 overlays are used to
build a 2.11 kernel. The actual limit of kernel size that can be
booted is a bit lower due to how the boot process functions - in order
to simplify the memory manangement during booting the boot code
relocates to 192KB. The sum of the kernel text plus initialized data
(but not the .bss segment) can not exceed 192KB or the boot code will
be overwritten. Another complicating factor comes from UMR (Unibus
Mapping Registers) handling - if the boot code ever runs above 256KB
then UMR handling would have to be done by the boot code on UNIBUS
machines (Qbus machines of course don't have this problem since they
don't have UMRs to contend with).
GCC (all of the GNU stuff actually) was written with, I believe,
"malloc aforethought" ;) It's outright hostile to 16 bit machines.
There might be a few bytes free to add a feature or two to 2.11BSD
but much more than that would mean a lot of work to come up with some
free D space for the data structures that would be needed.
Cheers,
Steven Schultz
sms(a)2bsd.com
Hello from Gregg C Levine
I've got a question for those of you, who work more in that field then I.Has
anyone successfully gotten, say, NetBSD, or anything along the lines of the
4.4 series to run on a PDP-11? Granted I don't think it would work there,
because of the way its hardware was constructed. Or for that matter, say
Linux? Since the Simh collection builds easily on Linux, I was thinking that
it would be relatively simple to do so.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
Hello from Gregg C Levine
The web site links, that contain the SCO location, now point to a site on
Caldera's site. I tried e-mailing someone via their contacts page, but so
far to no avail. Has anyone on the list had any favorable response,
regarding the ability to access their archives of the older versions of
UNIX? As always, I am interested in the versions of UNIX that are targeted
towards the PDP-11. Seriously though, has anyone actually gotten any
feedback from Caldera? Warren if you want to comment, please do so, and I'll
even accept a private one.
Gregg C Levine drwho8(a)worldnet.att.net
"How many floors does this TARDIS of yours have, anyway?"
Gregg C Levine:
>gotten the distribution to boot, using a version of Simh? A text file of
>commands to be fed to the Simh program would be a great help.
Here is a transcript:
PDP-11 simulator V2.9-10
sim> set rl0 rl02
sim> show rl0
RL0, 5242KW, not attached, write enabled, RL02
sim> att rl0 unix_v6.rl02
sim> show rl0
RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02
sim> boot rl0
!unix
unix v6 11/23
mem = 99 KW max = 63
#
Good Luck,
Wolfgang
Gregg C Levine:
>gotten the distribution to boot, using a version of Simh? A text file of
>commands to be fed to the Simh program would be a great help.
Here is a transcript:
PDP-11 simulator V2.9-10
sim> set rl0 rl02
sim> show rl0
RL0, 5242KW, not attached, write enabled, RL02
sim> att rl0 unix_v6.rl02
sim> show rl0
RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02
sim> boot rl0
!unix
unix v6 11/23
mem = 99 KW max = 63
#
Good Luck,
Wolfgang
