11 Sep
2015
11 Sep
'15
10:36 a.m.
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.)
Noel
11 Sep
11 Sep
10:39 a.m.
On 2015-09-11 16:36, Noel Chiappa wrote:
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.
Johnny
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.) 
10:49 a.m.
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:
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.
Warner
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.)
11:03 a.m.
On Sep 11, 2015, at 10:49 AM, Warner Losh <imp at
bsdimp.com> wrote:
...
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.
Perhaps the program was too large. But it may just be that the overlay structure was not
right. Overlays involve significant overhead, and it's well known that the
flexibility of TKB can cost a lot. (TKB itself is an example of that, which is why there
was a button with the text "TKB forever... and ever... and ever...".)
For efficient overlays, RT-11 with Link tends to be better. It's less flexible but
that reduced flexibility enforces more care in overlay design, and the implementation is a
whole lot faster.
paul
11:23 a.m.
On Fri, Sep 11, 2015 at 9:03 AM, Paul Koning <paulkoning at comcast.net> wrote:
True. We were running under RSTS-E and so had some more flexibility.
However, by the time we got to this overlay structure, we knew we'd done
something horribly wrong and spent several weeks slimming down the program,
reducing the number of parameters to some routines and redesigning some
code to have either simpler algorithms, or inlining some code. We slimmed
it by 30% but more importantly went from about 8 overlay depth to 3. Still
slow, but it was acceptably slow rather than insane.
Warner
On Sep 11, 2015, at 10:49 AM, Warner Losh <imp
at bsdimp.com> wrote:
...
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.
Perhaps the program was too large. But it may just be that the overlay
structure was not right. Overlays involve significant overhead, and it's
well known that the flexibility of TKB can cost a lot. (TKB itself is an
example of that, which is why there was a button with the text "TKB
forever... and ever... and ever...".)
For efficient overlays, RT-11 with Link tends to be better. It's less
flexible but that reduced flexibility enforces more care in overlay design,
and the implementation is a whole lot faster.
11:28 a.m.
On Sep 11, 2015, at 11:23 AM, Warner Losh <imp at
bsdimp.com> wrote:
On Fri, Sep 11, 2015 at 9:03 AM, Paul Koning <paulkoning at comcast.net> wrote:
The nice thing about RSTS/E is that you can use either the RT11 or the RSX tools,
according to which is the best answer for what you're doing. And that gives you a
choice of overlay schemes (regions with LINK, or trees with TKB).
paul
...
For efficient overlays, RT-11 with Link tends to be better. It's less
flexible but that reduced flexibility enforces more care in overlay design,
and the implementation is a whole lot faster.
True. We were running under RSTS-E and so had some more flexibility.
However, by the time we got to this overlay structure, we knew we'd done
something horribly wrong and spent several weeks slimming down the program,
reducing the number of parameters to some routines and redesigning some
code to have either simpler algorithms, or inlining some code. We slimmed
it by 30% but more importantly went from about 8 overlay depth to 3. Still
slow, but it was acceptably slow rather than insane.
11:31 a.m.
On 2015-09-11 17:28, Paul Koning wrote:
True. However, depending on which language they were using, that could
limit them to just one or the other RTS. If your compiler generated code
for RSX, you still could not use the RT-11 linker.
Johnny
On Sep 11, 2015, at 11:23 AM, Warner Losh <imp
at bsdimp.com> wrote:
On Fri, Sep 11, 2015 at 9:03 AM, Paul Koning <paulkoning at comcast.net> wrote:
The nice thing about RSTS/E is that you can use either the RT11 or the RSX tools,
according to which is the best answer for what you're doing. And that gives you a
choice of overlay schemes (regions with LINK, or trees with TKB). ...
For efficient overlays, RT-11 with Link tends to be better. It's less
flexible but that reduced flexibility enforces more care in overlay design,
and the implementation is a whole lot faster.
True. We were running under RSTS-E and so had some more flexibility.
However, by the time we got to this overlay structure, we knew we'd done
something horribly wrong and spent several weeks slimming down the program,
reducing the number of parameters to some routines and redesigning some
code to have either simpler algorithms, or inlining some code. We slimmed
it by 30% but more importantly went from about 8 overlay depth to 3. Still
slow, but it was acceptably slow rather than insane.
11:19 a.m.
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:
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.
Johnny
On 2015-09-11 16:36, Noel Chiappa wrote:
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. 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.)
11:33 a.m.
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:
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.
Warner
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:
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. 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.
11:41 a.m.
On 2015-09-11 17:33, Warner Losh wrote:
On Fri, Sep 11, 2015 at 9:19 AM, Johnny Billquist
<bqt at update.uu.se> wrote:
Ok. Well, yes, I believe we all agree that a larger address space would
have been nice. Even DEC noted that one pretty soon.
Just like Jon Elson said initially. :-)
Overlays were a way to try getting around the address space limitations.
I still would not consider overlays as any part of the PDP-11
architecture. But maybe that is just me.
Johnny
On 2015-09-11 16:49, Warner Losh wrote:
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. 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:
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.
> 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.
11:58 a.m.
On Sep 11, 2015, at 11:41 AM, Johnny Billquist <bqt
at Update.UU.SE> wrote:
...
Overlays were a way to try getting around the address space limitations. I still would
not consider overlays as any part of the PDP-11 architecture. But maybe that is just me.
I agree. You can use overlays on any hardware platform that has random access secondary
storage. You need it if your programs are larger than your primary memory. It's
found on many machines prior to the arrival of really large memories and address spaces.
And you could use it even there -- there's nothing that prevents the use of overlays
on a VAX, for example, though in practice I doubt it has been done.
The main alternative is paging, which is easier to use at the expense of lower
performance. That follows from the fact that paging is done by an automatic mechanism
that isn't aware of what the application is doing, while overlays are designed by a
programmer who is (usually) smarter than the paging automaton. There are in-between
approaches, where code and data are broken into fixed size pages that are paged in and out
automatically, but the assignment of bits of code or data to pages is optimized by the
programmer to improve performance. The THE operating system is a nice early (mid 1960s)
example of this.
paul
12:31 p.m.
New subject: Overlays - was Re: PDP-11 architecture Was: internet blocking problem ?
----- Original Message -----
From: "Paul Koning" <paulkoning at comcast.net>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Sent: Friday, 11 September, 2015 4:58:41 PM
I agree. You can use overlays on any hardware
platform that has random access secondary storage.
You need it if your programs are larger than your primary memory. ?
Overlays were also commonly used on Mag Tape systems before disk became common.
The George 1 and 2 operating systems for the ICL1900 series (and many compilers) came in
both disk overlaid and tape overlaid versions
(e.g. the Fortran compiler XFAE was disk overlaid, XFAM was tape overlaid but otherwise
identical - both were designed for 16K word systems allowing about 3K for Exec and the
"run-time"
overlay of George.)
Andy
2:47 p.m.
On 9/11/2015 8:39 AM, Johnny Billquist wrote:
On 2015-09-11 16:36, Noel Chiappa wrote:
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.
NOW if the had made the PDP 11 - 18 bits I think we could have had a
winner. It is the loss of two address bits that is the problem with 16
bits.
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.) 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.
Too bad we got the 8086 rather than PDP-11 style (simplified design?)
for 8/16 bit CPU.
Johnny
Ben.
3238
days inactive
3238
days old
12 comments
6 participants
participants (6)
-
andy.holt＠tesco.net -
bfranchuk＠jetnet.ab.ca -
bqt＠update.uu.se -
imp＠bsdimp.com -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net