PDP11 Memory Mangement - DEC

This is a discussion on PDP11 Memory Mangement - DEC ; Hi, I am looking for some description of the PDP11 memory management on the internet. Any hints ??? Thanks Mario...

+ Reply to Thread
Results 1 to 14 of 14

Thread: PDP11 Memory Mangement

  1. PDP11 Memory Mangement

    Hi,
    I am looking for some description of the PDP11 memory management on the
    internet. Any hints ???

    Thanks
    Mario


  2. Re: PDP11 Memory Mangement

    Mario Premke wrote:

    > Hi,
    > I am looking for some description of the PDP11 memory management on the
    > internet. Any hints ???
    >
    > Thanks
    > Mario
    >


    For starters, you'll need to be more specific; memory management was
    different for different PDP-11 models. For example, the map.reg's
    could be changed by UNIBUS devices on the 11/70, but not on the 11/34.
    --
    Cheers, Bob

  3. Re: PDP11 Memory Mangement

    Bob Willard writes:
    > For starters, you'll need to be more specific; memory management was
    > different for different PDP-11 models. For example, the map.reg's
    > could be changed by UNIBUS devices on the 11/70, but not on the 11/34.


    Cool! I thought I knew a lot about 11s, but I certainly didn't know that.

  4. Re: PDP11 Memory Mangement

    > For starters, you'll need to be more specific; memory management was
    > different for different PDP-11 models. For example, the map.reg's
    > could be changed by UNIBUS devices on the 11/70, but not on the 11/34.
    > --


    What I am interested in: was paging possible an these machines, could
    segments became larger than 64K, was there a restriction that executables
    were confined to 64K code + 64K data?

    Thanks,
    Mario


  5. Re: PDP11 Memory Mangement

    In article <36bckaF4vf01dU1@individual.net>, "Mario Premke" writes:
    >> For starters, you'll need to be more specific; memory management was
    >> different for different PDP-11 models. For example, the map.reg's
    >> could be changed by UNIBUS devices on the 11/70, but not on the 11/34.
    >> --

    >
    > What I am interested in: was paging possible an these machines,

    No , if You mean paging=virtual memory; PDP memory management
    is virtual addressing by segmenting.

    > could
    > segments became larger than 64K, was there a restriction that executables
    > were confined to 64K code + 64K data?


    Virtual address segments are fixed 8KB, there are
    8 segments in each "address space", depending on the
    model: Kernel Instruction, Kernel Data,
    Supervisor I+D, User I+D.
    (Supervisor mode I think started with model 11/45).
    Use of supervisor I+D was supported on RSX11M+, so a program
    could use 128K Instructions + 128K Data.

    --
    Joseph Huber, Muenchen http://www.huber-joseph.de/

  6. Re: PDP11 Memory Mangement

    Mario Premke wrote:
    > What I am interested in: was paging possible an these machines,


    Joseph Huber wrote:
    > No , if You mean paging=virtual memory; PDP memory management
    > is virtual addressing by segmenting.


    A few PDP-11s, including the 11/45, 11/50, 11/55, 11/70, and the J11
    chip, have some hardware support that was intended to facilitate
    virtual memory by allowing a trap handler to unwind the effect of a
    faulted instruction. If this was used, demand paging would be possible.
    Though that still does not expand the per-process address space, so it's
    not particularly useful.

    As far as I know, this was not used in any commercial operating systems
    for the PDP-11.

    Mario wrote:
    > could
    > segments became larger than 64K, was there a restriction that executables
    > were confined to 64K code + 64K data?


    A user-mode executable could ask the OS to swap 8K pages, or to load
    overlays, but at any given time the maximum process address space is 64KB
    instruction space and 64KB data space.

    Joseph wrote:
    > Use of supervisor I+D was supported on RSX11M+, so a program
    > could use 128K Instructions + 128K Data.


    Though since it took an OS call to switch modes, there was still an
    instantaneous limit of 64KB instruction + 64KB data.

  7. Re: PDP11 Memory Mangement

    >Joseph Huber wrote:

    >"Mario Premke" writes:
    >
    >>>For starters, you'll need to be more specific; memory management was
    >>>different for different PDP-11 models. For example, the map.reg's
    >>>could be changed by UNIBUS devices on the 11/70, but not on the 11/34.
    >>>

    >>What I am interested in: was paging possible an these machines,
    >>

    >No , if You mean paging=virtual memory; PDP memory management
    >is virtual addressing by segmenting.
    >
    >

    Jerome Fine replies:

    The first thing to understand is that for the PDP-11, the program
    address range
    (64 KByte of instructions/data and 64 KByte of separate
    Instructions/Data for
    those systems with a separate I/D MMU capability) was ALWAYS less than
    the physical address range for those systems WITH an MMU (memory
    management unit), or at least the systems which were produced when memory
    had become much less expensive. The maximum allowable memory for a
    standard PDP-11 is 4 MBytes with the top 8 KBytes not available since the
    address lines are switched by the hardware to the hardware I/O PAGE.

    As for the PDP-11/34, as far as I can understand, the reason that there were
    no map registers for I/O devices was that the maximum memory was 256 KBytes
    which, as far as I remember, Unibus I/O devices could handle without map
    registers. Map registers were not required on Qbus systems with more than
    256 KBytes of memory since I/O devices which were for the Qbus and for
    systems with 4 MBytes of memory had the extra bits in the CSR to allow
    user buffers above 256 KBytes. However, when I/O devices such as the
    RX02 floppy controller were used, on a Qbus, it was also possible to use
    a bounce buffer, although with the RT-11 operating system, DEC never did.

    As for your actual question about paging, that concerns operating systems
    which have less physical memory than the program address space, at least
    as far as I am concerned. I have worked with DEC, IBM and CDC virtual
    paging systems which automatically swap pages in for a user when the page
    is referenced and is not already in physical memory.

    >>could
    >>segments became larger than 64K, was there a restriction that executables
    >>were confined to 64K code + 64K data?
    >>

    >Virtual address segments are fixed 8KB, there are
    >8 segments in each "address space", depending on the
    >model: Kernel Instruction, Kernel Data,
    >Supervisor I+D, User I+D.
    >(Supervisor mode I think started with model 11/45).
    >Use of supervisor I+D was supported on RSX11M+, so a program
    >could use 128K Instructions + 128K Data.
    >
    >

    While I would use "Logical" rather than "Virtual", the
    exact words are not essential. In addition, the address
    segments are a maximum of 8 KBytes, and may be any size
    in increments of 64 Bytes. PLUS, as far as the user is
    concerned, by combining up to 8 address segments in a
    contiguous area of physical memory, it is possible to
    use a maximum of 64 KBytes as an area of memory either
    for instructions or data which could be considered as
    one address segment by the program even though the MMU
    would still consider it to be 8 separate address segments
    AND would set up the 8 pairs of hardware registers to
    handle the 64 KBytes.

    As stated above, where there is a separate I/D capability
    (instruction/data), there are 3 hardware modes in the MMU
    (such as the PDP-11/73):
    Kernel
    Supervisor
    User

    When there is no separate I/D capability, the 2 hardware
    modes in the MMU are (such as the PDP-11/23):
    Kernel
    User

    As for the restriction that the program space (both instruction
    and data - if available) be restricted to 64 KBytes, this aspect
    is a function of the instruction set and the hardware registers,
    especially the PC (Program Counter). In general, all single
    registers with the PDP-11 are 16 bits which allows an address
    of zero to 65535 bytes, although each word is 2 bytes and always
    has an even address. Since Base Registers (as per x86 hardware)
    do NOT exist with the PDP-11, your question (while it makes sense
    with the x86 hardware) shows that you need to read the manual for
    a PDP-11 to understand why your question has no meaning in the
    PDP-11 architecture. The fact that the PDP-11 has up to 4 MBytes
    of physical memory with a program address space of only 64 KBytes
    seems to imply a virtual address capability. In my opinion, that
    assumption is incorrect based on my experience with systems which
    have a program address space many times greater than the physical
    memory. In my mind, I refer to the program addresses as logical
    (with the MMU converting them to physical addresses at execution
    time) and which the program, in general, has no knowledge of nor
    even cares.

    This topic can be extremely confusing unless you read the manual
    which describes the PDP-11 MMU hardware.

    If you have any more questions, please ask!

    Sincerely yours,

    Jerome Fine
    --
    To obtain the original e-mail address, please remove
    the ten characters which immediately follow the 'at'.
    If you attempted to send a reply and the original e-mail
    address has been discontinued due a high volume of junk
    e-mail, then the semi-permanent e-mail address can be
    obtained by replacing the four characters preceding the
    'at' with the four digits of the current year.

  8. Re: PDP11 Memory Mangement

    "Jerome H. Fine" writes:

    > As for your actual question about paging, that concerns operating systems
    > which have less physical memory than the program address space, at least
    > as far as I am concerned. I have worked with DEC, IBM and CDC virtual
    > paging systems which automatically swap pages in for a user when the page
    > is referenced and is not already in physical memory.


    The Tops-10 operating system on the PDP-10 restricted[1] users to a 256KW
    address space, although the KI-10 and KL-10 processors can address up to 4MW
    (and KL's, at least, were physically endowed with same). Even the KS-10 could
    have 512KW physical.

    Tops-10 is a paging VM operating system, even on hardware with 4MW physical,
    so your restriction of the term to "less physical memory than the program
    address space" is suboptimal.

    [1] Prior to release 7.03.

    --
    Rich Alderson | /"\ ASCII ribbon |
    news@alderson.users.panix.com | \ / campaign against |
    "You get what anybody gets. You get a lifetime." | x HTML mail and |
    --Death, of the Endless | / \ postings |

  9. Re: PDP11 Memory Mangement

    In article , Eric Smith writes:
    > Joseph wrote:
    >> Use of supervisor I+D was supported on RSX11M+, so a program
    >> could use 128K Instructions + 128K Data.

    >
    > Though since it took an OS call to switch modes, there was still an
    > instantaneous limit of 64KB instruction + 64KB data.


    In RSX11M+ through the linker (TKB), it was possible to link
    code in supervisor space as "supervisor mode libraries"
    (don't remember the exact term :-), and then calling this code
    (and mode switching) was transparent for the higher level language
    programmer. Planning the program structure of course was necessary,
    i.e. one could not simply link a straight main program exceeding
    64K.

    --
    Joseph Huber, Muenchen http://www.huber-joseph.de/

  10. Re: PDP11 Memory Mangement

    In article ,
    Rich Alderson wrote:
    >"Jerome H. Fine" writes:
    >
    >> As for your actual question about paging, that concerns operating

    systems
    >> which have less physical memory than the program address space, at least
    >> as far as I am concerned. I have worked with DEC, IBM and CDC virtual
    >> paging systems which automatically swap pages in for a user when the

    page
    >> is referenced and is not already in physical memory.

    >
    >The Tops-10 operating system on the PDP-10 restricted[1] users to a 256KW
    >address space, although the KI-10 and KL-10 processors can address up to

    4MW
    >(and KL's, at least, were physically endowed with same). Even the KS-10

    could
    >have 512KW physical.
    >
    >Tops-10 is a paging VM operating system, even on hardware with 4MW

    physical,
    >so your restriction of the term to "less physical memory than the program
    >address space" is suboptimal.
    >
    >[1] Prior to release 7.03.
    >

    Slight nitpik. Not users but segment. We used GETSEG to get
    a new segment. FORTRAN compiler had, IIRC, 8 EXEs. When
    the first EXE was done with its job, it would GETSEG the next
    segment which would then do its job and get the next segment.

    You could have a "program" that was much larger than the
    available address space.

    /BAH

    Subtract a hundred and four for e-mail.

  11. Re: PDP11 Memory Mangement

    "Mario Premke" writes:

    > What I am interested in: was paging possible an these machines,
    > could segments became larger than 64K, was there a restriction that
    > executables were confined to 64K code + 64K data?


    It *COULD* page, but it would be a dumb idea to do that. This is due
    to a single MMU unit taking up a large fraction of the address space,
    and you need to have all reference an instruction can make to get
    any sort of eficiency. This results in needing most of the memmory
    mapped, so better to dump paging and just swap.

    Not, the 11 MMU has holes in the right place to go larger than 4M
    of physical memory, to 32MB in fact.

    --
    Paul Repacholi 1 Crescent Rd.,
    +61 (08) 9257-1001 Kalamunda.
    West Australia 6076
    comp.os.vms,- The Older, Grumpier Slashdot
    Raw, Cooked or Well-done, it's all half baked.
    EPIC, The Architecture of the future, always has been, always will be.

  12. Re: PDP11 Memory Mangement

    jmfbahciv@aol.com writes:

    > In article ,
    > Rich Alderson wrote:


    >> The Tops-10 operating system on the PDP-10 restricted[1] users to a 256KW
    >> address space, although the KI-10 and KL-10 processors can address up to
    >> 4MW (and KL's, at least, were physically endowed with same). Even the
    >> KS-10 could have 512KW physical.


    >> Tops-10 is a paging VM operating system, even on hardware with 4MW
    >> physical, so your restriction of the term to "less physical memory than
    >> the program address space" is suboptimal.


    > Slight nitpik. Not users but segment. We used GETSEG to get a new segment.
    > FORTRAN compiler had, IIRC, 8 EXEs. When the first EXE was done with its
    > job, it would GETSEG the next segment which would then do its job and get
    > the next segment.


    > You could have a "program" that was much larger than the available address
    > space.


    Yes, but that is also true of the PDP-11 operating systems. My point, in
    response to Jerome Fine's claim, was in regard to *paging* in any particular
    process, rather than the wholesale *segment replacement* of chained processes.
    In that context, each user process *was* limited to a 256K address space in a
    system that could physically be much bigger, but the OS still paged things.

    --
    Rich Alderson | /"\ ASCII ribbon |
    news@alderson.users.panix.com | \ / campaign against |
    "You get what anybody gets. You get a lifetime." | x HTML mail and |
    --Death, of the Endless | / \ postings |

  13. Re: PDP11 Memory Mangement

    >Rich Alderson wrote:

    >>jmfbahciv@aol.com writes:

    >
    >
    >>You could have a "program" that was much larger than the available address
    >>space.
    >>

    >Yes, but that is also true of the PDP-11 operating systems. My point, in
    >response to Jerome Fine's claim, was in regard to *paging* in any particular
    >process, rather than the wholesale *segment replacement* of chained processes.
    >In that context, each user process *was* limited to a 256K address space in a
    >system that could physically be much bigger, but the OS still paged things.
    >
    >

    Jerome Fine replies:

    If anyone reading my response does not agree, I suggest
    that we are using the same words with different definitions.
    If anyone is responding, then before any additional
    viewpoint is expressed, the terms we are using need to
    first be defined and agreed upon.

    Both of you seem to have missed the key phrase
    "PROGRAM ADDRESS SPACE"
    which refers to the total addressable memory which
    may be used at one time (or another) by the program
    for either instructions or data. In particular, when
    used for data and there is less physical memory than
    "program address space", then by using an algorithm which
    results in an excessive number of page swaps to reference
    the data across the "program address space", the job
    is reduced to thrashing.

    Just because the program reuses the same memory many
    times due to having many overlays does not, in my
    opinion, mean that the program size exceeds the
    program address space. Nor does any other method
    of reusing the same memory many times! Indeed, by
    definition, a program can ONLY execute or use data
    from within the program address space of the hardware
    which is being used. Only if the physical memory
    is less than the total addressable program memory can
    there be a problem. With many early PDP-11 systems
    (which did not have or need memory management), that was
    often the case. And in those early systems with less
    physical memory then total addressable program memory
    (i.e. less than 64 KBytes of memory), I can't seem to
    remember anyone suggesting that paging was taking place
    even though many programs did require overlays - such
    as MACRO-11 on these old systems (maybe not a good
    example since MACRO-11 still uses overlays and chains).

    The examples used by the previous responders were not
    what I accept as paging since the same program addresses
    are just being reused, which is what is explicitly done
    with program overlays. So while any technique of managing
    memory may be referred to as paging (as in a virtual system),
    having worked with and helped to design an operating system
    which had a 48 bit address (32 terabytes - it was bit
    addressable - which might soon be equaled in physical memory,
    but not in 1972 when it was developed using core memory),
    I suggest that virtual paging should be with reference to
    an operating system which manages memory for a user program
    in a manner such that when the maximum allotment is exceeded
    for any given program, making a new page available at an
    address not currently present requires an older page at a
    different address to be swapped (usually to the disk drive).

    Under the conditions of true virtual paging, a program
    requires a minimum amount of memory to execute in a
    reasonable manner at any given time. That amount of
    memory could expand or contract during execution, but
    it would often be much smaller than the maximum program
    address space that a program would reference in total.

    With a PDP-11, the use of overlays which could allow a
    program to reuse the same program address space many
    times (or the use of chained programs which amounted to
    the same thing except that even the root segment was also
    replaced), the limited (usually much less than 64 KBytes)
    program address space was explicitly managed by the
    programmer and reused as often as necessary via explicit
    requests to the operating system - as opposed to the
    programmer relying on the operating system to swap in a
    newly used page without an explicit request to the
    operating system as when a page fault (page not in memory)
    occurs.

    If anyone reading my response does not agree, I suggest
    that we are using the same words with different definitions.
    If anyone is responding, then before any additional
    viewpoint is expressed, the terms we are using need to
    first be defined and agreed upon.

    Sincerely yours,

    Jerome Fine
    --
    To obtain the original e-mail address, please remove
    the ten characters which immediately follow the 'at'.
    If you attempted to send a reply and the original e-mail
    address has been discontinued due a high volume of junk
    e-mail, then the semi-permanent e-mail address can be
    obtained by replacing the four characters preceding the
    'at' with the four digits of the current year.

  14. Re: PDP11 Memory Mangement

    In article ,
    Rich Alderson wrote:
    >jmfbahciv@aol.com writes:
    >
    >> In article ,
    >> Rich Alderson wrote:

    >
    >>> The Tops-10 operating system on the PDP-10 restricted[1] users to a

    256KW
    >>> address space, although the KI-10 and KL-10 processors can address up

    to
    >>> 4MW (and KL's, at least, were physically endowed with same). Even the
    >>> KS-10 could have 512KW physical.

    >
    >>> Tops-10 is a paging VM operating system, even on hardware with 4MW
    >>> physical, so your restriction of the term to "less physical memory than
    >>> the program address space" is suboptimal.

    >
    >> Slight nitpik. Not users but segment. We used GETSEG to get a new

    segment.
    >> FORTRAN compiler had, IIRC, 8 EXEs. When the first EXE was done with

    its
    >> job, it would GETSEG the next segment which would then do its job and

    get
    >> the next segment.

    >
    >> You could have a "program" that was much larger than the available

    address
    >> space.

    >
    >Yes, but that is also true of the PDP-11 operating systems. My point, in
    >response to Jerome Fine's claim, was in regard to *paging* in any

    particular
    >process, rather than the wholesale *segment replacement* of chained

    processes.
    >In that context, each user process *was* limited to a 256K address space

    in a
    >system that could physically be much bigger, but the OS still paged

    things.
    >

    Yes. I really meant a very small nitpik :-).

    /BAH

    Subtract a hundred and four for e-mail.

+ Reply to Thread