[Coco] Coco Digest, Vol 49, Issue 20

[Bob Devries]

Paul,

Can you run IDENT on the modules in your c compiler CMDS directory, and make 
sure there's no problem there?

Just a thought...

--
Regards, Bob Devries, Dalby, Queensland, Australia

Isaiah 50:4 The sovereign Lord has given me
the capacity to be his spokesman,
so that I know how to help the weary.

website: http://www.home.gil.com.au/~bdevasl
my blog: http://bdevries.invigorated.org/

----- Original Message ----- 
From: "Paul Fitch" <pfitchjr at bellsouth.net>
To: <coco at maltedmedia.com>
Sent: Monday, August 06, 2007 1:24 PM
Subject: Re: [Coco] Coco Digest, Vol 49, Issue 20


>
>> 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.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco