[Coco] Compiler info from an offline conversation...

[KnudsenMJ at aol.com]

In a message dated 4/28/04 2:41:11 AM Eastern Daylight Time, 
secure at ytunnelpro.com writes:

> Microware C compiler/Flex Compiler: These compilers are generally
>  considered the defacto standard for the systems they run on. The reason
>  I mention both compilers at the same time is that the Flex C compiler
>  looks VERY similar to the Microware compiler.

Well, that's interesting -- hadn't heard before that the two systems' 
compilers were in any way related.  Though honestly, I didn't now FLEX had a C 
compiler!

> Both operate in two passes
>  (cpass1, cpass2) where the first pass creates intermedial code (ICODE)
>  extremely similar to Microwares. As I understand it though Microware was
>  able to merge cpass1 and cpass2 into a single application but it was
>  never released.

I forget where I got it, but I do have the single-pass version and have given 
it out a few times.  It's faster, naturally, and less vulnerable to the 
undetected-out-of-memory bugs that plague MW's compiler. but ISTR it's too big to 
run under Level 1.

> If you need a CoCo hosted compiler THIS is the first and
>  probably only compiler you should look at as it's the only one that has
>  the potential to run on the CoCo *AND* generate decent code while
>  allowing updates, enhancements, and fixes to any bugs that may be found.

The code is very well optimized at the expression and statement level, but 
desperately needs peephole optimization from one statement to another, as in 
your example below.  Also, its insistence on SEX-promoting every byte variable to 
short int is a great waste of time and space.  Hopefully one of the 8-bit 
compilers you mentioned avoids this waste.
  
>  Most ANSI C compilers generate a certain amount of code that doesn't
>  make sense when targeting 8bit cpu's. This is generally a preamble
>  which promotes basic types to be aligned on a specific boundary. You
>  might see code like this:
>  This is to ensure things like the following are taken into account:
>  
>  void function(char param)
>  {
>  }
>  
>  compiles to:
>  
>      ldb param+1,s
>      sex
>      std param,s
>  
>  This makes sure that the argument is promoted to signed (or unsigned)
>  type of size(int) to accommodate promotion of signed/unsigned types.

Yep, this is part of the waste that makes no sense on our machines.

You can do some peephole optimizing in your source code --
>      a = c;
>      b = c;

can be written 
    a = b = c;
which ISTR will compile, in Microware C, to
>      ldd 0,s
>      std 2,s
>      std 4,s
 
Someone mentioned a while back that writing tight, efficient optimizing C 
source is becoming a lost art, as it actually works against the multiple-stream 
32-bit CPUs in modern PCs and Macs.    And it's harder to modify and debug.  
But it really helps on the Coco.  --Mike K.