[Coco] Coco Digest, Vol 49, Issue 20

[Gene Heskett]

On Sunday 05 August 2007, Paul Fitch wrote:
>> 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.

Possibly.  I at first read it as the finished program crashed, which is the 
trademark of the original c.prep.

>C.prep isn't 
>dying, c.pass1 is.  And somehow, VCC and MESS are crashing.  Or rather the
>emulation is.

Its possible c.prep could generate something that c.pass1 (or c.comp) might 
get upset over, but that's not a condition I ever triggered.

>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

ctmp.3.m _should_ be nothing more nor less than the input src stream with the 
includes & defines etc all merged in the order encountered, with defined 
substitutions for var name values.  I don't think it should contain any 
non-printable characters other than the EOL (chr$(13)) unless there are 
#defines in the src for them as constants or that sort of thing.  In other 
words, that file should be human readable.  Is it?

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

No, at $142b, that's pretty small to trigger c.prep19's more or less silent 
buffer overflow.


-- 
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)
Established technology tends to persist in the face of new technology.
		-- G. Blaauw, one of the designers of System 360