[Coco] gcc-coco revisited

[KnudsenMJ at aol.com]

In a message dated 10/31/03 12:08:39 PM Eastern Standard Time, 
dbree at duo-county.com writes:

> > And (4) a lost of Coconuts are used to its syntax and pseudo-ops.
>  Yes, this poses the biggest problem for me.
>  > Learning 
>  > the pseudo-ops and memory allocation conventions of different assemblers 
(
> to 
>  > say nothing of macro processing) can be a big learning curve.
>  
>  Of course, unless you wish to stop compiling before the assembly stage
>  for debugging purposes (e.g. cc -a), and try to read the assembly
>  source, then the difference would be transparent to the user.

Yes, though most of us have looked at intermediate assembly for debugging, 
learning, and other reasons.  Another issue would be whether hand-coded 
assembler routines could still be linked in with the GCC ones.

Maybe the real question is user base -- would this GCC be used mostly by old 
hands who still know and love assembly, and would want to at least look at it 
now and then -- or would this attract new programmers who wouldn't know SEX 
from PULS and don't care?  What the heck, there are C compilers that don't even 
generate intermediate assembly code.  Not that I would want to debug with one.
 
>  > Also, why such a hurry to abandon the original Microware C compiler?  
Its 
>  > bugs and shortcomings are well enough understood to work around.  CPrep2 
> makes up for a lot.
>  
>  Well, the idea is to create a fast cross-compiler, in the vein of
>  Boisy's "os9tools" project.  Most of us now spend most of our time on
>  PC's either Windows or Linux. 

Sure, I understand the advantages of working on a fast, modern machine.  Like 
every time I re-make UltiMusE on Linux (45 seconds) versus the MM/1 (45 
minutes) or Coco (go out for dinner and a movie).  However, running Microware C 
compiler on a fast emulator should get much the same effect.  I forget whether 
Roger's IDE uses MWC or something else, but it could use MWC.

>  Also, although it would break using the standard Microware C compiler,
>  we could add features - how about a much-needed (IMO) "unsigned char".

Buddy, you just earned yourself a case of beer!  I've been faking "unsigned 
char" in UME code for years, and still get bit occasionally!  And all the 
compiler has to do is replace SEX with CLRA.  But I agree, hard to patch MWC to do 
that.
 
>  As for the thought of abandonment of MW-C, if we could stick with the
>  original "rma/rlink" format, it wouldn't be an abandonment.  However, if
>  we adapt AS, then, yes, it would represent pretty much a total
>  abandonment.

I'd vote to stick with rma/rlink format, to keep all the assembler gurus 
productively turning out fast routines that can be co-linked with C code.
  
>  PIC is, indeed, available.  I believe I was able to get this when I
>  fooled with it at first.  As far as PIC in L2 is concerned, we could
>  probably get a bit more efficient code if we did use non-PIC code, but
>  would it not be good to keep it PIC?  Especially if we intend to
>  maintain support for L1?

It should be a compiler option, either as yet more destination types, or 
"pragma", or whatever.  RSDOS typically does not use it, for example, but may want 
it for utility routines that can be put anywhere in RAM.
 
>  I think 6309 support would require a rewrite of the Microware C
>  compiler.  If we developed gcc, then it would be a matter of using
>  different mnemonics for the calls.  Taking info from James Dessar's
>  message above, it would be a matter of adding an m6309 target or more
>  likely, m6309-RSDOS m6309-os9 targets.

I get the impression that target machines can be specified, or at least 
modified, for GCC by relatively non-experts (not compiler writers).  But I think 
it's  more than mnemonics -- the 6309 has more registers, and opcodes that take 
several 6809 ops to emulate.

Anyway, you could end up with 8 target combinations:
RSDOS or OS9
68 or 63
PIC or not

--Mike K.