[Coco] CoCo gcc project

[David]

On Tue, Nov 04, 2003 at 02:42:07PM -0600, Roger Taylor wrote:
> At 08:33 AM 11/4/2003 -0600, you wrote:
> >That's true. However, I tend to think that non-PIC code in OS9 products
> >that are for public consumption might be dangerous.
> 
> I agree - for a compiler meant to just create code that is meant to be run 
> in the BASIC environment, position-idependent code probably won't be used 
> much, anyway.

Well, that's the whole idea, I think.  PIC for BASIC is unnecessary,
although, if it didn't cause a noticable performance hit, it would do no
harm in making PIC standard in that, if a new compiler was implemented.
Especially if a universal compiler - for all environments for the coco -
then it would eliminate a lot of conditionals in determining which mode
to use - just use PIC for everything.  Again, I do think that we ought
to keep PIC standard for OS9 - even L2.

> However, it would be trivial to add support for this.  The main thing is to 
> address memory as LEAr address,PCR instead of LDr #address.  That's not a 
> problem.

Sure.  I've never compared the cycle count or byte counts between the
relative operations.  Also, your jumps have to be [l]bsr and [l]bra
instead of jsr/jmp - I'd assume these take longer, but in most cases,
probably wouldn't be noticable.

> In fact, I could add in such a translator into CCASM that could 
> take fixed position code and *maybe* allow it to run anywhere in 
> memory.

Do you mean for writing new code or something to convert existing code?
If the latter, although no doubt doable, would take some work to get
implemented.

As far as writing new code is concerned, all that it takes is, as you
stated above, to use the correct addressing modes in loads, stores,
brances, etc.

> Complex programs probably can't be converted so easily.  Anyway, 
> that's just an idea that is nowhere in my near plans.  :)

Well, the way I look at it, all these things are fun to discuss, but I
wonder whether the benefits would be worth the effort to get them
implemented.  I'd think the main benefit would be from the satisfaction
of knowing we did it.  Actually, I think that's about all we can expect
to gain from any of this stuff we're discussing and/or doing regarding
the coco.

> While this GCC project stuff is interesting,

Yes, it is, but, as I said above, it may take quite a bit of work to get
implemented and I wonder if there are very many people who would use it
after it was completed.  It's fun and quite interesting researching the
internals of things like gcc, etc. but it is also disheartening thinking
that you might put in all that time and then there was no one to benefit
by it.  If I did something like that, I'd want people to benefit by it.

> my own focus is totally in a 
> complete IDE for Windows that almost anybody will be able to use to create 
> ML programs of any kind, even those knowing little about assembly.  It will 
> eventually include a BASIC compiler, ML sniplets you can insert, project 
> templates, and all of the basic I/O code for doing keyboard scans, joystick 
> reads, hi-res mouse reads, screen printing, serial I/O, and probably disk 
> I/O.   You'll be hard-pressed not to want to use it to create something.

I've been seeing a lot of discussion about this, but haven't taken the
time to explore it.  Will this be a total replacement of the BASIC that
is now in the coco rom?