From clemc at ccc.com Wed Oct 1 00:32:57 2014 From: clemc at ccc.com (Clem Cole) Date: Tue, 30 Sep 2014 10:32:57 -0400 Subject: [TUHS] TMG and B In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: ​amen​ On Tue, Sep 30, 2014 at 9:52 AM, Noel Chiappa wrote: > I said something to the effect of 'clearly I've lived > through a second golden age, and only now am I understanding that'. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Oct 1 03:44:37 2014 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 1 Oct 2014 03:44:37 +1000 (EST) Subject: [TUHS] TMG and B In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: On Tue, 30 Sep 2014, Noel Chiappa wrote: > And of course the networking work soon sucked me in completely. In that > message to Jerry, I said something to the effect of 'clearly I've lived > through a second golden age, and only now am I understanding that'. Please, people; keep these stories up! TUHS == The Unix Historical Society (ignore my own name for it; I'm in Oz). -- Dave From cowan at mercury.ccil.org Wed Oct 1 06:08:21 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 30 Sep 2014 16:08:21 -0400 Subject: [TUHS] TMG and B In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: <20140930200821.GN22934@mercury.ccil.org> Noel Chiappa scripsit: > And of course the networking work soon sucked me in completely. In that > message to Jerry, I said something to the effect of 'clearly I've lived > through a second golden age, and only now am I understanding that'. "What is the Golden Age of science fiction?" "Twelve." --Peter Graham -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org The experiences of the past show that there has always been a discrepancy between plans and performance. --Emperor Hirohito, August 1945 From spedraja at gmail.com Wed Oct 1 07:07:51 2014 From: spedraja at gmail.com (SPC) Date: Tue, 30 Sep 2014 23:07:51 +0200 Subject: [TUHS] TMG and B In-Reply-To: <20140930200821.GN22934@mercury.ccil.org> References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> <20140930200821.GN22934@mercury.ccil.org> Message-ID: A beautiful discussión. Thanks everybody. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations ​ -- *Sergio Pedraja* -- mobile: +34-699-996568 twitter: @sergio_pedraja | skype: Sergio Pedraja -- http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://www.quora.com/Sergio-Pedraja http://spedraja.wordpress.com https://www.xing.com/profile/Sergio_Pedraja ----- No crea todo lo que ve, ni crea que está viéndolo todo 2014-09-30 22:08 GMT+02:00 John Cowan : > Noel Chiappa scripsit: > > > And of course the networking work soon sucked me in completely. In that > > message to Jerry, I said something to the effect of 'clearly I've lived > > through a second golden age, and only now am I understanding that'. > > "What is the Golden Age of science fiction?" > > "Twelve." > > --Peter Graham > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > The experiences of the past show that there has always been a discrepancy > between plans and performance. --Emperor Hirohito, August 1945 > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Oct 1 07:15:46 2014 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 1 Oct 2014 07:15:46 +1000 (EST) Subject: [TUHS] TMG and B In-Reply-To: References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> <20140930200821.GN22934@mercury.ccil.org> Message-ID: On Tue, 30 Sep 2014, SPC wrote: > A beautiful discussión. Thanks everybody. The best bit (which I've saved somewhere) is that needing a PL/I compiler *for* TMG, they wrote such a compiler *in* TMG... Talk about boot-strapping... -- Dave From dave at horsfall.org Wed Oct 1 07:26:18 2014 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 1 Oct 2014 07:26:18 +1000 (EST) Subject: [TUHS] TMG and B In-Reply-To: References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do I have to find a CDC/PDP-7 emulator first? :-) -- Dave From random832 at fastmail.us Wed Oct 1 08:13:39 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Tue, 30 Sep 2014 18:13:39 -0400 Subject: [TUHS] Fwd: [tz] Time, Clock, and Calendar Programming In C, by Eric S. Raymond Message-ID: <1412115219.3741374.173656693.20224E67@webmail.messagingengine.com> Eric S. Raymond has written an article about the history of the time.h functions at http://www.catb.org/esr/time-programming/ >From his blog post announcing it (http://esr.ibiblio.org/?p=6311): > The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that. > > Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries. > > What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator. When I saw it I thought it might be generally interesting to people who subscribe to this list. From cubexyz at gmail.com Wed Oct 1 08:52:01 2014 From: cubexyz at gmail.com (Mark Longridge) Date: Tue, 30 Sep 2014 18:52:01 -0400 Subject: [TUHS] TMG and B In-Reply-To: References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: >Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do > I have to find a CDC/PDP-7 emulator first? :-) > >-- Dave TMG is mentioned in the v3 manual: /sys/tmg/tmgl.o -- the compiler-compiler There's no files for it for v5 but it is in v6 and it seems to disappear after that. On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file. I did manage to get something running for pdp-7 on simh and got to the GA prompt. Didn't get it to do much beyond printing "CAB DECSYS7 COPY 15 JUNE 1966" Mark Mark On 9/30/14, Dave Horsfall wrote: > Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do > I have to find a CDC/PDP-7 emulator first? :-) > > -- Dave > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From doug at cs.dartmouth.edu Wed Oct 1 23:53:37 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 01 Oct 2014 09:53:37 -0400 Subject: [TUHS] TMG and B Message-ID: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu> TMG was in v2-v6, sometimes in man1 and sometimes in man6. I have an apparently complete source listing. The year is uncertain. (Back then date headings from pr didn't mention the year!) The accompanying manual, though, is dated 1972. There is also, besides the TMGL definition of TMGL, a TMGL definition of pig Latin as a simple test case. None of this is useful, though, without a PDP-11 binary for tmg-- the usual chicken-and-egg problem with a full-blown compiler written in its own language. Doug > >Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do > > I have to find a CDC/PDP-7 emulator first? :-) > > > >-- Dave > > TMG is mentioned in the v3 manual: > > /sys/tmg/tmgl.o -- the compiler-compiler > > There's no files for it for v5 but it is in v6 and it seems to > disappear after that. > On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file. > > I did manage to get something running for pdp-7 on simh and got to the > GA prompt. > Didn't get it to do much beyond printing "CAB DECSYS7 COPY 15 JUNE 1966" > > Mark From jnc at mercury.lcs.mit.edu Thu Oct 2 00:04:23 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Oct 2014 10:04:23 -0400 (EDT) Subject: [TUHS] TMG and B Message-ID: <20141001140423.D047418C10D@mercury.lcs.mit.edu> > From: Doug McIlroy > None of this is useful, though, without a PDP-11 binary for tmg There seems to be be binary for TMG on the V6 distribution. Noel From dave at horsfall.org Thu Oct 2 06:23:14 2014 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 2 Oct 2014 06:23:14 +1000 (EST) Subject: [TUHS] TMG and B In-Reply-To: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu> References: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu> Message-ID: On Wed, 1 Oct 2014, Doug McIlroy wrote: > None of this is useful, though, without a PDP-11 binary for tmg-- the > usual chicken-and-egg problem with a full-blown compiler written in its > own language. Hmmm... I haven't used YACC for many years (not since my CompSci days, when I was considering a Pascal->C translator for my thesis; I had threatened to write it in SNOBOL) so if a suitable rainy day comes along (and I can get the manpage etc) I might give it a stab. -- Dave From dave at horsfall.org Thu Oct 2 06:33:18 2014 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 2 Oct 2014 06:33:18 +1000 (EST) Subject: [TUHS] TMG and B In-Reply-To: References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu> Message-ID: On Tue, 30 Sep 2014, Mark Longridge wrote: > On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file. Hmmm... It *almost* makes sense, to someone who has never seen TMG before. -- Dave From wkt at tuhs.org Thu Oct 2 21:46:26 2014 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 2 Oct 2014 21:46:26 +1000 Subject: [TUHS] made up errno contest, at an early USENIX In-Reply-To: <201409271919.s8RJJwPx019024@skeeve.com> References: <201409271919.s8RJJwPx019024@skeeve.com> Message-ID: <20141002114626.GA548@www.oztivo.net> On Sat, Sep 27, 2014 at 10:19:58PM +0300, Aharon Robbins wrote: > This is really gonna stretch the memories. (I may have even asked about > it on this list before.) > At one of the earlier USENIX conferences that I attended, maybe in > Atlanta, there was a contest to make up humorous new errno values. I'm back from a trip to Cania Gorge in Queensland Australia where there is next to no phone reception. When I scanned in the old AUUG newsletters, I told the photocopier to also do OCR. This means that I can do this to the scanned files: for i in *.pdf do j=`echo $i | sed 's/pdf/txt/'` echo $j pdftotext $i grep ENO $j rm $j done Yet another reason why Unix is so much better :-) Here are the results which will help Arnold out with his question. Cheers, Warren http://minnie.tuhs.org/Archive/Documentation/AUUGN/ AUUGN-V07.23.txt ENOTOBACCO ENOHORSE ENONSEQUITUR AUUGN-V07.45.txt ENOINSTRUCTIONSET ENOSTD ENOP ENOTON UNIX ENOVAX ENOFOOT ENOCOFFEE ENOLICENCE ENOLICENSE ENOTUNIX ENOMONEYNOFUN ENOTFOUND ENOALCHOHOL ENOJOY ENOBAR ENOTOBACCO AUUGN-V08.34.txt ENOTABACCO, read on an empty pipe? ENOGOOD ENOWARP ENOTHEAVY ENOUGH ENOTONHORSE ENOPHONEBOOK ENOCONTEST ENOARMSCONTROL ENOSTRADAMUS ENOAIR ENOARMSCONTROL ENOBOZOS ENOCH ENOCHICKEN ENOCONTEST ENOCORN ENOCURRENT ENODICE ENOENO ENOENO ENOERROR ENOFLUID ENOGOOD ENOGREYHOUND ENOH20 ENOHOPE ENOKISS ENOKNOW ENOMAAM ENOMULTIHOP ENON ENONCOGNISCENT ENONO ENOONE ENOPAPER ENOPHONEBOOK ENORMOUS ENOSALT ENOSAUSAGE ENOSELECTRIC ENOSTRADAMUS ENOTATE ENOTCOMPLETE ENOTHEAVY ENOTME ENOTMYFAULT ENOTONHORSE ENOUGH ENOUGH ENOUGH ENOUGH ENOUNIX ENOV1CE ENOWARP ENOWA.Y AUUGN-V09.6.txt ENOTUNIX ENOTOBACCO From arnold at skeeve.com Thu Oct 2 22:12:21 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Oct 2014 06:12:21 -0600 Subject: [TUHS] made up errno contest, at an early USENIX In-Reply-To: <20141002114626.GA548@www.oztivo.net> References: <201409271919.s8RJJwPx019024@skeeve.com> <20141002114626.GA548@www.oztivo.net> Message-ID: <201410021212.s92CCL1L015109@freefriends.org> Hi Warren. Really cool. Can you grep for EMRED? (Doesn't match ENO). Thanks! Arnold Warren Toomey wrote: > On Sat, Sep 27, 2014 at 10:19:58PM +0300, Aharon Robbins wrote: > > This is really gonna stretch the memories. (I may have even asked about > > it on this list before.) > > At one of the earlier USENIX conferences that I attended, maybe in > > Atlanta, there was a contest to make up humorous new errno values. > > I'm back from a trip to Cania Gorge in Queensland Australia where there is > next to no phone reception. > > When I scanned in the old AUUG newsletters, I told the photocopier to also > do OCR. This means that I can do this to the scanned files: > > for i in *.pdf > do j=`echo $i | sed 's/pdf/txt/'` > echo $j > pdftotext $i > grep ENO $j > rm $j > done > > Yet another reason why Unix is so much better :-) Here are the results > which will help Arnold out with his question. > > Cheers, Warren > > http://minnie.tuhs.org/Archive/Documentation/AUUGN/ > > ... From norman at oclsc.org Thu Oct 2 23:00:34 2014 From: norman at oclsc.org (Norman Wilson) Date: Thu, 2 Oct 2014 09:00:34 -0400 (EDT) Subject: [TUHS] made up errno contest, at an early USENIX Message-ID: <20141002130034.2DDA71DE38C@lignose.oclsc.org> arnold at skeeve.com: Can you grep for EMRED? (Doesn't match ENO). ==== Why not grep for E[A-Z][A-Z]*? Norman Wilson Toronto ON From dwalker at doomd.net Fri Oct 3 00:52:25 2014 From: dwalker at doomd.net (Derrik Walker v2.0) Date: Thu, 02 Oct 2014 10:52:25 -0400 Subject: [TUHS] made up errno contest, at an early USENIX In-Reply-To: <20141002114626.GA548@www.oztivo.net> References: <201409271919.s8RJJwPx019024@skeeve.com> <20141002114626.GA548@www.oztivo.net> Message-ID: <542D66A9.9050903@doomd.net> On 10/2/14, 7:46, Warren Toomey wrote: > Yet another reason why Unix is so much better :-) UNIX is just better than just about anything when you have real work to get done. For example, we have a popular web log analyzer program ( that shall remain nameless ), that apparently is not very capable, because they frequently ask me to make custom reports. Naturally I use the UNIX tools available to that I know how to use ... And so I keep threatening to just re-write that application in AWK. - Derrik From wkt at tuhs.org Fri Oct 3 08:19:06 2014 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 3 Oct 2014 08:19:06 +1000 Subject: [TUHS] made up errno contest, at an early USENIX In-Reply-To: <201410021212.s92CCL1L015109@freefriends.org> References: <201409271919.s8RJJwPx019024@skeeve.com> <20141002114626.GA548@www.oztivo.net> <201410021212.s92CCL1L015109@freefriends.org> Message-ID: <20141002221906.GA7379@www.oztivo.net> On Thu, Oct 02, 2014 at 06:12:21AM -0600, arnold at skeeve.com wrote: > Hi Warren. > Really cool. > Can you grep for EMRED? (Doesn't match ENO). Results are: AUUGN-V07.23 and AUUGN-V08.34 which are in http://minnie.tuhs.org/Archive/Documentation/AUUGN/ Cheers, Warren From wkt at tuhs.org Fri Oct 3 12:45:14 2014 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 3 Oct 2014 12:45:14 +1000 Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine) Message-ID: <20141003024514.GA16961@www.oztivo.net> I just received a new TUHS subscription request along with an interesting query. Can anybody help Michael with his problem? Cheers, Warren ----- Forwarded message from "Engel, Michael" ----- Dear Warren, Could you please subscribe me to the TUHS mailing list? I haven't worked with old Unix systems for quite some time, but I was appointed as a Senior Lecturer at Leeds Beckett University (UK) two months ago and - to my big surprise - I found an old Unix machine collecting dust in a corner.. The machine is a Codata 300, a Multibus-based system using a licensed clone of the original Sun 100U CPU board and a number of additional Multibus controllers. The machine seems to be complete, including two 8" SMD disks and a Cipher 9-track tape drive, we also seem to have a set of replacement boards and the CPU board manual (including schematics and code snippets explaining how to access the onboard devices - some Codata documentation can also be found on bitkeeper). We haven't tried to power up the machine yet (and, built around 1983, it certainly needs a close examination of the power supply and capacitors). From information on the net, this machine runs a Unisoft port of 7th Edition Unix - similar to the Sun 1 machines and probably a Whitesmiths C compiler (there's a Whitesmiths license badge attached to the case). Definitely a very interesting and probably quite rare machine and we would like to revive it (and, if things go well, create a FPGA reimplementation of the system in the context of a student design project). Now, I would love to know more details about the implementation of 7th Edition Unix on the 68000 and the use of the custom MMU built out of fast SRAM and TTL logic. I do not think that source code to any of the various 68k 7th Edition ports produced by Unisoft is available somewhere - do you know of a possible source? Alternatively, do you think it would be worthwhile asking Unisoft for the source code or do you know if anyone has tried this already? According to the Unisoft history web page (http://www.unisoft.com/history.html), they still seem to know that they were porting Unix 30 years ago... The only remotely related source code I could find in my archives is the A/UX 0.7 source (SVR2, if I'm not mistaken), which probably already required a 68020 with 68851 MMU. Best regards, Michael Engel ----- End forwarded message ----- From wkt at tuhs.org Fri Oct 3 13:36:32 2014 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 3 Oct 2014 13:36:32 +1000 Subject: [TUHS] 2.9bsd on 11/45 restoration Message-ID: <20141003033632.GD18537@www.oztivo.net> Also, I had this e-mail sent to me from Jacob who is a long-time TUHS person. Again, he has questions I don't know the answers to. Anybody? Cheers, Warren ----- Forwarded message from Jacob Ritorto ----- Greetings Warren,  It's been decades since we last corresponded and I'm delighted to see that you're still active in the pdp11 unix community! I've found some free time and have been kicking around the idea of repairing the11/45 I scored some years ago (11/45 system number 273 from Stanford University) and installing 2.9bsd on it. You helped me out years ago when I had an 11/34 and I managed to do it back then, so I have some hope this time around too, though there are some more serious hurdles now. Glad to see that a lot of the license trolling finally appears to be settled and we can have unfettered access to all the good stuff!   Any pointers to who has parts and troubleshooting knowledge would be a big help.  Softwarewise, I was also thinking I'd like to get my Fuji160 disks working on the machine. Has work like this been done already, or would you have pointers as to how to go about it?   Also, has anyone written a miniature httpd for any of the ancient bsds? thanks jake ----- End forwarded message ----- From arnold at skeeve.com Fri Oct 3 19:24:02 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 03 Oct 2014 03:24:02 -0600 Subject: [TUHS] made up errno contest, at an early USENIX In-Reply-To: <20141002221906.GA7379@www.oztivo.net> References: <201409271919.s8RJJwPx019024@skeeve.com> <20141002114626.GA548@www.oztivo.net> <201410021212.s92CCL1L015109@freefriends.org> <20141002221906.GA7379@www.oztivo.net> Message-ID: <201410030924.s939O2Rl027337@freefriends.org> Warren Toomey wrote: > On Thu, Oct 02, 2014 at 06:12:21AM -0600, arnold at skeeve.com wrote: > > Hi Warren. > > Really cool. > > Can you grep for EMRED? (Doesn't match ENO). > > Results are: AUUGN-V07.23 and AUUGN-V08.34 which are in > http://minnie.tuhs.org/Archive/Documentation/AUUGN/ > > Cheers, Warren Much thanks! Arnold From steve at quintile.net Sat Oct 4 05:03:15 2014 From: steve at quintile.net (Steve Simon) Date: Fri, 3 Oct 2014 20:03:15 +0100 Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine) Message-ID: <94465b124eb0b546811ba9c04caf37d2@quintile.net> > The machine is a Codata 300 Wow. I went to Leeds Poly (as it was then) in the mid 1980s. There where two Codatas in the electronics dept., one in its original plastic case and one 19inch rackmount - built as a IEEE 488 controller; I assume what you have is one of those. The former machine was loaded with Whitesmiths cross compilers and I learnt z80 assembly language on it ☺ It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer 3210, the main electronics teaching machine. If it is this machine then it should have the V7 source from the 3210 (Xelos as it was called) and the source for the drivers for the codata (which we gained by "accident"). I may be able to remember some other snippets - contat me off-list with specific questions. I can give you the names of the lecturers who would know most about it but I guess they are now retired (though they may still be Headingly somwhere). (fondly remembers Leeds). -Steve From M.Engel at leedsbeckett.ac.uk Sat Oct 4 06:23:46 2014 From: M.Engel at leedsbeckett.ac.uk (Engel, Michael) Date: Fri, 3 Oct 2014 20:23:46 +0000 Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine) In-Reply-To: <94465b124eb0b546811ba9c04caf37d2@quintile.net> References: <94465b124eb0b546811ba9c04caf37d2@quintile.net> Message-ID: <3C89F8B8-AE41-426B-80EF-1438FCCEAA7F@leedsmet.ac.uk> Hi Steve, whow, what a small world! On 03 Oct 2014, at 20:03, Steve Simon wrote: >> The machine is a Codata 300 > > Wow. > > I went to Leeds Poly (as it was then) in the mid 1980s. > > There where two Codatas in the electronics dept., one in its > original plastic case and one 19inch rackmount - built as a > IEEE 488 controller; I assume what you have is one of those. The machines were a bit cannibalised over the last decades, we actually have the boards from both machines, one of them build into the 19" rack machine. The machine survived the closing down of the electronics department, now we're busy building everything up again... > The former machine was loaded with Whitesmiths cross compilers > and I learnt z80 assembly language on it ☺ There's still a Whitesmiths logo attached to the case - this is what the machine looks like today: http://multicores.org/Codata.jpg A 5.25" ST412 disk, two 8" SMD disks and a Cypher 9 track tape are also still there. > It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer > 3210, the main electronics teaching machine. If it is this > machine then it should have the V7 source from the 3210 (Xelos > as it was called) and the source for the drivers for the > codata (which we gained by "accident"). Whow, let's keep our fingers crossed that the disks still work... I haven't tried powering the machine up so far. Unfortunately, the Interdata no longer exists (what a pity), but the first thing I will do when the machine is running is to run a full backup. Luckily, the Codata has a 5.25" floppy drive, since I no longer have easy access to a 9-track SCSI drive (and the last time I set up UUCP is far too long ago...). > I may be able to remember some other snippets - contat me > off-list with specific questions. I can give you the names > of the lecturers who would know most about it but I guess they > are now retired (though they may still be Headingly somwhere). Actually, quite a number of the people are still here. More off-list. > (fondly remembers Leeds). I only came to Leeds about two months ago - and so far, it's really great here! Best wishes, Michael From fair at netbsd.org Fri Oct 3 14:02:31 2014 From: fair at netbsd.org (Erik Fair) Date: Thu, 2 Oct 2014 21:02:31 -0700 Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine) In-Reply-To: <20141003024514.GA16961@www.oztivo.net> References: <20141003024514.GA16961@www.oztivo.net> Message-ID: I recently sent the following message to port-m68k at netbsd.org that relates to that period in time: Begin forwarded message: > From: Erik Fair > Subject: DUAL Systems documentation > Date: February 22, 2014 at 02:12:17 PST > To: port-m68k at netbsd.org > > For those of you of a historical or digital archeological bent: while googling for something else, I came across this URL: > > http://www.hartetechnologies.com/manuals/DUAL/ > > which contains PDFs of a few manuals & a price list from DUAL Systems of Berkeley, CA. DUAL produced the very first mc68000-based UNIX system (V7 UNIX on the S-100 (IEEE-696) bus), starting in November of 1981. I worked there as a UNIX systems programmer (kernel hacker) as my first job out of U.C. Berkeley from March 1983 to May 1985. > > Of particular interest to this group: the CPU/MMU board manual. Please note: the mc68000 could not demand-page (i.e. no virtual memory) because the CPU did not save enough state from a memory access fault to restart the faulted instruction, so UNIX was a swapping OS (whole process in RAM, whole process out to swap area on disk if not enough RAM is available for whatever else needed to run). > > Motorola corrected the fault state save in the mc68010, which provided the ability to make a proper VM system ... except for the mc68451 MMU (yes, a discrete MMU chip, in a package every bit as big as the CPU) which had only 32 descriptor registers (translation table entries). Motorola's theory was that if you wanted more (as one might for a lots of smaller-sized pages), add more MMU chips to your CPU board. Unfortunately, that doesn't fly on a board size as small as allowed by the S-100 standard. They were working on a proper paged MMU (PMMU) chip to go along with the mc68020 (the first fully 32-bit (address & data) 68k family CPU), but it was very, very late (DUAL was moving onto VMEbus from S-100 for the mc68020). > > An aside, before Motorola shipped the mc68010, I saw another solution to the faulted-instruction state save problem from MassComp: their CPU board had two mc68k CPUs on it, one running a cycle behind the other, so a page fault would stop them both, the missing page could be paged in (I think they designed their own MMU; long since forgotten), and then execution resumed on the second, following CPU which hadn't taken the memory-access fault. Throw hardware at the problem ... > > faulting my way down memory lane, > > Erik > formerly {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair UniSoft Systems was started by Jeff Schriebman at the behest of Dual to port V7 UNIX to Dual’s system; they were just a few blocks away from Dual in west Berkeley, on 6th Street, if memory serves. CoData was one of Dual’s competitors - I usually saw their gear at vendor shows (e.g. when /usr/group held its vendor show co-located with USENIX conferences). One of the problems at the time that bedeviled UniSoft was that every 68k-based Unix box had its own unique MMU because Motorola’s offerings in that space (as noted above) were … lacking. So UniSoft had to redo the kernel MMU code for every strange and wonderful MMU that each hardware vendor came up with. Pixel, Plexus, Fortune, Codata, Apple (yes, UniSoft did a port of Unix to the Lisa and the awful 5MB “profile” drive on a parallel port (!!)), ... I have at least two old Dual boxes in my garage that I keep for sentimental reasons, but I have no idea what’s on those disks, or if they’ll even spin up after so long. They’re ST-506/419 interface 5.25 inch “winchester” drives; a forerunner of a sort of the IBM PC’s IDE. I wrote the drivers for the Morrow Designs (“ThinkerToys”) S-100 controller as my first project for Dual in March/April 1983. Previously, Dual was using 8-inch Memorex hard drives controlled by a CompuPro (nee “Godbout Electronics”) controller whose interface standard I don’t recall. I’ll have to see if they can be fired up again, and see what’s on the hard drives. Dual was very particular about using big, heavy linear power supplies in its systems as a matter of reliability, over the (to their mind) squirrelly switching power supplies that many of our competitors were using. The other way to go to get Unix going on that old Codata box would be a port of NetBSD/m68k - it supports a wide array of mc68k systems: http://www.netbsd.org/ports/#ports-by-cpu The trick would be writing the MMU code, and a booter that would work with whatever firmware Codata used back in the day. I had to work on Dual’s boot firmware from time to time, and I recall it being fairly simple (“find /unix and see if it’s a.out, load, and jump”), and usually the trick is to make a secondary booter that the system firmware will load (in whatever executable format the firmware will recognize) to then parse a modern ELF kernel from FFSv2. NetBSD continues to support a whole lot of pretty old hardware - we believe in portability. Erik From random832 at fastmail.us Sat Oct 4 18:06:08 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sat, 04 Oct 2014 04:06:08 -0400 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: <20141003033632.GD18537@www.oztivo.net> References: <20141003033632.GD18537@www.oztivo.net> Message-ID: <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com> On Thu, Oct 2, 2014, at 23:36, Warren Toomey wrote: > Also, I had this e-mail sent to me from Jacob who is a long-time TUHS > person. Again, he has questions I don't know the answers to. Anybody? > > Cheers, Warren > ----- Forwarded message from Jacob Ritorto ----- > ... >   Also, has anyone written a miniature httpd for any of the ancient > bsds? Seeing this question, I figured "it can't be that hard", and managed to get tinyhttpd http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD. Mostly just required K&R-ification, though I also had to fix some bugs in the way it uses buffers to get it to work at all. Normal GET requests work; The whole CGI thing I disabled because I couldn't get it to work reliably even on modern linux. Not actually tested, though - I couldn't get simh to emulate a network device. From jnc at mercury.lcs.mit.edu Sat Oct 4 22:19:01 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 4 Oct 2014 08:19:01 -0400 (EDT) Subject: [TUHS] 2.9bsd on 11/45 restoration Message-ID: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu> > From: Warren Toomey >> have been kicking around the idea of repairing the11/45 I scored some >> years ago (11/45 system number 273 from Stanford University) >> .. >> Any pointers to who has parts and troubleshooting knowledge would be a >> big help. Anyone seriously working on bringing old hardware back to life needs to get in touch with the Classic Computer Talk list: http://www.classiccmp.org/mailman/listinfo/cctalk A wealth of experience and knowledge on every conceivable topic involved in old hardware is available there, and people are very helpful. Noel From jnc at mercury.lcs.mit.edu Sat Oct 4 22:31:06 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 4 Oct 2014 08:31:06 -0400 (EDT) Subject: [TUHS] RL02 drives available Message-ID: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu> Some guy on eBay has a flock of RL02 drives available (in New York, USA) for a pretty reasonable price: http://www.ebay.com/itm/261288230510 I just bought a flock of them, and they are in very good condition. They were only recently withdrawn from service (at the FAA, so they were professionally maintained up until they went), and were properly prepared for moving (heads immobilized, _and_ the motor was locked down - very rare to see that last step, as is involves finding the right machine screws - or having saved them). They are late-production ones, too (looked, but couldn't find a date) - they have the anti-RFI/EMI 'finger' strips (the kind that make a pressure-loaded contact with the incoming connector shell), which I personally had never seen on any RL0x drives. Alas, they have no packs or terminators available, nor cables or slides (any more :-). But other than that, recommended. Noel From dave at horsfall.org Sun Oct 5 06:26:40 2014 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Oct 2014 07:26:40 +1100 (EST) Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu> References: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu> Message-ID: On Sat, 4 Oct 2014, Noel Chiappa wrote: > Anyone seriously working on bringing old hardware back to life needs to > get in touch with the Classic Computer Talk list: Is John Dodson on this list? He has an 11/70 in his house. -- Dave From dave at horsfall.org Sun Oct 5 06:36:44 2014 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Oct 2014 07:36:44 +1100 (EST) Subject: [TUHS] RL02 drives available In-Reply-To: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu> References: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu> Message-ID: On Sat, 4 Oct 2014, Noel Chiappa wrote: > They are late-production ones, too (looked, but couldn't find a date) - > they have the anti-RFI/EMI 'finger' strips (the kind that make a > pressure-loaded contact with the incoming connector shell), which I > personally had never seen on any RL0x drives. Ex-FAA? Airport radar? Those puppies are *powerful*. ObReminisce: Back in the 70s-80s, the University of NSW put its new computer centre on the top floor of a 14-floor building (they were afraid of student riots at the time[*]), within clear view of Sydney Airport; the windows were lined with mesh, and you could hear them *click* every time the radar swung around. [*] Ah yes, the top floor. The other reason was fear of flooding. One day, the air conditioning sprang a major leak, and this corrosive green liquid ended up all over the brand spanking new high-speed CDC card reader... -- Dave From random832 at fastmail.us Sun Oct 5 13:26:53 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sat, 04 Oct 2014 23:26:53 -0400 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: References: <20141003033632.GD18537@www.oztivo.net> <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com> Message-ID: <1412479613.72555.175236101.7727764C@webmail.messagingengine.com> On Sat, Oct 4, 2014, at 12:37, Jacob Ritorto wrote: > nice. may i see your difffs? > > On Sat, Oct 4, 2014 at 4:06 AM, wrote: > > > > Seeing this question, I figured "it can't be that hard", and managed to > > get tinyhttpd http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD. > > Mostly just required K&R-ification, though I also had to fix some bugs > > in the way it uses buffers to get it to work at all. Normal GET requests > > work; The whole CGI thing I disabled because I couldn't get it to work > > reliably even on modern linux. > > > > Not actually tested, though - I couldn't get simh to emulate a network > > device. Sure. Security note: the httpd itself doesn't appear to do anything about e.g. ".." in pathnames, and I didn't do anything about that. -------------- next part -------------- A non-text attachment was scrubbed... Name: tinyhttpd.diff Type: application/octet-stream Size: 12009 bytes Desc: not available URL: From random832 at fastmail.us Mon Oct 6 05:49:28 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sun, 05 Oct 2014 15:49:28 -0400 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: <1412538525.277114.175397473.12347280@webmail.messagingengine.com> References: <20141003033632.GD18537@www.oztivo.net> <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com> <1412479613.72555.175236101.7727764C@webmail.messagingengine.com> <1412538525.277114.175397473.12347280@webmail.messagingengine.com> Message-ID: <1412538568.277182.175397609.016E5931@webmail.messagingengine.com> On Sun, Oct 5, 2014, at 13:47, Jacob Ritorto wrote: > awesome, man, thanks. If I fork tinyhttpd on github, mind if I use 'em? > I'll attribute to you of course If ok, any license preference? I > usually > use MIT.. tinyhttpd itself is not mine and appears to be under the GPL. From bqt at update.uu.se Mon Oct 6 07:01:43 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 05 Oct 2014 23:01:43 +0200 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: References: Message-ID: <5431B1B7.1040303@update.uu.se> On 2014-10-05 03:00, Dave Horsfall wrote: > > On Sat, 4 Oct 2014, Noel Chiappa wrote: > >> >Anyone seriously working on bringing old hardware back to life needs to >> >get in touch with the Classic Computer Talk list: > Is John Dodson on this list? He has an 11/70 in his house. No idea. I occasionally scan cctalk, but most of the time don't bother. Too much noise and irrelevant or ignorant posts. However, unfortunately I don't have any better suggestions where to go if you are trying to restore old hardware and don't have enough knowledge. And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, including 11/70 systems. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From downing.nick at gmail.com Mon Oct 6 07:46:12 2014 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 6 Oct 2014 08:46:12 +1100 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: <5431B1B7.1040303@update.uu.se> References: <5431B1B7.1040303@update.uu.se> Message-ID: I had an 11/70 service manual as an ebook at one stage, it had full schematics etc, you also have access to various simulators to help you understand the programming interface so i can't see what other info you would need for your restoration, maybe you'd need help jerry rigging some setup to get an initial tape written to get u started? If you have any questions about the schematics or electrical troubleshooting I'm happy to help although I have never owned a physical pdp11... concepts are the same as any more modern system. cheers, Nick On 06/10/2014 8:08 AM, "Johnny Billquist" wrote: > On 2014-10-05 03:00, Dave Horsfall wrote: > >> >> On Sat, 4 Oct 2014, Noel Chiappa wrote: >> >> >Anyone seriously working on bringing old hardware back to life needs to >>> >get in touch with the Classic Computer Talk list: >>> >> Is John Dodson on this list? He has an 11/70 in his house. >> > > No idea. I occasionally scan cctalk, but most of the time don't bother. > Too much noise and irrelevant or ignorant posts. However, unfortunately I > don't have any better suggestions where to go if you are trying to restore > old hardware and don't have enough knowledge. > > And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, > including 11/70 systems. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: bqt at softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Mon Oct 6 08:49:10 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 06 Oct 2014 00:49:10 +0200 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: References: <5431B1B7.1040303@update.uu.se> Message-ID: <5431CAE6.9000703@update.uu.se> The 11/70 service manual is all good, but it's definitely not enough. Ideally, you should have access to the full drawings, the service manual for the CPU, the service manual for the memory subsystem, I seem to remember that the FP11 has its own service manual, and I think the massbus interface also has its own documentation set. Also, the memory system consists of both the Unibus map, the cache and memory bus system, and they you have separate documentation for the memory boxes (either MJ11 or MK11 box). I don't know how much documentation have been scanned, and I haven't really checked. Since I still have access to all the documentation on paper I usually use that. I don't even remember all the manuals and drawings that exist. Johnny On 2014-10-05 23:46, Nick Downing wrote: > I had an 11/70 service manual as an ebook at one stage, it had full > schematics etc, you also have access to various simulators to help you > understand the programming interface so i can't see what other info you > would need for your restoration, maybe you'd need help jerry rigging > some setup to get an initial tape written to get u started? > > If you have any questions about the schematics or electrical > troubleshooting I'm happy to help although I have never owned a physical > pdp11... concepts are the same as any more modern system. > > cheers, Nick > > On 06/10/2014 8:08 AM, "Johnny Billquist" > wrote: > > On 2014-10-05 03:00, Dave Horsfall > wrote: > > > On Sat, 4 Oct 2014, Noel Chiappa wrote: > > >Anyone seriously working on bringing old hardware back to > life needs to > >get in touch with the Classic Computer Talk list: > > Is John Dodson on this list? He has an 11/70 in his house. > > > No idea. I occasionally scan cctalk, but most of the time don't > bother. Too much noise and irrelevant or ignorant posts. However, > unfortunately I don't have any better suggestions where to go if you > are trying to restore old hardware and don't have enough knowledge. > > And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, > including 11/70 systems. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: bqt at softjar.se || > Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > _________________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/__mailman/listinfo/tuhs > > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From norman at oclsc.org Mon Oct 6 11:36:39 2014 From: norman at oclsc.org (Norman Wilson) Date: Sun, 5 Oct 2014 21:36:39 -0400 (EDT) Subject: [TUHS] 2.9bsd on 11/45 restoration Message-ID: <20141006013639.560F11DE38B@lignose.oclsc.org> The 11/70 service manual is all good, but it's definitely not enough. Ideally, you should have access to the full drawings, the service manual for the CPU, the service manual for the memory subsystem, I seem to remember that the FP11 has its own service manual, and I think the massbus interface also has its own documentation set. Also, the memory system consists of both the Unibus map, the cache and memory bus system, and they you have separate documentation for the memory boxes (either MJ11 or MK11 box). It might be worth while to contact the Living Computer Museum. I forget whether they have an 11/70 running or just an 11/45, but I do know that they collect all the documentation they can get for old computers--I saw the room where they store it. Whenever they need to use it, or there's some other need to access it, they try to make time to scan it, so the precious copy can stay in the archive room. Since their goal is to have ancient computers actually running, they are certainly interested in having all the documents (even if you can't get the wood, as Warren might remark at this point), including full engineering drawings. It's also a neat place to visit if you have some free time in Seattle. I'm disappointed to have figured out that, although I'll be in Seattle for a conference in about a month, I won't be able to visit LCM while they're open unless I skip some conference sessions ... or unless I can convince them to open up specially. Anyone else on this list planning to attend LISA and interested in visiting a museum of old running computers? Norman Wilson Toronto ON From peter at rulingia.com Tue Oct 7 18:54:18 2014 From: peter at rulingia.com (Peter Jeremy) Date: Tue, 7 Oct 2014 19:54:18 +1100 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: <20141003033632.GD18537@www.oztivo.net> References: <20141003033632.GD18537@www.oztivo.net> Message-ID: <20141007085418.GB15122@server.rulingia.com> On 2014-Oct-03 13:36:32 +1000, Warren Toomey wrote: >----- Forwarded message from Jacob Ritorto ----- >   Also, has anyone written a miniature httpd for any of the ancient > bsds? You probably won't get much smaller than hibachi (http://ioccc.org/2004/hibachi.tar.gz). Disclaimer: I haven't actually tried building it on an old Unix. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From bqt at update.uu.se Wed Oct 8 04:15:44 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 07 Oct 2014 20:15:44 +0200 Subject: [TUHS] 2.9bsd on 11/45 restoration In-Reply-To: References: Message-ID: <54342DD0.6060904@update.uu.se> On 2014-10-07 03:00, norman at oclsc.org (Norman Wilson) wrote: > > The 11/70 service manual is all good, but it's definitely not enough. > Ideally, you should have access to the full drawings, the service manual > for the CPU, the service manual for the memory subsystem, I seem to > remember that the FP11 has its own service manual, and I think the > massbus interface also has its own documentation set. > Also, the memory system consists of both the Unibus map, the cache and > memory bus system, and they you have separate documentation for the > memory boxes (either MJ11 or MK11 box). > > It might be worth while to contact the Living Computer Museum. > I forget whether they have an 11/70 running or just an 11/45, > but I do know that they collect all the documentation they can > get for old computers--I saw the room where they store it. > Whenever they need to use it, or there's some other need to > access it, they try to make time to scan it, so the precious > copy can stay in the archive room. LCM have atleast one 11/70 running. Although they are not really doing anything fun on it. I hope to maybe help them with that next time I'm there. I can't remember seeing any 11/45 running, but I'm pretty sure there are some in their storage if nothing else... I'm not going to try dragging a lot of documentation from Sweden to Seattle, though (I'm not even in Sweden myself lots of the time). On the other hand, I know they have plenty of documentation, so I would hope they (and/or CHM) already have most of it. > Since their goal is to have ancient computers actually > running, they are certainly interested in having all the > documents (even if you can't get the wood, as Warren might > remark at this point), including full engineering drawings. > > It's also a neat place to visit if you have some free time in > Seattle. I'm disappointed to have figured out that, although > I'll be in Seattle for a conference in about a month, I won't > be able to visit LCM while they're open unless I skip some > conference sessions ... or unless I can convince them to open > up specially. Anyone else on this list planning to attend > LISA and interested in visiting a museum of old running > computers? I know of the place, and have known Rich Alderson for a long time. It is a fun place, and I could see myself working there, if I just had the right offer. Don't expect that to happen, though... I'll be there for different reasons in about a month from now. But my weekends are free... :-) Johnny From M.Engel at leedsbeckett.ac.uk Sat Oct 11 03:26:58 2014 From: M.Engel at leedsbeckett.ac.uk (Engel, Michael) Date: Fri, 10 Oct 2014 17:26:58 +0000 Subject: [TUHS] Codata restoration - day 1 Message-ID: Hi, after carefully examining the power supply and checking the generated voltages, we were convinced that this wouldn't kill our Multibus boards. Maybe some of you are interested in our progress, so I though I would send you an update. After reconnecting the Multibus backplane, we started the system with only a CPU board and a memory board. On one of our CPU boards the smaller (P2) Multibus connector is masked with tape, I'll have to dig deeper to find out what is deactivated by this… One of our two CPU boards is currently non functional (the one without the masking take, this doesn't say a thing on the console UART, will bring in the scope in Monday to check for details). The other one brings up the monitor startup message and prompt on a connected serial terminal (emulator) - however, we are unable to get any characters echoed back. The serial cable is working, we tried all sorts of handshake configurations. If we get any characters back (the system is running at 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or similar). The UART itself seems to work (exchanged it with the one from the non working board - same result), so now I suspect the AM26LS32 RS423 driver to be the culprit. I uploaded some pictures to http://s1372.photobucket.com/user/michaelengel/library/Codata?sort=3&page=1 - there you can see that this machine is far from being in any sort of original condition. Nevertheless, it's great to see it come alive again! Btw., current versions of MAME/MESS include a rudimentary Codata simulator. This doesn't do very much so far, but it can successfully run the firmware ROM code (picture also uploaded to photobucket). Best wishes, Michael From dave at horsfall.org Sat Oct 11 04:00:07 2014 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 11 Oct 2014 05:00:07 +1100 (EST) Subject: [TUHS] Codata restoration - day 1 In-Reply-To: References: Message-ID: On Fri, 10 Oct 2014, Engel, Michael wrote: > After carefully examining the power supply and checking the generated > voltages, we were convinced that this wouldn't kill our Multibus boards. > Maybe some of you are interested in our progress, so I though I would > send you an update. Yes please! I long for the days when it was possible to understand the entire kernel source... > After reconnecting the Multibus backplane, we started the system with > only a CPU board and a memory board. On one of our CPU boards the > smaller (P2) Multibus connector is masked with tape, I'll have to dig > deeper to find out what is deactivated by this… The P2 bus is designated as "private" i.e. do whatever you want with it with your proprietary hardware. I don't think the "standard" CPU board even looks at it. > One of our two CPU boards is currently non functional (the one without > the masking take, this doesn't say a thing on the console UART, will > bring in the scope in Monday to check for details). The other one brings > up the monitor startup message and prompt on a connected serial terminal > (emulator) - however, we are unable to get any characters echoed back. > The serial cable is working, we tried all sorts of handshake > configurations. If we get any characters back (the system is running at > 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space > parity and 1/2 stop bits), these are garbled and contain mostly "1" bits > (0xfc, 0xfe, 0xff or similar). Have you tried speeds other than 9600? They look to me like framing errors. -- Dave From M.Engel at leedsbeckett.ac.uk Sat Oct 11 05:21:52 2014 From: M.Engel at leedsbeckett.ac.uk (Engel, Michael) Date: Fri, 10 Oct 2014 19:21:52 +0000 Subject: [TUHS] Codata restoration - day 1 In-Reply-To: References: Message-ID: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> On 10 Oct 2014, at 19:00, Dave Horsfall wrote: > On Fri, 10 Oct 2014, Engel, Michael wrote: > >> After carefully examining the power supply and checking the generated >> voltages, we were convinced that this wouldn't kill our Multibus boards. >> Maybe some of you are interested in our progress, so I though I would >> send you an update. > > Yes please! I long for the days when it was possible to understand the > entire kernel source... Thanks, Dave! Unfortunately, I haven't heard back from Unisoft so far, but I have tried something else last night. A few months ago, ragge (of NetBSD/VAX and pcc fame) added a 68k backend to (modern) pcc. With this, I was able to (cross-)compile more than half of the files of the PDP11 v7 kernel without changes (but the compiler still seems to have some problems, I'll try to generate a useful error report over the weekend). So, a new 7th Edition Unix port to Sun 100U-derived boards seems to be possible, perhaps also incorporating pieces from System III or early BSDs. Another alternative would be a port of RetroBSD, the 2.11 BSD port which currently runs on the PIC32 MIPS microcontroller cores in just 128kB RAM. One of these systems will also be the basis for my upcoming operating systems course :-). Nevertheless, I will first try to get the existing installation to work, maybe there are some interesting sources on the disks (and we have also found a number of 1600bpi 9-track backup tapes and 5.25" backup floppies...). >> After reconnecting the Multibus backplane, we started the system with >> only a CPU board and a memory board. On one of our CPU boards the >> smaller (P2) Multibus connector is masked with tape, I'll have to dig >> deeper to find out what is deactivated by this… > > The P2 bus is designated as "private" i.e. do whatever you want with it > with your proprietary hardware. I don't think the "standard" CPU board > even looks at it. That's what I also thought. Do you know if there were systems which used P2 to connect to memory boards? [...] >> The serial cable is working, we tried all sorts of handshake >> configurations. If we get any characters back (the system is running at >> 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space >> parity and 1/2 stop bits), these are garbled and contain mostly "1" bits >> (0xfc, 0xfe, 0xff or similar). > > Have you tried speeds other than 9600? They look to me like framing > errors. The terminal emulator (screen and minicom behave identically) receives the output from the console perfectly - otherwise, I would have also suspected an incorrect baudrate. And different baudrates for RX and TX would be highly unusual (I have only seen these in German BTX dialup systems in the 1980s, which used 1200/75 baud modems). Luckily, the driver chip for the UART RX line is an AM26LS32. While this chip is no longer available, I can get an AM26LS32A here at Farnell (which is just around the corner from my house :-)). Does anyone know the difference between the 26LS32 and the 26LS32A? I only found a page at TI that didn't list specific differences... -- Michael From dave at horsfall.org Sat Oct 11 05:55:10 2014 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 11 Oct 2014 06:55:10 +1100 (EST) Subject: [TUHS] Codata restoration - day 1 In-Reply-To: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> References: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> Message-ID: On Fri, 10 Oct 2014, Engel, Michael wrote: > > The P2 bus is designated as "private" i.e. do whatever you want with > > it with your proprietary hardware. I don't think the "standard" CPU > > board even looks at it. > > That's what I also thought. Do you know if there were systems which used > P2 to connect to memory boards? I think (and this is going back to the early 80s) that some WICAT models did. I've used the 150, 160, and 200, but never saw a 220. The smaller models were Multibus, and the 200 on had something loosely based on it and was unofficially referred to as the Pussy-bus. The P2 bus on those small ones was used for something that I've long since forgotten; there was a project in the Lionel Singer Group (Aussie agent for WICAT) to use standard Multibus cards in them until we discovered upon reading the circuits (we had circuit diagrams in those days!) that WICAT had hijacked the P2 bus, possibly for extended memory, possibly for its weird ICI board (8-port serial board + disk, as I vaguely recall), possibly something else. I was glad to see the end of the WICATs, because their attempt at System III was woeful; I had to do pre-sales demos, *knowing* that the damned thing would crash on me, and got very good at excuses. "Sorry guys, we've been having a bit of trouble with this new controller, but we're told it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at fault. How do you explain to the customer that the OS itself is fundamentally rat-shit? I am desperately trying to forget the exact details, but it involved someone telling Lionel Singer himself that his half-arsed idea was just that... > [...] > >> The serial cable is working, we tried all sorts of handshake > >> configurations. If we get any characters back (the system is running > >> at 9600 baud, I tried all combinations of 7/8 bit, > >> none/even/odd/mark/space parity and 1/2 stop bits), these are garbled > >> and contain mostly "1" bits (0xfc, 0xfe, 0xff or similar). > > > > Have you tried speeds other than 9600? They look to me like framing > > errors. > > The terminal emulator (screen and minicom behave identically) receives > the output from the console perfectly - otherwise, I would have also > suspected an incorrect baudrate. And different baudrates for RX and TX > would be highly unusual (I have only seen these in German BTX dialup > systems in the 1980s, which used 1200/75 baud modems). 1200/75? That was popular in Australia, on a scheme called Viatel, which thankfully died off when ISPs began to rise up (until then it was either FidoNet or the Phone Company's Viatel) and implement 1200/1200. > Luckily, the driver chip for the UART RX line is an AM26LS32. While this > chip is no longer available, I can get an AM26LS32A here at Farnell > (which is just around the corner from my house :-)). Does anyone know > the difference between the 26LS32 and the 26LS32A? I only found a page > at TI that didn't list specific differences... Offhand no, but Farknell (as they're known in Australia - say it out loud) ought to know, as they're pretty clued up. -- Dave From rosenfeld at grumpf.hope-2000.org Sat Oct 11 06:13:03 2014 From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld) Date: Fri, 10 Oct 2014 22:13:03 +0200 Subject: [TUHS] Codata restoration - day 1 In-Reply-To: References: Message-ID: <20141010201303.GF25824@grumpf.hope-2000.org> Hi Michael, On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote: > The serial cable is working, we tried all sorts of handshake configurations. > If we get any characters back (the system is running at 9600 baud, I tried > all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop > bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or > similar). > > The UART itself seems to work (exchanged it with the one from the non > working board - same result), so now I suspect the AM26LS32 RS423 > driver to be the culprit. I've had that a few times with PDP11s and VAXen from the 80s. The line receivers suddenly died, showing exactly the symptoms you describe. Those were different chips (ua96XX), but the concept is the same. Replacing them with newer chips from the same family worked without problems. Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From imp at bsdimp.com Sat Oct 11 06:37:04 2014 From: imp at bsdimp.com (Warner Losh) Date: Fri, 10 Oct 2014 14:37:04 -0600 Subject: [TUHS] Codata restoration - day 1 In-Reply-To: <20141010201303.GF25824@grumpf.hope-2000.org> References: <20141010201303.GF25824@grumpf.hope-2000.org> Message-ID: <2FE72B5A-E2ED-4EEC-A872-17D075BA83DC@bsdimp.com> These days, you can buy 5.0V or 3.3V to USB adapters in the hobbyist or robotics section of many computer stores. I’ve used them to trouble shoot blown driver chips to verify they really were toast. Be careful of the voltage levels, though, since many 3.3V products can’t tolerate 5.0V… Warner On Oct 10, 2014, at 2:13 PM, Hans Rosenfeld wrote: > Hi Michael, > > On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote: >> The serial cable is working, we tried all sorts of handshake configurations. >> If we get any characters back (the system is running at 9600 baud, I tried >> all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop >> bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or >> similar). >> >> The UART itself seems to work (exchanged it with the one from the non >> working board - same result), so now I suspect the AM26LS32 RS423 >> driver to be the culprit. > > I've had that a few times with PDP11s and VAXen from the 80s. The line > receivers suddenly died, showing exactly the symptoms you describe. > Those were different chips (ua96XX), but the concept is the same. > Replacing them with newer chips from the same family worked without > problems. > > > Hans > > > -- > %SYSTEM-F-ANARCHISM, The operating system has been overthrown > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From clemc at ccc.com Sun Oct 12 07:48:13 2014 From: clemc at ccc.com (Clem Cole) Date: Sat, 11 Oct 2014 17:48:13 -0400 Subject: [TUHS] Codata restoration - day 1 In-Reply-To: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> References: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> Message-ID: below On Fri, Oct 10, 2014 at 3:21 PM, Engel, Michael wrote: > > > That's what I also thought. Do you know if there were systems which used > P2 to connect to memory boards? > ​Pretty much everyone that was successfull - Masscomp, Apollo, etc... And they are all different.​ > > > Luckily, the driver chip for the UART RX line is an AM26LS32. While > this chip is no longer available, I can get an AM26LS32A here at Farnell > (which is just around the corner from my house :-)). Does anyone know > the difference between the 26LS32 and the 26LS32A? I only found a > page at TI that didn't list specific differences... ​Hmm... I looked in my old AMD books, and I unfortunately do not have an AM26xxx anything in there. the difference between the MC1489/SN75189 and MC1489A/ SN75189 is input hysteresis on the receiver side. I wonder if AMD did the same when they created the 26L32​ ​ to compete with Moto and TI (in those days the 1488/1489 system was king until MAX shows up on the scene with a single 5v device). So, I'll give you the text from Page 5-42 of the Moto Interface book on the 1489/1489A: *The MC1489 input has typical turn-on voltage of 1.25 volts and turn off of 1.0 volt for an input hysteresis of 250mv. ​ The MC1489A has a typical turn on a 1.95 volts and turn off of .8 volts for typically 1.15 volts of hysteresis.* I suspect the A version will work fine, usually the differences was things like this where they made the part better in real world applications (250mv of hysteresis for a device that was supposed to be able to handle swing between +30/-30 volts is tiny). Best of luck. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.nini at yahoo.it Sun Oct 12 18:59:52 2014 From: luca.nini at yahoo.it (luca.nini) Date: Sun, 12 Oct 2014 10:59:52 +0200 Subject: [TUHS] ISPS Message-ID: Back in the 80s in my University days  I was  using ISPS (Instruction  Set  Processor  Simulator if  I remember  correctly ) a software tool To simulate CPU.  It ran on a Vax  with  BSD 4.2. I have been  unable  to find any reference to It on the Internet . Do someone on this list  know anything offerte this software ?  Thanks  Luca  -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Oct 13 04:26:54 2014 From: clemc at ccc.com (Clem Cole) Date: Sun, 12 Oct 2014 14:26:54 -0400 Subject: [TUHS] ISPS In-Reply-To: References: Message-ID: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com> sure I helped to write the original version in Vax serial #1 in bliss with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD the system lives today as VHDL I'll see if I can dig up a copy in my archives and give it to Warren or bit savers > On Oct 12, 2014, at 4:59 AM, luca.nini wrote: > > Back in the 80s in my University days I was using ISPS (Instruction Set Processor Simulator if I remember correctly ) a software tool To simulate CPU. It ran on a Vax with BSD 4.2. I have been unable to find any reference to It on the Internet . Do someone on this list know anything offerte this software ? > > Thanks > Luca > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From fair at netbsd.org Mon Oct 13 04:18:12 2014 From: fair at netbsd.org (Erik Fair) Date: Sun, 12 Oct 2014 11:18:12 -0700 Subject: [TUHS] Codata restoration - day 1 In-Reply-To: References: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk> Message-ID: <6CD9CF81-CE94-45DA-873E-AC1D79B1B7A1@netbsd.org> On Oct 10, 2014, at 12:55, Dave Horsfall wrote: > I was glad to see the end of the WICATs, because their attempt at System > III was woeful; I had to do pre-sales demos, *knowing* that the damned > thing would crash on me, and got very good at excuses. "Sorry guys, we've > been having a bit of trouble with this new controller, but we're told > it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at > fault. How do you explain to the customer that the OS itself is > fundamentally rat-shit? At Dual Systems, we never shipped AT&T USG System III to our customers, other than a few alphas/betas - it was such a disaster, we spent a year fixing show-stopper bugs in it. By the time we got System III into what we considered "shippable/supportable" shape, System V was out, so we started work on that. Our customers had to jump from v7 to System V, but they were spared System III. System V was pretty awful too, but it was "industry standard" and we had to put up with that idiocy from AT&T USG. I daily retreated back to the much more pleasant use of BSD UNIX systems at UCB that I still had access to. Erik From cubexyz at gmail.com Mon Oct 13 10:57:14 2014 From: cubexyz at gmail.com (Mark Longridge) Date: Sun, 12 Oct 2014 20:57:14 -0400 Subject: [TUHS] Getting Unix v5 to talk Message-ID: Thanks to the efforts of Jonathan Gevaryahu I have managed to get the Unix v5 speak utility to compile and execute. All this was done using the simh emulator emulating a PDP-11/70. Jonathan managed extract enough of speak.c to reconstruct it to the point it could be compiled with v5 cc. I believe it was necessary to look at speak.o to accomplish this. Jonathan also states that there are more interesting things that could possibly be recovered from v6doc.tar.gz One can look at speak.c source here: http://www.maxhost.org/other/speak.c Now had we have speak compiled we can go a bit further: cat speak.v - | speak -v null generates speak.m from ascii file speak.v speak speak.m computer !p (prints out phonetics for working word) which outputs: ,k,a0,m,p,E2,U1,t,er,-1 ctrl-d exits Looking at speak.c we can see that it opens /dev/vs. Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could be compiled into the kernel although I haven't done this as yet. speak.c looks like Unix v5 era code. My understanding is that Unix v5 appeared in June 1974 and the comments say 'Copyright 1974' so it seems plausible. I'm intrigued by the possibility of getting Unix v5 to talk. Mark From jnc at mercury.lcs.mit.edu Mon Oct 13 12:14:19 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 12 Oct 2014 22:14:19 -0400 (EDT) Subject: [TUHS] Getting Unix v5 to talk Message-ID: <20141013021419.B1A3918C0AB@mercury.lcs.mit.edu> > From: Mark Longridge > Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could > be compiled into the kernel although I haven't done this as yet. The vs.c seems to be a Votrax speech synthesizer hooked up to a DC11 interface. Do any of the simulators support the DC11? If not, adding the driver won't do you much good. Noel PS: I seem to recall the DSSR group on the 4th floor at LCS actually had one of these, back in the day. The sound quality was pretty marginal, as I recall! From clemc at ccc.com Tue Oct 14 02:29:52 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 13 Oct 2014 12:29:52 -0400 Subject: [TUHS] ISPS In-Reply-To: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com> References: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com> Message-ID: Checkout: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci On Sun, Oct 12, 2014 at 2:26 PM, Clem Cole wrote: > sure I helped to write the original version in Vax serial #1 in bliss > with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the > Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD > > the system lives today as VHDL > > I'll see if I can dig up a copy in my archives and give it to Warren or > bit savers > > > > On Oct 12, 2014, at 4:59 AM, luca.nini wrote: > > > > Back in the 80s in my University days I was using ISPS (Instruction > Set Processor Simulator if I remember correctly ) a software tool To > simulate CPU. It ran on a Vax with BSD 4.2. I have been unable to find > any reference to It on the Internet . Do someone on this list know > anything offerte this software ? > > > > Thanks > > Luca > > > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.nini at yahoo.it Wed Oct 15 06:09:12 2014 From: luca.nini at yahoo.it (Luca Nini) Date: Tue, 14 Oct 2014 21:09:12 +0100 Subject: [TUHS] ISPS In-Reply-To: References: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com> Message-ID: <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com> Thank yiou Clem. I remember this paper... Luca ________________________________ Da: Clem Cole A: luca.nini Cc: "tuhs at tuhs.org" Inviato: Lunedì 13 Ottobre 2014 18:29 Oggetto: Re: [TUHS] ISPS Checkout: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci On Sun, Oct 12, 2014 at 2:26 PM, Clem Cole wrote: sure I helped to write the original version in Vax serial #1 in bliss with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD > >the system lives today as VHDL > >I'll see if I can dig up a copy in my archives and give it to Warren or bit savers > > > >> On Oct 12, 2014, at 4:59 AM, luca.nini wrote: >> >> Back in the 80s in my University days I was using ISPS (Instruction Set Processor Simulator if I remember correctly ) a software tool To simulate CPU. It ran on a Vax with BSD 4.2. I have been unable to find any reference to It on the Internet . Do someone on this list know anything offerte this software ? >> >> Thanks >> Luca >> >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Oct 15 06:18:30 2014 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 15 Oct 2014 07:18:30 +1100 (EST) Subject: [TUHS] ISPS In-Reply-To: <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com> References: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com> <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com> Message-ID: On Tue, 14 Oct 2014, Luca Nini wrote: > > http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci > > Thank yiou Clem.  I remember this paper... Seconded. I had graduated by then, but I certainly remember being taught something like it in Computer Science. -- Dave Horsfall (VK2KFU) http://www.horsfall.org/spam.html From cubexyz at gmail.com Fri Oct 17 11:51:56 2014 From: cubexyz at gmail.com (Mark Longridge) Date: Thu, 16 Oct 2014 21:51:56 -0400 Subject: [TUHS] early cc variable and function names Message-ID: Hi folks, I've been looking at Unix v5 cc limitations. It seems like early cc could only use variable and function names up to 8 characters. This limitation occurs in v5, v6 and v7. But when using the nm utility to print out the name list I see function test1234() listed as: 000044T _test123 That seems to suggest that only the first 7 characters are significant, but when looking at other sources they stated that one can use up to 8 characters. I hacked up a short program to test this: main() { test1234(); test1235(); } test1234() { printf ("\nWorking"); } test1235() { printf ("\nAlso working"); } This generated: Multiply defined: test5.o;_test123 So it would seem that function names can only be 7 characters in length. I am not sure if limitations of early cc were documented anywhere. When I backported unirubik to v5 it compiled the longer functions without any problem. Did anyone document these sorts of limitations of early cc? Does anyone remember when cc started to use function names longer than 7 characters? Mark From milov at cs.uwlax.edu Fri Oct 17 12:20:23 2014 From: milov at cs.uwlax.edu (Milo Velimirovic) Date: Thu, 16 Oct 2014 21:20:23 -0500 Subject: [TUHS] early cc variable and function names In-Reply-To: References: Message-ID: <07F8EFBD-054E-4296-BDE9-879F6C36A649@cs.uwlax.edu> External names were limited to 7 (user-defined) characters because the compiler prepended the _ to them. Function names were always external in that era of C. Internal variables could be up to 8 characters. As for longer names, they were allowed but only the first 8 ( including the compiler supplied _ for external names) were signiicant. I'll look for my documentation from v6. - Milo On Oct 16, 2014, at 8:51 PM, Mark Longridge wrote: > Hi folks, > > I've been looking at Unix v5 cc limitations. > > It seems like early cc could only use variable and function names up > to 8 characters. > > This limitation occurs in v5, v6 and v7. > > But when using the nm utility to print out the name list I see > function test1234() listed as: > 000044T _test123 > > That seems to suggest that only the first 7 characters are > significant, but when looking at other sources they stated that one > can use up to 8 characters. > > I hacked up a short program to test this: > > main() > { > test1234(); > test1235(); > } > > test1234() > { > printf ("\nWorking"); > } > > test1235() > { > printf ("\nAlso working"); > } > > > This generated: > Multiply defined: test5.o;_test123 > > So it would seem that function names can only be 7 characters in > length. I am not sure if limitations of early cc were documented > anywhere. When I backported unirubik to v5 it compiled the longer > functions without any problem. > > Did anyone document these sorts of limitations of early cc? Does > anyone remember when cc started to use function names longer than 7 > characters? > > Mark > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From jnc at mercury.lcs.mit.edu Fri Oct 17 12:29:13 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 16 Oct 2014 22:29:13 -0400 (EDT) Subject: [TUHS] early cc variable and function names Message-ID: <20141017022913.7A77818C092@mercury.lcs.mit.edu> > From: Mark Longridge > It seems like early cc could only use variable and function names up to > 8 characters. > This limitation occurs in v5, v6 and v7. > ... > That seems to suggest that only the first 7 characters are significant, > but when looking at other sources they stated that one can use up to 8 > characters. The a.out symbol tables use 8-character fields to hold symbol names. However, C automagically and unavoidably prepends an _ to all externals (I forget about automatics, registers, etc - too tired to check right now), making the limit for C names 7 characters. > I am not sure if limitations of early cc were documented anywhere. I remember reading the above. Other limits... well, you need to remember that C was still changing in that period, so limits were a moving target. > When I backported unirubik to v5 it compiled the longer functions > without any problem. ISTR that C truncated external names longer than 7 characters. Probably the ones in that program were all unique within 7, so you won. > Did anyone document these sorts of limitations of early cc? I seem to recall at least one document from that period (I think pertaining to the so-called 'Typesetter C') about 'changes to C'. Also, I have started a note with a list of 'issues with C when you're backporting V7 and later code to V6', I'll see if I can dig them out tomorrow. Noel From cowan at mercury.ccil.org Fri Oct 17 12:40:49 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 16 Oct 2014 22:40:49 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017022913.7A77818C092@mercury.lcs.mit.edu> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> Message-ID: <20141017024049.GI17227@mercury.ccil.org> Noel Chiappa scripsit: > The a.out symbol tables use 8-character fields to hold symbol names. However, > C automagically and unavoidably prepends an _ to all externals (I forget > about automatics, registers, etc - too tired to check right now), making the > limit for C names 7 characters. The _ was only for externals, including all procedure names. It prevented collisions with names introduced into the assembly-language source or in libc. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org A male Jang appeared at my side. "Get a grip on yourself," he said. "Get a grip on your graks," I suggested. --Tanith Lee, Drinking Sapphire Wine From dave at horsfall.org Fri Oct 17 12:21:59 2014 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 17 Oct 2014 13:21:59 +1100 (EST) Subject: [TUHS] early cc variable and function names In-Reply-To: References: Message-ID: On Thu, 16 Oct 2014, Mark Longridge wrote: > It seems like early cc could only use variable and function names up to > 8 characters. In those days it took only the first seven and ignored the rest, prepending an underscore as you discovered. I don't remember when longer names were recognised; for all I know it could've been around when pathnames could be longer than 14 chars (which I think may have been a BSDism). -- Dave Horsfall (VK2KFU) http://www.horsfall.org/spam.html From lm at mcvoy.com Fri Oct 17 12:52:42 2014 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Oct 2014 19:52:42 -0700 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017024049.GI17227@mercury.ccil.org> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> Message-ID: <20141017025242.GH6963@mcvoy.com> On Thu, Oct 16, 2014 at 10:40:49PM -0400, John Cowan wrote: > Noel Chiappa scripsit: > > > The a.out symbol tables use 8-character fields to hold symbol names. However, > > C automagically and unavoidably prepends an _ to all externals (I forget > > about automatics, registers, etc - too tired to check right now), making the > > limit for C names 7 characters. > > The _ was only for externals, including all procedure names. It prevented > collisions with names introduced into the assembly-language source or > in libc. This is perhaps a side note but I believe all structure fields shared a namespace. So stat.size and whatever.size were not allowed, they collided. So we got sb.st_size which I personally love and wish it were still like that. xyz.size abc.size foobar.size What are the types of those structures? abc.st_size Huh, abc is a struct stat. I get that it was a bug and needed to be fixed but I wish that everyone still pretended that it was one namespace, makes code so much easier to read. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From cowan at mercury.ccil.org Fri Oct 17 13:46:18 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 16 Oct 2014 23:46:18 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017025242.GH6963@mcvoy.com> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com> Message-ID: <20141017034618.GJ17227@mercury.ccil.org> Larry McVoy scripsit: > xyz.size > abc.size > foobar.size > > What are the types of those structures? You can't tell because the names are meaningless. With more meaningful names, it's usually possible to see what the type must be. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. --Bilbo From lm at mcvoy.com Fri Oct 17 13:54:36 2014 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Oct 2014 20:54:36 -0700 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017034618.GJ17227@mercury.ccil.org> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com> <20141017034618.GJ17227@mercury.ccil.org> Message-ID: <20141017035436.GE11233@mcvoy.com> So I've been doing C programming since the early 80's and leading people doing that for at least 20 years, huh, more like 25 years. As much as I wish people did what you suggest, they don't. And I mean really good people, top 1%. So I like the type_name style. As with many things, I may like it but I don't always get it. On Thu, Oct 16, 2014 at 11:46:18PM -0400, John Cowan wrote: > Larry McVoy scripsit: > > > xyz.size > > abc.size > > foobar.size > > > > What are the types of those structures? > > You can't tell because the names are meaningless. With more meaningful > names, it's usually possible to see what the type must be. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > I don't know half of you half as well as I should like, and I like less > than half of you half as well as you deserve. --Bilbo -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From random832 at fastmail.us Fri Oct 17 23:35:11 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 17 Oct 2014 09:35:11 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: References: Message-ID: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote: > On Thu, 16 Oct 2014, Mark Longridge wrote: > > > It seems like early cc could only use variable and function names up to > > 8 characters. > > In those days it took only the first seven and ignored the rest, > prepending an underscore as you discovered. I don't remember when longer > names were recognised; for all I know it could've been around when > pathnames could be longer than 14 chars (which I think may have been a > BSDism). For externals, it's a limitation of the PDP-11 a.out format. Other systems may or may not have had the same limit or a different limit. For VAX, 4BSD appears to use an "index into file string table", whereas 3BSD still has an 8-character string. I don't see any provision in the 4BSD linker for loading 3BSD binaries. Filenames over 14 characters appear to have been introduced in 4.1BSD. From imp at bsdimp.com Fri Oct 17 23:44:13 2014 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Oct 2014 07:44:13 -0600 Subject: [TUHS] early cc variable and function names In-Reply-To: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> References: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> Message-ID: <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com> On Oct 17, 2014, at 7:35 AM, random832 at fastmail.us wrote: > On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote: >> On Thu, 16 Oct 2014, Mark Longridge wrote: >> >>> It seems like early cc could only use variable and function names up to >>> 8 characters. >> >> In those days it took only the first seven and ignored the rest, >> prepending an underscore as you discovered. I don't remember when longer >> names were recognised; for all I know it could've been around when >> pathnames could be longer than 14 chars (which I think may have been a >> BSDism). > > For externals, it's a limitation of the PDP-11 a.out format. Other > systems may or may not have had the same limit or a different limit. > > For VAX, 4BSD appears to use an "index into file string table", whereas > 3BSD still has an 8-character string. I don't see any provision in the > 4BSD linker for loading 3BSD binaries. As someone that wrote an assembler and a linker/loader for the VAX back in the day (for my first CS class), I know that 4.2 definitely had the string table, as did all the descendants that I encountered in the field back during the great unix wars when I was instructed by my employer to obfuscate certain symbols to “protect” IP. Warner > Filenames over 14 characters appear to have been introduced in 4.1BSD. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From arnold at skeeve.com Sat Oct 18 00:07:45 2014 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 17 Oct 2014 08:07:45 -0600 Subject: [TUHS] early cc variable and function names In-Reply-To: <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com> References: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com> Message-ID: <201410171407.s9HE7jXl010061@freefriends.org> Warner Losh wrote: > > For VAX, 4BSD appears to use an "index into file string table", whereas > > 3BSD still has an 8-character string. I don't see any provision in the > > 4BSD linker for loading 3BSD binaries. I think System III or System V picked this up. > > Filenames over 14 characters appear to have been introduced in 4.1BSD. No, at 4.2 BSD with the Fast Filesystem. (Maybe 4.1c or some such already had the FFS, but the original 4.1 didn't...) Arnold From milov at cs.uwlax.edu Sat Oct 18 00:22:00 2014 From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=) Date: Fri, 17 Oct 2014 09:22:00 -0500 Subject: [TUHS] early cc variable and function names In-Reply-To: <201410171407.s9HE7jXl010061@freefriends.org> References: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com> <201410171407.s9HE7jXl010061@freefriends.org> Message-ID: <9B907A1F-0FAD-4633-8E74-17F332905E9B@cs.uwlax.edu> On Oct 17, 2014, at 9:07 AM, arnold at skeeve.com wrote: > Warner Losh wrote: >>> For VAX, 4BSD appears to use an "index into file string table", whereas >>> 3BSD still has an 8-character string. I don't see any provision in the >>> 4BSD linker for loading 3BSD binaries. > > I think System III or System V picked this up. > >>> Filenames over 14 characters appear to have been introduced in 4.1BSD. > > No, at 4.2 BSD with the Fast Filesystem. (Maybe 4.1c or some such > already had the FFS, but the original 4.1 didn't...) > > Arnold Right! McKusick, et al. say that it came with the Fast Filesystem in 4.2 [1] I recall a presentation at UW in Madison where he said, (paraphrasing from memory) We heard you guys. We included long file names in the Fast File System. (loud cheers) - Milo [1] https://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf From jnc at mercury.lcs.mit.edu Sat Oct 18 02:11:43 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 17 Oct 2014 12:11:43 -0400 (EDT) Subject: [TUHS] early cc variable and function names Message-ID: <20141017161143.5E25618C090@mercury.lcs.mit.edu> > From: jnc at mercury.lcs.mit.edu (Noel Chiappa) >> Did anyone document these sorts of limitations of early cc? > I seem to recall at least one document from that period (I think > pertaining to the so-called 'Typesetter C') about 'changes to C'. > ... > I'll see if I can dig them out tomorrow. OK, there are three documents which sort of fall into this class. First, there is something titled "New C Compiler Features", no date, available here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/newstuff.nr no date, but it appears to describe an early version of the so-called 'Typesetter C', mentioned in other documents, so this would be circa 1976 or so. There is a second document, untitled, no date, which I have not been able to locate online at all. I scanned my hard-copy, available here: http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements1.jpg .. http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements5.jpg >From the content, it seems to be from shortly after the previous one, so say, circa 1977. Sorry about the poor readability (it looked fine on the monitor of the machine my scanner is attached to); fudging with contrast would probably make it more readable. When I get the MIT V6 Unix tapes read (they have been sent off to a specialist in reading old tapes, results soon, I hope) I might be able to get more info (e.g. date/filename), and machine-readable source. Finally, there is "Recent Changes to C", from November 15, 1978, available here: http://cm.bell-labs.com/cm/cs/who/dmr/cchanges.pdf which documents a few final bits. There is of course also Dennis M. Ritchie, "The Development of the C Language", available here: http://cm.bell-labs.com/who/dmr/chist.html which is a good, interesting history of C. > Also, I have started a note with a list of 'issues with C when you're > backporting V7 and later code to V6' I found several documents which are bits and pieces of this. http://ana-3.lcs.mit.edu/~jnc/history/unix/C_Backport.txt http://ana-3.lcs.mit.edu/~jnc/history/unix/V6_C.txt Too busy to really clean them up at the moment. Noel From b4 at gewt.net Sat Oct 18 02:44:49 2014 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 17 Oct 2014 12:44:49 -0400 (EDT) Subject: [TUHS] 3BSD/32V: 2 RP06 (SIMH) Message-ID: Afternoon, # /etc/mkfs /dev/rrp1g 145673 isize = 65488 m/n = 3 500 write error: 2 # file rp0g rp0g: block special (0/6) # file rp1g rp1g: block special (0/14) # file rp0a rp0a: block special (0/0) # file rp1a rp1a: block special (0/8) # file rrp0a rrp0a: character special (4/0) # file rrp1a rrp1a: character special (4/8) # file rrp0g rrp0g: character special (4/6) # file rrp1g rrp1g: character special (4/14) DESCRIPTION Files with minor device numbers 0 through 7 refer to various portions of drive 0; minor devices 8 through 15 refer to drive 1, etc. The origin and size of the pseudo-disks on each drive are as follows: What am I forgetting? I have an image attached, I have modified hp.c to have NHP as 2. Is it conflict between rp.c and hp.c? (I patched hp.c to have NHP 2 after patching NURP in rp.c to be 2). -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects From random832 at fastmail.us Sat Oct 18 05:29:10 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 17 Oct 2014 15:29:10 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <201410171407.s9HE7jXl010061@freefriends.org> References: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com> <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com> <201410171407.s9HE7jXl010061@freefriends.org> Message-ID: <1413574150.106130.180291125.467C98A8@webmail.messagingengine.com> On Fri, Oct 17, 2014, at 10:07, arnold at skeeve.com wrote: > Warner Losh wrote: What's actually quoted is what I wrote. > > > For VAX, 4BSD appears to use an "index into file string table", whereas > > > 3BSD still has an 8-character string. I don't see any provision in the > > > 4BSD linker for loading 3BSD binaries. > > I think System III or System V picked this up. > > > > Filenames over 14 characters appear to have been introduced in 4.1BSD. > > No, at 4.2 BSD with the Fast Filesystem. (Maybe 4.1c or some such > already had the FFS, but the original 4.1 didn't...) I was looking at 4.1c in the archive, sorry for not being clear. From clemc at ccc.com Sat Oct 18 05:41:17 2014 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Oct 2014 15:41:17 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017034618.GJ17227@mercury.ccil.org> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com> <20141017034618.GJ17227@mercury.ccil.org> Message-ID: Larry - AMEN. The key is that in the old days it was much easier to glance and code and know which struct or union was being examined. Today, that context is lost and I have to think more about what the type of the ptr is. Yes the >>compiler<< knows, but I as the random programmer reading the code later do not. Larry and my experiences with very, very good programmers is the same. Clem On Thu, Oct 16, 2014 at 11:46 PM, John Cowan wrote: > Larry McVoy scripsit: > > > xyz.size > > abc.size > > foobar.size > > > > What are the types of those structures? > > You can't tell because the names are meaningless. With more meaningful > names, it's usually possible to see what the type must be. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > I don't know half of you half as well as I should like, and I like less > than half of you half as well as you deserve. --Bilbo > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.us Sat Oct 18 06:37:08 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Fri, 17 Oct 2014 16:37:08 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141017025242.GH6963@mcvoy.com> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com> Message-ID: <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com> On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote: > abc.st_size > > Huh, abc is a struct stat. > > I get that it was a bug and needed to be fixed but I wish that everyone > still pretended that it was one namespace, makes code so much easier to > read. I'm not sure what your design is that you're more than a screen away from either its declaration, a stat call, or the fact that it's got size _and_ mode _and_ mtime etc. And if you do that, why stop there? Why not require the type to be repeated to dereference any pointer? while(*x == 0) is x a pointer to int, to char, to another pointer, etc? From lm at mcvoy.com Sat Oct 18 06:42:29 2014 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Oct 2014 13:42:29 -0700 Subject: [TUHS] early cc variable and function names In-Reply-To: <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com> References: <20141017022913.7A77818C092@mercury.lcs.mit.edu> <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com> <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com> Message-ID: <20141017204229.GA4249@mcvoy.com> On Fri, Oct 17, 2014 at 04:37:08PM -0400, random832 at fastmail.us wrote: > On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote: > > abc.st_size > > > > Huh, abc is a struct stat. > > > > I get that it was a bug and needed to be fixed but I wish that everyone > > still pretended that it was one namespace, makes code so much easier to > > read. > > I'm not sure what your design is that you're more than a screen away > from either its declaration, a stat call, or the fact that it's got size > _and_ mode _and_ mtime etc. > > And if you do that, why stop there? Why not require the type to be > repeated to dereference any pointer? Hey, everyone is welcome to their own opinion and it doesn't have to match mine. I review a lot of code, a lot of code that I didn't write. Lots of times the review is in a web browser that doesn't know how to tag to the definition. Sure I can clone the repo and make tags and tag to it but for small reviews there is no need. I do a bunch of code reviews every day. foo.size is a lot less helpful than foo.vfs_size or whatever. Your mileage may vary, where I work we optimize for the reader not for the writer. That's how it is when you work for me. When I work for you then your rules win :) -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From grog at lemis.com Sat Oct 18 17:25:56 2014 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 18 Oct 2014 18:25:56 +1100 Subject: [TUHS] early cc variable and function names In-Reply-To: References: Message-ID: <20141018072556.GC41494@eureka.lemis.com> On Thursday, 16 October 2014 at 21:51:56 -0400, Mark Longridge wrote: > So it would seem that function names can only be 7 characters in > length. I am not sure if limitations of early cc were documented > anywhere. This is really an identifier issues, and it's documented in K&R 1st edition, page 179: DEC PDP-11 7 characters, 2 cases Honeywell 6000 6 characters, 1 case IBM 360/370 7 characters, 1 case Interdata 8/32 8 characters, 2 cases Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From jnc at mercury.lcs.mit.edu Sat Oct 18 20:32:21 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 18 Oct 2014 06:32:21 -0400 (EDT) Subject: [TUHS] early cc variable and function names Message-ID: <20141018103221.204F418C089@mercury.lcs.mit.edu> > From: Greg 'groggy' Lehey > This is really an identifier issues Probably actually a function of the relocatable object format / linker on the machines in question, which in most (all?) cases predated C itself. > it's documented in K&R 1st edition, page 179: Oooh, good piece of detective work! Noel From ron at ronnatalie.com Sun Oct 19 09:03:21 2014 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 18 Oct 2014 19:03:21 -0400 Subject: [TUHS] early cc variable and function names In-Reply-To: <20141018103221.204F418C089@mercury.lcs.mit.edu> References: <20141018103221.204F418C089@mercury.lcs.mit.edu> Message-ID: The assembler could handle 8 case independent symbols. C prepended an underscore to avoid any symbol conflicts. If I recall the compiler allowed longer symbols but it just lost those letters after 7. Amusingly an early IBM 370 compiler omitted prepending the underscore which lead to hilarity when you declared variables called things like R15. On Oct 18, 2014, at 6:32 AM, Noel Chiappa wrote: >> From: Greg 'groggy' Lehey > >> This is really an identifier issues > > Probably actually a function of the relocatable object format / linker on the > machines in question, which in most (all?) cases predated C itself. > >> it's documented in K&R 1st edition, page 179: > > Oooh, good piece of detective work! > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From dave at horsfall.org Sun Oct 19 09:11:30 2014 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 19 Oct 2014 10:11:30 +1100 (EST) Subject: [TUHS] early cc variable and function names In-Reply-To: References: <20141018103221.204F418C089@mercury.lcs.mit.edu> Message-ID: On Sat, 18 Oct 2014, Ron Natalie wrote: > Amusingly an early IBM 370 compiler omitted prepending the underscore > which lead to hilarity when you declared variables called things like > R15. Holy snot! -- Dave Horsfall (VK2KFU) http://www.horsfall.org/spam.html (and check the home page) From M.Engel at leedsbeckett.ac.uk Tue Oct 21 21:23:33 2014 From: M.Engel at leedsbeckett.ac.uk (Engel, Michael) Date: Tue, 21 Oct 2014 11:23:33 +0000 Subject: [TUHS] Codata progress update Message-ID: <5F320B50-8490-4B3C-B774-737B017603C1@leedsbeckett.ac.uk> Hi, it's time for an update on our progress with the Codata machine. The serial interface problem was not caused by a defective transceiver chip (which I found out after buying a couple…), but by an extreme amount of noise on the (quite long and old) serial cable we used to connect the machine to the PC acting as a terminal. Using a USB to serial adapter and a short 9-to-25-pin adapter cable solved this problem. Well, try the obvious things first (using a scope helped). The second CPU board also works, so we could build a complete second machine with our spare boards if we have another multibus backplane... We could get the machine up and booting from the first 8" hard disk last Friday. Luckily, an old version of Kermit was installed and we were able to transmit a large part of the root file system from single user more - especially the Unix kernels, driver sources, the build directories for the kernel, include files and the build directory for the standalone boot floppies. All with a speed of 500 bytes/s (9600 bps serial line minus kermit overhead). cksum was used to confirm that the files were transferred correctly (this was the only checksumming tool that was available on the Codata, I didn't want to mount the fs read-write and compile software before completing the backup). I had to shut the machine down on Friday evening (security policy that kicks you out of the building here), since I didn't want to leave it running unattended over the weekend. Unfortunately, the disk seems to have developed a bad sector in the autoconfiguration region (the system seems to be quite modern in this respect). The kernel can be booted successfully, but it refuses to mount the root fs, complaining about a timeout. There seems to be a complete root file system on the second disk (the firmware is able to read files from the disk, but it doesn't offer a feature to list directories…), but the kernel on the second disk also is hardwired to mount its root fs from the first disk. Trying to connect disk 2 as disk 1 resulted in a non-booting system... The good news is that both root file systems seem to be reasonably intact so far, I can read text files from the boot monitor. So our next step to backup the rest of the system is to build an emergency boot floppy. At the moment, however, the Codata refuses to talk to its floppy drive. The machine has a Multibus FD controller with its own 8085 CPU and a uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80 tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I (printed on the motor assembly). I couldn't find any information on that drive online, so I hesitate to simply connect a more modern drive due to possible pinout differences. I also found out a bit more on the SMD disk controller. It seems to be an OEM variant of the Micro Computer Technology MCT-4300 controller. The only place I could find this mentioned was in a catalog of Multibus boards on archive.org. It has its own driver (cd.c), there is a separate one for the Interphase 2180 and an additional one for the Codata MFM controller. So, if you happen to have any information on the Codata floppy controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I would be happy to hear from you... -- Michael From jnc at mercury.lcs.mit.edu Tue Oct 21 22:44:18 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Oct 2014 08:44:18 -0400 (EDT) Subject: [TUHS] Codata progress update Message-ID: <20141021124418.5591E18C0CD@mercury.lcs.mit.edu> > From: "Engel, Michael" > The machine has a Multibus FD controller with its own 8085 CPU and a > uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80 > tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I > ... I couldn't find any information on that drive online, so I hesitate > to simply connect a more modern drive due to possible pinout differences. > ... > I also found out a bit more on the SMD disk controller. It seems to be > an OEM variant of the Micro Computer Technology MCT-4300 controller. > The only place I could find this mentioned was in a catalog of Multibus > boards on archive.org. > ... > So, if you happen to have any information on the Codata floppy > controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I > would be happy to hear from you... I don't, but can I suggest the Classic Computers mailing list: http://www.classiccmp.org/mailman/listinfo/cctalk They seem to have an extremely deep well of knowledge, and perhaps someone there can help? (I'd rate the odds very high on the floppy drive.) Noel From jsteve at superglobalmegacorp.com Mon Oct 27 20:32:52 2014 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 27 Oct 2014 18:32:52 +0800 Subject: [TUHS] speaking of early C compilers Message-ID: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> has anyone ever tried to compile any of the old C compilers with a 'modern' C compiler? I tried a few from the 80's (Microsoft/Borland) and there is a bunch of weird stuff where integers suddenly become structs, structures reference fields that aren't in that struct, c01.c register int t1; .... t1->type = UNSIGN; And my favorite which is closing a bunch of file handles for the heck of it, and redirecting stdin/out/err from within the program instead of just opening the file and using fread/fwrite.. c00.c if (freopen(argv[2], "w", stdout)==NULL || (sbufp=fopen(argv[3],"w"))==NULL) How did any of this compile? How did this stuff run without clobbering each-other? I don't know why but I started to look at this stuff with some half hearted attempt at getting Apout running on Windows. Naturally there is no fork, so when a child process dies, the whole thing crashes out. I guess I could simulate a fork with threads and containing all the cpu variables to a structure for each thread, but that sounds like a lot of work for a limited audience. But there really is some weird stuff in v7's c compiler. From jsteve at superglobalmegacorp.com Mon Oct 27 22:06:52 2014 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 27 Oct 2014 20:06:52 +0800 Subject: [TUHS] Getting Unix v5 to talk Message-ID: <0F0B9BFC06289346B88512B91E55670D2F87@EXCHANGE> Have you looked at http://real-votrax.no-ip.org/ they have a votrax hooked up, and yes it'll use your phonemes that speak generates. It just likes things to be upper case though. So.. hello !p ,h,e0,l,o0,o1,-1 works more like H E0 L O0 O1 PA1 I wonder if anyone's generated wav's for each of the phonemes, then you could hook up a line printer or something that'll read it as a pipe and just play the wav's as needed.. It is rough 1970's speech synthesis, but I had one of those Intellivoice things as a kid, so I kinda like it. -----Original Message----- From: Mark Longridge To: tuhs Sent: 10/13/14 8:57 AM Subject: [TUHS] Getting Unix v5 to talk Thanks to the efforts of Jonathan Gevaryahu I have managed to get the Unix v5 speak utility to compile and execute. All this was done using the simh emulator emulating a PDP-11/70. Jonathan managed extract enough of speak.c to reconstruct it to the point it could be compiled with v5 cc. I believe it was necessary to look at speak.o to accomplish this. Jonathan also states that there are more interesting things that could possibly be recovered from v6doc.tar.gz One can look at speak.c source here: http://www.maxhost.org/other/speak.c Now had we have speak compiled we can go a bit further: cat speak.v - | speak -v null generates speak.m from ascii file speak.v speak speak.m computer !p (prints out phonetics for working word) which outputs: ,k,a0,m,p,E2,U1,t,er,-1 ctrl-d exits Looking at speak.c we can see that it opens /dev/vs. Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could be compiled into the kernel although I haven't done this as yet. speak.c looks like Unix v5 era code. My understanding is that Unix v5 appeared in June 1974 and the comments say 'Copyright 1974' so it seems plausible. I'm intrigued by the possibility of getting Unix v5 to talk. Mark _______________________________________________ TUHS mailing list TUHS at minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs From brantley at coraid.com Mon Oct 27 23:03:15 2014 From: brantley at coraid.com (Brantley Coile) Date: Mon, 27 Oct 2014 13:03:15 +0000 Subject: [TUHS] speaking of early C compilers In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> Message-ID: <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> Early C allowed you to use the '->' operator with any scaler. See early C reference manuals. This is the reason there is one operator to access a member of a structure using a pointer and another, '.', to access a member in a static structure. The B language had no types, everything was a word, and dmr evolved C from B. At first it made sense to use the '->' operator to mean add a constant to whatever is on the left and use as an l-value. You will also find that member names share a single name space. The simple symbol table had an bit in each entry to delineate members from normal variables. You could only use the same member name in two different structs if the members had the same offsets. In other words, it was legal to add a member name to the symbol table that was already there if the value of the symbol was the same as the existing entry. Dennis' compilers kept some backward compatibility even after the language evolved away from them. This really shows the value of evolving software instead of thinking one has all the answers going into development. If one follows the development of C one sees the insights learned as they went. The study of these early Unix systems have a great deal to teach that will be valuable in the post Moore's law age. Much of the worlds software will need to a re-evolution. By the way, did you notice the compiler overwrites itself? We used to have to work in tiny spaces. Four megabytes was four million dollars. Sent from my iPad > On Oct 27, 2014, at 6:42 AM, Jason Stevens wrote: > > has anyone ever tried to compile any of the old C compilers with a 'modern' > C compiler? > > I tried a few from the 80's (Microsoft/Borland) and there is a bunch of > weird stuff where integers suddenly become structs, structures reference > fields that aren't in that struct, > > c01.c > register int t1; > .... > t1->type = UNSIGN; > > > And my favorite which is closing a bunch of file handles for the heck of it, > and redirecting stdin/out/err from within the program instead of just > opening the file and using fread/fwrite.. > > c00.c > if (freopen(argv[2], "w", stdout)==NULL || > (sbufp=fopen(argv[3],"w"))==NULL) > > > How did any of this compile? How did this stuff run without clobbering > each-other? > > I don't know why but I started to look at this stuff with some half hearted > attempt at getting Apout running on Windows. Naturally there is no fork, so > when a child process dies, the whole thing crashes out. I guess I could > simulate a fork with threads and containing all the cpu variables to a > structure for each thread, but that sounds like a lot of work for a limited > audience. > > But there really is some weird stuff in v7's c compiler. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From ron at ronnatalie.com Mon Oct 27 23:34:53 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 27 Oct 2014 09:34:53 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> Message-ID: <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com> Yep, the kernel was littered with funky memory constants using -> to point at various registers. Probably the most ubuiqtous was #define PS 0177776 struct { int integ; }; yielding the PS->integ access to the Processor Status Register. From random832 at fastmail.us Mon Oct 27 23:40:36 2014 From: random832 at fastmail.us (random832 at fastmail.us) Date: Mon, 27 Oct 2014 09:40:36 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com> Message-ID: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com> On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote: > Yep, the kernel was littered with funky memory constants using -> to > point at various registers. Probably the most ubuiqtous was > #define PS 0177776 > struct { > int integ; > }; > > yielding the PS->integ access to the Processor Status Register. Is there any reason this is superior to *(int *)0177776 [and e.g. #define integ(x) (*(int *)(x))]? Did casting not exist back then? From jnc at mercury.lcs.mit.edu Mon Oct 27 23:46:58 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Oct 2014 09:46:58 -0400 (EDT) Subject: [TUHS] speaking of early C compilers Message-ID: <20141027134658.C64BE18C0A5@mercury.lcs.mit.edu> > From: random832 at fastmail.us > Did casting not exist back then? No, not in the early V6 compiler. It was only added as of the Typesetter compiler. (I think if you look in those 'Recent C Changes' things I sent in recently {Oct 17}, you'll find mention of it.) Noel From jsteve at superglobalmegacorp.com Mon Oct 27 23:54:53 2014 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 27 Oct 2014 21:54:53 +0800 Subject: [TUHS] speaking of early C compilers Message-ID: <0F0B9BFC06289346B88512B91E55670D2F89@EXCHANGE> Thanks for clearing that the whole members out of nowhere thing. I had thought (ha ha) that since I don't have a working fork, I could just rebuild CC as a native executable, and then just call apout for each stage, but I never realized how interdependent they all are, at least C0 to C1. It's crazy to think of how much this stuff cost once upon a time. And now we live in the era of javascript pdp-11's http://pdp11.aiju.de/ -----Original Message----- From: Brantley Coile To: Jason Stevens Cc: tuhs at minnie.tuhs.org Sent: 10/27/14 9:03 PM Subject: Re: [TUHS] speaking of early C compilers Early C allowed you to use the '->' operator with any scaler. See early C reference manuals. This is the reason there is one operator to access a member of a structure using a pointer and another, '.', to access a member in a static structure. The B language had no types, everything was a word, and dmr evolved C from B. At first it made sense to use the '->' operator to mean add a constant to whatever is on the left and use as an l-value. You will also find that member names share a single name space. The simple symbol table had an bit in each entry to delineate members from normal variables. You could only use the same member name in two different structs if the members had the same offsets. In other words, it was legal to add a member name to the symbol table that was already there if the value of the symbol was the same as the existing entry. Dennis' compilers kept some backward compatibility even after the language evolved away from them. This really shows the value of evolving software instead of thinking one has all the answers going into development. If one follows the development of C one sees the insights learned as they went. The study of these early Unix systems have a great deal to teach that will be valuable in the post Moore's law age. Much of the worlds software will need to a re-evolution. By the way, did you notice the compiler overwrites itself? We used to have to work in tiny spaces. Four megabytes was four million dollars. Sent from my iPad > On Oct 27, 2014, at 6:42 AM, Jason Stevens wrote: > > has anyone ever tried to compile any of the old C compilers with a 'modern' > C compiler? > > I tried a few from the 80's (Microsoft/Borland) and there is a bunch of > weird stuff where integers suddenly become structs, structures reference > fields that aren't in that struct, > > c01.c > register int t1; > .... > t1->type = UNSIGN; > > > And my favorite which is closing a bunch of file handles for the heck of it, > and redirecting stdin/out/err from within the program instead of just > opening the file and using fread/fwrite.. > > c00.c > if (freopen(argv[2], "w", stdout)==NULL || > (sbufp=fopen(argv[3],"w"))==NULL) > > > How did any of this compile? How did this stuff run without clobbering > each-other? > > I don't know why but I started to look at this stuff with some half hearted > attempt at getting Apout running on Windows. Naturally there is no fork, so > when a child process dies, the whole thing crashes out. I guess I could > simulate a fork with threads and containing all the cpu variables to a > structure for each thread, but that sounds like a lot of work for a limited > audience. > > But there really is some weird stuff in v7's c compiler. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From clemc at ccc.com Tue Oct 28 00:04:30 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Oct 2014 10:04:30 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com> <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com> Message-ID: Cast became part of Typesetter C IIRC - so V6 and before does not support casting and a number of other "modern" C features. Again you need to think about the time. C, BLISS, PL/360 et al were being developed to replace writing in raw assembler. So supporting assembler style idioms that allowed you to get the raw addresses like PS or specific registers were natural and also remember the optimizers are still in their infancy. i.e. while (SOME_HW_REG_BASE_ADDR->some_sub-register&SOME_MASK) { ... do something/spin etc .. ... } would be a two assembler instruction loop and a natural type of thing a programmer we want to do, The idea of things like "const" etc we use today - just did yet exist As side note from those times, the BLISS compiler's optimizer (which was much more sophisticated than the C compilers) got so good that idioms that test constants like that were removed as . So Wulf created "code comments" (aka today's PRAGMAs) to inform the compiler that the writer of the code knew what they were doing and to "just do it." If you look at CMU kernel code from things like Hydra and other kernels of time - you will see a the code comment: "BOH" - meaning "Buzz Off Hobbes" - the nasty shot at my friend Steve Hobbes. Bill student, who did much of the BLISS optimizer. On Mon, Oct 27, 2014 at 9:40 AM, wrote: > On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote: > > Yep, the kernel was littered with funky memory constants using -> to > > point at various registers. Probably the most ubuiqtous was > > #define PS 0177776 > > struct { > > int integ; > > }; > > > > yielding the PS->integ access to the Processor Status Register. > > Is there any reason this is superior to *(int *)0177776 [and e.g. > #define integ(x) (*(int *)(x))]? Did casting not exist back then? > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Oct 28 00:48:33 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Oct 2014 10:48:33 -0400 (EDT) Subject: [TUHS] speaking of early C compilers Message-ID: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> > From: Jason Stevens > has anyone ever tried to compile any of the old C compilers with a > 'modern' C compiler? > ... > How did any of this compile? How did this stuff run without clobbering > each-other? As Ron Natalie said, the early kernels are absolutely littered with all sorts of stuff that, by today's standards, are totally unacceptable. Using a variable declared as an int as a pointer, using a variable declared as a 'foo' pointer as a 'bar' pointer, yadda-yadda. I ran (tripped, actually :-) across several of these while trying to get my pipe-splicing code to work. (I used Version 6 since i) I am _totally_ familiar with it, and ii) it's what I had running.) For example, I tried to be all nice and modern and declared my pointer variables to be the correct type. The problem is that Unix generated unique ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated by "p+1" depends on what type "p" is declared as - and if you look in pipe.c, you'll see it's often declared as an int pointer. So when _I_ wrote "sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got the wrong number. I can only speculate as to why they wrote code like this. I think part of it is, as Brantley Coile points out, historical artifacts due to the evolution of C from (originally) BCPL. That may have gotten them used to writing code in a certain way - I don't know. I also expect the modern mindset (of being really strict about types, and formal about coverting data from one to another) was still evolving back then - partly because they often didn't _have_ the tools (e.g. casts) to do it right. Another possibility is that they were using line editors, and maintaining more extensive source is a pain with an editor like that. Why write "struct file *p" wnen you can just write "*p"? And of course everyone was so space-concious back then, with those tiny disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a 3.5" floppy!) every byte counted. I have to say, though, that it's really kind of jarring to read this stuff. I have so much respect for their overall structure (the way the kernel is broken down into sub-systems, and the sub-systems into routines), how they managed to get a very powerful (by anyone's standards, even today's) OS into such a small amount of code... And the _logic_ of any given routine is usually quite nice, too: clear and efficient. And I love their commenting style - no cluttering up the code with comments unless there's something that really needs elucidation, just a short header to say, at a high level, what the routine does (and sometimes how and why). So when I see these funky declarations (e.g. "int *p" for something that's _only_ going to be used to point to a "struct file"), I just cringe - even though I sort of understand (see above) why it's like that. It's probably the thing I would most change, if I could. Noel From dave at horsfall.org Tue Oct 28 01:04:33 2014 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Oct 2014 02:04:33 +1100 (EST) Subject: [TUHS] speaking of early C compilers In-Reply-To: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com> <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com> Message-ID: On Mon, 27 Oct 2014, random832 at fastmail.us wrote: > Is there any reason this is superior to *(int *)0177776 [and e.g. > #define integ(x) (*(int *)(x))]? Did casting not exist back then? Type casts? In a compiler/linker that supported e.g.: int abort 4; ... abort(); Thou jests... -- Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From ron at ronnatalie.com Tue Oct 28 01:09:27 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 27 Oct 2014 11:09:27 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> Message-ID: <25DC9219-F0CD-4456-81A3-CF93EDD7A616@ronnatalie.com> We thought the kernels got cleaned up a lot by the time we got to the BSD releases. We were wrong. When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure. The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits. The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow). If the bottom three were zero, then it was the full word. If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words. (Byte operations used different instructions so they directly addressed the memory). Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing. If you cast "int *" to "short *" it would tweak the low order bits to make things work. However the BSD kernel in several places did what I call conversion by union: essentially this: union carbide { char* c; short* s; int* i; } u; u.s = ...some valid short* ... int* ip = u.i; Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures. I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it. The other amusing thing was what to call the data types. Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer). I lobbied hard for "medium" but we ended up using int32. Of course, this is long before the C standards ended up reserving the _ prefix for the implementation. The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved. Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well. Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies. From dave at horsfall.org Tue Oct 28 01:13:38 2014 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Oct 2014 02:13:38 +1100 (EST) Subject: [TUHS] speaking of early C compilers In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> Message-ID: On Mon, 27 Oct 2014, Noel Chiappa wrote: > So when I see these funky declarations (e.g. "int *p" for something > that's _only_ going to be used to point to a "struct file"), I just > cringe - even though I sort of understand (see above) why it's like > that. It's probably the thing I would most change, if I could. What, as opposed to spelling creat() with an "e"? -- Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From jnc at mercury.lcs.mit.edu Tue Oct 28 01:48:10 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Oct 2014 11:48:10 -0400 (EDT) Subject: [TUHS] speaking of early C compilers Message-ID: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu> > From: Dave Horsfall > What, as opposed to spelling creat() with an "e"? Actually, that one never bothered me at all! I tended to be more annoyed by _extra_ characters; e.g. the fact that 'change directory' was (in standard V6) "chdir" (as opposed to just plain "cd") I found far more irritating! Why make that one _five_ characters, when most common commands are two?! (cc, ld, mv, rm, cp, etc, etc, etc...) Noel From dave at horsfall.org Tue Oct 28 02:25:41 2014 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Oct 2014 03:25:41 +1100 (EST) Subject: [TUHS] speaking of early C compilers In-Reply-To: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu> References: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu> Message-ID: On Mon, 27 Oct 2014, Noel Chiappa wrote: > > What, as opposed to spelling creat() with an "e"? > > Actually, that one never bothered me at all! It still annoys me, and it lives on in O_CREAT. Then again, I once got annoyed with TBL's use of "center" [sic], and promptly implemented "centre" as well. > I tended to be more annoyed by _extra_ characters; e.g. the fact that > 'change directory' was (in standard V6) "chdir" (as opposed to just > plain "cd") I found far more irritating! Why make that one _five_ > characters, when most common commands are two?! (cc, ld, mv, rm, cp, > etc, etc, etc...) Especially when the syscall itself is chdir(). Perhaps "cd" was used for something else at the time? -- Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From norman at oclsc.org Tue Oct 28 02:50:04 2014 From: norman at oclsc.org (Norman Wilson) Date: Mon, 27 Oct 2014 12:50:04 -0400 Subject: [TUHS] speaking of early C compilers Message-ID: <1414428608.27921.for-standards-violators@oclsc.org> Noel Chiappa: > I tended to be more annoyed by _extra_ characters; e.g. the fact that > 'change directory' was (in standard V6) "chdir" (as opposed to just > plain "cd") I found far more irritating! Why make that one _five_ > characters, when most common commands are two?! (cc, ld, mv, rm, cp, > etc, etc, etc...) In the earliest systems, e.g. that on the PDP-7, the change-directory command was just `ch'. Two vague memories about the change: -- Dennis, in one of his retrospective papers (possibly that in the 1984 all-UNIX BLTJ issue, but I don't have it handy at the moment) remarked about ch becoming chdir but couldn't remember why that happened. -- Someone else, possibly Tom Duff, once suggested to me that in the earliest systems, the working directory was the only thing that could be changed: no chown, no chmod. Hence just ch for chdir. I don't know offhand whether that's true, but it makes a good story. Personally I'd rather have to type chdir and leav off th trailing e on many other words than creat if it let me off dealing with pieces of key system infrastructure that insist on printing colour-change ANSI escape sequences (with, so far as I can tell, no way to disable them) and give important files names beginning with - so that grep pattern * produces an error. But that happens in Linux, not UNIX. Norman Wilson Toronto ON From crossd at gmail.com Tue Oct 28 02:52:56 2014 From: crossd at gmail.com (Dan Cross) Date: Mon, 27 Oct 2014 12:52:56 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu> Message-ID: An interesting digression.... A few years ago, the architects of MIT's 6.828 course ("Operating Systems Engineering") were unsatisfied with the current stable of systems for teaching, so they did a re-implementation of 6th Edition in modern ANSI C (with a couple of GNU extensions for things like assigning names to registers) targeting a multiprocessor x86. It's an interesting, accessible piece of work; a modern take on a classic. http://pdos.csail.mit.edu/6.828/2014/xv6.html - Dan C. On Mon, Oct 27, 2014 at 10:48 AM, Noel Chiappa wrote: > > From: Jason Stevens > > > has anyone ever tried to compile any of the old C compilers with a > > 'modern' C compiler? > > ... > > How did any of this compile? How did this stuff run without > clobbering > > each-other? > > As Ron Natalie said, the early kernels are absolutely littered with all > sorts > of stuff that, by today's standards, are totally unacceptable. Using a > variable declared as an int as a pointer, using a variable declared as a > 'foo' pointer as a 'bar' pointer, yadda-yadda. > > I ran (tripped, actually :-) across several of these while trying to get my > pipe-splicing code to work. (I used Version 6 since i) I am _totally_ > familiar with it, and ii) it's what I had running.) > > For example, I tried to be all nice and modern and declared my pointer > variables to be the correct type. The problem is that Unix generated unique > ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value > generated > by "p+1" depends on what type "p" is declared as - and if you look in > pipe.c, > you'll see it's often declared as an int pointer. So when _I_ wrote > "sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got > the wrong number. > > I can only speculate as to why they wrote code like this. I think part of > it > is, as Brantley Coile points out, historical artifacts due to the evolution > of C from (originally) BCPL. That may have gotten them used to writing code > in a certain way - I don't know. I also expect the modern mindset (of being > really strict about types, and formal about coverting data from one to > another) was still evolving back then - partly because they often didn't > _have_ the tools (e.g. casts) to do it right. Another possibility is that > they were using line editors, and maintaining more extensive source is a > pain > with an editor like that. Why write "struct file *p" wnen you can just > write > "*p"? And of course everyone was so space-concious back then, with those > tiny > disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a > 3.5" floppy!) every byte counted. > > > I have to say, though, that it's really kind of jarring to read this stuff. > > I have so much respect for their overall structure (the way the kernel is > broken down into sub-systems, and the sub-systems into routines), how they > managed to get a very powerful (by anyone's standards, even today's) OS > into > such a small amount of code... And the _logic_ of any given routine is > usually quite nice, too: clear and efficient. And I love their commenting > style - no cluttering up the code with comments unless there's something > that > really needs elucidation, just a short header to say, at a high level, what > the routine does (and sometimes how and why). > > So when I see these funky declarations (e.g. "int *p" for something that's > _only_ going to be used to point to a "struct file"), I just cringe - even > though I sort of understand (see above) why it's like that. It's probably > the > thing I would most change, if I could. > > Noel > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Tue Oct 28 03:09:21 2014 From: scj at yaccman.com (scj at yaccman.com) Date: Mon, 27 Oct 2014 10:09:21 -0700 Subject: [TUHS] speaking of early C compilers In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> Message-ID: <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Casts were invented as part of the port of Unix to the 32-bit Interdata. The early Unix system manuals actually printed the structure declarations for things like directory inodes in the manual -- there were no header files. This meant a massive amount of work when we wanted to use different structures for the 32-bit system. To make matters worse, many system calls returned -1 as an error indication, and on the Interdata loading an integer from location -1 gave an unrecoverable machine fault (!). As a final blow, the lack of type checking between pointers and structure members made it very hard to catch old code at compile time. The cast syntax, arguably one of the ickiest parts of C syntax, was invented in desperation -- we needed the feature, and there was no good syntax proposal. I blush to admit that the one Dennis chose is one that I suggested, largely because (unlike some of the others) it was easy to implement in Yacc. We hacked a version of Lint to force structures whose physical declaration locations were different to appear to be different structures, even if they were identical. Then, as header files were introduced, we could find all the user-level structure declarations that were copied from the man pages and fix them. This was extremely valuable, and allowed a summer intern from Princeton to convert most of the user-level programs to V7 in a summer. As an aside, one of the hairiest pieces of code I ever wrote was the part of PCC that handled structure declarations--it had to understand the "old style anything goes" syntax, but if the compiler decided that there was some attempt to use the new semantics, it changed modes and retroactively complained about possible type mismatches. The code was festooned with assertions, most of which were very short (memory being precious) -- one or two words like "junk" or "garbage". When compiling the V7 file system, Ken managed to totally confound my code by declaring a structure that had an array whose dimension was computed using a sizeof of another structure declared inside of the sizeof. He came to me one afternoon with a strange expression on his face and asked "Hey Steve, what is a gummy structure?"... From beebe at math.utah.edu Tue Oct 28 04:16:57 2014 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 27 Oct 2014 12:16:57 -0600 (MDT) Subject: [TUHS] speaking of early C compilers Message-ID: Norman Wilson writes today: >> ... >> -- Dennis, in one of his retrospective papers (possibly that >> in the 1984 all-UNIX BLTJ issue, but I don't have it handy at >> the moment) remarked about ch becoming chdir but couldn't >> remember why that happened. >> ... The reference below contains on page 5 this comment by Dennis: >> (Incidentally, chdir was spelled ch; why this was expanded when we >> went to the PDP-11 I don't remember) @String{pub-PH = "Pren{\-}tice-Hall"} @String{pub-PH:adr = "Upper Saddle River, NJ 07458, USA"} @Book{ATT:AUS86-2, author = "AT{\&T}", key = "ATT", title = "{AT}{\&T UNIX} System Readings and Applications", volume = "II", publisher = pub-PH, address = pub-PH:adr, pages = "xii + 324", year = "1986", ISBN = "0-13-939845-7", ISBN-13 = "978-0-13-939845-2", LCCN = "QA76.76.O63 U553 1986", bibdate = "Sat Oct 28 08:25:58 2000", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib", acknowledgement = ack-nhfb, xxnote = "NB: special form AT{\&T} required to get correct alpha-style labels.", } That chapter of that book comes from this paper: @String{j-ATT-BELL-LAB-TECH-J = "AT\&T Bell Laboratories Technical Journal"} @Article{Ritchie:1984:EUT, author = "Dennis M. Ritchie", title = "Evolution of the {UNIX} time-sharing system", journal = j-ATT-BELL-LAB-TECH-J, volume = "63", number = "8 part 2", pages = "1577--1593", month = oct, year = "1984", CODEN = "ABLJER", DOI = "http://dx.doi.org/10.1002/j.1538-7305.1984.tb00054.x" ISSN = "0748-612X", ISSN-L = "0748-612X", bibdate = "Fri Nov 12 09:17:39 2010", bibsource = "Compendex database; http://www.math.utah.edu/pub/tex/bib/bstj1980.bib", abstract = "This paper presents a brief history of the early development of the UNIX operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system.", acknowledgement = ack-nhfb, fjournal = "AT\&T Bell Laboratories Technical Journal", topic = "computer systems programming", } Incidentally, on modern systems with tcsh and csh, I use both chdir and cd; the long form does the bare directory change, whereas the short form is an alias that also updates the shell prompt string and the terminal window title. I also have a personal alias "xd" (eXchange Directory) that is short for the tcsh & bash sequence "pushd !*; cd .", allowing easy jumping back and forth between pairs of directories, with updating of prompts and window titles. ------------------------------------------------------------------------------- - 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 ron at ronnatalie.com Tue Oct 28 06:35:57 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Mon, 27 Oct 2014 16:35:57 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Message-ID: The original UNIX system calls returned error by setting the CARRY ("C") bit on the PSW. It was the little wrapper to make them C callable that mapped that to -1. Yes, there was much cleanup going to Version 7 to get rid of using -1 with pointers in lieu of the null pointer. The original argv list was terminated with a -1 as well. Not that loading from *(int*) 0 was ever a good idea. On the PDP-11, you got garbage...specifically the first few instructions of the program, the first of which was "setd" and if you did "printf("%s\n", 0), you got something like "p&P6" printed out. Some idiot decided in the split I/D mode (and later on the VAX) to put a ZERO at location zero. This led to a lot more sloppy coding. We moved to the Gould SEL machines and like your machine, the default was to get a trap on *(int*)0 as there was nothing mapped there. We subsequently added a flag to the a.out format that changed this behavior (called "braindamaged vax compatibility mode") to map a zero at zero for the few programs we only had in binary form and we couldn't fix their errant behavior. > > The cast syntax, arguably one of the ickiest parts of C syntax, was > invented in desperation -- we needed the feature, and there was no good > syntax proposal. I blush to admit that the one Dennis chose is one that I > suggested, largely because (unlike some of the others) it was easy to > implement in Yacc. Yep, the problem was that the book said that a cast was to perform the same operation as assigning a value to an invented temporary of the cast type. This of course, didn't fully explain it in the case of some cast behavior. C++ had to devolve the C cast into FIVE different kinds of cast to make it sane. From clemc at ccc.com Tue Oct 28 07:34:18 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Oct 2014 17:34:18 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Message-ID: below On Mon, Oct 27, 2014 at 4:35 PM, Ronald Natalie wrote: > The original UNIX system calls returned error by setting the CARRY ("C") > bit on the PSW. > ​I've forgotten that factoid. I remember running into issues with it because the CMU 11/40E had special CSV/CRET ​ ​microcode which we could not use on the 11/34. I've forgotten all the hacks we had associated with the system calls. I do remember, when we moved the CS systems' to EE 11/34 have to unwind a whole ton of that. When tjk brought a UNIX/TS based kernel from MH to us we had reintegrate. I've forgotten all the details now, I just remember many, many hours cleaning things up > > > Some idiot decided in the split I/D mode (and later on the VAX) to put a > ZERO at location zero. This led to a lot more sloppy coding. When we did Magix for the the Tek Magonlia, we cheated and put zeros there. But as got smarter and better (like Masscomp and Stellar), we have two versions of the C runtime - "production mode" and "development mode." In one, we made sure there was a RO page of zeros @ location 0, so we c​ould take the traps and try to clean things up. If I recall correctly, Bourne Shell and ADB were two of the worst offenders. I also seem to remember the original V7 library code was riddled with those bugs ( in particular I seem to remember that malloc/free code), which is why it was such a problem - you own code could be clean, but you brought in a library and got in trouble. The other things for those days, that has not yet been brought up was the famous "NUXI" problem. The PDP-11 byte swapping was idemic in the code. When the first ports to system that were not the same "endianess" came about - you would find strange things in memory. Clem Clem > > > > > The cast syntax, arguably one of the ickiest parts of C syntax, was > > invented in desperation -- we needed the feature, and there was no good > > syntax proposal. I blush to admit that the one Dennis chose is one that > I > > suggested, largely because (unlike some of the others) it was easy to > > implement in Yacc. > > Yep, the problem was that the book said that a cast was to perform the > same operation as assigning a value to an > invented temporary of the cast type. This of course, didn't fully > explain it in the case of some cast behavior. C++ > had to devolve the C cast into FIVE different kinds of cast to make it > sane. > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Tue Oct 28 10:16:36 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 27 Oct 2014 20:16:36 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu> Message-ID: <20141028001636.GL9104@mercury.ccil.org> Dave Horsfall scripsit: > Especially when the syscall itself is chdir(). Perhaps "cd" was used for > something else at the time? On the other hand, chdir is conceptually compatible with mkdir and rmdir, both commands and system calls. I note that MS-DOS and successors allow md and rd as alternatives. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Andrew Watt on Microsoft: Never in the field of human computing has so much been paid by so many to so few! (pace Winston Churchill) From dave at horsfall.org Tue Oct 28 11:09:08 2014 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Oct 2014 12:09:08 +1100 (EST) Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Message-ID: On Mon, 27 Oct 2014, Clem Cole wrote: > [...] because the CMU 11/40E had special CSV/CRET microcode which we > could not use on the 11/34. The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60 was micro-programmable; I never did get around to implementing CSV/CRET on our 60 (Digital had a bunch of them when a contract with a publishing house fell through). > The other things for those days, that has not yet been brought up was > the famous "NUXI" problem.   The  PDP-11 byte swapping was idemic in the > code.   When the first ports to system that were not the same > "endianess" came about - you would find strange things in memory. Reminds me of the time when I used 2-char constants in case statements; my boss yelled at me. -- Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From jsteve at superglobalmegacorp.com Tue Oct 28 11:55:00 2014 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 28 Oct 2014 09:55:00 +0800 Subject: [TUHS] speaking of early C compilers Message-ID: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE> Wow BSD on a supercomputer! That sounds pretty cool! http://web.ornl.gov/info/reports/1986/3445600639931.pdf >From here it mentions it could scale to 16 process execution modules (CPU's?) while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs which each could run 8 processes. It still looks like an amazing machine. -----Original Message----- From: Ronald Natalie To: Noel Chiappa Cc: tuhs at minnie.tuhs.org Sent: 10/27/14 11:09 PM Subject: Re: [TUHS] speaking of early C compilers We thought the kernels got cleaned up a lot by the time we got to the BSD releases. We were wrong. When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure. The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits. The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow). If the bottom three were zero, then it was the full word. If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words. (Byte operations used different instructions so they directly addressed the memory). Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing. If you cast "int *" to "short *" it would tweak the low order bits to make things work. However the BSD kernel in several places did what I call conversion by union: essentially this: union carbide { char* c; short* s; int* i; } u; u.s = ...some valid short* ... int* ip = u.i; Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures. I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it. The other amusing thing was what to call the data types. Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer). I lobbied hard for "medium" but we ended up using int32. Of course, this is long before the C standards ended up reserving the _ prefix for the implementation. The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved. Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well. Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies. _______________________________________________ TUHS mailing list TUHS at minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs From clemc at ccc.com Tue Oct 28 12:06:29 2014 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Oct 2014 22:06:29 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Message-ID: yes: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it because we got an 11/70 > On Oct 27, 2014, at 9:09 PM, Dave Horsfall wrote: > >> On Mon, 27 Oct 2014, Clem Cole wrote: >> >> [...] because the CMU 11/40E had special CSV/CRET microcode which we >> could not use on the 11/34. > > The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60 > was micro-programmable; I never did get around to implementing CSV/CRET on > our 60 (Digital had a bunch of them when a contract with a publishing > house fell through). > >> The other things for those days, that has not yet been brought up was >> the famous "NUXI" problem. The PDP-11 byte swapping was idemic in the >> code. When the first ports to system that were not the same >> "endianess" came about - you would find strange things in memory. > > Reminds me of the time when I used 2-char constants in case statements; my > boss yelled at me. > > -- > Dave Horsfall (VK2KFU) "Bliss is a MacBook with a FreeBSD server." > http://www.horsfall.org/spam.html (and check the home page whilst you're there) > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Oct 28 22:22:10 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 08:22:10 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> Message-ID: <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com> > On Oct 27, 2014, at 10:06 PM, Clem Cole wrote: > > yes: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci > > I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it because we got an 11/70 Problem with the 60 was it lacked Split I/D (as did the 40's). We kind of relied on that for the kernels towards the end of the PDP-11 days, We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along. We just didn't have enough segments to handle all the overlaying needed to do. I recycled all the non split-I/D machines into BRL GATEWAYS. Of course, there was the famous (or imfamous) MARK instruction. This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller. I know of no compiler (either DEC-written or UNIX) that used the silly thing. It obviously wouldn't work in split I/D mode anyhow. Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK. Me and one other PDP-11 trivia guy are going "What? No mark instruction?" in the back of the room. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Oct 28 22:42:12 2014 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Oct 2014 08:42:12 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com> Message-ID: On Tue, Oct 28, 2014 at 8:22 AM, Ronald Natalie wrote: > Problem with the 60 was it lacked Split I/D (as did the 40's). ​A problem was that it was 40 class processor and as you says that means it was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit. The 60 has went into history as the machine that went from product to "traditional products" faster than any other DEC product (IIRC 9 months). I'm always surprised to hear of folks that had them because so few were actually made. I've forgotten the details nows, but they also had some issues when running UNIX. Steve Glaser and I chased those for a long time. The 60 had the HCM instruction sequences (halt a confuse microcode) which were some what random although UNIX seemed to hit them. DEC envisioned it as a commercial machine and added decimal arithmetic to it for RSTS Cobol.​ I'm not sure RSX was even supported on it. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Oct 28 22:52:47 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 08:52:47 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE> Message-ID: > On Oct 27, 2014, at 9:55 PM, Jason Stevens wrote: > > Wow BSD on a supercomputer! That sounds pretty cool! > > http://web.ornl.gov/info/reports/1986/3445600639931.pdf > > From here it mentions it could scale to 16 process execution modules > (CPU's?) > > while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs > which each could run 8 processes. > > It still looks like an amazing machine. The US Army (notably the Ballistic Research Laboratory) contracted to have this computer built to solve fluid dynamics problems. Originally, it was going to be an analog computer, then a hybrid, then Burton Smith came up with this idea for a high power multiple-instruction, multiple data stream parallel processor. The BRL one had four PEMs each could run 8 processes in parallel but it could hardware schedule up to 256 processes. Each data memory location had in addition to the 64 data bits semaphore bits called the "full/empty bits." Instructions were such like "STORE AND SET FULL" and "WAIT EMPTY AND LOAD" so the hardware would suspend your thread (called processes in the hardware) until something else twiddled the bit. Mike Muuss had pretty much ran the JHU EE computer and was my mentor all while I was there. My junion year he had taken a job at BRL. I worked for him as a summer intern and then consultant while Bob Jesse and I ran the JHU EE computer our senior years. I spent a year in the defense industry when Mike said "I've got this great job for you." Apparently nobody gave any concern to software on the HEP, and of course Mike's answer is "Let's put UNIX on it!" He'd done this in the past with some graphics systems (11/34 based with vector processors attached) that had been delivered as remotes for the central CDC machine that never worked. He'd also upgraded the ANTS (University of Illinois ArpaNet Terminal Server) from its dedicated software to UNIX when long leaders came out on the Arpanet making the ANTS incompatible. Mike, Robert Miles, and I spent weeks out at the Denelcor facility developing our prototype UNIX at night (amusingly sometimes the Denelcor employees would come in and hit enter on their terminals to find our software still running... HEP, TWO, THREE, FOUR... was the login prompt...we were working for the Army after all). Amusingly our machine was set up in a big room with tape on the floor showing where the building pillar at BRL was located. You can see that tape in some of the publicity shots around. Back at BRL there was tape on the floor where the HEP cabinets went around the real building pillar. First thing Mike did was adapt the portable C compiler to generate code for the thing. Bob wrote the assembler I believe and me the loader. I also ported the F77 front end to PCC over (for the benefit of our eventual scientist users of the thing). Next, I set up UNIX on the PDP-11 front end the thing had. Mike then wrote the software that worked the "low speed bus" that you used to boot the thing up (more on this later) and the configuration of the switch network that interconnected all the PEMs and memory, etc... for high speed memory access. Mike did the process scheduling part of the kernel while I delved into the I/O issues (my specialty at the time). Bob aided by Doug Kingston took care of porting over most of the user mode code. Once the thing was limping along we came to a startling discovery. The thing, which had 32 UNIBUSes tied into it's I/O system, could only start about 10 ios a second. That's not going to work. I sat down at the Aberdeen Golden Corral steakhouse (our common dinner haunt) with Burton Smith and we designed a new I/O system, literally on napkins. We built it out of spare parts, a spare memory switch node and I contributed a PDP-11/34 I had laying around for a control processor. Now instead of feeding I/O to the front end which then talked tot he I/O system unibusses all over the low speed bus (aptly named), The PDP-11/34 running my "Little Operating System" that I used for the BRL Gateways listed to the high speed active switch for data and mirrored it to the slaved unibuses. Essentially, the PEMs could now run the actual UNIBUS device drivers with just a slight tweak to bounce the CSR's off the PDP-11/34 with what appeared to be just a memory access. At this point the Army had woken up to the fact that the Air Force had supercomputers and even the Navy had supercomputers, and darn it they needed supercomputers. As a result of the fact that we were a scientific organization with heavy computer expertise, we were slated to get the first two. The first being an X-MP which the Army used emergency authority to grab the next one out of production (which I believe was slated to go to Apple). Meanwhile at BRL we had turned the HEP over to production use but by then it was getting a little long in the tooth speedwise. Despite being built out of all discrete 10800 ECL chips, the more traditional processors were beating on the door. Denelcor was well on it's way to going out of business at this point. The one big job we ran on this was Mike's raytraced movie "a bullet's eye view of a tank." The HEP allowed us 60:1 compute time on the RT (Took one minute to make 1 second of movie....which was pretty darned good back then scares me when I watch video games these days). Shortly after we did that, they shut the thing down and replaced it with the X-MP. There weren't that many HEPs built. In addition to ours, the University of Georgia got a 2 PEM one in exchange Georgia was to develop the software for the thing. Messerschmidt got one, I never heard what they did with it. The NSA got one on lease I believe and after Denelcor went out of business, I hear they shipped the whole thing back and dumped it on the loading dock of whatever hapless person happened to be occupying the last known address of Denelcor. I've still got one of the DENELCOR H1000 name plates that were supposed to be affixed to thing but never got installed. As for the X-MP, some of you may remember the discussions that were gone around 1985 about whether a hacker with a Cray could break the Unix crypt routine. I put in my proposal and essentially was granted unlimited CPU time on the X-MP to try to vectorize the crypt routine and perform an analysis (I was heavy into computer security by then). My conclusion was that the Cray vector stuff wasn't well suited to breaking DES...a faster version of the HEP would have been ideal. Somewhere I do have a picture of me peering out of the center of the X-MP CPU. One of the last things I did at BRL was sit on the SSB to buy the Cray 2. I put my signature to a $25 MILLION dollar procurement. The biggest single year purchase I made in my Reagan years in the government (I had bought several smaller UNIX machines in previous years at around $2MM a piece). From ron at ronnatalie.com Tue Oct 28 23:03:44 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 09:03:44 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com> Message-ID: <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com> > > I've forgotten the details nows, but they also had some issues when running UNIX. Steve Glaser and I chased those for a long time. The 60 had the HCM instruction sequences (halt a confuse microcode) which were some what random although UNIX seemed to hit them. DEC envisioned it as a commercial machine and added decimal arithmetic to it for RSTS Cobol.​ I'm not sure RSX was even supported on it. > Ah, RSTS...the Really Sh-ty Timesharing System. An amusing UNIX story on that one. Hopkins EE department was a RSTS shop running primarily the Basic Plus interpreter which was the core of some classroom courses (especially the Freshman course: Modeling and Simulation). When the the guys found out about UNIX they lobbied the department faculty to switch to UNIX and they were told they could provided that Basic Plus continued to run. Amusingly, if you read the DEC processor handbook, it says the TRAP instruction is designed to invoke system calls. UNIX did this of course. Amuslingly, the DEC operating systems, including RSTS, used EMT to invoke system calls. The book says this was put there to allow emulating other OSs. Well this made it relatively easy. Basic Plus was calling EMT so they just had to catch the EMT traps and emulate the few RSTS calls that Basic Plus needed to make. JHU/UNIX was born. It was a Version 6 UNIX (which original system administrator John Day decided that 6.06 was a great version number and he kept it through many software updates). Mike took over and stared advancing the numbers again. We also had an 11/40 (lacking memory management) running miniUnix. They also ran miniUNIX in the Biomedical engineering lab on an LSI-11/03. I upgraded that lab to 11/23 running full up UNIX later on. You may recall that the UID was stored in a (unsigned) char in those days. This was problematic when you had a student body of a couple of thousand. The solution was a kludge: "JHU Ownership." If your GID was over 200, both your UID and GID were considered when computing identity. Obviously, newgrp was disabled for those accounts and I spent many an hour trying various combinations of setuid/gid bits and setuid/gid calls to see if there were any way to abuse that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Wed Oct 29 03:46:44 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 28 Oct 2014 18:46:44 +0100 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: References: Message-ID: <544FD684.6090001@update.uu.se> On 2014-10-28 13:42, Clem Cole wrote: > yes: > http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci Cool. I knew CMU did a lot of things with 11/40 machines. I didn't know they had modified them to be able to write their own microcode, but thinking about it, it should have been obvious. As they did multiprocessor systems based on the 11/40, they would have had to modify the microcode anyway. > I had a 60 running v7 years later. we also toyed with adding CSV/CRET > but never did it because we got an 11/70 >> >On Oct 27, 2014, at 9:09 PM, Dave Horsfall wrote: >> > >>> >>On Mon, 27 Oct 2014, Clem Cole wrote: >>> >> >>> >>[...] because the CMU 11/40E had special CSV/CRET microcode which we >>> >>could not use on the 11/34. >> > >> >The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60 >> >was micro-programmable; I never did get around to implementing CSV/CRET on >> >our 60 (Digital had a bunch of them when a contract with a publishing >> >house fell through). DEC actually made two PDP-11s that were micro programmable. The 11/60 and the 11/03 (if I remember right). DEC never had microprogramming for the 11/40, but obviously CMU did that. Ronald Natalie wrote: >> >On Oct 27, 2014, at 10:06 PM, Clem Cole wrote: >> > >> >yes:http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci >> > >> >I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it because we got an 11/70 > Problem with the 60 was it lacked Split I/D (as did the 40's). We kind of relied on that for the kernels towards the end of the PDP-11 days, > We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along. We just didn't have enough segments to handle all the overlaying needed to do. I recycled all the non split-I/D machines into BRL GATEWAYS. > > Of course, there was the famous (or imfamous) MARK instruction. This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller. I know of no compiler (either DEC-written or UNIX) that used the silly thing. It obviously wouldn't work in split I/D mode anyhow. Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK. Me and one other PDP-11 trivia guy are going "What? No mark instruction?" in the back of the room. Yurg... The MARK instruction was just silly. I never knew of anyone who actually used it. Rumors have it that DEC just came up with it to be able to extend some patent for a few more years related to the whole PDP-11 architecture. Clem Cole wrote: >> >Problem with the 60 was it lacked Split I/D (as did the 40's). > > ?A problem was that it was 40 class processor and as you says that means it > was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit. > The 60 has went into history as the machine that went from product to > "traditional products" faster than any other DEC product (IIRC 9 months). > I'm always surprised to hear of folks that had them because so few were > actually made. I picked up four 11/60 machines from a place in the late 80s. I still have a complete set of CPU cards, but threw the last machine away about 10 years ago. > I've forgotten the details nows, but they also had some issues when running > UNIX. Steve Glaser and I chased those for a long time. The 60 had the HCM > instruction sequences (halt a confuse microcode) which were some what > random although UNIX seemed to hit them. DEC envisioned it as a commercial > machine and added decimal arithmetic to it for RSTS Cobol.? I'm not sure > RSX was even supported on it. RSX-11M supports it. So do RSTS/E and RT-11. RSX-11M-PLUS obviously don't, since it have a minimal requirement of 22-bit addressing. The microcode specific instructions are interesting. But in general shouldn't crash things, but of course kernel is a different story. :-) Johnny From ron at ronnatalie.com Wed Oct 29 03:57:17 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 13:57:17 -0400 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: <544FD684.6090001@update.uu.se> References: <544FD684.6090001@update.uu.se> Message-ID: <873F0C73-0DD5-4138-9B23-DC060DCAE20D@ronnatalie.com> > > I picked up four 11/60 machines from a place in the late 80s. I still have a complete set of CPU cards, but threw the last machine away about 10 years ago. Chuckle. My wife would kill me. I finally got rid of the ASR-37 (you know a real UNIX teletype complete with a big NEWLINE key and able to interpret those ESC-8 and ESC-9 things that nroff outputs by default) decades ago (RS tells me he left it blocking someone's car in at Sprint or something, I disavow all knowledge of it). While at BRL I was the king of the surplus PDP-11. Any time a PDP-11 came up surplus I recycled it into internet routers. Sometimes I took the older machines for either their RK05 or RL02 drives, or just the racks. I got a call up from surplus people asking me about this $100,000 worth of computer equipment I had turned in and needed to come over and identify. What $100,000 worth of computer equipment? It says here "One PDP-11/40 and accessories." That thing is 16 years old. That's the price the government paid for it then. Do you know how much a 16 year old computer is worth? (especially one that had been stripped of just about everything but the CPU box itself). From ron at ronnatalie.com Wed Oct 29 03:58:03 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 13:58:03 -0400 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: <544FD684.6090001@update.uu.se> References: <544FD684.6090001@update.uu.se> Message-ID: <0C36721E-ADCE-4119-B157-1A3F464CF8B9@ronnatalie.com> Found a manual for the WCS for the 11/03...http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1103/EK-KUV11-TM_LSI11_WCS.pdf Amusing reading From clemc at ccc.com Wed Oct 29 04:22:00 2014 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Oct 2014 14:22:00 -0400 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: <544FD684.6090001@update.uu.se> References: <544FD684.6090001@update.uu.se> Message-ID: On Tue, Oct 28, 2014 at 1:46 PM, Johnny Billquist wrote: > DEC actually made two PDP-11s that were micro programmable. The 11/60 and > the 11/03 (if I remember right). DEC never had microprogramming for the > 11/40, but obviously CMU did that. C.mmp was 11/40E's and C.m* was LSI/11's and both needed them for the capabilities support. I never really got to mess with the WCS units - although we learned about them (along with ISPL/ISPS in courses), I did hack on the OS and in user space of both systems - which was a wonderful experience. It was how I learned about capabilities which I still have soft spot. But around that time, I was also introduced to this strange new system language and system and started to get paid better as a programmer for a group using it. I never went back ;-) As an a side, Wulf's dedication in the Hydra (C.mmp's OS) Book: "To the designers and builders of *real* programming systems." BTW: the 780 & 750 had ustore but it was not user documented and the tools were internal. Paul Guilbo wrote much of both and later would write the uCode for the Masscomp FPU and APU. Paul was bitching about the great tool(s) they had had at DEC, so one weekend two of us on the SW team got sick of his bitching a couple of us hacked up a uCode assembler in the same key in Yacc/lex/C (not BLISS ;-). Later when a couple of ex-PRISM guys started a firm in California there was an underground trade (i.e. no management knew about it). We were both using the same EE/CAD systems and we traded them some libraries for our uCode tools. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Oct 29 04:39:33 2014 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Oct 2014 14:39:33 -0400 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: References: <544FD684.6090001@update.uu.se> Message-ID: > On Oct 28, 2014, at 2:22 PM, Clem Cole wrote: > > > BTW: the 780 & 750 had ustore but it was not user documented and the tools were internal. Paul Guilbo wrote much of both and later would write the uCode for the Masscomp FPU and APU. Paul was bitching about the great tool(s) they had had at DEC, so one weekend two of us on the SW team got sick of his bitching a couple of us hacked up a uCode assembler in the same key in Yacc/lex/C (not BLISS ;-). Apparently they were at least advertised as available for the 780. http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Oct 29 05:03:53 2014 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Oct 2014 15:03:53 -0400 Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers) In-Reply-To: References: <544FD684.6090001@update.uu.se> Message-ID: That SPF shows a date of 1987. Masscomp was '83 for the FP and 84 for the APU and I know we could not get them - but then again KO was mad at us. At that point we had more of the 780 HW guys then DEC did, plus a bunch of ex-VMS and ex-LDP folks. The nasty-gram letter from Ken was framed and hung out the office of one of the VPs (I wonder if Palmer of one of the other Masscomp pack rats still has a picture of it). I know we tried to get it for our Vax, and it was a clear - no way. On Tue, Oct 28, 2014 at 2:39 PM, Ronald Natalie wrote: > > On Oct 28, 2014, at 2:22 PM, Clem Cole wrote: > > > BTW: the 780 & 750 had ustore but it was not user documented and the tools > were internal. Paul Guilbo wrote much of both and later would write the > uCode for the Masscomp FPU and APU. Paul was bitching about the great > tool(s) they had had at DEC, so one weekend two of us on the SW team got > sick of his bitching a couple of us hacked up a uCode assembler in the same > key in Yacc/lex/C (not BLISS ;-). > > > Apparently they were at least advertised as available for the 780. > http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at mercury.ccil.org Wed Oct 29 08:02:50 2014 From: cowan at mercury.ccil.org (John Cowan) Date: Tue, 28 Oct 2014 18:02:50 -0400 Subject: [TUHS] speaking of early C compilers In-Reply-To: <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com> References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE> <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com> <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com> <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com> Message-ID: <20141028220250.GC3885@mercury.ccil.org> Ronald Natalie scripsit: > Amusingly, if you read the DEC processor handbook, it says the TRAP > instruction is designed to invoke system calls. UNIX did this > of course. Amuslingly, the DEC operating systems, including RSTS, > used EMT to invoke system calls. The book says this was put there > to allow emulating other OSs. Well this made it relatively easy. Unless I have utterly forgotten, EMT was to be used by DEC and TRAP by users. Since Bell Labs was a user, they used TRAP (I asked ken -- I think it was ken, definitely not Ken -- about this). Of course, DEC didn't anticipate that any user would write an operating system! On RSTS/E as opposed to RSTS, both EMT and TRAP went to the user executive. To reach the kernel, you did EMT 377 followed by another EMT, but EMT 377; EMT 377 was vectored back to the user as an EMT 377. That's what allowed RSTS/E to host other OSes that used EMT. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Nobody expects the RESTifarian Inquisition! Our chief weapon is surprise ... surprise and tedium ... tedium and surprise .... Our two weapons are tedium and surprise ... and ruthless disregard for unpleasant facts.... Our three weapons are tedium, surprise, and ruthless disregard ... and an almost fanatical devotion to Roy Fielding.... From bqt at update.uu.se Wed Oct 29 08:48:10 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 28 Oct 2014 23:48:10 +0100 Subject: [TUHS] 11/40E and 11/60 In-Reply-To: References: <544FD684.6090001@update.uu.se> Message-ID: <54501D2A.30607@update.uu.se> On 2014-10-28 19:22, Clem Cole wrote: > > On Tue, Oct 28, 2014 at 1:46 PM, Johnny Billquist > wrote: > > DEC actually made two PDP-11s that were micro programmable. The > 11/60 and the 11/03 (if I remember right). DEC never had > microprogramming for the 11/40, but obviously CMU did that. > > > C.mmp was 11/40E's and C.m* was LSI/11's and both needed them for the > capabilities support. I never really got to mess with the WCS units - > although we learned about them (along with ISPL/ISPS in courses), I did > hack on the OS and in user space of both systems - which was a wonderful > experience. It was how I learned about capabilities which I still have > soft spot. But around that time, I was also introduced to this strange > new system language and system and started to get paid better as a > programmer for a group using it. I never went back ;-) Yeah, it was the C.mmp I was thinking of when I said that CMU obviously had to have been playing at this. > BTW: the 780 & 750 had ustore but it was not user documented and the > tools were internal. Paul Guilbo wrote much of both and later would > write the uCode for the Masscomp FPU and APU. Paul was bitching about > the great tool(s) they had had at DEC, so one weekend two of us on the > SW team got sick of his bitching a couple of us hacked up a uCode > assembler in the same key in Yacc/lex/C (not BLISS ;-). :-) As someone else mentioned, the 11/780 had a separate product for user written microcode. I think it actually also included a different board for the CPU, with more memory for the microcode. So it must have been documented externally somehow, somewhere. The 11/750 was not documented for external use, I think. However, I have some vague memory of seeing something about user written microcode for it as well. And of course, Ultrix had a microcode patch for the 11/750, which fixed some bugs in a couple of instructions. This microcode patch is still included in the NetBSD/vax distribution. :-) The 86x0 machines always loaded microcode from the FE RL02, and there is documentation on that microcode available today, although it was DEC internal at the time. And I still happen to have access to an 8650. But no time to actually try and play with the microcode. And that machine is rather complex as well. That's when things started to get pipelined and other stuff that makes things much more difficult to fool around with. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Wed Oct 29 08:54:43 2014 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 28 Oct 2014 23:54:43 +0100 Subject: [TUHS] 11/40E and 11/60 In-Reply-To: References: <544FD684.6090001@update.uu.se> Message-ID: <54501EB3.5030205@update.uu.se> On 2014-10-28 20:03, Clem Cole wrote: > That SPF shows a date of 1987. Masscomp was '83 for the FP and 84 for > the APU and I know we could not get them - but then again KO was mad at > us. At that point we had more of the 780 HW guys then DEC did, plus a > bunch of ex-VMS and ex-LDP folks. The nasty-gram letter from Ken was > framed and hung out the office of one of the VPs (I wonder if Palmer of > one of the other Masscomp pack rats still has a picture of it). > > I know we tried to get it for our Vax, and it was a clear - no way. That SPD is from 1987, true. But that is for version 3.0... I know that the user microcode option for the 11/780 is really much older than that. But I wonder how many actually ever purchased it? Johnny > > On Tue, Oct 28, 2014 at 2:39 PM, Ronald Natalie > wrote: > > >> On Oct 28, 2014, at 2:22 PM, Clem Cole > > wrote: >> >> >> BTW: the 780 & 750 had ustore but it was not user documented and >> the tools were internal. Paul Guilbo wrote much of both and >> later would write the uCode for the Masscomp FPU and APU. Paul >> was bitching about the great tool(s) they had had at DEC, so one >> weekend two of us on the SW team got sick of his bitching a couple >> of us hacked up a uCode assembler in the same key in Yacc/lex/C >> (not BLISS ;-). > > Apparently they were at least advertised as available for the 780. > http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF > > > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol