TUHS

tuhs@tuhs.org

12 participants
6534 discussions

Re: [TUHS] Using printf from Assembly Language in V6, and db.

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > I want to use printf from an assembly language program, in V6. ... the > substitutional arguments for printf are pushed onto the stack in reverse > order, then the address of the string, and then printf is called. After > this, 6 is added to the stack pointer. This is all down to the standard C environment / calling sequence on the PDP-11 (at least, in V6 C; other compilers may do it differently). Calls to printf() are in no way special. Very briefly, there's a 'frame pointer' (R5) which points to the current stack frame; all arguments and automatics are relative to that. A pair of special routines, csv and cret (I couldn't find the source on TUHS, but it happens to be here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/lib/csv.s if you want to see it), set up and tear down the frame on entry/exit to that routine. The SP (R6) points to a blank location on the top (i.e. lower address; PDP-11 stacks grow down) of the stack. To call a subroutine, the arguments are pushed, the routine is called (which pushes the return PC), and on return (which pops the return PC), the arguments are discarded by the caller. (I wrote a note, BITD, explaining how all this worked; I'll upload it to the CHWiki when I get a chance.) > I assume that the printf routine pops the address of the string off the > stack, but leaves the other values on the stack No, all C routines (including printf()) leave the stack more or less alone, except for CSV/CRET hackery, allocating space for automatic variables on routine entry (that would be at L1; try looking at the .s for a routine with automatic variables), and popping the return PC on exit. The exception to this is the stuff around calling _enother_ routine (sketched above). Another exception is alloca() (source here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/lib/alloca.s again, couldn't find it in TUHS), which allocated a block of memory on the stack (automatically discarded when the routine which called alloca() returns). Note that since all automatic variables and incoming arguments are relative to the FP, alloca is _really_ simple; justs adjusts the SP, and it's done. > What troubles me is that the stack pointer is not decremented before the > first mov, in the example below. Is this some C convention? I would > assume that the first push in my example would overwrite the top of the > stack. That's right; that's because in the C runtime environment, the top location on the stack is a trash word (set up by csv). > I understand db only works on files like a.out or core dumps. If I > wanted to break the assembly language program to examine values, how can > I force a termination and core dump elegantly, so I can examine some > register values? Use 'cdb': https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/man/man1/cdb.1 which can do interactive debugging. Noel

4 years

Using printf from Assembly Language in V6, and db.

by Paul Riley

Hi, I want to use printf from an assembly language program, in V6. It seems that the Unix Programmer's Manual doesn't show how to use it from assembly, so I wrote a short C program and captured the assembler output, for some clues. Listings below. In my example, the substitutional arguments for printf are pushed onto the stack in reverse order, then the address of the string, and then printf is called. After this, 6 is added to the stack pointer. I assume that the printf routine pops the address of the string off the stack, but leaves the other values on the stack, hence the need to add 2x3=6 to the stack after calling printf in my example. What troubles me is that the stack pointer is not decremented before the first mov, in the example below. Is this some C convention? I would assume that the first push in my example would overwrite the top of the stack. Perhaps I'm not used to PDP-11 stack conventions. I understand db only works on files like a.out or core dumps. If I wanted to break the assembly language program to examine values, how can I force a termination and core dump elegantly, so I can examine some register values? Paul *Paul Riley* Email: paul(a)rileyriot.com int a, b, c; int main(){ printf("printf: start\n"); a = 1; b = 2; c = 3; printf("A = %d, B = %d, C = %d", a, b, c); printf("printf: end\n"); } .comm _a,2 .comm _b,2 .comm _c,2 .globl _main .text _main: ~~main: jsr r5,csv jbr L1 L2:mov $L4,(sp) jsr pc,*$_printf mov $1,_a mov $2,_b mov $3,_c mov _c,(sp) mov _b,-(sp) mov _a,-(sp) mov $L5,-(sp) jsr pc,*$_printf add $6,sp mov $L6,(sp) jsr pc,*$_printf L3:jmp cret L1:jbr L2 .globl .data L4:.byte 160,162,151,156,164,146,72,40,163,164,141,162,164,12,0 L5:.byte 101,40,75,40,45,144,54,40,102,40,75,40,45,144,54,40,103,40,75,40,45,144,0 L6:.byte 160,162,151,156,164,146,72,40,145,156,144,12,0 #

4 years

demand paged 32V / Contacting Tom Raleigh

by Paul Ruizendaal

> The demand paging code for SysVR2 was written by Keith A. Kelleman and Steven J. Buroff, and in contemporary conference talks they were saying that they wanted to combine the best parts of demand-paged 32V and BSD. They may have some additional memories that could help with getting a better understanding of the final version of 32V. > > Does anybody have contact details for these two gentlemen? I’ve managed to contact Keith Kelleman and he had some interesting remarks. The paging code in SVR2 was all new code, with a focus the 3B dual processor. It does not derive at the code level from 32V and in fact he does not recall working with the 32V paging code. This kills the hope that the SVR2 code had clues about the 32V code. Keith did suggest that I tried to contact Tom Raleigh, who might have worked with the later 32V code base. Anybody with suggestions for locating him? === Besides functionality, the people that remember paged 32V all recall it being very fast. I wonder what made it fast. First to consider is “faster than what?”. Maybe Rob P. has a specific memory, but I would assume faster than 4BSD: if the comparison was with the "scatter loading, partial swapping” version of 32V people would have expected the better performance and not remember it as impressive 40 years later. Possibly the comparison is with 8th Edition which would have used the 4BSD paging code by then. If the comparison is with 4BSD, then the CoW feature in paging 32V would have been mostly matched by the vfork mechanism in 4BSD: it covers 80% of the use and it leaves the code paths simpler. If the comparison is with 8th edition, this may be the difference that people remember. The next possibility is that paging 32V had a better page-out algorithm. Joy/Babaoglu mention that the cost of the clock process is noticable. Maybe paged 32V used a VMS-like FIFO/second chance algorithm that did not need a separate kernel process/thread. Arguably this is not enough for a convincing speed difference. It is also possible that JFR found a more clever way to do LRU approximation. He remembers that his code used ‘strict LRU’, but not the algorithm. On Tenex - his conceptual reference - that was natural to do, because the MMU hardware maintains a table with 4 words of 36 bits for each frame with statistical data. With the VAX hardware it is a challenge. Considering his mathematical prowess it is maybe plausible that JFR found an efficient way. A slightly better page hit rate gives a significant speed improvement. All speculation of course: only finding the source will truly tell.

4 years

Re: [TUHS] "The programmer must have been carried away ...

by Paul Ruizendaal

> So there you have it. Just a line of B code that wasn't updated to C. > > Cheers, > aap I love posts like this, thank you! “Sherlock Holmes and the mysterious case of the excessive parameter list"

4 years

Code Review Request: 2.8BSD

by Warner Losh

Greetings, It has always bugged me that the bsd-family-tree file got 2.8BSD slightly wrong. It has the relationship V6 -> 1BSD -> 2BSD -> 2.79BSD -> 2.8BSD with V7 -> 32V -> 3BSD ... -> 4.1BSD -> 2.8BSD Now, as far as it goes, that's not terrible. But it's missing something. First, there was no V6 code in 1BSD or 2BSD through 2.79BSD. It was for V6 at first then for both V6 and V7, but w/o V7 code. There weren't even patches for V6 or new drivers on the early 1BSD and 2BSDs. However, starting with 2.8BSD, there's a V7 kernel. Or should I say a heavily patched V7 kernel with a ton of #ifdefs for all the fixes and enhancements collected by Berkeley and a few minor build system tweaks. Also, the code from 4.1BSD that's in 2.8 is rather minimal from what I can tell with my analysis so far, except indirectly in some of the patches to the V7 kernel appear to also be in 4.1BSD. The biggest thing that's in 2.8BSD from 4.1BSD is the job control (confined to its own directory with big warnings that basically say you'll need to update the code and even then the system is unstable). 2.9BSD has much better 4.xBSD integration, but 2.8 was quite early days for rejoining the two lines. 4.1BSD didn't have many berkeley rewrites of userland code, and the 2.8 tape has only a few of them (eg ls). So although it's not as complete as one would hope, there was a decent amount of code from 4.1BSD flowing into 2.8BSD. Now, my request. I've created a code review for FreeBSD to fix this. https://reviews.freebsd.org/D30883 is the review. We use phabricator in the FreeBSD project. Anybody can view this, but if you don't want to create an account, please send me email with a comment about the change and/or the commit message. It just adds an arc from V7 to 2.8BSD. Thanks for any time and/or insight you might have here. I'm judging the above entirely on the archived code rather than any historical knowledge... Warner

4 years

Re: [TUHS] [EXT] "The programmer must have been carried away ...

by Angelo Papenhoff

On 23/06/21, silas poulson wrote: > I’m aware line 2238’s famous “You are not expected to understand > this.” Comment is due to odd PDP-11/45 behaviour. Actually there are two different takes on what it is exactly that you're not expected to understand. The "obvious" one in Lions' book, (i.e. saved stack being overwritten when swapping so you have to restore from the special swap-saved stack), but dmr had a different take on it, that it had to do with functions really not being happy if you switch the stack underneath them. You can find dummy variables in the interdata port that make sure the stack frames of some functions (newproc and swtch?) match. So not really a hardware thing but a consequence of the compiler. > Do you know if other sections of the C show remnants of B or the PDP? > Or is it just those spots? For the kernel I'm just aware of this one. printf was copied over a number of times (the c compiler also includes a version) but the kernel was never written in B, so i wouldn't expect any B-ness in there otherwise. aap

4 years

"The programmer must have been carried away ...

by Angelo Papenhoff

... when he declared all the parameters for this procedure" I'm sure some of you remember this quote expressing John Lions' puzzlement over the declaration of printf in the UNIX kernel: printf(fmt,x1,x2,x3,x4,x5,x6,x7,x8,x9,xa,xb,xc) Note that parameters x2 and following are never referenced by name in the function body, only by pointer arithmetic from &x1. The historical reason for this long list of parameters is probably not well known, so I want to explain it and hope that you will find it as enjoyable as I did when I came across it some time ago while studying leftover files of B. To call a function in B, there's a little dance you have to do: first push the function address onto the stack, remember the stack pointer, push all the arguments, then restore the stack pointer and do the actual call. In diagrams, this is what happens to the B stack: push func addr: +------------+ | | <- sp +------------+ | func addr | +------------+ mark (n2): +------------+ | | <- sp +------------+ | | <- old sp (saved on native stack) +------------+ | func addr | +------------+ push arguments: +------------+ | | <- sp +------------+ | arg n | +------------+ | ... | +------------+ | arg 0 | +------------+ | | <- old sp (saved on native stack) +------------+ | func addr | +------------+ call (n3): pop old sp from stack jump to func addr on stack set ret addr and old fp +------------+ | arg n | +------------+ | ... | +------------+ | arg 0 | +------------+ | ret addr | +------------+ | old fp | <- sp, fp +------------+ The callee then sets sp, so has to know how many args and automatics! +------------+ | | <- sp +------------+ | auto n | +------------+ | ... | +------------+ | auto 0 | +------------+ | arg n | +------------+ | ... | +------------+ | arg 0 | +------------+ | ret addr | +------------+ | old fp | <- fp +------------+ So because the arguments to a functions were grouped together with the automatics and not below the ret addr and saved fp, there has to be space on the stack lest they clash. This of course means that this printf in B would probably break if called with more arguments than it expects. So there you have it. Just a line of B code that wasn't updated to C. Cheers, aap

4 years

Arithmetic expansion in Unix shells

by Michael Siegel

Hello, I'm currently trying out the rc shell (using Byron Rakitzis' implementation for Unix). Compared to Bash, which I normally use, this shell has a rather small feature set (which isn't to say that that's necessarily a bad thing). Now, one of the features that Bash has and rc doesn't have is the ability to perform arithmetic expansion. That's not really a problem because you can just use `expr` instead. I wonder, though, when arithmetic expansion as a shell built-in became a thing, especially in POSIX sh. POSIX has included that feature since at least 2001, and probably quite some years earlier, given that Bash already had it in 1995 (going by the manual page of version 1.14.7, the oldest I could find). So, maybe someone here can help me find out when this was actually standardized. Thanks. -- Michael

4 years

Re: [TUHS] Arithmetic expansion in Unix shells

by Brian Walden

even tho it was there, in-shell integer arithmetic had a few issues before ksh86. pre-ksh86 these had problems -- A. decimal point in a number $ integer I $ I=2.2 would error on the assignment, but with ksh86 $I is truncated to 2 (yes "integer" is an builtin alias to typeset -i and ksh courses at the time instructed to use that over typset) B. negative numbers $ integer I $ I=-2 here pre-86 $I would be assigned a large value like 2147483646 also ksh was not stardard until SVR4 (very late 80s) so it was found in paths like /usr/add-on/bin/ksh or /usr/exptools/bin/ksh, or not even there at all, you could not reliably #! ksh scripts also with ksh86 the double paren ((...)) notation was exactly the same as "let ..." and were completely optional if the variable was predefined as an integer, so $ I=0 $ ((I=I+1)) and $ integer I $ I=0 $ I=I+1 are the same. All internal integers in ksh were C longs (at least 32-bits) where Bourne shell all vars are strings so you would need to do this -- $ I=`expr $I + 1` But also at that time expr(1) could NOT deal with negative numbers on input, they became strings. So $ expr -9 + 1 is an error with "non-numeric argument", and $ expr -11 '<' -1 returns 0, a false statement, which are hidden bugs with variables. expr(1) was also 32-bits, as was test (i.e [ ) which could deal with negative numbers just fine. for arbitrarily large numbers you needed use dc(1) or bc(1). but dc(1) also has a issue with inputing negative numbers as it uses an _ not a - to denote a negatve number on input, but does use the - on output. $ I=`echo _9 1 - p | dc` is how you would do ((I=-9 - 1)) in bourne with dc which is cumbersome if you have a variable with a neagtive number in it, and required a "tr - _" first. however $ I=`echo -9 - 1 | bc` worked just fine in bourne. -Brian Chet Ramey wrote: > On 6/21/21 5:57 AM, arnold at skeeve.com wrote: > > Arithmetic expansion dates back at least as far as ksh88. > > ksh had the `let' builtin from at least 1983. The ((...)) compound command > was there by ksh-86. > > > Bash likely picked it up from there. > > Sort of, see below. > > > The original was only integer math and Bash remains that way (IIRC, > > Chet can correct me if I'm wrong). ksh93 added floating point math. > > Yes, bash only has integer arithmetic, since it's all POSIX requires. > > > POSIX would have picked it up from ksh88. > > The $((...)) form of arithmetic expansion is something POSIX picked up > from ksh-88, eventually. The early drafts of the standard (through 1003.2 > d9, at least), used $[...], but they eventually adopted $((...)) because > ksh-88 had already implemented it, though it's not documented in Bolsky > and Korn. > > I put $[...] into bash first (it's still there, though deprecated), then > `let', then $((...)) after POSIX added it, and finally `((' for > compatibility. > > Chet

4 years

demand paged 32V / Contacting Kelleman and/or Buroff

by Paul Ruizendaal

I’m still researching John Reiser’s 32V with demand paging, copy-on-write and mmap. Unfortunately, JFR does not have the bits or a listing for this version of 32V. I’ve read the MSc theses of Leffler and Shannon with interest (https://www.tuhs.org/Archive/Documentation/Theses/) The thesis of Shannon has an interesting discussion of a demand paged version of his Harris/6 Unix (Chapter 5). It is based on the Tenex ideas, just as JFR mentioned for his version. The thesis of Leffler contains a gant chart that shows that the demand paged version was written in the first months of 1980 -- concurrently with or slightly after the 32V version. I’ve also (superficially) read the papers on Tenex memory management. The design is closely tied to PDP-10 MMU that BBN designed for Tenex. Some of its data structuring is recognisable in Shannon’s version. One defining aspect is that the design for both is for a virtual address space that is smaller than the physical address space; on a 1980 VAX it was the reverse. If 32V followed the same design ideas (a big if), it most likely limited processes to a capped address space (e.g. 2MB). It might also have contained an in-core flag/data vector with as many entries as there are pages frames in swap space. If true, these downsides may have been why it did not go on to become the root for SysVR1 or R2 paging. The demand paging code for SysVR2 was written by Keith A. Kelleman and Steven J. Buroff, and in contemporary conference talks they were saying that they wanted to combine the best parts of demand-paged 32V and BSD. They may have some additional memories that could help with getting a better understanding of the final version of 32V. Does anybody have contact details for these two gentlemen?

4 years

70th anniversary of (official) programming errors

by Steffen Nurpmeso

Not Unix in particular. At least in Germany it is already the 16th, and my BSD calendar notifies that "first programming error is encountered at the U. S. Census Bureau". As not being hard-to-the-core i may have missed it, but also in 1951, in March, the wonderful Grace Hopper "conceives the first compiler, called A-O and later released as Math-Matic. Hopper is also credited with coining the term 'bug' following an incident involving a moth and a Mark II. All (hm!) according to COMPUTERWORLD January 18th, 1999 (i was young!), with assistance of the Computer Museum of Boston. Like McCartney said in the legendary 1999 concert at the Cavern club, the first after his wonderful wife Linda died, "See, with this band, if we don't get it right ... we start again!". Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

4 years

Re: [TUHS] Disassemblers

by norman＠oclsc.org

Rob Pike: Although upon reflection, I think what I did was fix 'adb' and call it 'db'. Haven't had my coffee yet this morning. ==== I don't think so. I did quite a lot of work on adb during my time at the Labs. I remember clearly that it still used all the Bournegol macros when I started; I doubt Rob would have left that there. (It was Rob who translated the shell back to C, I believe.) I got into adb because it still used ptrace and everyone else seemed scared to touch the code to convert it to use /proc. So I fixed that, and fixed sdb too, and finally removed the ptrace call from the kernel. I remember celebrating by expunging ptrace from the UNIX Room copy of the V8 manual. ptrace happened to occupt two facing pages, which I glued together. I did a lot more hacking on adb after that, ranging from little stuff like making # a synonym for 0x in input (so that adb's output could be picked up from the screen and re-used as input, a principle established firmly and correctly by Rob!) to a major restructuring to isolate machine-dependent pieces like instruction decoding and word formats, so that it was simpler not only to make adb work on a new processor architecture but even to make a sort of cross-adb that could, say, correctly interpret a PDP-11 core image on a VAX. (This actually mattered; by the time I arrived Research had no PDP-11s running general-purpose UNIX, but did have LSI-11s acting as Datakit controllers and a standalone power-backed-up LSI-11 that decoded the time signal from WWVB.) I was never really happy about the restructuring; it did more or less what I wanted but it wasn't really graceful. And cross-adb needed a distinct binary for each target. I had thoughts of trying to make a meta-language to describe the target's data formats (simple except for floating point) and how to print its instructions (messier, but I remember being inspired by the clever table-driven code in an disassembler Ken wrote for, I think it was, the NS32000), so that one could load a table from a file at startup; never had the time or the courage to carry through on it. Norman Wilson Toronto ON

4 years

Re: [TUHS] Disassemblers

by jnc＠mercury.lcs.mit.edu

> From: Henry Bent > From what I can gather the only way to reasonably examine the > disassembly of a program in the early days of Unix was adb. Is this > true? Was there a way to easily produce a full disassembly? 'adb' is quite late. We had it on the PWB1 (V6 enhanced, basically) system at MIT, so its roots lie before V7. (Every time I run across people who think V7 is early, I go into 'get off my lawn' mode.) The first thing I know of that could disassemble PDP-11 code on Unix was 'db', which dates back to V1: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1/man/man1/db.1 It wasn't optimal for doing disassembly, because it was non-trivial to dump an entire object file as assembler source - but it could be done. Later (V5 era) there was something called 'cdb', which was 'db' with extensions to make it useful for debugging code whose source was in C: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V4/man/man1/cdb.1 There were other non-Unix disassembler (such as DDT), also. Noel

4 years

[tuhs] New version of a paper on Unix evolution

by Nelson H. F. Beebe

A new journal issue published today carries this paper: Diomidis Spinellis and Paris Avgeriou Evolution of the Unix System Architecture: An Exploratory Case Study IEEE Transactions on Software Engineering 47(6) 1134--1163 June 2021 https://doi.org/10.1109/TSE.2019.2892149 A preprint is available here: https://www.researchgate.net/publication/332826685_Evolution_of_the_Unix_Sy… However, it is dated four years ago, and after removing its cover page, diffpdf shows numerous changes compared to today's publication. In the new version, a footnote on the first page says Manuscript received 19 May 2018; revised 18 Dec. 2018; accepted 28 Dec. 2018. Date of publication 2 May 2019; date of current version 14 June 2021. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

4 years

Re: [TUHS] 70th anniversary of (official) programming errors

by Jason Stevens

Sounds very "Deus ex machina" like. Although it's hard to staple a ghost to your notebook. -----Original Message----- From: Bakul Shah To: Rob Pike Cc: The Eunuchs Hysterical Society Sent: 6/16/21 12:13 PM Subject: Re: [TUHS] 70th anniversary of (official) programming errors https://spectrum.ieee.org/the-institute/ieee-history/did-you-know-edison -coined-the-term-bug <https://spectrum.ieee.org/the-institute/ieee-history/did-you-know-ediso n-coined-the-term-bug> Like Edison, she (Grace Hopper) was recalling the word’s older origins in the Welsh bwg, the Scottish bogill or bogle, the German bögge, and the Middle English bugge: the hobgoblins of pre-modern life, resurrected in the 19th century as, to paraphrase philosopher Gilbert Ryle, ghosts in the machine. Electrical circuits can have "bad connections" so I do wonder if Edison coined this word based on "ghost like" faults that magically appear and disappear! -- Bakul On Jun 15, 2021, at 8:48 PM, Rob Pike <robpike(a)gmail.com> wrote: There are citations from Edison in the 19th century using the word, and a quote somewhere by Maurice Wilkes about the stairwell moment when he realized much of the rest of his life would be spent finding programming errors. That moth was not the first bug, nor the first "bug", it was the first recorded "actual bug". -rob On Wed, Jun 16, 2021 at 9:46 AM Dan Cross < crossd(a)gmail.com <mailto:crossd@gmail.com> > wrote: On Tue, Jun 15, 2021 at 6:55 PM John Cowan < cowan(a)ccil.org <mailto:cowan@ccil.org> > wrote: On Tue, Jun 15, 2021 at 6:25 PM Steffen Nurpmeso < steffen(a)sdaoden.eu <mailto:steffen@sdaoden.eu> > wrote: As not being hard-to-the-core i may have missed it, but also in 1951, in March, the wonderful Grace Hopper "conceives the first compiler, called A-O and later released as Math-Matic. Hopper is also credited with coining the term 'bug' following an incident involving a moth and a Mark II. Yes, but wrongly. The label next to the moth is "First actual case of bug being found", and the word "actual" shows that the slang term already existed then. Brief unexplained faults on telephony (and before that telegraphy) lines were "bugs on the line" back in the 19C. Vibroplex telegraph keys, first sold in 1905, had a picture of a beetle on the top of the key, and were notorious for creating bugs when inexperienced operators used them. (Vibroplex is still in business, still selling its continuous-operation telegraph keys, which ditt as long as you hold the paddle to the right.) Indeed, the Vibroplex key is called a "bug". I suspect this has something to do with its appearance more than anything else, though (it kinda sorta looks like, er, a bug). - Dan C.

4 years

Help Contacting Unix Legal People

by Paul Ruizendaal

I understand the preference for a bottom-up entry, with somebody already sympathetic. If there is no such entry point, top-down may work at Microfocus. I guess the ask is for a statement for SysV similar to the Nokia statement for 8th-10th Edition: https://media-bell-labs-com.s3.amazonaws.com/pages/20170327_1602/statement%… According to Companies’ House, the general counsel is Jane Smithard: https://find-and-update.company-information.service.gov.uk/company/01504593… She appears to be 67, to have a long tenure with Microfocus and maybe is just the right person: "Jane has more than 25 years’ experience as a lawyer in the IT industry and software sector. She has worked with Micro Focus for over 20 years providing a wide range of commercial and corporate legal services, from leading the efforts through the 2005 IPO to driving the legal aspects of the group’s mergers, acquisitions and divestitures strategy including the acquisition of HPE Software and divestiture of SUSE. Jane leads a team of approximately 60 lawyers and other professionals worldwide, the majority of whom are focused directly on supporting the Company’s commercial teams and business.” https://www.microfocus.com/en-us/about/leadership-about Her e-mail appears to be jane (dot) smithard (at) microfocus (dot) com But I guess that Dan Doernberg already knows all that. His book project sounds intriguing, by the way. Paul

4 years

Re: [TUHS] Help Contacting Unix Legal People

by Jason Stevens

I tried sending a letter a while back asking how much is a commercial SYSV license anyways, never got a reply. I called their legal and they didn't know what a Unix was. I guess shockingly all the public facing micro focus is all on cobol -----Original Message----- From: Warren Toomey To: tuhs(a)tuhs.org Sent: 6/10/21 8:32 AM Subject: [TUHS] Help Contacting Unix Legal People All, we need help contacting some people so that Dan Doernberg can make progress on a new Unix book that he's working on. I've attached his request to the TUHS list below. If you can help out in any way, please contact Dan directly. Cheers, Warren From: Peer-to-Peer Communications LLC <dan(a)peerllc.com> Hello all, I’m the publisher of Lions' Commentary on UNIX (still going strong after 25 years!) and I have an “Ancient UNIX” book project in mind that I need some community help with. To avoid running into any “who has copyright rights to UNIX” legal problems, we’re trying to reach out in advance to any companies/organizations that may have such rights (Micro Focus, Xinuos, Nokia, are there others?) in advance. To that end, I’m trying to find staffers there who are: 1. sympathetic to sharing information about “ancient UNIX” with the operating system/UNIX communities 2. somewhat familiar with the past legal issues and controversies over UNIX ownership (perhaps someone in the legal department) If you know any such person(s) at Micro Focus, Xinuos, Nokia, and/or other relevant organizations that has either quality (or ideally a unicorn with both!), please pass on their name and email address to me (even better, add any context about why they might be helpful to me, if it’s OK to say that you referred me to them, etc.]. Thanks much, all referrals greatly appreciated! Dan Doernberg dan(a)peerllc.com

4 years

System IV

by Warner Losh

So I've seen a number of places that talk about Unix TS 3.0 -> 4.0 -> 5.0 progression and how System III was released and System V was released and System IV was internal only. What I've not seen is the "why" part of this. Why was it internal only? Warner

4 years, 1 month

Help Contacting Unix Legal People

by Warren Toomey

All, we need help contacting some people so that Dan Doernberg can make progress on a new Unix book that he's working on. I've attached his request to the TUHS list below. If you can help out in any way, please contact Dan directly. Cheers, Warren From: Peer-to-Peer Communications LLC <dan(a)peerllc.com> Hello all, I’m the publisher of Lions' Commentary on UNIX (still going strong after 25 years!) and I have an “Ancient UNIX” book project in mind that I need some community help with. To avoid running into any “who has copyright rights to UNIX” legal problems, we’re trying to reach out in advance to any companies/organizations that may have such rights (Micro Focus, Xinuos, Nokia, are there others?) in advance. To that end, I’m trying to find staffers there who are: 1. sympathetic to sharing information about “ancient UNIX” with the operating system/UNIX communities 2. somewhat familiar with the past legal issues and controversies over UNIX ownership (perhaps someone in the legal department) If you know any such person(s) at Micro Focus, Xinuos, Nokia, and/or other relevant organizations that has either quality (or ideally a unicorn with both!), please pass on their name and email address to me (even better, add any context about why they might be helpful to me, if it’s OK to say that you referred me to them, etc.]. Thanks much, all referrals greatly appreciated! Dan Doernberg dan(a)peerllc.com

4 years, 1 month

32V memory management: not quite V7 style swapping -- source code update

by Paul Ruizendaal

I just noticed that the 32V tape on the TUHS Unix Tree page includes a directory “slowsys”: https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/slowsys This “slowsys” directory appears to contain the 32V kernel with a pure swapping architecture. It is not quite the kernel described in the well known 32V paper, as it seems to have advanced from a fixed 192KB image size mapping to a more variable mapping of up to 1MB — but otherwise the code appears to be as described in the July 1978 paper. The directory https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/sys contains the scatter loading, partial swapping version of the 32V kernel. Paul

4 years, 1 month

Looking for a 1987 paper - origins of “phishing”

by Arrigo Triulzi

Dear TUHS, would anyone happen to have a copy of: Felix, Jerry & Hauck, Chris (September 1987). "System Security: A Hacker's Perspective". 1987 Interex Proceedings. I can only find references to it on the web but no link to an electronic version. Cheers, Arrigo

4 years, 1 month

32V memory management: not quite V7 style swapping

by Paul Ruizendaal

Received wisdom is that 32V used V7 style swapping for memory management. Over the past days I’ve come to the conclusion that this is a very partial truth and only holds true for 32V as it existed in the first half of 1978. In the second half of ’78 it implemented something that is referred to as “scatter loading” which is an interesting halfway house on the road to demand paging. It was also used in the VAX version of Sys III (and presumably in SysV R1 and early R2). In the 32V report from July 1978 it says: "Like the UNIX system for the PDP-11, the current implementation for the VAX-11/780 maintains each process in contiguous physical memory and swaps processes to disk when there is not enough physical memory to contain them all. Reducing external memory fragmentation to zero by utilizing the VAX- 11/780 memory mapping hardware for scatter loading is high on the list of things to do in the second implementation pass. To simplify kernel memory allocation, the size of the user-segment memory map is an assembly parameter which currently allows three pages of page table or 192K bytes total for text, data, and stack.” (https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf) It turns out that scatter loading was added in the next months, and it was this version that was used as the basis for 3BSD and SysIII. Babaoglu & Joy write: "Except for the machine-dependent sections of code, UNIX for the VAX was quite similar to that for the PDP-11 which has a 16-bit address space and no paging hardware. It made no use of the memory-management hardware available on the VAX aside from simulating the PDP-11 segment registers with VAX page table entries. The main-memory management schemes employed by this first version of the system were identical to their PDP-11 counterparts -- processes were allocated contiguous blocks of real memory on a first-fit basis and were swapped in their entirety. A subsequent version of the system was capable of loading processes into noncontiguous real memory locations, called scatter loading, and was able to swap only portions of a process, called partial swapping, as deemed necessary by the memory contention. This would become the basis for the paging system development discussed in this paper.” (https://www.researchgate.net/publication/247924813_Converting_a_swap-based_…) The 32V code on the TUHS website (e.g. here https://www.tuhs.org/cgi-bin/utree.pl?file=32V) is actually this later scatter loading code, and not the early 1978 code that used V7 style memory management. The 32-bit Sys III code is closely related (see https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/uts/vax) === My current understanding of how scatter loading worked (based on a brief code review) is as follows: (Note that on the VAX pages/frames are 512 bytes and the page list is essentially single level; page lists grow quickly. It is also unusual in the sense that user page table entries point to kernel virtual memory, but kernel page table entries point to physical memory). - Each process keeps a list of pages in its u-area (a page table prototype, if you will). This list is fixed size and allows up to 512KB per process in 32V and ~2.5MB per process in Sys III (i.e up to 1024 resp. 5120 pages). - The kernel keeps a bitmap of free/used frames in physical memory. - When a process loads/grows, the bitmap is scanned for free frames, these are marked as in-use, and added to the u-area list. If there are not enough free pages a process is selected for swapping out. Swapping out is gradual, in 8KB chunks in 32V and 32KB chunks in SysIII. When a process shrinks or completes, its pages are added back to the bitmap. - When a partially swapped out process needs to run, the swapped out part is loaded back similar to the above. Partial swap-outs truncate the process, so everything above the remaining size needs to re-load. - The user process page table is not swapped, but recreated from the u-area data instead. - When switching between user processes, the kernel needs to update 16 (32V) or 40 (SysIII) kernel page table entries to update the user memory map. Scatter loading and partial swapping seem to be a major improvement over V7 style swapping, although it of course falls short of demand paging. So far I have not seen bits of code that suggest ‘lazy loading’ or copy-on-write functionality in 32V or Sys III, but these things would not seem impossible to do in this memory management scheme. In short, the view that “32V used V7 style swapping” seems to be an oversimplification.

4 years, 1 month

Early Unix paging

by Paul Ruizendaal

Following the recent discussion on this list about early paging systems and John Reiser’s work in this area, I succeeded in reaching out to him. It is all very long ago, but John’s recollection is that his paging system work was initially done late in 1979 or maybe 1980. This matches with Rob Pike’s memory of seeing it demoed in early 1981. John’s recollection confirms that his design implemented mmap and copy-on-write, and was integrated with the file buffer cache (all features that Norman Wilson also remembered). I have appended John’s message below (with permission). I am not sure I understand - at this time - how John’s code was multiplexing page table entries with kernel data structures beyond what is mentioned, but I think it might be an interesting summer project to see how much of the design can be resurrected using related code, old documents and memories. Paul ==== > I joined Bell Labs department 1135 ("Interactive Computer Systems Research") > at Holmdel, NJ in Feb.1977. I soon gained fame by re-writing the C pre-processor, > which was bug-infested and slow. (" 1.e4 " was recognized as an opportunity > to expand the macro "e4", instead of as a floating-point constant.) > cpp used to take 15% to 18% of total CPU compile time. My replacement code > was 2% to 3%. The average improvement was a factor of 7; the minimum: > a factor of 5; the best: a factor of 11 or 12. > During the rest of 1977, I became dissatisfied with our PDP-11/45 (and other's > PDP-11/70), having spent a few student years at Stanford Univ and its AI Lab, > where PDP-6 and PDP-10 reigned. So Tom London and I wrote an "internal grant" > for $250,000 to get a new machine, with a "research goal" of exploring CCD > (charge coupled device) which was promised to replace spinning harddrive. > Actual CCD product never appeared until flash memory devices in 1990s > and SSD (current solid state drive) later. > > Our VAX-11/780, the first one delivered to a customer, arrived Feb.12, 1978 > (Lincoln's Birthday). Tom and I had been preparing using PDP-11/45 since > December, and we achieved "login: " on the console DECwriter by April 15 > (the deadline for US income tax filing). The rest of 1978 was "tuning", > and preparing for the release of "UNIX-32/V" to UC Berkeley. My annual > performance review in early 1979 said "Well done; but don't ever do it again" > because it was not regarded as "Research". > So what did I do? I did it again; this time, with demand paging. > I designed and implemented mmap() based on experience with PDP-10/Tenex > PMAP page mapping system call. I fretted over introducing the first > UNIX system call with 6 arguments. > > The internal design of the paging mechanism "broke the rules" by having a > non-hierarchical dependency: A1 calls B1 calls A2 calls B2 where {A1, A2} > are parts of one subsystem, and {B1, B2} are parts of another subsystem. > (One subsystem was the buffer cache; I forget what was the other subsystem.) > Our machine started with 512KB of RAM, but within a few months was upgraded > to 4 MB with boards that used a new generation of RAM chips. > The hardware page size was 512 bytes, which is quite small. Strict LRU > on 8,192 pages, plus Copy-On-Write, made the second reference to a page > "blindingly fast". It was impressive, running sometime in 1979 or 1980, > I think. But it was not "Research", so I got many fewer accolades. > My internal design strategy was to use the hardware page table entry > (4 bytes per page, with "page not present" being one bit which freed > the other 31 bits for use by software) as the anchor to track everything > about a page. This resulted in a complicated union of bitfield structs, > which became a headache. When other departments took over the work, > the first thing they did was use 8 bytes per page, which meant shuffling > between the software and the hardware descriptors: its own mess. > I wasn't interested in maintaining a paging system, so I moved on > to other things such as design of integrated circuits using > Carver-Mead methodology.

4 years, 1 month

H.J. Lu Bootable Root & Base System disks

by Grant Taylor

Is it okay for me to ask a question about Linux that's from '91~'92? Does anyone happen to have copies of H.J. Lu's Bootable Root and the associated Linux Base System disk images from the early '90s? I've managed to find a copy of 0.98.pl5-31 bootable root disk. But I can't find any base disks to go along with it. The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and basedisk subdirectories. Unfortunately all of the mirrors I'm finding of tsx-11 are newer, have the basedisk directories, but no image files there in. -- Grant. . . . unix || die

4 years, 1 month

Some mysteries solved and other musty history

by Jon Steinhart

More mildewy items from my dödsstäda project. Finally found my March 1974 BTL directory. A while ago I was trying to figure out who the people with the initials EPR, LIS, and MAS were in the 516-TSS documents. Best guesses via vgrep on an ancient single-processor are that EPR is Peter E. Rosenfeld, supervisor of Computer Graphics Design Group, LIS is Loretta I. Stukas in Programming Aids Software And Techniques Group. No reasonable looking matches on MAS. Nothing else spectacular in this box - it does have my Lyons books and a whole bunch or original UNIX docs such as the C manual, introduction to ed, and so on which I think are all sufficiently preserved that I don't need to scan them in. Jon

4 years, 1 month

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