5 May
2008
5 May
'08
6:08 a.m.
Still no great progress. I can confirm that "cc" and "cvopt" both
work, but
the two compiler passes "c1" and "c2" don't work. Sometimes I can
get them
to core, but with different arguments the system locks up.
On http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html, Dennis notes this:
A second, less noticeable, but astonishing peculiarity is
the space allocation: temporary storage is allocated that
deliberately overwrites the beginning of the program,
smashing its initialization code to save space. The two
compilers differ in the details in how they cope with this.
In the earlier one, the start is found by naming a function;
in the later, the start is simply taken to be 0. This
indicates that the first compiler was written before we had
a machine with memory mapping, so the origin of the program
was not at location 0, whereas by the time of the second,
we had a PDP-11 that did provide mapping. (See the Unix
History paper). In one of the files (prestruct-c/c10.c) the
kludgery is especially evident.
It could be that this sort of memory operation is what is causing the
problem. Is there a way for simh to give an instruction trace beginning
at a certain address e.g. 040000, so I can watch c0's behaviour and see
where it goes off the rails?
Thanks,
Warren
5 May
5 May
6:59 a.m.
It could be that this sort of memory operation is what
is causing the
problem. Is there a way for simh to give an instruction trace beginning
at a certain address e.g. 040000, so I can watch c0's behaviour and see
where it goes off the rails?
Simh has a cpu execution history which is already turned on in our
configuration file, so at any point when youre at the simh prompt
you can "show cpu history" to see the recently executed instructions.
You can also use breakpoints to do some tracing, for example:
break 1350;ex r0;go
will break at 1350, in syscall right after it figures out what syscall
number, dump r0, which has the syscall number, and continue, so that
you get a running syscall trace..
The downside to these methods is that they capture the entire operating
system, not just a single userland process... It would be nice if
we could rig the emulator to skip over context switches to other
processes.... Then again, it's probably a lot easier than debugging
with blinking lights and switches...
Warren
I suspect there are some more kernel gotchas left to be found. The
fact that "cc" doesnt work properly could be due to my 0407 patch
but could equally be another kernel typo somewhere. The fact that
init doesnt like running getty on other ttys is also making me suspect
some hidden kernel bugs... During one of my tests with "cc" I saw
it go into panic (probably good to run with a breakpoint on panic,
too! see build/a.out.syms) after syscall got reentered!
Tim Newsham
http://www.thenewsh.com/~newsham/
7:12 a.m.
On Sun, May 04, 2008 at 08:59:25PM -1000, Tim Newsham wrote:
Simh has a cpu execution history which is already
turned on in our
configuration file, so at any point when youre at the simh prompt
you can "show cpu history" to see the recently executed instructions.
Thanks Tim.
It looks like we are not starting /usr/lib/c0 properly: the CPU never gets
to execute at 040000, and we end up in sysbreak without ever calling it.
I have a CPU history from sysexec at 004250 right up to where it hits a
supposed HALT instruction in sysbreak at 005752, which previously was
CMP R1,SP.
Here's the simh and Unix commands I tried:
./simh.cfg
sim> c
:login: root
# /tmp/a.out # Mount /usr
# chdir /usr/tmp
#
Simulation stopped, PC: 007332 (MOV (SP)+,25310)
sim> break 004250
sim> c
/usr/lib/c0 z.c a b # Run pass c0 on z.c, creating a & b tempfiles
Breakpoint, PC: 004250 (JSR R0,5634)
sim> set CPU HISTORY=0
sim> set CPU HISTORY=100000
sim> continue
HALT instruction, PC: 005754 (BCC 5762)
sim> show CPU HISTORY
I won't include the history here, as it's 49,000 instructions. But if
anybody wants a look at it, let me know.
Thanks,
Warren
You can also use breakpoints to do some tracing, for example:
break 1350;ex r0;go
will break at 1350, in syscall right after it figures out what syscall
number, dump r0, which has the syscall number, and continue, so that
you get a running syscall trace..
The downside to these methods is that they capture the entire operating
system, not just a single userland process... It would be nice if
we could rig the emulator to skip over context switches to other
processes.... Then again, it's probably a lot easier than debugging
with blinking lights and switches...
Warren
I suspect there are some more kernel gotchas left to be found. The
fact that "cc" doesnt work properly could be due to my 0407 patch
but could equally be another kernel typo somewhere. The fact that
init doesnt like running getty on other ttys is also making me suspect
some hidden kernel bugs... During one of my tests with "cc" I saw
it go into panic (probably good to run with a breakpoint on panic,
too! see build/a.out.syms) after syscall got reentered!
Tim Newsham
http://www.thenewsh.com/~newsham/
_______________________________________________
Unix-jun72 mailing list
Unix-jun72(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/unix-jun72
7:50 a.m.
On Mon, May 05, 2008 at 05:12:12PM +1000, Warren Toomey wrote:
It looks like we are not starting /usr/lib/c0
properly: the CPU never gets
to execute at 040000, and we end up in sysbreak without ever calling it.
Um, just an observation: u0.s defines:
core = orig+40000 / specifies beginning of user's core
ecore = core+20000 / specifies end of user's core (4096 words)
so a user program has 020000 bytes of space; but size /usr/lib/c0 gives:
023326+03574+06640=035762, and 035762 >> 020000.
Is the value of ecore arbitrary? What's above ecore, the kernel stack?
Mind you, if we set ecore== 040000+035762, thats 075762 which doesn't
leave much room, assuming that memory on the PDP-11/20 ends at 100000.
Warren
8:02 a.m.
New subject: [Unix-jun72] C compiler: it works!
On Mon, May 05, 2008 at 05:50:17PM +1000, Warren Toomey wrote:
Um, just an observation: u0.s defines:
core = orig+40000 / specifies beginning of user's core
ecore = core+20000 / specifies end of user's core (4096 words)
so a user program has 020000 bytes of space; but size /usr/lib/c0 gives:
023326+03574+06640=035762, and 035762 >> 020000.
Is the value of ecore arbitrary?
Apparently it is. I just patched u0.s to have ecore = core+35764, and
the C compiler works! i.e. it compiles a trivial C program. Later on
after dinner, I'll try to get the compiler to recompile itself.
We still need to check the effects of ecore = core+35764, just in case.
Cheers,
Warren
8:38 a.m.
New subject: [Unix-jun72] C compiler: it works!
On Mon, May 05, 2008 at 06:02:49PM +1000, Warren Toomey wrote:
Apparently it is. I just patched u0.s to have ecore =
core+35764, and
the C compiler works! i.e. it compiles a trivial C program. Later on
after dinner, I'll try to get the compiler to recompile itself.
With ecore = core+60000, cc, cvopt and c0 can all be recompiled and
then used to recompile themselves. However, the existing c1 binary
from the s2 tape works, but not the recompiled c1. So it's close...
I will upload a couple of files to svn soon.
Warren
4:57 p.m.
Is the value of ecore arbitrary? What's above
ecore, the kernel stack?
ecore should be the top of memory on a 24k machine. If you add more
RAM, you could raise ecore, but you'd have to adjust a bunch of things
- each process has storage on rf0 allocated for it to swap to
- the core dump dumps out 8k of memory
and probably others.
Warren
Tim Newsham
http://www.thenewsh.com/~newsham/
5833
days inactive
5833
days old
6 comments
2 participants
participants (2)
-
Tim Newsham -
Warren Toomey