[Coco] gcc-coco revisited

[David]

On Fri, Oct 31, 2003 at 11:00:56AM -0500, KnudsenMJ at aol.com wrote:
> In a message dated 10/31/03 9:24:19 AM Eastern Standard Time, 
> billcousert at yahoo.com writes:
> 
> > Reasons for using RMA:
> >  1. It's Coco - strictly nostalgic.
> >  2. It's Coco - The rof's generated by gcc09 could be used on a real
> >  Coco or an emulator.
> >  3. We already have rlink libraries
> 
> 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.

> 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.  Editing source files, actual assembly,
disassembly of coco programs, is so much more convenient and so much
faster on these machines.  For example, using a disassembler such as
Dynamite+ on a coco to disassemble, for example, Dynamite itself, or
"asm" - huge programs - 13 and 6 k, respectively - take quite a while
IIRC, something like 10-15 minutes, if not more.  But using os9disasm
from os9tools, even on my extremely slow P-166, just a very few seconds
at most.

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

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.

> Originally, C++ compilers were just pre-processors that "macro expanded" C++ 
> source into straight C code.  Granted, they require some things that 
> Microware's old K&R C can't handle, like long names.  But I wonder if an extra pre-proc 
> stage couldn't fix that too.
> 
> If there *is* a back end to GCC++ that can not only output 6809 code, but can 
> be optioned to do it PIC or not (for L2 or RSDOS, see my other posting), then 
> maybe GCC is worth pursuing.

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
maintail support for L1?

> Don't know how, if ever, 6309 extensions could 
> be provided, either by Microware C or GCC.  --Mike K.

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.