[Coco] Fwd: MW-C Cross compiler bug - Solved

[Gene Heskett]

On Monday 10 March 2014 00:15:33 Gene Heskett did opine:

> On Sunday 09 March 2014 23:57:12 Willard Goosey did opine:
> > On Sun, Mar 09, 2014 at 04:58:01PM -0400, Gene Heskett wrote:
> > > I believe Willard Goosey did the last version of it, cprep19b I
> > > believe.
> > 
> > Yes.  I believe, however, the cross compiler is still using your
> > cprep19. I would really recommend bringing over 19b for the structure
> > element names fix.
> > 
> > I haven't done anything with my copy of the cross compiler. I can try
> > to get it working and then see if I can bring cprep19b over to it, but
> > don't hold your breath.
> > 
> > Willard
> 
> I am not, but neither am I looking at the problem that closely.  The MRI
> on my lower back confirmed what I already knew.  Its a mess.  So its
> hard to concentrate on that when you are in constant pain.
> 
> In a way, if there are further bug-fixes and improvements to be made, I
> am glad to stand aside and cheer whoever gets a grip on what its
> supposed to do and makes it do it better.  So I salute you and thank
> you for the effort.  You, like me at the time, were "scratching an
> itch".
> 
> Small joke, teachers ask a student why he is scratching, and he reply's
> that he is the only one who knows where he itches...
> 
> 
> Cheers, Gene

More along this thread, I sicced "find" off to find clib.l on my machine, 
and found on that I had apparently rebuilt for some reason I don't recall 
now after 19 years, ran an rdump on it, and by golly, it does have a 
memmove_a in it:

Module name: memmove_a
TyLa/RvAt:   00/00
Asm valid:   Yes
Create date: Jun 29, 1995 14:20
Edition/ROF:  0/1
  Section    Init Uninit
   Code:     0040
     DP:       00   00
   Data:     0000 0000
  Stack:     0000
Entry point: 0000

So, if cprep19b can do it, the code IS there.

It may have been module order and I was trying to get something to build in 
one pass because our present c.link, only scans a library once, and I'd 
found I had to name the library more than once on the command line from cc 
in order for it to find, resolve and link in, all the back references in 
the code stream.

Frankly I don't think Microware ever tested this whole package with a 
source tree that ran to more than 8 or 9 kilobytes with includes.  It sure 
fell apart and generated crash-o-matic code when I first tried to build 
rzsz with it, as the sources for both rz and sz run to about 40 kb with all 
the includes.  About that time, a student named Matt Thompson started 
publishing a from scratch replacement, got a good grade from his prof & 
went on, so I emailed him & asked permission to continue working on it and 
was told to help myself.  That was at about version 15.  By the time I had 
it working for me, it was up to 19 & up till Willard got an itch, we've 
been using it.  With cntx (I didn't write that from scratch either, but 
started with somebody else's code there too) checking my syntax for proper 
pairing of (), [], {} etc, I managed to write several bits of code that 
have come in handy in their heyday.  Now we are asking it to be built with 
a cross-compiler on linux, so the size limits are expanding yet again.

So I am encouraged that we might have a renewal of interest in coding in C.

Side comment:  This cpu doesn't have a "barrel shifter" for bit shift ops, 
so the compiler can generate some pretty horrible, slow code by using 
loops.

BUT, if you are willing to stop the compiler at the output stage that will 
be fed on to rma or (spit) c.asm, there are some quite useful speedup 
tricks that can be edited into the assembly code at that (output of 
c.pass2) point, by bypassing 8 passes through this loop when an 8 bit or 
more shift is needed because the exact same result can be had (depending on 
which direction the shift is of course) by "tfr a,b;clra" or "tfr b,a; 
clrb" which only takes 9 or 10 cycles, where one pass through the loop to 
shift it one bit is 40+ cycles.

That, and the 16 bit crc's rzsz uses by compiled in lookup tables gained me 
about a 35% speedup in the cps rate in the most recent rzsz-3.36.  A stock 
coco3/6809 machine without those, would move a file at about 375 cps.  With 
those "patches", and a 6309 running in 6309 mode, the most recent speeds I 
have seen are in the 640 cps range. IMO that was worth the effort at the 
time.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>