[Coco] Coco Digest, Vol 49, Issue 20

[Paul Fitch]

> From: Gene Heskett <gene.heskett at verizon.net>
> Subject: Re: [Coco] c.pass1 and Nitros9 6309 v030206
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <200708052145.54374.gene.heskett at verizon.net>
> Content-Type: text/plain; charset=iso-8859-1
> 
> On Sunday 05 August 2007, Paul Fitch wrote:
> >I'm seeing some odd behavior here.  I'm compiling Rick Adams 
> CC2 with the
> >stock CC1 patched for /dd.  I also patched c.prep for /dd.
> >I made changes to Ricks CC2 so that it would use RMA and 
> RLINK once it was
> >compiled, but I'm letting c.asm and c.link do the work the first time
> >through.
> >
> >
> >I type in "cc1 cc2.c" and the compile crashes almost immediately.  It
> >crashes under both VCC and MESS104.  When I say crash, I 
> don't mean it
> >errors out, I mean my screen gets filled with all sorts of 
> trash and I have
> >to hard reset and reboot.
> >
> >Now, cc1 does appear to run OK.  The following files are 
> generated c.com,
> >ctmp.3.m and ctmp.3.i.
> >C.com looks likes a batch file to do the compile, and 
> ctmp.3.m looks like
> >cc2.c without all the pretty formatting.  Ctmp.3.i is a 0 
> length file.
> >
> >Just before the compile crashes I can see that cc1 and 
> c.prep are completed,
> >and c.pass1 starts.  Then everybody dies.
> >
> >So, for suspects I have the following:
> >1) something in the emulation doesn't like c.pass1  <--- Not 
> very likely
> >considering all the other software that runs happily under emulation.
> >2) something in c.pass1 doesn't like the 6309, but to stomp 
> all over the
> >operating system like it does, it would have to me something 
> major I'm sure
> >I'd have heard about before now.
> >3) something in c.pass1 doesn't like Nitros9.  Same response as #2.
> >
> >Any thoughts?
> 
> Yes, this is one of the classic (if it quacks its probably a 
> duck) symptoms of 
> the src file being too big for the original c.prep.  It 
> generates code that 
> falls over once the src file exceeds about 8k-12k, depending 
> on how many vars 
> it has to track.  I also believe its 'scope' of memory for 
> these vars is 
> broken but never really tried to test it specifically for that.
> 
> Replace it with the c.prep in c.prep19.lzh. (see 
> os9archive.rtsi.com) I hope 
> and think this will fix it for you.
> 
> Scopewise, the version I sort of inherited from Matthew 
> (Thompson?, he of 
> scsisys fame) purportedly had the scope problems fixed, so 
> the expansions I 
> did in the next 3 releases concentrated on allowing it to use 
> more memory for 
> var storage, which in turn allowed it to handle larger 
> collations of src.  It 
> is after all, c.preps job to not only #include all the header 
> files into its 
> output stream, and to insert all the #define 'var's in the 
> right places by 
> substitution in the output stream data, but to keep track of 
> all the vars 
> used.
> 
> Yes, I had a hand in that code, and it was the difference 
> between being able 
> to build the rz/sz you may be using for file transfers, or building a 
> crash-o-matic.  That src code totals about 34k IIRC for each 
> of rz and sz.
> 
> -- 
> 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)
> When angry, count four; when very angry, swear.
>
Tried that Gene, no go.  But, I think you misread my post.  C.prep isn't
dying, c.pass1 is.  And somehow, VCC and MESS are crashing.  Or rather the
emulation is.

Under VCC I can watch the disk reads and writes during the c.prep phase.
Seems to be working.  Then c.pass1 starts, the disk goes idle, and then
(this is weird) the reported cpu speed drops to .89Mhz from 1.7Mhz, and the
computer is now locked up.

I've run just the following line, and it crashed the VCC and MESS emulations
of the COCO36309 everytime:

c.pass1 ctmp.3.m -o=ctmp.3.i

ctmp.3.m has a bytecount of 142b
cc2.c has a bytecount of 1e85

Somehow, I don't think it's a file size thing.