[Unix-jun72] last1120 C compiler added to svn

[Unix-jun72] last1120 C compiler added to svn

[Warren Toomey]

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 :-)

[Unix-jun72] last1120 C compiler added to svn

[Peter Jeremy]

On Mon, May 05, 2008 at 02:52:29PM +1000, Warren Toomey wrote:
>    i= *c & 0277;
             ^^^^ 0377 maybe

>But it's very sloooow. I wonder why; V7 on simh is much faster than V1.

Is V1 executing more instructions to get the same thing done or is simh
managing to execute V7 instruction streams (or maybe emulate higher-end
PDP-11's) better?  Judging by some of the earlier hardware comments,
maybe V1 is thrashing.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080505/80c69108/attachment.sig>

[Unix-jun72] Why is V1 so slow?

[Warren Toomey]

On Mon, May 05, 2008 at 07:10:11PM +1000, Peter Jeremy wrote:
> On Mon, May 05, 2008 at 02:52:29PM +1000, Warren Toomey wrote:
> >    i= *c & 0277;
>              ^^^^ 0377 maybe

Yep :)
 
> >But it's very sloooow. I wonder why; V7 on simh is much faster than V1.
> 
> Is V1 executing more instructions to get the same thing done or is simh
> managing to execute V7 instruction streams (or maybe emulate higher-end
> PDP-11's) better?  Judging by some of the earlier hardware comments,
> maybe V1 is thrashing.

I think there are output delays in the kernel, probably to deal with
the speed of mechanical output devices. When I use the compiler, the
compilations are fast, but doing an ls -l /bin takes ages. We might be
able to tweak out the delays.

For example, grep delay build/u9.s, and these lines in u4.s:

1:
       cmp     r1,$11 / char = ht
       bne     1f
       movb    $15.,toutt+0 / set time out to 15 clock tics
1:
       cmp     r1,$15 / char = cr
       bne     2f
       movb    $15.,toutt+0 / set time out to 15 clock ticks
2:
       rts     r0

Cheers,
	Warren

[Unix-jun72] Why is V1 so slow?

[Warren Toomey]

On Mon, May 05, 2008 at 09:36:32PM +1000, Warren Toomey wrote:
> I think there are output delays in the kernel.

There certainly were. I've svn committed a patch to remove these lines
from u4.s, and that really speeds things up!

	Warren
 
1:
       cmp     r1,$11 / char = ht
       bne     1f
       movb    $15.,toutt+0 / set time out to 15 clock tics
1:
       cmp     r1,$15 / char = cr
       bne     2f
       movb    $15.,toutt+0 / set time out to 15 clock ticks

[Unix-jun72] Why is V1 so slow?

[P.A.Osborne]

On Mon, May 05, 2008 at 09:44:18PM +1000, Warren Toomey wrote:
> On Mon, May 05, 2008 at 09:36:32PM +1000, Warren Toomey wrote:
> > I think there are output delays in the kernel.
> 
> There certainly were. I've svn committed a patch to remove these lines
> from u4.s, and that really speeds things up!

But but but surely that will be less authentic?!

:-)

Paul

[Unix-jun72] Why is V1 so slow?

[Warren Toomey]

On Wed, May 07, 2008 at 11:19:52AM +0100, P.A.Osborne wrote:
> But but but surely that will be less authentic?!

True, what was the top baud rate for an ASR33? 110, 300?

	Warren