From henry.r.bent at gmail.com Sat May 1 03:31:36 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 30 Apr 2021 13:31:36 -0400 Subject: [TUHS] SunOS Patches Message-ID: Does anyone here have an archive of SunOS patches? I'm looking for one specific one, 100332-08, for Fortran 1.4. Feel free to reply off-list. Thanks! -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From amp1ron at gmail.com Sat May 1 06:28:44 2021 From: amp1ron at gmail.com (Ron Pool) Date: Fri, 30 Apr 2021 16:28:44 -0400 Subject: [TUHS] SunOS Patches In-Reply-To: References: Message-ID: <003001d73dff$6ab72020$40256060$@gmail.com> > Does anyone here have an archive of SunOS patches? I'm looking for one specific one, 100332-08, > for Fortran 1.4. Feel free to reply off-list. Thanks! There are ISO images of SunSolve patch CDs from 1995 to 1998 on archive.org: https://archive.org/search.php?query=sunsolve I found that at least one of the March 1996 SunSolve v2.8 archive has the patch you're after. Disc B (https://archive.org/download/SUNSOLVE_1996-03_280/SUNSOLVE_1996-03_2_8_b.iso.gz) of the two ISOs for SunSolve v2.8 of March 1996 has many patches, including FILES/100382_0.gz. I was doing all of this on Windows so the names were not what I'd expect to see if I mounted the CD in SunOS. I ended up having to change the names of files a little before I could unpack them with 7-zip. Unpacking 100382_0.gz gave me 10032_0 . I renamed that as 100382_0.ar and unpacked it which yielded these three files: README Sun3/SC1.0.1_tar Sun4/SC1.0.1_tar The .tar files unpack what look like complete, usable files for patch-ID 100332-08. README's contents: Patch-ID# 100332-08 Keywords: Fortran, Optimizer, Assembler, Code Generator, Math Library, SC1.0 Synopsis: Fortran 1.4: Fixes several bugs including the back end components Date: 11/Nov/92 SunOS release: 4.1 / 4.1.x Unbundled Product: FORTRAN Unbundled Release: 1.4, Patch Release 8 Topic: FORTRAN 1.4, Patch Release 8 BugIds fixed in this patch: 1105525, 1104272, 1097078, 1096836, 1077374, 1080566 (sun3 only), 1081835, 1088393, 1089298 1026497, 1038650, 1041789, 1044329, 1044552, 1052173, 1052645, 1054414, 1056865, 1056866, 1058033, 1058888, 1059673, 1060916, 1061604, 1062128, 1065805, 1065943, 1066115, 1066839, 1067259, 1069293, 1069318, 1070243, 1070315, 1070381, 1073309, 1074464, 1075144, 1076384, 1078317 Changes incorporated in this version: 1105525, 1104272 Architectures for which this patch is available: Sun4(all), Sun3(all) Patches which may conflict with this patch: NOTE: If you have previous versions of this Patch Release, you can install this over them. The fixes are cumulated in this release. Obsoleted by: Problem Description: Detailed in the README/fortran_software file in the SC1.0.1 directory 1026497 f77 produces bad .stabs for complex structure/union/map 1038650 data value too large for most negative (smallest) integer -2147483648 1041789 Compiler error Impossible tag impldo in routine frexp 1044329 compile -g fails if include is first statement new_triple: 1044552 libF77 contains yacc and lex names _yyparse _yyerror _yylex 1052173 f77pass1 generates kernel error: sendsig: bad signal stack 1052645 Chars 0 to 255 not in fully ordered sequence (not unsigned) 1054414 -U leave upper case option cancels $pragma C() 1056865 do not compute (1/x)**k for x**-k 1056866 x**(-k) computed by inverting x first 1058033 Imaginary part of complex # element of array crashes with O2 or > 1058888 1.3.1 G Format fails on 1.4 libF77.so ld.so undefined ___no 1059673 namelist read of certain sizes fails 1060916 bug in complex template Fc_ne 1061604 Spurious spaces embedded in writing unformatted file 1062128 SC1.0 Optimizer is missing some things it did under SC0.0 1065805 trivial program segment faults f77pass1 1065943 ieee_retrospective "broken" 1066115 secnds doesn't return correct results 1066839 Assigning a binary constant to a character results in core 1067259 1 or 2 byte hollerith strings or constants are not aligned 1069293 CONVERT_EXTERNAL fails for double precision vax to double precision sun 1069318 sscanf does not work correctly when long double value overflows 1070243 Undefined symbol _MAIN_ when using ld1.1.38 patch. 1070315 binaries compiled on 1.3.1 can give undefined symbol when run with 1.4 1070381 printf of 1.0*2**1937 in long double format dumps core 1073309 Bus error and seg. violation due to optimization problem with 1.4 1074464 run-time segmentation violation from four_digits_quick 1075144 Fortran 1.4 is missing the srcbrowser help file SourceBrowser.info 1076384 impossible tag bad tag with inquire statement and -C option. 1077374 segmentation violation when reading a formatted file as unformatted. 1078317 -Nx option set to high number (of COMMON blocks) causes compiler error. 1080566 Valid fortran programs fail to compile on Sun3 machines without 68881s 1081835 fortran programs can't start up if stdin has been closed 1088393 f77 -pic with large number of external symbols fails 1089298 SC1.0.1 patch 100332-05 library breaks format P/G descriptor combination 1096836 double_to_decimal incorrectly rounds the converted number 1097078 Incorrect rounding of floating point numbers on formatted output 1104272 runtime core dump from compiling w/ -r8 and type-conversion assignments 1105525 Incorrect alternate return taken during execution Note: The new Assembler and Code Generator backend components are included in the sun4 version only. The sun3 version still uses the original backend components. INSTALL: These instructions assume you have the following in /tmp this README file (SC1.0.1_README), and a tar file of the directory SC1.0.1 (called SC1.0.1_tar) Do either A or B: A. If FORTRAN 1.4 was installed into /usr/lang 1. Put the files into /usr/lang: cd /usr/lang tar xvf /tmp/SC1.0.1_tar 2. Remove the soft links of f77, as & fpversion to /usr/lang/SC1.0 rm /usr/lang/f77 rm /usr/lang/as (sun4 only) rm /usr/lang/fpversion (sun4 only) 3. Replace them with the soft links to /usr/lang/SC1.0.1 ln -s /usr/lang/SC1.0.1/f77 ln -s /usr/lang/SC1.0.1/as (sun4 only) ln -s /usr/lang/SC1.0.1/fpverison (sun4 only) 4. Copy the "whatis" file from SC1.0.1/README to /usr/lang/man cp SC1.0.1/README/whatis man/whatis B. If FORTRAN 1.4 was installed into /mydir (Non-Standard Installation ) 1. Put the files into /mydir: cd /mydir tar xvf /tmp/SC1.0.1_tar 2. Remove the soft links of f77, as and fpversion to /mydir/SC1.0 rm /mydir/f77 rm /mydir/as (sun4 only) rm /mydir/fpversion (sun4 only) 3. Replace them with the soft links to /mydir/SC1.0.1 ln -s /mydir/SC1.0.1/f77 ln -s /mydir/SC1.0.1/as (sun4 only) ln -s /mydir/SC1.0.1/fpversion (sun4 only) 4. Copy the "whatis" file from SC1.0.1/README to /mydir/man cp SC1.0.1/README/whatis man/whatis NOTE: If you have older binaries that are dynamically linked and you would like to run them such that they get linked in with these newer patched dynamic libraries then you can: setenv LD_LIBRARY_PATH /usr/lang/SC1.0.1 or setenv LD_LIBRARY_PATH /mydir/SC1.0.1 so that these newer dynamic libraries are linked in. From pnr at planet.nl Sat May 1 09:08:08 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 1 May 2021 01:08:08 +0200 Subject: [TUHS] pcc in 8th edition In-Reply-To: References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: I’m still playing with PCC2. I’ve solved the issue with building an ILP32 version, but the ’stin’ file remains equally intriguing and mysterious. Unfortunately, it seems that PCC2 retargeting manual is lost - so this list appears my best source. From the paper that Clem shared, I get the general idea behind PCC2 and its tree tile covering algorithm: it does a full top-down search, matching on the basis of operations (“OPCODES”) and addressing modes (“SHAPES”). In general, the cost of a tile is estimated as the sum of the number of memory accesses and the number of instructions (normally 1). The SHAPES section of a ’stin’ file defines the addressing modes, and the OPCODES section defines instructions for operations. The instructions are specified as macros, similar in style to PCC or the dmr compiler. What I find difficult to understand is the role of the “needs” field. The grammer for the ’stin’ pre-processor has the following comment about the ’needs’ field: 1,2,3 Number of needed registers $P need pairs $< share left $> share right $L result left $R result right $1,2,3 result in reg 1, 2, 3 $C operation produces correct condition codes $N no value produced: side effects only $A need them all $[ share left, RHS is preferred (if a temp register) $] share right, RHS is preferred (if a temp register) $l left side is referenced once more $r right side is referenced once more I am puzzled as to how 'needs' should be read. Are the needs properties of or requirements for the tile? Or both? For example, here is two lines from the ’stin’ file for the 68K: operation: = shapes: SAWD[sus], SAWD[sus] (means: operands must be "signed/unsigned addressable short words") needs: {$C} macro: "mov.w AR,AL" operation: = shapes: LAWD[lul], LAWD[lul] needs: {$C $l $r} macro: "mov.l AR,AL” Does this mean that instruction sets the condition codes as a side effect, or does it say that the line must be used when the conditions codes are required?. Why are the left and right side used once more for move.l but not for move.w? And why is the below a separate definition on yet another line? operation: = shapes: LAWD[lul], LAWD[lul] needs: {$R $l $r} macro: “RL!R mov.l AR,AL” Hopefully there is somebody on the list who has worked with PCC2 and still remembers about the ’needs’ field. Paul > Thank you, that Usenix paper is most helpful. > > In short, there were (at least) 4 generations of PCC: PCC, PCC2, QCC and RCC. The first two by SCJ and the latter two by Kristol. > PCC2 seems to go back to about 1980, and QCC and RCC were created in the first half of 1985. The C compiler in 8th Edition seems to be PCC2 based. > > For ease of reference I’ve put the M68K compiler that is included in the Blit source tree (https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/ ) here: > https://gitlab.com/pnru/pcc2_m68k > > Anybody who has some more info on how to read a “stin” file, please share. > > Paul > >> On Apr 25, 2021, at 7:11 PM, Clem Cole > wrote: >> >> yes i'll mail under separate cover a scan >> ᐧ >> >> On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal > wrote: >> By now found some more clues, in particular this link: >> http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm >> >> Apparently I am talking about PCC and PCC2 in the below question. >> >> The first post mentions 4 papers. They can be found online, apart from the USENIX one: >> "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer USENIX Conference Proceedings) >> >> Anybody have that? >> >> The second post mentions official documentation: >> >> "In porting QCC, a useful text is the "Portable C Compiler - >> Version 2 (PCC2) Internals". It includes documentation of >> stin file formats, PCC2 tree forms, debugging flags, and >> compiler #defines. The manual is expensive so it's worth it >> most if you buy it before you figure it all out doing a >> port. Since the manual is based on PCC2 (and hasn't been >> updated), it's a good starting point, but doesn't have the >> latest information.” >> >> Anybody have that? (It is not on bitsavers) >> >> Paul >> >> > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: >> > >> > Not an answer to your questions, but you may want to take a look >> > at the PCC Revived project. It lives in CVS, but I have a git mirror at >> > git://github.com/arnoldrobbins/pcc-revived >> > >> > HTH, >> > >> > Arnold >> > >> > Paul Ruizendaal > wrote: >> > >> >> For clarity and ease of reference: >> >> >> >> - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 > >> >> >> >> - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > >> >> >> >> - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin > >> >> >> >> - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > >> >> >> >> >> >> ==== >> >> >> >> Sometimes one thing leads to another. >> >> >> >> Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. >> >> >> >> My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. >> >> >> >> This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. >> >> >> >> All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. >> >> >> >> A quick google did not yield much background or documentation on the STY format. >> >> >> >> Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? >> >> >> >> Many thanks in advance >> >> >> >> Paul >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat May 1 20:07:54 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 1 May 2021 12:07:54 +0200 Subject: [TUHS] Evolution of Unix (demand) paging 1980-1985 Message-ID: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> As an offshoot of looking more closely at 32V, SysIII and 8th Edition I got interested in how each managed memory. I’ve not deep-dived into the code yet, but from cursory inspection and searching past posts on this list, I get to the following summary: - As has been documented widely, 32V essentially retained the V7 swapping architecture, merely increasing the maximum process size a bit versus the PDP-11 version. - SysIII appears to have retained this, just cleaning up the source code a bit. I assume that all the V7/SysIII derivatives of the early 80’s were swapping systems. - John Reiser further developed 32V memory management into a (reportedly elegant) demand paging system in 1980-1981, but this code appears lost. - 3BSD/4BSD/4.1BSD developed 32V memory management into a full demand paging setup as well. This code base was dominant in the 1980-1985 era. - 8th Edition pulled in the BSD VM code and is essentially identical to that in 4.1BSD. This choice was made because it was not a research interest and using a maintained code base freed up scarce time. - SysV R1 appears to have retained the SysIII memory system. - SysV R2 (floating about on the net, eg. here https://github.com/ryanwoodsmall/oldsysv) seems to have used a new implementation. Questions: Is that about correct, or am I missing major elements? Several places mention that there was also a setup that was still swapping in nature, but did not require allocations in core to be contiguous (“scatter paging”). Did this get used much in the era? At first glance, the SysV R2 code seems shorter and cleaner than the early BSD code (~2000 vs. ~3000 sloc). Is this implementation perhaps a derivative of John Reiser’s work? From clemc at ccc.com Sun May 2 00:42:08 2021 From: clemc at ccc.com (Clem Cole) Date: Sat, 1 May 2021 10:42:08 -0400 Subject: [TUHS] Evolution of Unix (demand) paging 1980-1985 In-Reply-To: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> References: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> Message-ID: On Sat, May 1, 2021 at 6:09 AM Paul Ruizendaal via TUHS < tuhs at minnie.tuhs.org> wrote: > Questions: > > Is that about correct, or am I missing major elements? > I'm going to stretch your time frame a little, but this is what I remember: SRV3 was an alternative that was more widely distributed than SVR2. This is described in Maury Bach's book. It was the basis that the VM in the Stellar machine (we would do a bit of a rewrite to make it reentrant and multi-threaded). SVR4 would eventually do that as well (not nearly as well in IMO - but alas Stellix is lost to winds I fear). Sun did their own, which Rob and Larry can describe. I don't think they cribbed much from anyone, but I would ask. DG/UX was a scratch kernel rewrote with its own VM code. Probably the nicest scheme I ever saw. Extremely clean and easy to understand the locks. I've often wondered what happened to that code case. It's too bad it not to be found these days. The CMU Mach code would be very widely used and is still in the wide in Mac OSx and iOS. Tru64 and the Intel paragon were also based on the system. By the time of the Linux VM, the Mach code was what many people were comparing things to. The Mach VM code was extremely flexible and could handle a number of different types of HW and paging/backing store schemes (had a 'plugin' called the pager) and of course worked well on SMP's from time t0, but if you look that codebase was huge and noted to be slow. Even when the OSF/1 and CMU folks created the Mach ukernel, it was a bit of joke as the Mach 386/uk was over 1.2M of memory before any of the servers started to run (at one point they talked about creating a nanokernel and moving the MMU code out of the UK but I don't think anyone ever did). The Chorus folks had something different yet that A&T was excited about as an alternative to Mach, but I don't think it went very far. > Several places mention that there was also a setup that was still swapping > in nature, but did not require allocations in core to be contiguous > (“scatter paging”). Did this get used much in the era? > Depends on the code base and if the kernel could use the FS for paging or needed a dedicated paging file. In that era, most systems had a dedicated area (either disk partition or reserved file on the FS). If it uses the FS, then it tended to be able to handle the pages being scattered. We did that on Stellix and IIRC, DG could also. Masscomp and the Intel Paragon did not because predictable performance on a fault was important, although Masscomp cheated later on since we had contiguous files support and eventually allow those files to be used for paging also. > At first glance, the SysV R2 code seems shorter and cleaner than the early > BSD code (~2000 vs. ~3000 sloc). At the time, the SysV VM code was often considered easier to work, a tad less Vax dependent. Which again, ask Rob or Larry, I think is why Sun rewrote the BSD for their use. We used a BSD base at Masscomp because it worked, but ... Tom, Terry, and I had long memories of making the original BSD code MP-safe for the MC-500/DP [which was the first commercial MP UNIX]. So by Stellar time, since we had a 'do over,' we started with the SVR3 code and thread it for exactly this reason. > Is this implementation perhaps a derivative of John Reiser’s work? I don't know, but you might ask someone like Steve Rago, who I believe was part of the implementation team. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun May 2 21:47:53 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 2 May 2021 13:47:53 +0200 Subject: [TUHS] Evolution of Unix (demand) paging 1980-1985 In-Reply-To: References: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> Message-ID: <7ACDBEAE-B418-48F9-AE6D-ABD36F63C50C@planet.nl> > On 1 May 2021, at 16:42, Clem Cole wrote: Thanks for that context Clem! >> Is this implementation perhaps a derivative of John Reiser’s work? > I don't know, but you might ask someone like Steve Rago, who I believe was part of the implementation team. I did a bit more googling and this list and the AUUGN archive gave some interesting results. It would seem that Keith Kellman and Steven Buroff are the key people for more insight into the Reiser paging system (see below for some quotes). Based on the below my hypothesis would be that when looking at the surviving SYSV R2.4 paging code, Kellman and Buroff mainly added the “Region” abstraction (~900 sloc), and that the actual paging (~1100 sloc) probably is a close derivative of the Reiser code. A more speculative hypothesis would be that moving that actual paging code to SysIII, replacing the Region abstraction with the classic shared text abstraction (as present since the V4 days), would result in something close to what Rob and Norman recall. As you already pointed out, the paging code in R2.4 carries through to R3 and is described in the Bach book. Paul ==== TUHS list (Rob Pike, Aug 2019) I think it was slightly later. I joined mid-1980 and VAXes to replace the 11/70 were being discussed but had not arrived. We needed to convert a lab into a VAX machine room and decide between BSD and Reiser, all of which happened in the second half of 1980. Reiser Unix got demand paging a little later, and it was spectacularly fast. I remember being gobsmacked when I saw a demo in early 1981. Dead ends everywhere. ==== TUHS list (Norman Wilson, Aug 2019) John Reiser did do his own paging system for UNIX 32/V. I heard about it from friends at Bell Labs ca. 1982-83, when I was still running systems for physicists at Caltech. It sounded very interesting, and I would love to have had my hands on it--page cache unified with buffer cache, copy-on-write from the start. The trouble is that Reiser worked in a different group from the original UNIX crowd, and his management didn't think his time well spent on that work, so it never got released. I remember asking, either during my interview at the Labs or after I started work there, why the 4.1 kernel had been chosen instead of Reiser's. It had to do with maintainability: there were already people who could come in and hack on the Berkeley system, as well as more using it and maintaining it, whereas Reiser's system had become a unicorn. Nobody in 1127 wanted to maintain a VM system or anything much close to the VAX hardware. So the decision was to stick with a kernel for which someone else would do those things. Once I'd been there for a year or so and settled in, I found that I was actually looking after all that stuff, because I was really interested in it. (Which seemed to delight a lot of people.) Would we have ended up using Reiser's kernel had I been there a couple of years earlier? I don't know. It is in any case a shame that jfr's code never saw the light of day. I really hope someone can find it on an old tape somewhere and we can get it into the archive, if only because I'd love to look at it. ==== AUUGN Vol 5.1 (Keith Kellman, Dec 1983) Two research derivatives of the UNIX system have supported paging for several years: Reiser 32V, and BSD. Work is under way at AT&T Bell Labs to bring together the features of both of these systems [and others] to form a demand paged kernel for UNIX System V. This talk will discuss three areas of this work: requirements, architecture, and implementation. The primary requirement of the paging system is that it be upward compatible with its predecessor. This means that old objects must execute unchanged, and that the meaning of system calls should not be changed. For example, fork(2) should be made efficient rather than inventing a new type of call. A second requirement is that the paging system be based on a general machine-independent architecture. As part of the paging kernel development, a UNIX system memory management architecture is being defined. The architecture is general enough to support both paging and swapping kernels and many different memory management units. The fundamental component of the architecture is the "region." A region is a kernel data structure that represents a potential virtual address space. The basic operations defined for regions are: create/destroy, attach/detach, copy, change size, and load a file. The defined architecture can support potential new UNIX system features such as shared libraries and mapped files. ==== AUUGN Vol 5.3 (Keith Kellman, Feb 1984) Work is currently underway at AT&T Bell Laboratories to develop a demand paged kernel for UNIX System V. It is hoped that it will utilize the best features of both 32V and BSD. Some of the requirements for the System V paging is that it will require no program changes -- it will not change system calls. A priority is to not hurt those who don’t need paging -- there should be no performance loss. Also, as part of the development, there will be a definition of memory management architecture -- the architecture must be general enough to support many different memory management units, paging and swapping kernels. A main component of the architecture is the "region." A region is a data structure within a system that represents a potential virtual address space. The reason for not merely supporting Berkeley paging is because AT&T feels it is too complex and too specific to the VAX (not portable enough). They also do not like the vfork call, and claim there is no well-defined architecture. The status of the project is that there is currently a prototype implemented on the 3B20 computer. The performance is good relative to System V, Release 2. They are currently porting it to a VAX ==== AUUGN Vol 5.6 (Steven Buroff, Nov 1984) Two research derivatives of the UNIX system have supported paging for several years: Reiser 32V, and BSD. Work is under way at AT&T Bell Labs to bring together the features of both of the systems [and others] to form a demand paged kernel for UNIX System V. This talk will discuss three areas of this work: requirements, architecture, and implementation. The requirements are: there should be no user program changes for either binary or source; the system must not hurt users who don’t require paging, this means that if you want to use a paging system because it is faster, then you can do so; and the system should provide the capability of large address spaces if that is wanted. The idea was to generate a general model of memory management in the UNIX kernel and to abstract all the code which deals with it into one generalised set of routines. Different memory allocation methods can then be used because a clean internal interface has been designed. The main primitive in the design is a Region, which is an area of memory. It can be shared or private and is manipulated by a set of well defined operations. These operations are: create, delete, attach, detach, grow, load and copy. The system allows copy on write by adroit use of the page descriptors. ==== From stewart at serissa.com Mon May 3 01:48:09 2021 From: stewart at serissa.com (Larry Stewart) Date: Sun, 2 May 2021 11:48:09 -0400 Subject: [TUHS] JF Reiser Message-ID: <19DCAD9F-4047-4C9D-95C4-AEDE7E6696D3@serissa.com> I never saw his 32V work, but I reimplemented his additive random number generator in my own work. Not too many people can write a 35 page PhD thesis. Fewer can do it for Knuth. -Larry From saif.resun at outlook.com Wed May 5 21:08:17 2021 From: saif.resun at outlook.com (Saif Resun) Date: Wed, 5 May 2021 11:08:17 +0000 Subject: [TUHS] How to use V5 UNIX? Message-ID: hello there I'm Resun, a teenaged programmer and I love C and UNIX. I want to use the 5th edition UNIX operating system. From here Index of /Archive/Distributions/Research/Dennis_v5 (tuhs.org) I've got a compressed file of the 5th edition UNIX. I want to use it using the SimH emulator but there's no guide about how to install it or use it. I'm using SimH in Windows 10. Can someone please help me to use this system? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Wed May 5 22:28:33 2021 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 5 May 2021 14:28:33 +0200 Subject: [TUHS] How to use V5 UNIX? In-Reply-To: References: Message-ID: On 05/05/21, Saif Resun wrote: > Can someone please help me to use this system? Not much to do really: create an ini like this: set cpu 11/45 att rk0 disk0.rk d sr 1 b rk0 and then boot like this: % pdp11 boot.ini PDP-11 simulator V4.0-0 Current git commit id: 938aa58f Disabling XQ @unix mem = 64537 ;login: root # to shutdown, type `sync` a couple of times and stop the simulation with ^E. Otherwise read the manual and maybe explore v6 or v7 as they're a little more complete. aap From jnc at mercury.lcs.mit.edu Thu May 6 04:08:23 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 5 May 2021 14:08:23 -0400 (EDT) Subject: [TUHS] How to use V5 UNIX? Message-ID: <20210505180823.F21A718C094@mercury.lcs.mit.edu> > From: Saif Resun > I want to use the 5th edition UNIX operating system. > ... > I want to use it using the SimH emulator but there's no guide about > how to install it or use it. As they say,'Google is your friend': https://gunkies.org/wiki/Running_Unix_v5_in_SIMH Also, V6 Unix is very similar to V5 (the main difference, IIRC, is that V6 supports so-called 'Split I/D space' on the PDP-11) so anything for V6 will mostly apply to V5: https://gunkies.org/wiki/Running_UNIX_v6_in_SIMH https://gunkies.org/wiki/Installing_UNIX_v6_(PDP-11)_on_SIMH https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition_on_Ersatz-11 Have fun! Noel From clemc at ccc.com Thu May 6 05:02:53 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 May 2021 15:02:53 -0400 Subject: [TUHS] How to use V5 UNIX? In-Reply-To: <20210505180823.F21A718C094@mercury.lcs.mit.edu> References: <20210505180823.F21A718C094@mercury.lcs.mit.edu> Message-ID: The only thing I would add is to find yourself a copy of Lion's book: https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code You can get a nicely bound version inexpensively from Amazon, although there are PDFs in the wild too. Like, others I would suggest starting with Sixth Edition if you want to follow John. The biggest advantage of Seventh besides having more complete toolchains is that the compiler matches K&R Version 1, so you are likely to have fewer issues, you will already be giving up ANSI (as described in K&R2). I started with Fifth years ago in the early/mid-1970s but quickly got Sixth's so I have little memory of it. I have played with it on simh since frankly, the differences between 5 and 6 are not going to be huge from a learning standpoint. ᐧ On Wed, May 5, 2021 at 2:09 PM Noel Chiappa wrote: > > From: Saif Resun > > > I want to use the 5th edition UNIX operating system. > > ... > > I want to use it using the SimH emulator but there's no guide about > > how to install it or use it. > > As they say,'Google is your friend': > > https://gunkies.org/wiki/Running_Unix_v5_in_SIMH > > Also, V6 Unix is very similar to V5 (the main difference, IIRC, is that V6 > supports so-called 'Split I/D space' on the PDP-11) so anything for V6 will > mostly apply to V5: > > https://gunkies.org/wiki/Running_UNIX_v6_in_SIMH > https://gunkies.org/wiki/Installing_UNIX_v6_(PDP-11)_on_SIMH > https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition_on_Ersatz-11 > > Have fun! > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu May 6 11:57:16 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 6 May 2021 11:57:16 +1000 Subject: [TUHS] Lion's book (was: How to use V5 UNIX?) In-Reply-To: References: <20210505180823.F21A718C094@mercury.lcs.mit.edu> Message-ID: <20210506015716.GC61513@eureka.lemis.com> On Wednesday, 5 May 2021 at 15:02:53 -0400, Clem Cole wrote: > The only thing I would add is to find yourself a copy of Lion's book: > https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code > > You can get a nicely bound version inexpensively from Amazon, > although there are PDFs in the wild too. It's available at http://www.lemis.com/grog/Documentation/Lions/ This version dates back to 1994 and is based on wkt's original publication in 1991. It contains scan errors, but should be intelligible. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From pnr at planet.nl Mon May 10 05:47:57 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 9 May 2021 21:47:57 +0200 Subject: [TUHS] Genix / early 80's VM variants Message-ID: Looking at some VM stuff, I came across this: http://bitsavers.org/bits/AmericanInformationSystems/ It seems American Information Systems was a short-lived National Semiconductor spinoff that made a 32016 based board that plugged into a PDP-11 QBus: https://books.google.nl/books?id=xyjys2kz1RQC&pg=RA1-PA58&lpg=RA1-PA58&dq=american+information+system+3210&source=bl&ots=f1JGu1boT6&sig=ACfU3U2X04c3Myuhea-MLepeKFed6vvVCw&hl=en&sa=X&redir_esc=y#v=onepage&q=american%20information%20system%203210&f=false It ran a version of Unix called Genix that appears to be SysV R2 derived, but with VM code that is neither 4BSD derived, nor SysV R2.4 derived. The VM code names David I. Bell and Laura Neff as authors. Anybody recall American Info Systems and/or Genix? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon May 10 05:57:45 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 9 May 2021 12:57:45 -0700 Subject: [TUHS] Genix / early 80's VM variants In-Reply-To: References: Message-ID: <20210509195745.GS2329@mcvoy.com> Pretty sure Bill Jolitz either had a 32016 Unix or he was also selling similar boxes. National couldn't get it together to produce bug free chips or maybe we'd all be running that, pretty nice architecture (in theory). On Sun, May 09, 2021 at 09:47:57PM +0200, Paul Ruizendaal wrote: > Looking at some VM stuff, I came across this: > http://bitsavers.org/bits/AmericanInformationSystems/ > > It seems American Information Systems was a short-lived National Semiconductor spinoff that made a 32016 based board that plugged into a PDP-11 QBus: > https://books.google.nl/books?id=xyjys2kz1RQC&pg=RA1-PA58&lpg=RA1-PA58&dq=american+information+system+3210&source=bl&ots=f1JGu1boT6&sig=ACfU3U2X04c3Myuhea-MLepeKFed6vvVCw&hl=en&sa=X&redir_esc=y#v=onepage&q=american%20information%20system%203210&f=false > > It ran a version of Unix called Genix that appears to be SysV R2 derived, but with VM code that is neither 4BSD derived, nor SysV R2.4 derived. > > The VM code names David I. Bell and Laura Neff as authors. > > Anybody recall American Info Systems and/or Genix? > > Paul > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Tue May 11 00:26:03 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 10 May 2021 10:26:03 -0400 Subject: [TUHS] Genix / early 80's VM variants In-Reply-To: <20210509195745.GS2329@mcvoy.com> References: <20210509195745.GS2329@mcvoy.com> Message-ID: On Sun, May 9, 2021 at 3:58 PM Larry McVoy wrote: > Pretty sure Bill Jolitz either had a 32016 Unix or he was also selling > similar boxes. National couldn't get it together to produce bug free > chips or maybe we'd all be running that, pretty nice architecture > (in theory). > He did. It was about the size and form factor of the Compaq 'luggable.' IIRC hBill used a flavor of the multibus, which made a large power supply and more expensive peripherals (although Sun, Masscomp, and Apollo were also using Multibus in those days -- as Multibus was cheaper than the Unibus or QBUS). Bill's computer showed up at about the same times as the Sun-2, which was 68010 based. As Yale Pratt once said of the NS32016 ISA, 'it was a VAX/780 cleaned up but on a single chip'. Still technically a CISC, but did had fewer specialty features (more like PDP-10 in that what Bill Wulf used to call a 'regular and complete' architecture). Conceptually the ISA more powerful than the 68000 ISA, but it lacked a good compiler (*a.k.a.* 'production quality' compiler) that could exploit it, and as you point out, Nat Semi had a difficult time producing them. Funny, the compiler issue was SOP for the chip folks in those times as they had traditionally relied on 3rd parties to build the compiler for them - they would put out an assembler (usually written in Fortran-IV), make the assembler 'open source' and let the ecosystem go from there. Compiler houses (such as Green Hills, MCA, Frieberghouse, and PG) had to decide if they wanted to invest in that new ISA or not if they could not get someone else to pay them to write one for it. The systems folks (like DEC/DG knew that was not good enough). Sun was just awakening to that fact and I >>think<< it would have been around then that they started their real compiler team (Rob G -- you probably know more than I do here). Anyway, I always felt it was the compiler that killed them as much as Nat Semi's well-known Si production issues. Also, so many of us were ignoring the PC because it was based on the x86, that we did not realize that the PC's ISA bus was 'good enough (Masscomp never built anything with it, and Apollos did not until they finally did the DN3000 a couple of years later and I think it was not until RR that Sun tried). But in the end, the 386 'won' for economic reasons -- by being on the PC ecosystem much cheaper peripherals snd eventually got the ability to solve the addressing issues so you could run large programs on it, so the fact that it had the worst ISA did not matter. I've always wondered if a Nat Semi NS32016 based system running in a PC/AT form factor had appeared that was priced like a PC/AT if that might have had a chance. Clem ᐧ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed May 12 22:58:21 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 12 May 2021 08:58:21 -0400 Subject: [TUHS] Bill Joy on the "Open Systems Imperative" Message-ID: This video got passed around at my (new!) job, and I think it's very relevant to this list. It's Bill Joy talking about what he and Sun were thinking about as the future of workstations and computing in general ca 1987. Some of the predictions were not accurate, but some were. I'm curious what others think. https://www.youtube.com/watch?v=k8Pd6xYaHGU - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Thu May 13 05:43:09 2021 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 12 May 2021 12:43:09 -0700 Subject: [TUHS] Bill Joy on the "Open Systems Imperative" In-Reply-To: References: Message-ID: At Wed, 12 May 2021 08:58:21 -0400, Dan Cross wrote: Subject: [TUHS] Bill Joy on the "Open Systems Imperative" > > This video got passed around at my (new!) job, and I think it's very > relevant to this list. It's Bill Joy talking about what he and Sun were > thinking about as the future of workstations and computing in general ca > 1987. Some of the predictions were not accurate, but some were. > > I'm curious what others think. https://www.youtube.com/watch?v=k8Pd6xYaHGU I'm pretty sure Bill Joy gave that same talk as a keynote at the /usr/group/cdn conference and trade show that I think was in the summer of 1987 in Toronto. I can't find a programme for it at the moment (maybe there's one in my old files somewhere, if I didn't recycle all of the old /usr/group/cdn stuff), but my memory of the talk very closely matches what's in the video, and given how little remains of some of those old conferences and trade shows, this is a remarkable video to still have access to. I distinctly remember him comparing the 1-MIP/1-Megabyte/1-megapixel workstation with his predictions and I also distinctly remember his analogy with warp speed in space travel compared to a 100-year @ 1-MIP problem on a VAX vs. waiting 15 years and running it all in 8 hours. At that time I would have been quite happy to have a 1m/1m/1m machine, but just two years later I had a 3B2/500 and a DMD5620. (and the latter alone more or less matched that spec) I was fairly amazed by some of his predictions at the time, particularly on the hardware front, and not all have turned out true of course, but I was also quite hopeful that they would come true. And now I'm currently contemplating buying a new workstation that in many ways exceeds many of the specifications he proposed; and it will be running a derivative of Unix. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From jsteve at superglobalmegacorp.com Tue May 18 11:33:35 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 May 2021 09:33:35 +0800 Subject: [TUHS] [COFF] Vint Cerf tests positive for COVID-19. In-Reply-To: References: Message-ID: I’m more impressed by his IMDb! https://www.imdb.com/name/nm0148576/ From: Dave Horsfall Sent: Tuesday, March 31, 2020 11:14 AM To: The Eunuchs Hysterical Society; Computer Old Farts Followers Subject: Re: [COFF] [TUHS] Vint Cerf tests positive for COVID-19. On Mon, 30 Mar 2020, Dan Cross wrote: > He announced it on Twitter. I'm sure we all wish him well and a speedy > recovery. Note, his tweet says that he is recovering. Indeed. On a whim I did a search for him, and got: Get Vint Cerf With Fast and Free Shipping on eBay. Looking For Vint Cerf? We Have Almost Everything on eBay. I'm sure that he'll be happy to hear that... -- Dave _______________________________________________ COFF mailing list COFF at minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Tue May 18 11:33:40 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 May 2021 09:33:40 +0800 Subject: [TUHS] Status of Net/2 In-Reply-To: <20200516013930.GG1670@eureka.lemis.com> References: <20200516013930.GG1670@eureka.lemis.com> Message-ID: <2d3a0a5a-bd46-4a8d-bf1d-8f95f949a316@PU1APC01FT027.eop-APC01.prod.protection.outlook.com> Nobody ever said peep when I ‘mashed’ enough 386BSD and what was available from NetBSD 0.9 and the NetBSD 0.8 to make 0.8 work… The closest I got is ‘why do you want that we have version 17!’ or whatever $HEAD is . I guess in the same way I was more interested in preserving 386BSD 0.0, and again nobody ever told me to stop. I guess in the same way nobody told me to stop making Mach 2.6 available, or even Darwin 0.3 for i386. I wanted to take that IBM 4.4BSD and try to replace enough of 386BSD 0.1 pl32 to have something more akin to ‘real’ 4.4 BSD. Although I have a bunch of things I need to wrap up before I take that on (people are actually looking for bug fixes for Quake II on MS-DOS of all things….). I don’t think its exactly policed like 1984, although I think people are more excited about RIAA/MPAA than things like Unix. (shrug) From: Greg 'groggy' Lehey Sent: Saturday, May 16, 2020 9:41 AM To: Warner Losh Cc: The Eunuchs Hysterical Society Subject: Re: [TUHS] Status of Net/2 On Friday, 15 May 2020 at 18:49:44 -0600, Warner Losh wrote: > What's the current status of net/2? > > I ask because I have a FreeBSD 1.1.5.1 CVS repo that I'd like to make > available. Some of the files in it are encumbered, though, and the > University of California has communicated that fact. But what does that > actually mean now that V7 has been released and that's what the files were > based on? Are they no longer encumbered? To the best of my knowledge, Net/2 would be covered by the license granted by Caldera on 23 January 2002: Caldera International, Inc. hereby grants a fee free license that includes the rights use, modify and distribute this named source code, including creating derived binary products created from the source code. The source code for which Caldera International, Inc. grants rights are limited to the following UNIX Operating Systems that operate on the 16-Bit PDP-11 CPU and early versions of the 32-Bit UNIX Operating System, with specific exclusion of UNIX System III and UNIX System V and successor operating systems: 32-bit 32V UNIX 16 bit UNIX Versions 1, 2, 3, 4, 5, 6, 7 I'm attaching the PDF of the license agreement, along with an email from Dion Johnson to wkt (misspelt as wht) the following day. It doesn't specifically address any particular operating system, but it was my understanding that this would free all BSD versions. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Tue May 18 11:33:46 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 18 May 2021 09:33:46 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: I helped a bit sourcing stuff for oldlinux.org http://oldlinux.org/ Although I don’t get any replies from Jiong anymore. As always shovelware CD-ROM’s are the best place to find these old things, and newer CD’s get added all the time to archive.org. The problem is that many are not indexed, so you have to download and trawl yourself… I’ve been looking for early NetBSD (again) and I was given the following CD’s to check out: https://archive.org/details/meeting-pearls-1 https://archive.org/details/meeting-pearls-2 https://archive.org/details/macbsd https://archive.org/details/cdrom-riscos-dev-cds and http://grumbeer.dyndns.org/ftp/iso/infomagic/infomagic-1-1-93.iso http://grumbeer.dyndns.org/ftp/iso/infomagic/infomagic-1-2-94.iso http://grumbeer.dyndns.org/ftp/iso/infomagic/infomagic-nov94.iso There was a bit of bleed between the early BSD and Linux on shareware stuff, along with hidden distros of SLS. Like this one from late ‘92 http://cd.textfiles.com/toomuch/NETWORK/ From: Grant Taylor via TUHS Sent: Thursday, July 16, 2020 12:18 PM To: The Unix Heritage Society Subject: [TUHS] H.J. Lu Bootable Root & Base System disks 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saif.resun at outlook.com Thu May 20 04:25:37 2021 From: saif.resun at outlook.com (Saif Resun) Date: Wed, 19 May 2021 18:25:37 +0000 Subject: [TUHS] How to use Dennis v6? Message-ID: Hello there I’m Resun a teenaged programmer who knows nothing about past days. Here Index of /Archive/Distributions/Research/Dennis_v6 (tuhs.org) there are some compressed file of v6 Unix. And here’s SETTING UP UNIX - Sixth Edition (tuhs.org) a documentation about how to set it up. But the documentation is not for me I mean I don’t understand what it’s saying. There are terms like “Mount magtape on drive 0 at load point”, “Mount formatted disk pack on drive 0.”, “Key in and execute at 100000” and lots of other stuffs that newbies like me don’t understand. Is there any easy documentation about it? Or any documentation that tells us what does those terms mean? Please help me. Thanks. Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu May 20 04:33:46 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 19 May 2021 14:33:46 -0400 Subject: [TUHS] How to use Dennis v6? In-Reply-To: References: Message-ID: search is your friend: "simh running sixth edition" The first hit is Noel's great text: http://gunkies.org/wiki/Running_UNIX_v6_in_SIMH There are others in the list including folks from this list not to slight anyone. Note to Warren - -- since this topic comes with newbies, maybe a pointer to gunkies and/or the like next to the distribution might cut down a few of these questions? ᐧ On Wed, May 19, 2021 at 2:26 PM Saif Resun wrote: > Hello there I’m Resun a teenaged programmer who knows nothing about past > days. > > > > Here Index of /Archive/Distributions/Research/Dennis_v6 (tuhs.org) > there > are some compressed file of v6 Unix. > > > > And here’s SETTING UP UNIX - Sixth Edition (tuhs.org) > > a documentation about how to set it up. > > > > But the documentation is not for me I mean I don’t understand what it’s > saying. There are terms like “Mount magtape on drive 0 at load point”, > “Mount formatted disk pack on drive 0.”, “Key in and execute at 100000” and > lots of other stuffs that newbies like me don’t understand. Is there any > easy documentation about it? Or any documentation that tells us what does > those terms mean? > > > > Please help me. > > Thanks. > > > > Sent from Mail for > Windows 10 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Thu May 20 04:45:45 2021 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 19 May 2021 20:45:45 +0200 Subject: [TUHS] How to use Dennis v6? In-Reply-To: References: Message-ID: On 19/05/21, Saif Resun wrote: > But the documentation is not for me I mean I don’t understand what it’s saying. There are terms like “Mount magtape on drive 0 at load point”, “Mount formatted disk pack on drive 0.”, “Key in and execute at 100000” and lots of other stuffs that newbies like me don’t understand. Is there any easy documentation about it? Or any documentation that tells us what does those terms mean? I documented how you can install it: http://squoze.net/UNIX/v6/installation cheers, aap From jnc at mercury.lcs.mit.edu Thu May 20 05:22:35 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 19 May 2021 15:22:35 -0400 (EDT) Subject: [TUHS] How to use Dennis v6? Message-ID: <20210519192235.EB5A018C101@mercury.lcs.mit.edu> > From: Clem Cole > search is your friend: The number of people who come here asking for help, who apparently don't know how to do a Web search, is pretty astounding. Get off my lawn. > The first hit is Noel's great text: Actually, I didn't write that; another CHWiki contributor imported it from the Web. (Wouldn't touch SIMH myself... :-) Most of the other pages at the bottom, in the 'See also' section, I did write. Some of them might actually be useful. Also, at the bottom of the 'Installing UNIX Sixth Edition on Ersatz-11' page, there are links to a couple of external pages that have lots of info on how to upgrade a V6 into something semi-usable. Noel From imp at bsdimp.com Thu May 20 08:36:14 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 19 May 2021 16:36:14 -0600 Subject: [TUHS] Status of Net/2 In-Reply-To: <2d3a0a5a-bd46-4a8d-bf1d-8f95f949a316@PU1APC01FT027.eop-APC01.prod.protection.outlook.com> References: <20200516013930.GG1670@eureka.lemis.com> <2d3a0a5a-bd46-4a8d-bf1d-8f95f949a316@PU1APC01FT027.eop-APC01.prod.protection.outlook.com> Message-ID: On Mon, May 17, 2021 at 7:33 PM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > Nobody ever said peep when I ‘mashed’ enough 386BSD and what was available > from NetBSD 0.9 and the NetBSD 0.8 to make 0.8 work… The closest I got is > ‘why do you want that we have version 17!’ or whatever $HEAD is . I guess > in the same way I was more interested in preserving 386BSD 0.0, and again > nobody ever told me to stop. > > > > I guess in the same way nobody told me to stop making Mach 2.6 available, > or even Darwin 0.3 for i386. > > > > I wanted to take that IBM 4.4BSD and try to replace enough of 386BSD 0.1 > pl32 to have something more akin to ‘real’ 4.4 BSD. Although I have a > bunch of things I need to wrap up before I take that on (people are > actually looking for bug fixes for Quake II on MS-DOS of all things….). > > > > I don’t think its exactly policed like 1984, although I think people are > more excited about RIAA/MPAA than things like Unix. > Part of the problem too isn't so much who owns the copyrights, but whether or not the copyrights for the V7 and earlier actually exist and are valid. One of the reasons the BSD suit was settled was at the time the judge strongly telegraphed that there wasn't a valid copyright by western union based on the copyright law at its time of creation.... So even the question of who owns the unix copyright might not be as simple as all that... The stuff is so old, there's no money in removing any of the ambiguity for the current copyright holders (to the extent that it is valid), so we're left with a lot of possibility, but no certainty. Though given the Supreme Court's latest 'fair use' rulings, it wouldn't surprise me if were it to wind up in court if that didn't further weaken the answer to the point where it just doesn't matter what the underlying details are, copying and making a derived work would be OK. Though that's my own layman's best guess... Warner > (shrug) > > > > > > *From: *Greg 'groggy' Lehey > *Sent: *Saturday, May 16, 2020 9:41 AM > *To: *Warner Losh > *Cc: *The Eunuchs Hysterical Society > *Subject: *Re: [TUHS] Status of Net/2 > > > > On Friday, 15 May 2020 at 18:49:44 -0600, Warner Losh wrote: > > > What's the current status of net/2? > > > > > > I ask because I have a FreeBSD 1.1.5.1 CVS repo that I'd like to make > > > available. Some of the files in it are encumbered, though, and the > > > University of California has communicated that fact. But what does > > that > > > actually mean now that V7 has been released and that's what the files > > were > > > based on? Are they no longer encumbered? > > > > To the best of my knowledge, Net/2 would be covered by the license > > granted by Caldera on 23 January 2002: > > > > Caldera International, Inc. hereby grants a fee free license that > > includes the rights use, modify and distribute this named source > > code, including creating derived binary products created from the > > source code. The source code for which Caldera International, > > Inc. grants rights are limited to the following UNIX Operating > > Systems that operate on the 16-Bit PDP-11 CPU and early versions of > > the 32-Bit UNIX Operating System, with specific exclusion of UNIX > > System III and UNIX System V and successor operating systems: > > > > 32-bit 32V UNIX > > 16 bit UNIX Versions 1, 2, 3, 4, 5, 6, 7 > > > > I'm attaching the PDF of the license agreement, along with an email > > from Dion Johnson to wkt (misspelt as wht) the following day. > > > > It doesn't specifically address any particular operating system, but > > it was my understanding that this would free all BSD versions. > > > > Greg > > -- > > Sent from my desktop computer. > > Finger grog at lemis.com for PGP public key. > > See complete headers for address and phone numbers. > > This message is digitally signed. If your Microsoft mail program > > reports problems, please read http://lemis.com/broken-MUA > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewe2 at ewe2.ninja Fri May 21 19:46:27 2021 From: ewe2 at ewe2.ninja (Sean Dwyer) Date: Fri, 21 May 2021 05:46:27 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: On Tue, May 18, 2021 at 09:33:46AM +0800, Jason Stevens wrote: > 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 > I do have the boot/roots for kernel 0.99 pl 7 from my Yggdrasil disks of July/August 1995 which I believe are also on archive.org. I used to have disks from 1994 but they've been lost in time and I only have stuff from 94-97 now, some of which are on archive.org already. Hope that helps. -- I love deadlines. I love the whooshing noise as they fly by. From jon at fourwinds.com Tue May 25 10:44:04 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 24 May 2021 17:44:04 -0700 Subject: [TUHS] Some mysteries solved and other musty history Message-ID: <202105250044.14P0i4ZV404009@darkstar.fourwinds.com> 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 From beebe at math.utah.edu Wed May 26 10:12:00 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 25 May 2021 18:12:00 -0600 Subject: [TUHS] [tuhs] Dennis Ritchie's couch Message-ID: The last article of the latest issue of the Communications of the ACM that appeared electronically earlier today is a brief interview with this year's ACM Turing Award winners, Al Aho and Jeff Ullman. The article is Last byte: Shaping the foundations of programming languages https://doi.org/10.1145/3460442 Comm. ACM 64(6), 120, 119, June 2021. and it includes a picture of the two winners sitting on Dennis Ritchie's couch. I liked this snippet from Jeff Ullman, praising fellow list member Steve Johnson's landmark program, yacc: >> ... >> At the time of the first Fortran compiler, it took several >> person-years to write a parser. By the time yacc came around, >> you could do it in an afternoon. >> ... ------------------------------------------------------------------------------- - 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 at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From robpike at gmail.com Wed May 26 10:37:45 2021 From: robpike at gmail.com (Rob Pike) Date: Wed, 26 May 2021 10:37:45 +1000 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: Message-ID: And today, we understand parsing so well we don't need yacc. -rob On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe wrote: > The last article of the latest issue of the Communications of the ACM > that appeared electronically earlier today is a brief interview with > this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > > The article is > > Last byte: Shaping the foundations of programming languages > https://doi.org/10.1145/3460442 > Comm. ACM 64(6), 120, 119, June 2021. > > and it includes a picture of the two winners sitting on Dennis > Ritchie's couch. > > I liked this snippet from Jeff Ullman, praising fellow list member > Steve Johnson's landmark program, yacc: > > >> ... > >> At the time of the first Fortran compiler, it took several > >> person-years to write a parser. By the time yacc came around, > >> you could do it in an afternoon. > >> ... > > > ------------------------------------------------------------------------------- > - 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 at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed May 26 11:12:01 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 26 May 2021 09:12:01 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> Message-ID: <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> Luckily in the rush to 0.99 the CD-ROM shovelware thing was in full swing so lots of stuff got archived. It’s the older stuff that was always purged like COFF patches, or OMF patches for older stuff, or even missing stuff from the big projects like Emacs or GCC, and huge missing gaps in other GNU projects of all things. GCC 0.90-1.21 everything in between these two is missing. Is it so bad? Well it’s the start of adding 3rd parties code and G++ stuff as well. Also lots of gaps in libraries. Things like the core utils, and other user-land stuff is missing and what little I have was snapshotted on DECUS archives. Much like how binutils and Linux has/is removing a.out the old legacy stuff is being swept out. Much as everyone else seems to try to kill 32bit stuff which makes running ancient GCC on modern platforms a bit more challenging as I’ll have to do it under emulation. If I had the time/knowledge a 64bit hosted copy of GCC 1.42 would be cool but I think I may be the only one interested in compiling old Linux/BSD stuff with the original tools on newer (and alien) platforms. From: Sean Dwyer via TUHS Sent: Friday, 21 May 2021 6:17 pm To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks On Tue, May 18, 2021 at 09:33:46AM +0800, Jason Stevens wrote: > 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 > I do have the boot/roots for kernel 0.99 pl 7 from my Yggdrasil disks of July/August 1995 which I believe are also on archive.org. I used to have disks from 1994 but they've been lost in time and I only have stuff from 94-97 now, some of which are on archive.org already. Hope that helps. -- I love deadlines. I love the whooshing noise as they fly by. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Wed May 26 11:34:29 2021 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 25 May 2021 21:34:29 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> Message-ID: Hello! If it helps atll the strange people at Ibib managed to rescue the collection that was running on the Linux distro side of the house, and it's stored in their historic-linux directory.. Oh and the very early Slackware stuff is available on the mirror of Slackware's FTP site on the Mirror Services site at ftp.mirrorservice.org. Incidentally a very early mirror of the TSX site is also inside that historic-linux directory. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, May 25, 2021 at 9:13 PM Jason Stevens wrote: > > Luckily in the rush to 0.99 the CD-ROM shovelware thing was in full swing so lots of stuff got archived. > > > > It’s the older stuff that was always purged like COFF patches, or OMF patches for older stuff, or even missing stuff from the big projects like Emacs or GCC, and huge missing gaps in other GNU projects of all things. > > > > GCC 0.90-1.21 everything in between these two is missing. Is it so bad? Well it’s the start of adding 3rd parties code and G++ stuff as well. Also lots of gaps in libraries. > > Things like the core utils, and other user-land stuff is missing and what little I have was snapshotted on DECUS archives. > > > > Much like how binutils and Linux has/is removing a.out the old legacy stuff is being swept out. Much as everyone else seems to try to kill 32bit stuff which makes running ancient GCC on modern platforms a bit more challenging as I’ll have to do it under emulation. If I had the time/knowledge a 64bit hosted copy of GCC 1.42 would be cool but I think I may be the only one interested in compiling old Linux/BSD stuff with the original tools on newer (and alien) platforms. > > > > From: Sean Dwyer via TUHS > Sent: Friday, 21 May 2021 6:17 pm > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks > > On Tue, May 18, 2021 at 09:33:46AM +0800, Jason Stevens wrote: > > > 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 > > > > I do have the boot/roots for kernel 0.99 pl 7 from my Yggdrasil disks of > > July/August 1995 which I believe are also on archive.org. I used to have disks > > from 1994 but they've been lost in time and I only have stuff from 94-97 now, > > some of which are on archive.org already. Hope that helps. > -- > > I love deadlines. I love the whooshing noise as they fly by. From jsteve at superglobalmegacorp.com Wed May 26 12:53:21 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 26 May 2021 10:53:21 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> Message-ID: Super thanks I’ll take a look! I guess I should also say the attempt at bringing Mach to the Amiga saved a few bits of Mach when they were doing the Net/2 sub system, but then the lawsuit happened and as we all know academia and the world moved away from the microkernel thing (well except for Utah). But I guess now with the news of SeL4’s demise it’s basically all Linux and NT these days. From: Gregg Levine Sent: Wednesday, 26 May 2021 9:57 am To: Jason Stevens Cc: Sean Dwyer; tuhs at minnie.tuhs.org Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks Hello! If it helps atll the strange people at Ibib managed to rescue the collection that was running on the Linux distro side of the house, and it's stored in their historic-linux directory.. Oh and the very early Slackware stuff is available on the mirror of Slackware's FTP site on the Mirror Services site at ftp.mirrorservice.org. Incidentally a very early mirror of the TSX site is also inside that historic-linux directory. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, May 25, 2021 at 9:13 PM Jason Stevens wrote: > > Luckily in the rush to 0.99 the CD-ROM shovelware thing was in full swing so lots of stuff got archived. > > > > It’s the older stuff that was always purged like COFF patches, or OMF patches for older stuff, or even missing stuff from the big projects like Emacs or GCC, and huge missing gaps in other GNU projects of all things. > > > > GCC 0.90-1.21 everything in between these two is missing. Is it so bad? Well it’s the start of adding 3rd parties code and G++ stuff as well. Also lots of gaps in libraries. > > Things like the core utils, and other user-land stuff is missing and what little I have was snapshotted on DECUS archives. > > > > Much like how binutils and Linux has/is removing a.out the old legacy stuff is being swept out. Much as everyone else seems to try to kill 32bit stuff which makes running ancient GCC on modern platforms a bit more challenging as I’ll have to do it under emulation. If I had the time/knowledge a 64bit hosted copy of GCC 1.42 would be cool but I think I may be the only one interested in compiling old Linux/BSD stuff with the original tools on newer (and alien) platforms. > > > > From: Sean Dwyer via TUHS > Sent: Friday, 21 May 2021 6:17 pm > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks > > On Tue, May 18, 2021 at 09:33:46AM +0800, Jason Stevens wrote: > > > 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 > > > > I do have the boot/roots for kernel 0.99 pl 7 from my Yggdrasil disks of > > July/August 1995 which I believe are also on archive.org. I used to have disks > > from 1994 but they've been lost in time and I only have stuff from 94-97 now, > > some of which are on archive.org already. Hope that helps. > -- > > I love deadlines. I love the whooshing noise as they fly by. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed May 26 13:03:41 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 25 May 2021 20:03:41 -0700 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: Message-ID: <20210526030341.GD27558@mcvoy.com> You do, I don't. I'm not alone in my lack of understanding. I think that all the things that yacc solved, Steve gets some kudos. I've used it a bunch and I did not need to be as smart as you or Steve to get the job done. You getting past that is cool but it doesn't make his work less. On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote: > And today, we understand parsing so well we don't need yacc. > > -rob > > > On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe > wrote: > > > The last article of the latest issue of the Communications of the ACM > > that appeared electronically earlier today is a brief interview with > > this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > > > > The article is > > > > Last byte: Shaping the foundations of programming languages > > https://doi.org/10.1145/3460442 > > Comm. ACM 64(6), 120, 119, June 2021. > > > > and it includes a picture of the two winners sitting on Dennis > > Ritchie's couch. > > > > I liked this snippet from Jeff Ullman, praising fellow list member > > Steve Johnson's landmark program, yacc: > > > > >> ... > > >> At the time of the first Fortran compiler, it took several > > >> person-years to write a parser. By the time yacc came around, > > >> you could do it in an afternoon. > > >> ... > > > > > > ------------------------------------------------------------------------------- > > - 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 at math.utah.edu - > > - 155 S 1400 E RM 233 beebe at acm.org > > beebe at computer.org - > > - Salt Lake City, UT 84112-0090, USA URL: > > http://www.math.utah.edu/~beebe/ - > > > > ------------------------------------------------------------------------------- > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From robpike at gmail.com Wed May 26 14:02:28 2021 From: robpike at gmail.com (Rob Pike) Date: Wed, 26 May 2021 14:02:28 +1000 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: <20210526030341.GD27558@mcvoy.com> References: <20210526030341.GD27558@mcvoy.com> Message-ID: In no way did I mean to diminish the work. Instead, I was admiring how our knowledge of the field has continued to grow through the work they have done. -rob On Wed, May 26, 2021 at 1:03 PM Larry McVoy wrote: > You do, I don't. I'm not alone in my lack of understanding. > > I think that all the things that yacc solved, Steve gets some kudos. > I've used it a bunch and I did not need to be as smart as you or > Steve to get the job done. > > You getting past that is cool but it doesn't make his work less. > > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote: > > And today, we understand parsing so well we don't need yacc. > > > > -rob > > > > > > On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe > > > wrote: > > > > > The last article of the latest issue of the Communications of the ACM > > > that appeared electronically earlier today is a brief interview with > > > this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > > > > > > The article is > > > > > > Last byte: Shaping the foundations of programming languages > > > https://doi.org/10.1145/3460442 > > > Comm. ACM 64(6), 120, 119, June 2021. > > > > > > and it includes a picture of the two winners sitting on Dennis > > > Ritchie's couch. > > > > > > I liked this snippet from Jeff Ullman, praising fellow list member > > > Steve Johnson's landmark program, yacc: > > > > > > >> ... > > > >> At the time of the first Fortran compiler, it took several > > > >> person-years to write a parser. By the time yacc came around, > > > >> you could do it in an afternoon. > > > >> ... > > > > > > > > > > ------------------------------------------------------------------------------- > > > - 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 at math.utah.edu - > > > - 155 S 1400 E RM 233 beebe at acm.org > > > beebe at computer.org - > > > - Salt Lake City, UT 84112-0090, USA URL: > > > http://www.math.utah.edu/~beebe/ - > > > > > > > ------------------------------------------------------------------------------- > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aavindraa at gmail.com Wed May 26 14:10:26 2021 From: aavindraa at gmail.com (Avindra G) Date: Wed, 26 May 2021 00:10:26 -0400 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: Message-ID: That is an impressive lotus posture (by Professor Ullman). What a fun picture. Thanks for sharing. avg On Tue, May 25, 2021 at 8:20 PM Nelson H. F. Beebe wrote: > The last article of the latest issue of the Communications of the ACM > that appeared electronically earlier today is a brief interview with > this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > > The article is > > Last byte: Shaping the foundations of programming languages > https://doi.org/10.1145/3460442 > Comm. ACM 64(6), 120, 119, June 2021. > > and it includes a picture of the two winners sitting on Dennis > Ritchie's couch. > > I liked this snippet from Jeff Ullman, praising fellow list member > Steve Johnson's landmark program, yacc: > > >> ... > >> At the time of the first Fortran compiler, it took several > >> person-years to write a parser. By the time yacc came around, > >> you could do it in an afternoon. > >> ... > > > ------------------------------------------------------------------------------- > - 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 at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed May 26 15:13:12 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 25 May 2021 23:13:12 -0600 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: References: Message-ID: <202105260513.14Q5DCBu016940@freefriends.org> As a quite serious question, what do you use instead? Hand-written recursive descent? Some other form of machine generated parser? Thanks, Arnold Rob Pike wrote: > And today, we understand parsing so well we don't need yacc. > > -rob > > > On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe > wrote: > > > The last article of the latest issue of the Communications of the ACM > > that appeared electronically earlier today is a brief interview with > > this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > > > > The article is > > > > Last byte: Shaping the foundations of programming languages > > https://doi.org/10.1145/3460442 > > Comm. ACM 64(6), 120, 119, June 2021. > > > > and it includes a picture of the two winners sitting on Dennis > > Ritchie's couch. > > > > I liked this snippet from Jeff Ullman, praising fellow list member > > Steve Johnson's landmark program, yacc: > > > > >> ... > > >> At the time of the first Fortran compiler, it took several > > >> person-years to write a parser. By the time yacc came around, > > >> you could do it in an afternoon. > > >> ... > > > > > > ------------------------------------------------------------------------------- > > - 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 at math.utah.edu - > > - 155 S 1400 E RM 233 beebe at acm.org > > beebe at computer.org - > > - Salt Lake City, UT 84112-0090, USA URL: > > http://www.math.utah.edu/~beebe/ - > > > > ------------------------------------------------------------------------------- > > From bakul at iitbombay.org Wed May 26 16:20:41 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 25 May 2021 23:20:41 -0700 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: <20210526030341.GD27558@mcvoy.com> References: <20210526030341.GD27558@mcvoy.com> Message-ID: <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> Many existing programming languages do have a simple enough syntax to make it easy to write a recursive descent parser for them but not alll. Handwritten recursive descent parsers are often LL(1) with may be a separate operator-precedence parsing for expressions. If you are defining a new language syntax you can make sure parsing is easy but not all languages are LL(1) (which is a subset of LALR(1), which is a subset of LR(1), which is a subset of GLR). Handwritten parsers for these more general grammars are bound to get more complicated. Even *we* understand parsing, writing a parser for some existing languages which grew "organically" can become tedious, or complicated or adhoc. Often such languages have no well specified grammar (the code is the specification!). A yacc grammar would help. Often one writes a yacc grammar while a new language & its syntax is evolving. Changing a yacc file is more localized & easier than fixing up a handwritten parser. Even Go has such a grammar initially. -- Bakul > On May 25, 2021, at 8:03 PM, Larry McVoy wrote: > > You do, I don't. I'm not alone in my lack of understanding. > > I think that all the things that yacc solved, Steve gets some kudos. > I've used it a bunch and I did not need to be as smart as you or > Steve to get the job done. > > You getting past that is cool but it doesn't make his work less. > > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote: >> And today, we understand parsing so well we don't need yacc. >> >> -rob >> >> >> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe >> wrote: >> >>> The last article of the latest issue of the Communications of the ACM >>> that appeared electronically earlier today is a brief interview with >>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman. >>> >>> The article is >>> >>> Last byte: Shaping the foundations of programming languages >>> https://doi.org/10.1145/3460442 >>> Comm. ACM 64(6), 120, 119, June 2021. >>> >>> and it includes a picture of the two winners sitting on Dennis >>> Ritchie's couch. >>> >>> I liked this snippet from Jeff Ullman, praising fellow list member >>> Steve Johnson's landmark program, yacc: >>> >>>>> ... >>>>> At the time of the first Fortran compiler, it took several >>>>> person-years to write a parser. By the time yacc came around, >>>>> you could do it in an afternoon. >>>>> ... >>> >>> >>> ------------------------------------------------------------------------------- >>> - 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 at math.utah.edu - >>> - 155 S 1400 E RM 233 beebe at acm.org >>> beebe at computer.org - >>> - Salt Lake City, UT 84112-0090, USA URL: >>> http://www.math.utah.edu/~beebe/ - >>> >>> ------------------------------------------------------------------------------- >>> > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lars at nocrew.org Wed May 26 16:06:16 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 26 May 2021 06:06:16 +0000 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> (Jason Stevens's message of "Wed, 26 May 2021 09:12:01 +0800") References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> Message-ID: <7w35uaghbb.fsf@junk.nocrew.org> Jason Stevens wrote: > If I had the time/knowledge a 64bit hosted copy of GCC 1.42 would be > cool but I think I may be the only one interested in compiling old > Linux/BSD stuff with the original tools on newer (and alien) > platforms. I understand your pain. I tried to foward port GNU Emacs 16. I got it somewhat limping along, but it really wants to live in its natural 4.2BSD-ish habitat. From robpike at gmail.com Wed May 26 16:52:43 2021 From: robpike at gmail.com (Rob Pike) Date: Wed, 26 May 2021 16:52:43 +1000 Subject: [TUHS] [tuhs] Dennis Ritchie's couch In-Reply-To: <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> References: <20210526030341.GD27558@mcvoy.com> <2834EEEA-1C32-461B-900B-7480CCC4399B@iitbombay.org> Message-ID: I enjoy writing recursive descent parsers, and I enjoy the grammars that result from such parsers when cleanly done. I do agree though that if you grammar is being invented as you go, yacc can be a boon. But in a sense, that's also it's biggest failing: it makes it too easy to write bad grammars. -rob On Wed, May 26, 2021 at 4:22 PM Bakul Shah wrote: > Many existing programming languages do have a simple enough > syntax to make it easy to write a recursive descent parser for them > but not alll. > > Handwritten recursive descent parsers are often LL(1) with may be > a separate operator-precedence parsing for expressions. > > If you are defining a new language syntax you can make sure parsing > is easy but not all languages are LL(1) (which is a subset of LALR(1), > which is a subset of LR(1), which is a subset of GLR). Handwritten > parsers for these more general grammars are bound to get more > complicated. > > Even *we* understand parsing, writing a parser for some existing > languages which grew "organically" can become tedious, or > complicated or adhoc. Often such languages have no well specified > grammar (the code is the specification!). A yacc grammar would help. > > Often one writes a yacc grammar while a new language & its syntax > is evolving. Changing a yacc file is more localized & easier than fixing > up a handwritten parser. Even Go has such a grammar initially. > > -- Bakul > > > On May 25, 2021, at 8:03 PM, Larry McVoy wrote: > > > > You do, I don't. I'm not alone in my lack of understanding. > > > > I think that all the things that yacc solved, Steve gets some kudos. > > I've used it a bunch and I did not need to be as smart as you or > > Steve to get the job done. > > > > You getting past that is cool but it doesn't make his work less. > > > > On Wed, May 26, 2021 at 10:37:45AM +1000, Rob Pike wrote: > >> And today, we understand parsing so well we don't need yacc. > >> > >> -rob > >> > >> > >> On Wed, May 26, 2021 at 10:20 AM Nelson H. F. Beebe < > beebe at math.utah.edu> > >> wrote: > >> > >>> The last article of the latest issue of the Communications of the ACM > >>> that appeared electronically earlier today is a brief interview with > >>> this year's ACM Turing Award winners, Al Aho and Jeff Ullman. > >>> > >>> The article is > >>> > >>> Last byte: Shaping the foundations of programming languages > >>> https://doi.org/10.1145/3460442 > >>> Comm. ACM 64(6), 120, 119, June 2021. > >>> > >>> and it includes a picture of the two winners sitting on Dennis > >>> Ritchie's couch. > >>> > >>> I liked this snippet from Jeff Ullman, praising fellow list member > >>> Steve Johnson's landmark program, yacc: > >>> > >>>>> ... > >>>>> At the time of the first Fortran compiler, it took several > >>>>> person-years to write a parser. By the time yacc came around, > >>>>> you could do it in an afternoon. > >>>>> ... > >>> > >>> > >>> > ------------------------------------------------------------------------------- > >>> - 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 at math.utah.edu - > >>> - 155 S 1400 E RM 233 beebe at acm.org > >>> beebe at computer.org - > >>> - Salt Lake City, UT 84112-0090, USA URL: > >>> http://www.math.utah.edu/~beebe/ - > >>> > >>> > ------------------------------------------------------------------------------- > >>> > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed May 26 17:03:21 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 26 May 2021 15:03:21 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <7w35uaghbb.fsf@junk.nocrew.org> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> Message-ID: <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> I know I’m going to probably regret this but have you tried 4.3BSD Tahoe? Not that im looking for an excuse to push more Mach 2.6 onto the world… From: Lars Brinkhoff Sent: Wednesday, 26 May 2021 2:29 pm To: Jason Stevens Cc: Sean Dwyer; tuhs at minnie.tuhs.org Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks Jason Stevens wrote: > If I had the time/knowledge a 64bit hosted copy of GCC 1.42 would be > cool but I think I may be the only one interested in compiling old > Linux/BSD stuff with the original tools on newer (and alien) > platforms. I understand your pain. I tried to foward port GNU Emacs 16. I got it somewhat limping along, but it really wants to live in its natural 4.2BSD-ish habitat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed May 26 17:37:48 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 26 May 2021 07:37:48 +0000 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> (Jason Stevens's message of "Wed, 26 May 2021 15:03:21 +0800") References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> Message-ID: <7wsg2aeyib.fsf@junk.nocrew.org> Jason Stevens writes: > I know I’m going to probably regret this but have you tried 4.3BSD > Tahoe? No, but I'd like to see it run on a Tahoe (emulator). Maybe my vote for one of the most well known machines (due to BSD) that has seemingly completely dissapeared off the face of the earth. Happy to be proved wrong. From jsteve at superglobalmegacorp.com Wed May 26 17:45:00 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 26 May 2021 15:45:00 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <7wsg2aeyib.fsf@junk.nocrew.org> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> Message-ID: <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> It took me years of on and off to finally figure out what the heck a Tahoe even was. Spoiler for anyone who wasn’t there when it happened it’s a Harris HCX-9. The config file has this snippet: GENERIC POWER 6/32 (HCX9) With other bits that fit the bill in the source. With that said I don’t think there is any system ROM or firmware dumps or did it use a writeable control store? But then again there is some movement on an RT emulator and there is the 3b2 stuff so maybe there only needs to be a ‘push’… I’m far too novice for that kind of thing. From: Lars Brinkhoff Sent: Wednesday, 26 May 2021 4:00 pm To: Jason Stevens Cc: Sean Dwyer; tuhs at minnie.tuhs.org Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks Jason Stevens writes: > I know I’m going to probably regret this but have you tried 4.3BSD > Tahoe? No, but I'd like to see it run on a Tahoe (emulator). Maybe my vote for one of the most well known machines (due to BSD) that has seemingly completely dissapeared off the face of the earth. Happy to be proved wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed May 26 17:51:09 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 26 May 2021 01:51:09 -0600 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> Message-ID: <202105260751.14Q7p90j010926@freefriends.org> The Tahoe was a CISC machine, different from both the RT and the 3B2. Those emulators might be useful as examples of how to write an emulator, but they won't help you to boot any code. I think there were several companies that sold Tahoe architecture machines, but I don't remember any more. Arnold Jason Stevens wrote: > It took me years of on and off to finally figure out what the heck a Tahoe even was. > > Spoiler for anyone who wasn’t there when it happened it’s a Harris HCX-9. > > The config file has this snippet: > > GENERIC POWER 6/32 (HCX9) > With other bits that fit the bill in the source. With that said I don’t think there is any system ROM or firmware dumps or did it use a writeable control store? > > But then again there is some movement on an RT emulator and there is the 3b2 stuff so maybe there only needs to be a ‘push’… > > I’m far too novice for that kind of thing. > > From: Lars Brinkhoff > Sent: Wednesday, 26 May 2021 4:00 pm > To: Jason Stevens > Cc: Sean Dwyer; tuhs at minnie.tuhs.org > Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks > > Jason Stevens writes: > > I know I’m going to probably regret this but have you tried 4.3BSD > > Tahoe? > > No, but I'd like to see it run on a Tahoe (emulator). Maybe my vote for > one of the most well known machines (due to BSD) that has seemingly > completely dissapeared off the face of the earth. Happy to be proved > wrong. > From lars at nocrew.org Wed May 26 17:56:31 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 26 May 2021 07:56:31 +0000 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> (Jason Stevens's message of "Wed, 26 May 2021 15:45:00 +0800") References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> Message-ID: <7wo8cyexn4.fsf@junk.nocrew.org> Jason Stevens wrote: > It took me years of on and off to finally figure out what the heck a > Tahoe even was. Spoiler for anyone who wasn’t there when it happened > it’s a Harris HCX-9. > > But then again there is some movement on an RT emulator and there is > the 3b2 stuff so maybe there only needs to be a ‘push’… Is there even a single shread of documentation though? It's a daunting task trying to write an emulator based only on inferring the internal workings of the machine from 4.3BSD source code. Mind, the end result wouldn't be too interesting; hey it works... just like a VAX. From aek at bitsavers.org Thu May 27 00:06:22 2021 From: aek at bitsavers.org (Al Kossow) Date: Wed, 26 May 2021 07:06:22 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> Message-ID: On 5/26/21 12:45 AM, Jason Stevens wrote: > GENERIC POWER 6/32 (HCX9) > > With other bits that fit the bill in the source.  With that said I don’t think there is any system ROM or firmware dumps or did it use a > writeable control store? > > But then again there is some movement on an RT emulator and there is the 3b2 stuff so maybe there only needs to be a ‘push’… > Harris, Unisys and others OEMed it from CCI https://en.wikipedia.org/wiki/Computer_Consoles_Inc. It is probably a lost architecture now like Pyramid and to some extent Ridge because the vendor never released architecture or service documentation. I managed to save one Ridge-32, docs and software. From lm at mcvoy.com Thu May 27 00:25:54 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 26 May 2021 07:25:54 -0700 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> Message-ID: <20210526142554.GA32396@mcvoy.com> On Wed, May 26, 2021 at 07:06:22AM -0700, Al Kossow wrote: > On 5/26/21 12:45 AM, Jason Stevens wrote: > > >GENERIC POWER 6/32 (HCX9) > > > >With other bits that fit the bill in the source.?? With that said I > >don???t think there is any system ROM or firmware dumps or did it use a > >writeable control store? > > > >But then again there is some movement on an RT emulator and there is the 3b2 stuff so maybe there only needs to be a ???push?????? > > > > Harris, Unisys and others OEMed it from CCI > https://en.wikipedia.org/wiki/Computer_Consoles_Inc. > > > It is probably a lost architecture now like Pyramid and to some extent Ridge > because the vendor never released architecture or service documentation. > > I managed to save one Ridge-32, docs and software. My wife worked at Ridge, if there is any interest in that machine I can see if she can dig something up. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Thu May 27 00:57:12 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 26 May 2021 10:57:12 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> Message-ID: On Wed, May 26, 2021 at 3:45 AM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > It took me years of on and off to finally figure out what the heck a Tahoe > even was. > > > > Spoiler for anyone who wasn’t there when it happened it’s a Harris HCX-9. > Hmm - that may be a private label from Harris, but the Tahoe was the development name for the CCI Power 6/32 machine from Rochester, NY. There had been some level of desire by the Arpa steering committee to have CSRG work with something other than DEC as a reference. Since Bill had gone to Sun by then (from the outside looking at that point) there seemed like there was concern about looking too friendly to anyone manufacturer such as Sun to an extent has CSRG had been with DEC. What I don't know is if CSRG picked it or the Steering Committee did, I would >>guess<< the later. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu May 27 00:58:44 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 26 May 2021 10:58:44 -0400 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: <7wo8cyexn4.fsf@junk.nocrew.org> References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> <7wo8cyexn4.fsf@junk.nocrew.org> Message-ID: Really good point -- I saw some years ago, but never owned a copy. ᐧ On Wed, May 26, 2021 at 3:57 AM Lars Brinkhoff wrote: > Jason Stevens wrote: > > It took me years of on and off to finally figure out what the heck a > > Tahoe even was. Spoiler for anyone who wasn’t there when it happened > > it’s a Harris HCX-9. > > > > But then again there is some movement on an RT emulator and there is > > the 3b2 stuff so maybe there only needs to be a ‘push’… > > Is there even a single shread of documentation though? It's a daunting > task trying to write an emulator based only on inferring the internal > workings of the machine from 4.3BSD source code. Mind, the end result > wouldn't be too interesting; hey it works... just like a VAX. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Thu May 27 04:12:22 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 27 May 2021 02:12:22 +0800 Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: References: <4fabd785-3763-d100-b97d-0a0a7377b833@spamtrap.tnetconsulting.net> <82114c60-2abd-4688-8bc1-444e32db257f@PU1APC01FT031.eop-APC01.prod.protection.outlook.com> <7w35uaghbb.fsf@junk.nocrew.org> <1c69effb-49bb-4ef6-aa5e-e10d667c94bc@PU1APC01FT051.eop-APC01.prod.protection.outlook.com> <7wsg2aeyib.fsf@junk.nocrew.org> <326daa73-ef29-49f7-ac63-c690ddfb73fc@PU1APC01FT023.eop-APC01.prod.protection.outlook.com> <7wo8cyexn4.fsf@junk.nocrew.org> Message-ID: In the CSRG DVD set there is some cci ports of 4.2BSD… stuff is #ifdef’d Tahoe in there so it’s not hard to pick out but it doesn’t seem to have anything really documents looking. I could be 100% wrong though, but they just look like ‘clean’ source trees. Not sure if sanitized though. The assembler shows 182 opcodes … /* * Boot program... arguments passed in r10 and r11 determine * whether boot stops to ask for system name and which device * boot comes from. */ /* r11 = 0 -> automatic boot, load file '/vmunix' */ /* r11 = 1 -> ask user for file to load */ The stand/boot sounds awefully vax like with r10/r11… From: Clem Cole Sent: Wednesday, 26 May 2021 11:22 pm To: Lars Brinkhoff Cc: Jason Stevens; tuhs at minnie.tuhs.org Subject: Re: [TUHS] H.J. Lu Bootable Root & Base System disks Really good point -- I saw some years ago, but never owned a copy. ᐧ On Wed, May 26, 2021 at 3:57 AM Lars Brinkhoff wrote: Jason Stevens wrote: > It took me years of on and off to finally figure out what the heck a > Tahoe even was.  Spoiler for anyone who wasn’t there when it happened > it’s a Harris HCX-9. > > But then again there is some movement on an RT emulator and there is > the 3b2 stuff so maybe there only needs to be a ‘push’… Is there even a single shread of documentation though?  It's a daunting task trying to write an emulator based only on inferring the internal workings of the machine from 4.3BSD source code.  Mind, the end result wouldn't be too interesting; hey it works... just like a VAX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Thu May 27 09:29:26 2021 From: torek at elf.torek.net (Chris Torek) Date: Wed, 26 May 2021 16:29:26 -0700 (PDT) Subject: [TUHS] H.J. Lu Bootable Root & Base System disks In-Reply-To: Message-ID: <202105262329.14QNTQEM057694@elf.torek.net> >The stand/boot sounds awefully vax like with r10/r11 The CSRG folks at the time joked that the Tahoe (CCI) was a "RISC": a Reused Instruction Set Computer. A lot of the opcodes were the same as the VAX except that they were nybble-swapped! Chris From pnr at planet.nl Mon May 31 06:34:07 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 30 May 2021 22:34:07 +0200 Subject: [TUHS] Early Unix paging Message-ID: <7766607B-92C8-486C-888F-E542F3BD4609@planet.nl> 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.