PC Unix, hacking the 64K limitation

mike%brl-vgr at sri-unix.UUCP mike%brl-vgr at sri-unix.UUCP
Tue Feb 7 14:05:10 AEST 1984


From:      Mike Muuss <mike at brl-vgr>

Herm -

First, it is not clear whether your intent was to get more than
64K code, or 64K data.  Also, is this for the UNIX Kernel, or
for user mode code, or both?

On our (BRL's) PDP-11 systems, we implemented (as 2 separate, but
related projets) code to support:

*) More than 64 K of Kernel I-space.  Still stuck with 64K of D-space,
but buffers-out-of-kernel space code actually helps this a lot.

*) More than 64 K of User I-space.  Still stuck with 64K of D-space.

Because the iAPX88 processor (that's the PC's processor, right?  I'm
not a PC person) uses 4-spaces (I,D,Stack,Extra), with addressing
in each segment being simply offset from the segment base register
(yuck, real IBM style), it seems to me that you could use the EXTRA
segment much the way we used the PDP-11 KISAR7 register to "map"
in external code segments.

It's a pity that this kind of crap is necessary for processors built
in the 1980s.  Sigh.

It is relatively easy to see how this extra segment capability can
be used to map in an arbitrary quantity of additional code in
a completely programmer-transparent way.  But, there is no easy
way to do this for data-space AT ALL.  Extentions to data space
would be programmer visible.  Furthermore, due to the lack of
fine-grain control over the memory management (just 4 segments),
it is unlikely that BOTH I-space and D-space extentions could
be used at the same time without a rather excessive amount of
(needless) context switching (of the EXTRA segment base value)
happening all the time.

RECOMENDATION.

Buy a 68000 or a 68010, or (gasp!) a BELMAC-32 (WE-32?) or some
other "real" 32-bit CPU.

	Back! PC Hackers!
	  -Mike



More information about the Comp.unix mailing list