[Coco] gcc-coco revisited

[Gene Heskett]

On Friday 31 October 2003 21:50, KnudsenMJ at aol.com wrote:
>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.

Thats one thing that under normal conditions, GCC cannot do, it has no 
#ASM directive.  That said, I've noted that since forever, compiling 
a linux kernel gets you one string of about 6 warnings from the 
assembler itself about the code that GAS or previously AS was 
compiling, so I assume someone has figured out a way around that, at 
least on X86 hardware.  But I've NDI where its at in the kernel 
src's.

>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.

Deliver us from that, the thought even scares me. :(

>>  > 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.

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.