TUHS

tuhs@tuhs.org

12 participants
6534 discussions

Re: [TUHS] speaking of early C compilers

by Norman Wilson

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

10 years, 8 months

Re: [TUHS] speaking of early C compilers

by Jason Stevens

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(a)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 <jsteve(a)superglobalmegacorp.com> 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(a)minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 8 months

Re: [TUHS] speaking of early C compilers

by jnc＠mercury.lcs.mit.edu

> From: random832(a)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

10 years, 8 months

Re: [TUHS] Getting Unix v5 to talk

by Jason Stevens

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(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 8 months

Re: [TUHS] Codata progress update

by jnc＠mercury.lcs.mit.edu

> From: "Engel, Michael" <M.Engel(a)leedsbeckett.ac.uk> > 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

10 years, 8 months

Codata progress update

by Engel, Michael

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

10 years, 8 months

Re: [TUHS] early cc variable and function names

by jnc＠mercury.lcs.mit.edu

> From: Greg 'groggy' Lehey <grog(a)lemis.com> > 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

10 years, 8 months

early cc variable and function names

by Mark Longridge

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

10 years, 8 months

Re: [TUHS] early cc variable and function names

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > 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

10 years, 8 months

3BSD/32V: 2 RP06 (SIMH)

by Cory Smelosky

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

10 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS