From tuhs at tuhs.org Mon May 4 05:59:50 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Sun, 3 May 2026 12:59:50 -0700 Subject: [TUHS] quick question on PDP-11 addressing Message-ID: I was re-reading the KT-11 docs, and got somewhat confused, and wanted to verify my memory, that (absent Split I&D) user programs had virtual addresses in the range 0-0xffff, and kernels the same: 0-0xffff. Thanks, I know this has been discussed before, but I'm giving a talk at IWP9 next week and want to make sure I'm not missing something. The KT-11 doc left me uncertain. You gotta love those old DEC docs, complete with SSI logic diagrams ... From tuhs at tuhs.org Mon May 4 06:33:24 2026 From: tuhs at tuhs.org (John Levine via TUHS) Date: 3 May 2026 16:33:24 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: <20260503203324.B64EC107B7BB2@ary.qy> It appears that ron minnich via TUHS said: >I was re-reading the KT-11 docs, and got somewhat confused, and wanted >to verify my memory, that (absent Split I&D) user programs had virtual >addresses in the range 0-0xffff, and kernels the same: 0-0xffff. Yes. All PDP-11's were 16 bit machines and the addresses generated by programs were 16 bits. We used octai so it was 0 to 0177777. Different models had more or less elaborate schemes to map the 16 bit program addresses into 18 or 22 bit physical addresses. Some models had two modes, user and kernel, some had three, user, supervisor and kernel, with separate I and D addressing in each. For each of the two or six virtual address spaces there was an eight-entry map that mapped 8K pages of program addresses to 8K pages of physical memory. Unix systems as far as I know always treated user programs as a single chunk, or with I/D a single sharable chunk of I and another chunk of D. Bonus kludgery: Unibus addresses were 18 bits so on 22 bit systems (11/44 and /70) there was another address map from Unibus to physical memory for DMA devices. R's, John From tuhs at tuhs.org Mon May 4 06:35:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 3 May 2026 16:35:26 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: below On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS wrote: > I was re-reading the KT-11 docs, A PDP-11 has 16-bit registers, so all addressing must be within a 64K boundary. There are a few versions of the MMU - KS11 [CSS option for 11/20 - http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option] - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual ] - KT-11C,CD for the 11/45 class [45, 50, 55) [ https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf ]\ - For the 11/70, the MMU is builtin and the PARs are SW compatible with KT-11-C - and the KT-11D for the 40 class [40, 35] https://gunkies.org/wiki/KT11-D_Memory_Management_Unit - later 40 class processors (34, 34A and 60) use the KT-11A which is software compatible with the KT-11D In all cases, regardless of operation mode (user, supervisor, kernel), the CPU has a 16-bit address (virtual) space of 32K words (64K bytes). The MMU then maps those 16 bits into either an 18 or 22-bit physical address space. On a 40-class processor, that means a total of 64K bytes of address space at a time, regardless of how the data in that address space is used. On the 45 and 70 class processors have the funky I/D bit, which gives 2 separate 16-bit address spaces, instruction or data, so the MMU and OS can provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU, however, the '17th' which picks which of those two 64K byte hunks is being used is inferred from either and instruction or data fetch. > and got somewhat confused, and wanted > to verify my memory, that (absent Split I&D) user programs had virtual > addresses in the range 0-0xffff, and kernels the same: 0-0xffff. > > Thanks, I know this has been discussed before, but I'm giving a talk > at IWP9 next week and want to make sure I'm not missing something. The > KT-11 doc left me uncertain. > > You gotta love those old DEC docs, complete with SSI logic diagrams ... > From tuhs at tuhs.org Mon May 4 06:39:26 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sun, 3 May 2026 16:39:26 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: Message-ID: As a PS and for completion, consider the registers: Register Usage Conventions - R0 and R1 (Accumulators/Return Values): These are used as temporary scratchpads for expression evaluation. When a function returns a value, it is placed in R0; if the return value is a 32-bit long, the high-order bits are placed in R0 and the low-order bits in R1. - R2, R3, and R4 (Local Variables): These are used for local variables within a function. By convention, their values must be saved to the stack upon entering a procedure and restored before exiting, ensuring the calling function's data remains intact. - R5 (Frame Pointer / Environment Pointer): Known in UNIX as the FP, R5 points to the current procedure's "activation record" or stack frame. It is used to access function arguments and local variables stored on the stack. - R6 (Stack Pointer / SP): This register tracks the top of the system stack. The hardware uses R6 implicitly during interrupts, traps, and subroutine calls (the JSR and RTS instructions). - R7 (Program Counter / PC): This register contains the memory address of the next instruction to be executed. Because it is a general register, it can be used with various addressing modes to provide immediate data and relative addressing On Sun, May 3, 2026 at 4:35 PM Clem Cole wrote: > below > > On Sun, May 3, 2026 at 4:00 PM ron minnich via TUHS wrote: > >> I was re-reading the KT-11 docs, > > A PDP-11 has 16-bit registers, so all addressing must be within a 64K > boundary. > > There are a few versions of the MMU > > - KS11 [CSS option for 11/20 - > http://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option] > - KT-11B [CSS option https://gunkies.org/wiki/KT11-B_Technical_Manual > ] > - KT-11C,CD for the 11/45 class [45, 50, 55) [ > https://bitsavers.trailing-edge.com/pdf/dec/pdp11/1145/EK-KT11C-MM-005-KT11-C_CD_Memory_Management_Maintenance_Manual_1976.pdf > ]\ > - For the 11/70, the MMU is builtin and the PARs are SW compatible > with KT-11-C > - and the KT-11D for the 40 class [40, 35] > https://gunkies.org/wiki/KT11-D_Memory_Management_Unit > - later 40 class processors (34, 34A and 60) use the KT-11A which is > software compatible with the KT-11D > > In all cases, regardless of operation mode (user, supervisor, kernel), the > CPU has a 16-bit address (virtual) space of 32K words (64K bytes). The MMU > then maps those 16 bits into either an 18 or 22-bit physical address > space. On a 40-class processor, that means a total of 64K bytes of address > space at a time, regardless of how the data in that address space is used. > On the 45 and 70 class processors have the funky I/D bit, which gives 2 > separate 16-bit address spaces, instruction or data, so the MMU and OS can > provide 2 64K bytes chunks of memory (for a total of 128K bytes) to the CPU, > however, the '17th' which picks which of those two 64K byte hunks is > being used is inferred from either and instruction or data fetch. > > > > >> and got somewhat confused, and wanted >> to verify my memory, that (absent Split I&D) user programs had virtual >> addresses in the range 0-0xffff, and kernels the same: 0-0xffff. >> >> Thanks, I know this has been discussed before, but I'm giving a talk >> at IWP9 next week and want to make sure I'm not missing something. The >> KT-11 doc left me uncertain. >> >> You gotta love those old DEC docs, complete with SSI logic diagrams ... >> > From tuhs at tuhs.org Mon May 4 07:10:47 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Sun, 03 May 2026 17:10:47 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <20260503203324.B64EC107B7BB2@ary.qy> References: <20260503203324.B64EC107B7BB2@ary.qy> Message-ID: <202605032110.643LAlMZ013157@ultimate.com> John Levine wrote: > ... there was an eight-entry map that > mapped 8K pages of program addresses to 8K pages of physical memory. DEC docs (or at least the KT11-C document Clem posted a link for) call them "variable size pages"; each of them can map anything from 32 words up to 4KW (8KB), but I think it's fairer to think of each (mode x I/D) virtual address space as broken into eight segments at 8KW boundaries. Each segment has the option to grow from up from the bottom of the segment, or down from the top. Not all systems make it easy to restart an instruction after a "fault" like one might expect from hearing the word "paging" CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared memory segments. From tuhs at tuhs.org Mon May 4 16:19:59 2026 From: tuhs at tuhs.org (Phil Budne via TUHS) Date: Mon, 04 May 2026 02:19:59 -0400 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605032110.643LAlMZ013157@ultimate.com> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> Message-ID: <202605040619.6446JxTO022824@ultimate.com> I wrote: > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > memory segments. The sysv_pdp11.tgz I just found has has a library shmsys.c which indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c AND I've yet to spot the kernel support in the available CB Unix listings... From tuhs at tuhs.org Mon May 4 17:18:20 2026 From: tuhs at tuhs.org (Jonathan Gray via TUHS) Date: Mon, 4 May 2026 17:18:20 +1000 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605040619.6446JxTO022824@ultimate.com> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> Message-ID: On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > I wrote: > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > memory segments. > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > AND I've yet to spot the kernel support in the available CB Unix > listings... You may be looking for MAUS? https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf maus.c cbunix4.pdf pp 64-66 sysent.c cbunix6.pdf pp 50-52 1, &maus, /* 58 = set up MAUS segment reg */ From tuhs at tuhs.org Mon May 4 17:50:53 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 04 May 2026 01:50:53 -0600 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> Message-ID: <202605040750.6447orQ8041827@freefriends.org> Jonathan Gray via TUHS wrote: > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > I wrote: > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > memory segments. > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > AND I've yet to spot the kernel support in the available CB Unix > > listings... > > You may be looking for MAUS? > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > maus.c cbunix4.pdf pp 64-66 > sysent.c cbunix6.pdf pp 50-52 > > 1, &maus, /* 58 = set up MAUS segment reg */ The UNIX 4.0 release notes that Matt sent out a little while ago mentions that on the PDP-11 MAUS is supported instead of the shared memory sys calls. FWIW. Arnold From tuhs at tuhs.org Mon May 4 19:35:38 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 04 May 2026 09:35:38 +0000 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: <202605040750.6447orQ8041827@freefriends.org> References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> Message-ID: On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS wrote: > Jonathan Gray via TUHS wrote: > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > I wrote: > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > > memory segments. > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > > AND I've yet to spot the kernel support in the available CB Unix > > > listings... > > > > You may be looking for MAUS? > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > maus.c cbunix4.pdf pp 64-66 > > sysent.c cbunix6.pdf pp 50-52 > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > The UNIX 4.0 release notes that Matt sent out a little while ago > mentions that on the PDP-11 MAUS is supported instead of the > shared memory sys calls. FWIW. > > Arnold > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 specific. Since shm is expected in future non-PDP-11 UNIX, a separate, more portable solution was developed (I don't know the internal name) which supports all the future platforms, but isn't workable in PDP-11 UNIX. Between this and other factors, SVR2 is the last USG UNIX to touch the PDP-11 as far as prevailing literature is concerned. For instance, I have the SVR2 System Release Description and it still mentions PDP-11/70 compatibility. That said, machid(1) as of SVR4 manuals lists pdp11 as a reportable target. I've never confirmed whether this is simply a matter of aged documentation or if somewhere deep inside AT&T they kept SysV going on PDP-11 past SVR2. For the record, 3B20 and 3B21 UNIX was supported long after SysV went the SCO route in the from of UNIX/RTR. That's only to point out that some of the 70s UNIX platforms do have continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. I have a Lucent training document on C in shipment currently, I'll see soon if it lends any credence to late-era PDP-11 support in the USG or BTL streams. Given BTL moving to VAX-11 in the early 80s though, anything post-that e.g. Lucent it's may yield nothing useful in the PDP-11 longevity question. - Matt G. From tuhs at tuhs.org Mon May 4 20:07:24 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Mon, 04 May 2026 04:07:24 -0600 Subject: [TUHS] quick question on PDP-11 addressing In-Reply-To: References: <20260503203324.B64EC107B7BB2@ary.qy> <202605032110.643LAlMZ013157@ultimate.com> <202605040619.6446JxTO022824@ultimate.com> <202605040750.6447orQ8041827@freefriends.org> Message-ID: <202605041007.644A7ObI052144@freefriends.org> segaloco via TUHS wrote: > On Monday, May 4th, 2026 at 00:51, Arnold Robbins via TUHS wrote: > > > Jonathan Gray via TUHS wrote: > > > > > On Mon, May 04, 2026 at 02:19:59AM -0400, Phil Budne via TUHS wrote: > > > > I wrote: > > > > > CB (Columbus Bell) Unix, and SVR1 ran on 11's and supported shared > > > > > memory segments. > > > > > > > > The sysv_pdp11.tgz I just found has has a library shmsys.c which > > > > indicates SHMSYS was syscall 52, but it's a "nosys" entry in sysent.c > > > > AND I've yet to spot the kernel support in the available CB Unix > > > > listings... > > > > > > You may be looking for MAUS? > > > > > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man2/maus.2.pdf > > > > > > maus.c cbunix4.pdf pp 64-66 > > > sysent.c cbunix6.pdf pp 50-52 > > > > > > 1, &maus, /* 58 = set up MAUS segment reg */ > > > > The UNIX 4.0 release notes that Matt sent out a little while ago > > mentions that on the PDP-11 MAUS is supported instead of the > > shared memory sys calls. FWIW. > > > > Arnold > > > > MAUS AFAIK starts as a CB phenomenon in the late 70s, very PDP-11 > specific. Since shm is expected in future non-PDP-11 UNIX, a separate, > more portable solution was developed (I don't know the internal name) > which supports all the future platforms, but isn't workable in PDP-11 > UNIX. Between this and other factors, SVR2 is the last USG UNIX to touch > the PDP-11 as far as prevailing literature is concerned. For instance, I > have the SVR2 System Release Description and it still mentions PDP-11/70 > compatibility. That said, machid(1) as of SVR4 manuals lists pdp11 > as a reportable target. I've never confirmed whether this is simply a > matter of aged documentation or if somewhere deep inside AT&T they kept > SysV going on PDP-11 past SVR2. For the record, 3B20 and 3B21 UNIX was > supported long after SysV went the SCO route in the from of UNIX/RTR. > That's only to point out that some of the 70s UNIX platforms do have > continuity to the 90s, 2000s, and beyond, so who knows, maybe somewhere > in BTL/Lucent there was some stripped out SVR4 running on a PDP-11/70. > Last confirmed date of USG UNIX issued for a PDP-11 falls in 1984 though. > I have a Lucent training document on C in shipment currently, I'll see > soon if it lends any credence to late-era PDP-11 support in the USG > or BTL streams. Given BTL moving to VAX-11 in the early 80s though, > anything post-that e.g. Lucent it's may yield nothing useful in the > PDP-11 longevity question. > > - Matt G. It is super unlikely that anything past SVR2 ran on the PDP-11. Demand paging was introduced sometime in the SVR3 period, along with STREAMS networking, the filesystem switch and RFS, and SVR4 was architectually very much like SunOS, with demand paging, a vnode-based filesystem architecture, both traditional and BSD fast filesystems, and with socket and STREAMS networking, NFS and I think even RFS. WWWWAAAAYYY too much to shoe-horn into an -11. The porting platform changed over time also, from -11 to Vax to 386 and 3Bxx, with older ones being dropped along the way. Arnold