[Coco] CoCo gcc project

[David]

On Mon, Nov 03, 2003 at 04:52:30PM -0500, KnudsenMJ at aol.com wrote:
> In a message dated 11/3/03 7:20:16 AM Eastern Standard Time, 
> dbree at duo-county.com writes:
> 
> > Personally, I'd like to see
> >  all OS9 code remain PIC.  RSDOS could go non-PIC, or for convenience, we
> >  might let it be PIC.
> 
> Sounds like we really need a PIC/absolute option for RSDOS, and so why not 
> have it for OS9 also (for faster, smaller  L2 code)?

I'm not sure if there would be a need for PIC code for RSDOS.  Where
would that be needful?

As far as non-PIC code for L2, I realize that it does work for a program
that is the only one in the address space, and most programs that would
be compiled with a C compiler would normally be pretty large, thus not
merged with others, but if you had a non-PIC program and merged it with
another, then wouldn't that break, if it wasn't the first program in the
group?

> >  I think a common assembler and linker could be
> >  used.  The biggest difference would come in the linker stage.  The
> >  linker would simply build a different module depending on whether it was
> >  OS9 or RSDOS.
> 
> Is there any RSDOS convention for object modules?  That is, have there been 
> any assemblers for RSDOS that didn't assemble everything as one big source file?
> If not, then there is no RSDOS convention, and we should carry OS9's RMA 
> convention over to RSDOS.

I think so.  The only thing I can think of now is the fact that RSDOS
data shares the same space as the executable code.  It would be
referenced differently.

> I agree that the linker is really where the difference is output for RSDOS 
> versus OS9.

.. and, in how the data would be referenced.  You could use a register
to point to data, and put it all in one location, but I'd think it would
be a wee bit slower by using indexed addressing rather than extended.

> >  Finally, what assembler/linker?  Do we use AS or try to do a totally
> >  rma/rlink compatible routine.  We do already have RMA rebuilt as a cross
> >  assembler (OS9 only for now), and we still have rlink to go.  If most
> >  people prefer to go to AS, we have all the source to rebuild it to
> >  whatever we want.
> 
> I never heard of AS until now.  Since we have RMA already, and no reason not 
> to port it into RSDOS as well, why not stick with what we all know?  --Mike K.

When we mention AS, then we're referring to the stuff that James Dessart
put together.  You might refer back to some previous threads in
bit.listserv.coco back about 6 months or so ago.  This was a generic
port of 6809 code to gcc.  James set it up and made some changes to
where it would compile RSDos modules, I believe.  Boisy worked with it a
bit and added some library definitions - the F$/I$ calls, and maybe some
others.

With the package is a assembler (AS) and a linker.  But the assembler
outputs ASCII ROF's.

Some time ago, downloaded the stuff and played around with it a bit
trying to get it to output an rma source file.  I got it to "mostly"
work, and laid it aside.  Recently, my interest was revived.  I'd
deleted my working files, but had a diff file I'd saved, but apparently,
it was a very early stage.  I had to do quite a bit of work to get it
back to about where I was when I quit.

As far as sticking with RMA/RLINK as a cross compiler, we now have an
rma that _seems_ to work running under linux.  It's my r63 program
ported over.  I got this by disassembling rma, rewriting it back into C,
and then adding 6309 opocodes.  As of yet, we don't have a working rlink
in a cross compiler.

My source for the rma is not really pretty. I think it is functionally
fairly accurate, but some of the label names are very vague and it might
be a bit hard to work with it to change it, especially if we want to
modify it to be RSDOS-compatible.

OTOH, although my feelings are the same as yours appear to be - hate to
abandon the old stuff.. we have clear source for AS and the linker and
it might be more straightforward to adapt this.

As far as being able to follow the code goes, it uses the standard
Motorola mnemonics so it might not be such a change after all.