[Coco] [Color Computer] Re: Cross development for 8 bits. Was: RELIC Is Coming...

[James Diffendaffer]

On Feb 28, 2007, at 2:21 PM, James Diffendaffer wrote:

>James,
>
>Sarcasm is noted as such :) Thanks for the kudos...

You're welcome.
Yeah, I've been too busy to deal with this so I'm glad someone has.

>> I'm anxious to see how good the code your compiler produces is.
>> It would be interesting to see which front end optimizes better. If
>> your compiler is based on a better front end then SDCC probably
>> wouldn't be the best choice, not for the CoCo anyway. I can't say
>> I've been thrilled with the level of activity around improving SDCC
>> beyond fixing the crashes but there appears to be a new release in the
>> works so I may change my mind.
>
>
>The front-end's code is horribly inefficient, though the trade-off is
>ease of development. The i-code optimizer which sits behind the
>front-end is where significant optimization will take place, and
>where a lot of the complexity of analyzation will be.

Your classes probably talk about the compiler sections differently and
I haven't exactly been in a compiler class lately either.

Most of the conversations I've been in lately refer to the back end as
the target code generator and peephole optimizer.  The initial front
end like you are talking about seems to be universally horrid unless
someone wants a huge complex compiler.  

Optimizations that take place in i-code will make a huge difference. 
Just think about what the output would look like if you skip this step
and you have small-c and what most early compilers generate.  It's
ugly.  Not even a peephole optimizer on the early ones.  Redundant
moves all over the place.

GCC had lots of special conditions for target code generation that
were everywhere.  I was just making changes based on differences
between an existing target and the 6809.  I was actually close to
testing it but it's such a beast I wouldn't have known where to start
if it had bugs and making optimizations... <gack>.

> I think it
>will be interesting to compare sizes of optimized vs non-optimized
>binaries, and I plan to have that demonstrated at the CoCo Fest.

I've personally seen peephole optimizers reduce fairly decent code by
over 20% if not 30% and that was just something *I* threw together in
a week to optimize 64180 code.  But then, that was in the early 90s.  

A free Amiga Pascal compiler generated horrid code and it only took be
a couple nights to cut it's output by 50%... but it was still dog slow
and unusable so I quit wasting my time.

>Will you be coming to the fest?

I'd love to but I'm in the job interview process at the moment and I'm
sure whatever I get will have be pretty busy the first month.  This is
actually the first year since 9/11 I've gotten so many contacts. 
Denver has trailed the nation in the tech recovery.

Maybe next year... and I might actually have something fun to show off
by then.