* [Unix-jun72] Observations about this ancient C dialect
2008-05-15 1:46 [Unix-jun72] s1 fragments are now in the svn repository Warren Toomey
2008-05-15 2:34 ` Warren Toomey
@ 2008-05-15 3:03 ` Doug Merritt
1 sibling, 0 replies; 3+ messages in thread
From: Doug Merritt @ 2008-05-15 3:03 UTC (permalink / raw)
Warren wrote:
> Remember, the C files will not compile with the existing
compiler.
For your amusement, and in case it helps, below are the notes I took
on observations on the weirdness of this old C, from reading the C
files and the C compiler source code the first day of my start on
this project (Apr 18 -- long, long ago :-)
E.g. the "C preprocessor" didn't exist at the time, but
an "expand()" function was called on lines starting with '%',
to perform a non-recursive file inclusion.
(BTW I've spoken with John Reiser since then to check some history.
He said he arrived at BTL in 1977, and did much rewriting of cpp
largely because it was a buggy crock. That places him significantly
later than my previous understanding; I had thought he implemented
the original cpp championed by Snyder and designed by Lesk, but
perhaps...but no, Lesk wouldn't have cranked out cruft. Hmm. Some
years ago Snyder more or less told me me he denied much involvement
in cpp, beyond pitching the idea of macro processing. Could mean
any number of things. :-) Always seemed strange, though, since
McIlroy is the one with a large historical presence associated with
macro processing. History is confusing.)
I've used the pre-stdio "portable I/O library", although my
notes don't indicate so, and there are other real or apparent
signs of cluelessness. My own Unix involvement originally
went back only as far as version 6, and my memory is imperfect
anyway.
And there are plain errors. This is as-is.
See below.
Doug
--
Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow
--------------------------------- cut here ------------------------
form1.s: daytab gives 29 days to february (changed to 28 in Unix v5 s1/form1.s),
perhaps confirming that this source code is from 1972 in particular,
which was a leap year.
cc.c:
Exactly 2 flags (other cmd line "-" treated as input files):
-c produce .o, as today
-2 Use Fortran startup,loader ( /lib/crt20.o )
callsys("/usr/lib/ld20", av);
library:
av[2] = "/lib/20.s";
callsys("/bin/ld", av);
No C preprocessor; function expand() does include files
marked by input lines starting with '%'
Non-recursive.
Appends SOH after each newline. Weird.
Verbose; if more than 1 c file, then:
printf("%s:\n", clist[i]);
Automatically sets -c flag if expand() fails.
(cflag causes early abort, no later stages)
...ah, that just means "early exit"
if (av[1] == 0) {
cflag++;
Passes:
av[0] = "c0";
av[1] = expand(clist[i]);
if (callsys("/lib/c0", av)) {
if(callsys("/lib/c1", av)) {
callsys("/bin/as", av);
moves .o to a.out before calling ld
callsys("/bin/ld", av);
tmp files:
tries /tmp/ctm0[a...] until finds nonexisting creatable name
That one is just used as filesys lock on this range of names
Then uses /tmp/ctm[1..4]a for pass tmp files
No '=' for init, e.g.
char *tmp0 "//";
Exotic keyboard interrupt handling:
intr(delfil);
...
delfil:
dexit();
Single '&', '|' used for both bitwise and logical, e.g.
return((status>>8) & 0377);
if (nc==1 & nl==1)
if(link("a.out", t) | unlink("a.out")) {
Old style op-equals, e.g.
s =- 3;
Exotic file I/O, 259 int buffers:
int ibuf1[259], ibuf2[259], obuf[259];
if (fopen(file, ibuf1)<0) ...
if (getc(ibuf1) != '%') {
if (fcreat(tmp4, obuf) < 0) {
while((creat(tmp0, 012))<0)
tmp0[9]++;
Buf struct:
ibuf1[1]++; /* back up over % */
ibuf1[2]--;
So file buf[1] -> avail count
file buf[2] -> first char index/ptr
getc() decremented the first, incremented the second
file buf[3] must hold the file descriptor
Same process management as today; callsys uses:
if ((t=fork())==0) {
execv(f, v);
printf("Can't find %s\n", f);
exit(1);
} else
if (t == -1) {
printf("Try again\n");
return(1);
}
while(t!=wait(&status));
if ((t=(status&0377)) != 0 & t!=14) {
if (t!=12) /* interrupt */
printf("Fatal error in %s\n", f);
dexit();
}
return((status>>8) & 0377);
cp.c:
No structures; just array of int
fstat(fold,buf);
mode = buf[2] & 037;
Return status survives func call, used as exit code:
fstat(fnew,buf);
exit();
ls.s:
Uses both "jsr, r5" (mostly) and also 3 "jsr pc":
jsr pc,ctime # external func
jsr pc,puid # local func
jsr pc,do # local func
I think pc is with stack params and r5 is with funky
param-in-next slot after jsr, mostly
Indication of structure of stat() buffer ("dska" is perhaps
"disk address"? "dska" also appears in frag0):
mov (r0)+,(r1)+ /flags
mov (r0)+,(r1)+ /nlinks, uid
mov r0,-(sp)
mov (r0),r0
jsr r5,calcb
add r0,tblocks
mov (sp)+,r0
mov (r0)+,(r1)+ /size
add $20.,r0 /dska, ctim
mov (r0)+,(r1)+ /mtim
mov (r0)+,(r1)+
mov statb,(r1)+ /inode
uniq -d, -u:
Routines defined and used within ls.s:
calcb
decimal
do
gstat
mode
pentry
pstring
puid
questf
Routines defined but not called:
eloop # branch target
euidbuf # data synonym
listl # branch target
loop # branch target
nondir # branch target
pass2 # branch target
pass3 # unused branch target
Routines called but not defined:
ctime
flush
fopen
getc
getw
putc
^ permalink raw reply [flat|nested] 3+ messages in thread