I'm still working on the last1120 C compiler, so I've added the original code
to svn. Right now, the compiler executes fine under Apout (enough to recompile
itself), but not on V1 with the 0407 patch. I can compile simple C programs,
and execute the resulting 0407 binary on V1. I'm running this program to get a
memory dump of the process while it is running:
main()
{
char c[];
int i;
printf("Hello world\n");
c= main;
while (c != 0) {
i= *c & 0277;
printf("%o %o\n", c, i);
c++;
}
}
so I can compare the Apout memory environment with the V1 memory environment.
But it's very sloooow. I wonder why; V7 on simh is much faster than V1.
Cheers,
Warren
P.S The C compiler doesn't have for loops :-)
In the svn repository, patches/upcase.patch now fixes the kernel so
that CR is converted into LF. This means that you don't have to type ^J
in any more.
Warren
I removed some older tools from the svn. If you're still using them
and want to hold on to them, you might want to back up your copy
before updating, or pull old versions from svn (feel free to send
me questions if you are unsure how).
Assemv7 and assem went away as did dumpaout.py.
Tim Newsham
http://www.thenewsh.com/~newsham/
Would people mind if I imported apout src code into svn under tools/?
It's 35 files, 280K. I've fixed one small bug, and as we use it a lot it
might be good that you can get the latest version.
Warren
I just tried this command and got this output. Any ideas?
Warren
# who bin
).. Jan 1 13:02:48
b Dec 17 21:22:33
:. Jan 6 04:04:20
Jan 1 00:00:00
s1c Jan 2 08:46:04
2cat Jan 1 15:35:29
e Jan 2 08:27:52
chmod6 Dec 3 20:05:51
Jan 1 00:00:00
d Nov 24 08:05:49
:db Jan 1 18:01:07
Jan 1 00:00:00
ds> Jan 9 10:39:19
Jan 1 00:00:01
hoAe Jan 1 00:00:00
Bexit Jan 1 20:26:45
n Jan 1 00:00:00
formF Dec 26 13:00:28
Jan 1 00:00:01
l Jan 1 00:00:00
Jlogin Jan 1 22:53:32
i Jan 1 00:00:00
makiN Nov 24 06:05:45
r Jan 1 00:00:01
n Jan 1 00:00:00
Rod Jan 2 01:19:06
w Jan 1 00:00:00
rmV Dec 20 04:59:37
Jan 1 00:00:01
s Nov 24 09:55:03
Zskip Jan 2 03:44:31
a Jan 1 00:00:00
strip^ Jan 12 21:01:19
Jan 1 00:00:01
mat Jan 2 09:58:53
btm Jan 2 06:10:31
Jan 1 00:00:00
wcf Dec 4 02:01:29
e Jan 1 00:00:01
In the V1 filesystem, there are a few files are owned by users which are
not in the /etc/passwd or /etc/uids files:
xrwr- 6 2860 169 Mar 7 12:23 /bin/cal
xrwr- 4 7154 61 Jul 21 12:42 /bin/roff
-rwr- 28 304 448 Jun 30 20:31 /usr/lib/fr0.o
-rwr- 28 12222 449 Jun 30 20:37 /usr/lib/filib.a
-rwr- 28 9158 419 Jun 30 20:46 /usr/lib/libf.a
xrwr- 28 3462 491 Jul 1 16:35 /usr/fort/fc1
xrwr- 28 3238 498 Jul 1 16:35 /usr/fort/fc2
xrwr- 28 6840 505 Jul 1 16:35 /usr/fort/fc3
xrwr- 28 4918 519 Jul 1 16:35 /usr/fort/fc4
Now, I know that ken worked on the Fortran compiler, Joe Ossanna (jfo)
wrote roff, and in V6 & V7, ken had uid 6 and dmr had uid 7. So I
propose the following:
- add ken == 6, dmr == 7, jfo == 4 to /etc/passwd and /etc/uids, as
new files in fs/new. Thus jfo will own /bin/roff and ken will own
/bin/cal
- modify the permissions file so that the Fortran files which are
uid 28 become uid 6 == ken.
Sound reasonable?
Cheers,
Warren
Now that we have the V1 and V2 binaries in the svn tree, I thought I would
try to use the V2 assembler to build the kernel, instead of the V7 one.
After a bit of experimentation, I got it to work. It means we can remove
our dependency on the V7 assembler.
I've committed tools/assemv2, the script to build with V2 as, and a patch
to redefine $mount and $gtty.
It probably means that we could rebuild the kernel while running V1; I
haven't tried this as yet.
Cheers,
Warren
I think it would be a good idea to import the V1 / and /usr filesystem from
the s2 tape into the subversion repository, so that we can write a tools/
script to build "known good" rf0.dsk and rk1.dsk disk images.
In my private tree I have 1root/ and 1usr/, but perhaps we should have
something like fs/root/ and fs/usr. They need to be split so that my
mkfs tool can build separate disk images.
Comments?
Warren
