[Unix-jun72] C compiler status

[Unix-jun72] C compiler status

[Warren Toomey]

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

[Unix-jun72] C compiler status

[Tim Newsham]

> 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/

[Unix-jun72] C compiler status

[Warren Toomey]

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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72

[Unix-jun72] C compiler status

[Warren Toomey]

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

[Unix-jun72] C compiler: it works!

[Warren Toomey]

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

[Unix-jun72] C compiler: it works!

[Warren Toomey]

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

[Unix-jun72] C compiler status

[Tim Newsham]

> 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/