TUHS

tuhs@tuhs.org

19 participants
6516 discussions

Re: [TUHS] phototypesetter C (was nm on Third Edition .o files)

by jnc＠mercury.lcs.mit.edu

> I don't think I ever heard the appellation "phototypesetter C" > before. Interesting data point; thanks for passing that along. > Certainly C and the phottypesetter developed independently, though in > the same room. But the explanation that they got linked by appearing in > the same tape release makes perfect sense. I have this vague memory of being told, or reading somewhere, that many of the changes from 'vanilla V6' C to 'phototypsetter' C were added because they were needed for that project, hence the name. Alas, I have no idea where I might have gotten that from (I had a quick look at a few likely documentary sources, but no joy). It's quite possible that this was a supposition on someone outside Bell's part (or perhaps inside Bell, but outside the Unix group), because the two came out in the same tape. Reading the notes about the upgrades (in particular, "newstuff.nr") makes it seem like a more likely driver of _some_ of the changes was the Interdata port (which was also happening at around the same time, if I have the timeline correct). And of course some might have been driven by general utility (e.g. the ability to initialize structures). It would be interesting to see if anyone remembers why these changes were made. Noel

8 years, 5 months

Validating the s2-bits tape epoch

by Diomidis Spinellis

The document http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme discusses the uncertainty regarding the epoch used for the file timestamps. "The biggest problem here is to pin down the epoch for the files. In the early version of UNIX, timestamps were in 1/60th second units. A 32-bit counter using these units overflows in 2.5 years, so the epoch had to be changed periodically, and I believe 1970, 1971, 1972 and 1973 were all epochs at one stage or another." "Given that the C compiler passes, and the library, are dated in June of the epoch year, and that Dennis has said ``1972-73 were the truly formative years in the development of the C language'', it's therefore unlikely that the epoch for the s2 tape is 1971: it is more likely to be 1972. The tape also contains several 1st Edition a.out binaries, which also makes it unlikely to be 1973." "Therefore, Warren's decoding of the s2-bits file, in s2-bits.tar.gz, uses 1972 as the epoch. However, Dennis decoding in s2.tar.gz uses 1973." "Finally, the date(1) a.out on the tape uses 1971 as its archive. How annoying! After a bit of discussion, Dennis and Warren have agreed that 1972 is the most probable epoch for s2-bits." I thought I could validate the epoch by looking at the distribution of weekdays for the three alternative years (1971 to 1973). Here are the results. wget http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme for guess in 1971 1972 1973 ; do echo $guess EPOCH=$(date +'%s' -d "$guess/01/01 00:00 UTC") awk '/\/core/,/\/etc\/init/ { if ($9) print strftime("%a", '$EPOCH' + $9 / 60)}' Readme | sort | uniq -c | sort -n done 1971 1 Sat 6 Mon 8 Thu 8 Tue 17 Fri 21 Wed 34 Sun 1972 1 Sun 6 Tue 8 Fri 8 Wed 17 Sat 21 Thu 34 Mon 1973 1 Tue 6 Thu 8 Fri 8 Sun 17 Mon 21 Sat 34 Wed As you can see, unless weekends at the Bell Labs were highly atypical, 1972 has the most probable distribution of work among the days of the week.

8 years, 5 months

Utility of C changes (Was: phototypesetter C)

by jnc＠mercury.lcs.mit.edu

> of course some [of the changes to C in this time period] might have been > driven by general utility (e.g. the ability to initialize structures). I was thinking about this, with my memory of the changes refreshed by re-reading those 'changes to C' notes, and it's interested how many of them were ones I personally (and most of the people working with me) didn't use. Here is a list of the changes described in those 3 documents: 'newstuff': - Longs - Unsigneds - Blocks (locals declared inside a non-top-level {} pair) - Initialization of structures - Initialization of automatic variables - Bit fields - Macro functions - Macro conditionals (#ifdef) - Arguments in registers - Typedefs - 'Static' scope 'Changes': - Multi-line macros - Undefine - Conditional expressions (#if) - Unions - Casts - Sizeof() on abstractions - '=' in initializations - Change binary operators from trailing to leading - 'extern' does not allocate storage (This note also includes unsigneds, blocks, and structure initializations, from the earlier? note.) 'cchanges': - Structure assignment and argument/return-value - Enum Of these, I never really used quite a few: blocks, automatic initializations, typedefs, unions, structure assignment/etc, or enum. I'm not sure if I ever used bit fields, either. Some of these are understandable; e.g. automatic initializations are just syntactic sugar (as are register arguments, but I did use those). Typedef is also effectively syntactic sugar; you can always use a macro and get almost (entirely?) the same result. In fact, I devised an entire system of types to make the code I was working on (almost entirely networking code, so lots of packet headers from other machines, etc) more rigorous - and later it turned out it had made it much more portable; it all used macros, not typedef. I don't think I ever used typedef... (The details of that might be of some interest: instead of int, long, etc we had things of the form {type}{len}, where {type}pe} was 'int', 'uns', 'bit', etc and length was 'b', 's', 'l', or two other interesting ones 'w' and 'f' - 'w' meant the machine's native word length, and 'f' meant whatever was fastest on the machine. So 'unsl' mean '32-bit unsigned'. Depending on the machine, the compiler couldn't always produce them all - e.g. the PDP-11 didn't have unsl - so sometimes you had to live with non-optimal replacements. There were also un-typed types, i.e. 'byte', 'swrd', 'lwrd' - 8, 16 and 32 bits - and 'word' - the machine's native length.) Unions didn't get used much either, in our stuff, although one would think it would be useful in network code - you get a packet with a pile of bits inside it, which can be one of N different formats, seems like a perfect application for a union. The problemis that it tied two different subsystems intimately together. If you have protocol A and protocol B, if you use a union to define the header format, the union has to have both A and B in it. Now if you want to add protocol C, that requires modifying that union definition. It was much easier to just take a pointer to the outer packet's data area, and assign (with cast) it to a new pointer variable which was of the correct type for the header you were trying to process. Some of the new things were incredibly useful, though - or, in fact, one couldn't get by without them. Casts were incredibly useful once the compiler got pickier. Initialization of structures was huge - other than 'bdevsw'-like hacks, there was just no other way to do that. Noel

8 years, 5 months

Re: [TUHS] User maintained programs in the Second Edition

by Doug McIlroy

> Does anyone remember whether at the time these were installed in the > system-wide /bin directory, Those that I remember were in /usr/bin. Doug

8 years, 5 months

Re: [TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Ritchie, D.M. The UNIX Time Sharing System. MM 71-1273-4. > which makes me think that the draft version Doug McIlroy found Not really a response to your question, but I'd looked at that 'UnixEditionZero' and was very taken with this line, early on: "the most important features of UNIX are its simplicity [and] elegance" and had been meaning for some time to send in a rant. The variants of Unix done later by others sure fixed that, didn't they? :-( On a related note, great as my respect is for Ken and Doug for their work on early Unix (surely the system with the greatest bang/buck ratio ever), I have to disagree with them about Multics. In particular, if one is going to have a system as complex as modern Unices have become, one might as well get the power of Multics for it. Alas, we have the worst of both worlds - the size, _without_ the power. (Of course, Multics made some mistakes - primarly in thinking that the future of computing lay in large, powerful central machines, but other aspects of the system - such as the single-level store - clearly were the right direction. And wouldn't it be nice to have AIM boxes to run our browers and mail-readers in - so much for malware!) Noel

8 years, 5 months

User maintained programs in the Second Edition

by Diomidis Spinellis

The Second Edition manual has a section titled "User Maintained Programs" listing the following utilities and games: basic, bc, bj, cal, chash, cre, das, dli, dpt, moo, ptx, tmg, and ttt. In the Introduction, the reader is asked to consult their authors for more information. Does anyone remember whether at the time these were installed in the system-wide /bin directory, or whether they were only available in their owners' home directories?

8 years, 5 months

14 new TUHS members

by Warren Toomey

All, I've just got back from a few days away to find 14 new subscription requests to the TUHS mailing list. Welcome aboard to you all. Normally I only get one request a month, so I have some concerns about the legitimacy of all these requests, so accept my apologies in advance if there is any off-topic e-mails in the next few days. P.S The mail while I was away was very interesting. Noel, you might also be interested in the B interpreter and Robert Swierczick's B compiler the PDP-7 Unix. The original B compiler doesn't exist, so Robert took the 11/20 C compiler and "undid" the code that does types so that it "became" a B compiler. https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other Cheers all Warren

8 years, 5 months

Happy birthday, Tommy Flowers!

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; amongst other things he designed Colossus, the world's first programmable electronic computer, which was used to break the German Lorenz cipher (not Enigma, as some think). Relevance to Unix? Well, without the world's first usable computer we would not have the world's first usable OS, and M$ would probably reign supreme by now... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 5 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> More here: > http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html Which sez: There is a second document, untitled, no date, which I have not been able to locate online at all. .. From the content, it seems to be from shortly after the previous one, so say, circa 1977. I poked around in a dump of the CSR Unix which I now have available to me, and found a copy of it. I just checked the Internet (using the canonical search engine) for various phrases from it, but I still could not turn it up. So, here it is in machine-readable form: http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt Hope this is some use to someone... :-) Noel

8 years, 5 months

phototypesetter C (was nm on Third Edition .o files)

by Doug McIlroy

Amusing, I don't think I ever heard the appellation "phototypesetter C" before. Certainly C and the phottypesetter developed independently, though in the same room. But the explanation that they got linked by appearing in the same tape release makes perfect sense. Thanks for the tidbit. Doug

8 years, 5 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > At some point .. and the ability to assign/pass structures got > supported, though I thought that was the compiler that came with V7. That is my vague recollection too. > I'm still annoyed they didn't fix arrays when they fixed structs. Which aspect? The ability to assign/pass/return arrays, or the funky way that array naming worked (I'm trying to remember the details, I think it was something to do with 'arrays' passed as arguments - it was actually a pointer that was passed, but the declaration didn't have to say 'pointer'). Noel

8 years, 5 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch > when did C get its cast operator? Well after that piece of code was written! :-) I don't recall exactly off the top of my head, but I recall 2-3 notes to users about the evolution of C post 'vanilla' V6; I think a lot of it was related to work being done on typetting stuff, hence the moniker 'phototypsetter compiler' which was applied to that 'improved' C. One of the notes is fairly common, but another I have only in hardcopy (although I scanned it at one point). I'll try and turn all of them, along with some notes I made about the differences between 'vanilla' V6 C and 'phototypsetter C' (which a lot of the later V6 users started with - I certainly did), into an article on the Computer History wiki on the early evolution of C. Noel

8 years, 5 months

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

PS: > I recall 2-3 notes to users about the evolution of C post 'vanilla' V6 > ... > One of the notes is fairly common, but another I have only in hardcopy > (although I scanned it at one point). More here: http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html If anyone knows of any other documentation of C evolution, I'd be interested in hearing about it for the Computer History wiki page. Noel

8 years, 5 months

Re: [TUHS] nm on Third Edition .o files?

by jnc＠mercury.lcs.mit.edu

> From: "Steve Johnson" > The number on the left is a PDP-11 address, probably for some kind of > control register. It's the Processor Status Word, which contained the CPU's hardware priority level, condition codes, etc. > That's a construction that's left over from B. I wonder why it was written as "0177776->integ", rather than "*017776"? Probably the former allowed the C compiler to work out what size the operand was. (BTW, 'integ' was declared in a structure declaration as follows: struct { int integ; }; (Did the code looked at actually say "0177776->int"? The compiler might have barfed on a reserved keyword being used like that.) Noel

8 years, 5 months

nm on Third Edition .o files?

by Diomidis Spinellis

Has anyone got a setup where they can run something like nm(1) on the compiled Third Edition Unix C files and send me the output? (Alternatively, just send me the .o files, and I'll whip up something to read their symbols.) I tried to compile the source code on a modern system by hacking old C to something closer to what GCC will accept, with commands such as the following. cc -E dp.c | sed 's/=$[&|+-]$/\1=/g;s/struct[ \t]*(/struct {/' | gcc -w -x c - However, I stumbled on the use of structure fields on things that aren't structures, e.g. "0177776->int =| 300"

8 years, 5 months

Re Dennis' Draft of the Unix Timesharing System: not so draft?

by arnold＠skeeve.com

I forwarded your note to BWK who seems to still have a few tenuous connections to the Labs. Good luck with it. Arnold

8 years, 5 months

How Unix made it to the top

by Doug McIlroy

It has often been told how the Bell Labs law department became the first non-research department to use Unix, displacing a newly acquired stand-alone word-processing system that fell short of the department's hopes because it couldn't number the lines on patent applications, as USPTO required. When Joe Ossanna heard of this, he told them about roff and promised to give it line-numbering capability the next day. They tried it and were hooked. Patent secretaries became remote members of the fellowship of the Unix lab. In due time the law department got its own machine. Less well known is how Unix made it into the head office of AT&T. It seems that the CEO, Charlie Brown, did not like to be seen wearing glasses when he read speeches. Somehow his PR assistant learned of the CAT phototypesetter in the Unix lab and asked whether it might be possible to use it to produce scripts in large type. Of course it was. As connections to the top never hurt, the CEO's office was welcomed as another ouside user. The cost--occasionally having to develop film for the final copy of a speech--was not onerous. Having teethed on speeches, the head office realized that Unix could also be useful for things that didn't need phototypesetting. Other documents began to accumulate in their directory. By the time we became aware of it, the hoard came to include minutes of AT&T board meetings. It didn't seem like a very good idea for us to be keeping records from the inner sanctum of the corporation on a computer where most everybody had super-user privileges. A call to the PR guy convinced him of the wisdom of keeping such things on their own premises. And so the CEO's office bought a Unix system. Just as one hears of cars chosen for their cupholders, so were these users converted to Unix for trivial reasons: line numbers and vanity. Doug

8 years, 5 months

Dennis' Draft of the Unix Timesharing System: not so draft?

by Warren Toomey

All, I'm writing a paper based on my June 2016 talk on PDP-7 Unix. As part of that I was looking at the BCPL -> B -> NB -> C history. And as part of that, I was reading Ken's B manual, written in 1972: https://www.bell-labs.com/usr/dmr/www/kbman.pdf Then I noticed at the end Ken refers to: Ritchie, D.M. The UNIX Time Sharing System. MM 71-1273-4. which makes me think that the draft version Doug McIlroy found (now at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEd…) must have made it into a full memorandum. Given that we have the memorandum number, does anybody know if it would be possible to find it in the archives from what was Bell Labs? Cheers, Warren

8 years, 5 months

Happy birthday, J.F.Ossanna!

by Dave Horsfall

J.F.Ossanna was given unto us in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. PS: Ada Lovelace, arguably the world's first computer programmer, was given unto us in 1815; she saw the potential in Charles Babbage's new-fangled thing. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 6 months

Re: [TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

by Clem Cole

On Thu, Dec 8, 2016 at 5:39 AM, Joerg Schilling <schily(a)schily.net> wrote: > Back to the Bourne Shell: > > The original Bourne Shell did not use malloc, but rather had a SIGSEGV > handler > that used to extend the "string stack" called "stak" via sbrk() whenever > the > code tried to access data beyond the end ot the heap. > Right although the 68K was not the first or the only system to have that problem - again IIRC Series/1 and maybe one of the PE systems. You are correct then SunOS and >>some<< of the 68000 based system did have the problem you suggested. And in fact, Masscomp (and Apollo) which used 68000's (but used two of them so could run full VM) could survive that style of fault (because it never occurred). BTW: the "conceptual problem" , you mentioned while true, is being a little harsh. As the one of the 68K designers (Les Crudele) said to me once, when they wrote the microcode, there were not thinking about instruction restart - so the issue was that Nick did not save enough state to do it. The model for the 68000 that they were using was the base/limit PDP-11 and the original PDP-10. Also at the time, the competition was the 6800, the 8080, Z80, 6502. They were trying to put a PDP-11/70 on chip (without getting into trouble like CalData did - which Les, Nick and team were very aware having been DEC and CalData customers before they were at Moto]. While we think of the 68000 family has being 32 bit, the fact is inside it is a 16 bit system (the barrel shifter and execution functions are 16). And it was a skunk works project -- the 6809 was Moto's real processor. It was an experiment done by a couple of rogue engineers that said - hey we can do better, The fact was they made a chip that was good enough to actually compete with the Vax in the end, because it was fast enough AND they had the wisdom to define 32 bits of address space and 32 bit operations (again having been PDP-11 users), but as Les used to say - part of the thinking was that while DEC was moving to the Vax, they had hoped to break into the area that they 16 bits minis claimed - which they in-fact did. And if you think in terms of a Clay Christensen's disruption theory, the fact that VM did not work easily (i.e. was a "worse" technology than the Vax) was ok - a new breed of customer did not care. 68000 was huge success, despite Moto marketing ;-) To me the larger issue with the 68010 was that when Nick did add the restart microcode, the new '10 microcode actually dumped version dependant state on the external stack (in Intel terminology -different "step" '10 put different state on the external stack or worse, could not restart an instruction that had been saved from a different step processor). This screw up was a huge issue when we did replaced the "executor" with a 68010, because it meant that all cpu boards had to be the same processor microcode revision. Masscomp was of course the first to make an MP, so was the the first firm to run into the issue (I remember debugging it - we could not reproduce the issue because of course tjt and my own machine's by chance had "MPU" boards as we called them with the same step -- it was one of the field service guys that realized that the customer system had a mixed step board -- i.e. when they replaced a single MPU in the field, the system stopped working). IIRC: Moto never fixed the '10, as that processor was reasonably short lived in the open market. They did fix the microcode in the '20 so the state on the external stack was independent of stepping. Clem

8 years, 6 months

That's not a computer...

by Dave Horsfall

*This* is a computer! http://archive.computerhistory.org/resources/text/EAI/EAI.HYDAC2400.1963.10… A hybrid analogue/digital box, what could possibly go wrong? And check out the dudes and dudess supporting it (except she'd better be careful when moving her chair, in case she takes out a paper tape unit...). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by jnc＠mercury.lcs.mit.edu

> Dennis Ritchie's home pages have some info on this Yeah, I'd read that - I was hoping for some actual technical info on the KS11, though. (I'm assuming he has given the name there correctly, or if his memory has dropped a bit - a thing which human memories do! :-) - since I've never been able to find a single mention of it, including in the Spare Module Handbook, which covers other Special Systems products). > I looked for (but did not find) information on what ""the classical > PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was. The best description is in the DECSystem-10 Hardware Reference Manual (mine is EK-10/20-HR-001, but alas that version appears not to be online - I'll scan my copy and put it online when I get a chance.) This version: http://pdp10.nocrew.org/docs/ad-h391a-t1.pdf does appear to cover it: pp. 5-38 through 5-40 (pp. 352-354 of the PDF) for the KA10, and pp. 5-15 to 5-30 (pp. 329-344) for the KI10. The KA10 provided one (optionally) two base/bounds register pairs, where the base register contains the location in real memory. With two pairs (the second one applied to high user address space), the high part could be write-protected, for sharing pure code. The KI10 provided something similar to this, but more complicated; it included paging, but also something called User 'Concealed', which allowed proprietary subroutine packages to be used, while hidden from the rest of the user's code. > Does anyone have an idea what PDP-10 MMU Dennis may have been referring > to? Almost certainly the KA10. > Here my hypothesis would be that in kernel mode mapping was off, and > that in user mode there were two segments, each with a base and limit > into physical memory Hard to say. Kernel mode might or might not have mapping, and User mode might have provided one, or two, segments; the KA10 did have an option for single-segment. > this setup has an echo in how the later KL-11 MMU was used. Sorry, what's a KL-11? The only 'KL11' I know of is the serial line board (M780) which was the predecessor to the DL11. Noel

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by Paul Ruizendaal

Finally took a look at the V1 source. Referring to http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s Toward the end of the sysexec function there is: cmp core,$405 / br .+14 is first instruction if file is / standard a.out format bne 1f / branch, if not standard format mov core+2,r5 / put 2nd word of users program in r5; number of / bytes in program text sub $14,r5 / subtract 12 cmp r5,u.count / bgt 1f / branch if r5 greater than u.count mov r5,u.count jsr r0,readi / read in rest of user's program text add core+10,u.nread / add size of user data area to u.nread br 2f 1: jsr r0,readi / read in rest of file 2: mov u.nread,u.break / set users program break to end of / user code add $core+14,u.break / plus data area jsr r0,iclose / does nothing br sysret3 / return to core image at $core $core is equated to 040000 in another file (u0.s). In V1 apparently the a.out header was 6 words (http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/a.out.5) not 8, and hence the magic for a standard executable was 0405. It was already used as magic to distinguish a.out format files from other executables. It also shows that indeed 'exec' jumped to the first word of the header (at location $core). From this I don't think we will find code for the KS-11 in the V1 source. The file http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u3.s also seems to support a LSX /MX like approach where each process switch equates a swap. I'd say that the lost V2 is where memory protection first appeared in Unix, i.e. 1972. Paul PS Sorry for writing 'V0' earlier -- I meant V1 all along.

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by Johnny Billquist

On 2016-12-08 18:18, Paul Ruizendaal <pnr(a)planet.nl> wrote: > >>> DEC's Custom Special Systems (CSS) group .. build a simple base/limi >>> register device, soon after the 11/20 was released.> ... So an early >>> version of after the original 11/20 port from the PDP-7 had this >>> however..... >> Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to >> see if anyone had _any_ documentation for this, but so far, nada. > I was looking for that a few years back. Dennis Ritchie's home pages have > some info on this (https://www.bell-labs.com/usr/dmr/www/odd.html) > At the bottom of that page he writes: > > ""Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not only did not support virtual memory, but didn't support any kind of hardware memory mapping or protection, for example against writing over the kernel. This was a pain, because we were using the machine for multiple users. When anyone was working on a program, it was considered a courtesy to yell "A.OUT?" before trying it, to warn others to save whatever they were editing. > [..snip..] > We knew the PDP-11/45, which did support memory mapping and protection for the kernel and other processes, was coming, but not instantly; in anticipation, we arranged with Digital Special Systems to buy a PDP-11/20 with KS-11 add-on. This was an extra system unit bolted to the processor that made it distinguish kernel from user mode, and provided a classical PDP-10 style "hi-seg" "low-seg" memory mapping unit. I seem to recall that maybe 6 of these had been made when we ordered it."" > > My hypothesis is that the very first versions of Unix were using a memory scheme similar to that used in the later LSX and MX derivatives: the kernel resides in lower memory and the user program in upper memory; each process switch implied a swap. Disclaimer: I have not studied the V0 source to verify this hypothesis. > > When this topic had my interest I looked for (but did not find) information on what ""the classical PDP-10 style "hi-seg" "low-seg" memory mapping unit"" was. Here my hypothesis would be that in kernel mode mapping was off, and that in user mode there were two segments, each with a base and limit into physical memory -- and that this setup has an echo in how the later KL-11 MMU was used. > > Does anyone have an idea what PDP-10 MMU Dennis may have been referring to? If you read the Wikipedia page about the PDP-10, you'd find the answer. Basically, kernel mode uses physical memory. User mode have a low segment and a high segment. This is decided by the high bit of the address. For each segment, there is a base register and a length register. Commonly, the low segment stored read/write data, while the high segment could be shared between processes, and have readonly data/code. But you could play in other ways with it, if you wanted to. Essex MUD, as far as I remember, had the game data in a shared hiseg, which could be written by the program. So your guessing is pretty good. Not sure I'd say this is similar to how the later PDP-11 MMU works, though. But I can see someone making the comparison, since the PDP-11 pages can vary in size, within limits. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 6 months

Re: [TUHS] Unix & Memory Management Units (MMU)

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > DEC's Custom Special Systems (CSS) group .. build a simple base/limi > register device, soon after the 11/20 was released.> ... So an early > version of after the original 11/20 port from the PDP-7 had this > however..... Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to see if anyone had _any_ documentation for this, but so far, nada. > I would look at Warren's First Edition work to see if there were dregs > of this in that code base Alas, I'd already had that idea (to try and at least re-create a programming spec, at least, for the KS11). There do not seem to be any traces there, perhaps because that code came from a document entitled "Preliminary Release of Unix Implementation", which argues that it's a very early 'version' of V0 (the early 'versions' weren't very formal, there was a continuous process of change/improvement going on, apparently). > It is also noted that the 45 class system (45/55/70/44) had "17th" > address bit - i.e. split I/D space. I believe that this is when "magic > numbers" were really introduced so that could be supported. No, they came in first for 'pure text' (0410): http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/sys1.c which I would expect arrived to minimize swapping on machines with small amounts of real memmory. Support for user split-I/D (411) didn't arrive until Version 6: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c although IIRC split I/D in the kernel was supported supported slightly before it was in user - although V5 didn't: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s so it couldn't have been much earlier than V6. Noel

8 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS