* [Unix-jun72] s1 fragments are now in the svn repository
@ 2008-05-15 1:46 Warren Toomey
2008-05-15 2:34 ` Warren Toomey
2008-05-15 3:03 ` [Unix-jun72] Observations about this ancient C dialect Doug Merritt
0 siblings, 2 replies; 3+ messages in thread
From: Warren Toomey @ 2008-05-15 1:46 UTC (permalink / raw)
I have just spent some time reconciling the differences between Doug's s1
fragment reconstruction and mine: we both had roughly the same # of errors,
and having the other's work was great. The repository has all the files in
src/cmd. I have not tried to assemble all of them yet, so any reports here
would be good. Remember, the C files will not compile with the existing
compiler.
Cheers,
Warren
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Unix-jun72] s1 fragments are now in the svn repository
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 ` [Unix-jun72] Observations about this ancient C dialect Doug Merritt
1 sibling, 0 replies; 3+ messages in thread
From: Warren Toomey @ 2008-05-15 2:34 UTC (permalink / raw)
On Thu, May 15, 2008 at 11:46:08AM +1000, Warren Toomey wrote:
> I have just spent some time reconciling the differences between Doug's s1
> fragment reconstruction and mine: we both had roughly the same # of errors,
> and having the other's work was great. The repository has all the files in
> src/cmd. I have not tried to assemble all of them yet, so any reports here
> would be good. Remember, the C files will not compile with the existing
> compiler.
Most of the files assemble, and I've created a "mak" script to do so under
1st Edition. C files are out, they need a later language than the last1120c
compiler. We are missing some files for bas. The dc and form source uses
"new" instructions like mul and ashc, which the existing V1 "as" binary
does not understand, but the assembler in source code does understand,
so these may still be assembled.
Warren
^ permalink raw reply [flat|nested] 3+ messages in thread
* [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
end of thread, other threads:[~2008-05-15 3:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [Unix-jun72] Observations about this ancient C dialect Doug Merritt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).