PDP-11 architecture Was: internet blocking problem ?

Warner Losh imp at bsdimp.com
Fri Sep 11 10:33:36 CDT 2015

On Fri, Sep 11, 2015 at 9:19 AM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2015-09-11 16:49, Warner Losh wrote:
>> On Fri, Sep 11, 2015 at 8:39 AM, Johnny Billquist <bqt at update.uu.se>
>> wrote:
>> On 2015-09-11 16:36, Noel Chiappa wrote:
>>>       > From: Jon Elson elson
>>>>       > I actually LIKED the PDP-11 architecture quite a LOT, but the
>>>> limited
>>>>       > memory was a big killer.
>>>> The good thing about the PDP-11 was the 16-bit word size. (It resulted
>>>> in
>>>> what's probably the most elegant architecture, in bang/buck terms, of
>>>> all
>>>> time.) The bad thing about the PDP-11 was the 16-bit word size. (For the
>>>> reason you point out.)
>>> WHile I agree that the PDP-11 is a wonderful architecture, it really is a
>>> few bits short of perfect, both for addressing, and for opcode
>>> allocation.
>>> The is obvious when you look at the EIS and FPP extensions, which could
>>> not retain the general instruction layout format because of a lack of
>>> bits.
>> I loved the PDP-11 architecture, until I wanted to run programs on it that
>> relied on the overlay manager and the overlays got to be 8 or 9 deep. Then
>> it was... painful.
> Uh? What do that have to do with the PDP-11 architecture? Overlays are a
> thing specific to the operating system and linker, and looks and works
> differently in different OSes on the PDP-11, if they have them at all.
> Mind you, even having said that, overlays are just a userland
> implementation of demand paging. Conceptually they are dead easy.
> Now, the overlay description language, as well as the capabilities in RSX,
> can make people seasick. But once you've worked with them for a while, you
> realized that most of the time it is not that tricky.

Well, the 16-bit address space forced a maximum limit on the text size of
the program that could be in memory at any time. This made the overlay
stuff trickier, since you had to use some kind of overlays (either managed
by the linker or the OS or some experimental home-grown stuff we tried).
Sure, the details were OS specific, but the tight memory of the
architecture forced some kind of mechanism. If your text space was <64k,
then OS demand paging was good. But if you needed more, there were no real
good choices.


More information about the cctalk mailing list