[Coco] [Color Computer] SDCC

[James Diffendaffer]

--- In ColorComputer at yahoogroups.com, "John R. Hogerhuis"
<jhoger at p...> wrote:
> On Mon, 2005-07-18 at 14:17 +0000, James Diffendaffer wrote:

> What I had done was replicate the source files and build stuff to add a
> copy of the hc08 module an rename it mc6809. What James had done was
> some of the register allocator.

I'm already past that so it's no big deal.

> > I won't know if everything is right until I start testing but it
> > looks like the changes are pretty obvious the more familiar I am
with it.
> > 
> 
> Good on you. I found the sdcc register allocator and code generator a
> bit of a mess.

It has flags for special purpose registers so it knows what they can
be used for and it just searches through the register structure array
till in finds the first free register of the proper type or size.  At
least that's what it looks like it's doing.  I'm not sure how smart it
will be for the combined registers though.  I'll have to worry about
that later.  The 32 bit register will almost be of no use to the code
generator.  It *might* be usefull to the peephole optimizer... I'll
have to look at it's functionality closer.  Loading up to 4 parameters
into registers at one time could be usefull.

There seems to be one issue with the hc08 compiler that should be
fixed.  Since the condition code register wasn't placed at the end of
the register structure array and the size reduced by one like the Z80
compiler, the allocator/deallocator routines always run an extra loop
each time once the previous registers are all allocated.  That slows
down the compiler.  It makes no difference to the code generated though.

Since register allocation seems to start at the bottom and works it's
way to the top of the array, the compiler may not produce the most
stack efficient code.  I had some deep discussion about this in
another group... it might be more theory than practice though.  

I'm planning on using the user stack pointer by default for stack
operations but a compiler directive (#pragma?) that lets you chose
which one for a section of code could prove usefull.  I'd call that a
want list item.

As for OS-9 code, I think a smart assembler could generate PC relative
code even if the compiler doesn't.  I'm sure there's more to worry
about but I pretty much missed the OS-9 part of the CoCo's life so I'm
no expert.

> Add to that I've never worked on compilers, poor
> vocabulary and abbeviation choices in the comments and I couldn't tell
> what the authors were attempting to accomplish in several places. 

You aren't kidding!  I had to look around a lot to figure out what
some of the variables are.  The good news is that you don't need wo
worry about most of them.  The bad news may be that I may miss one
that I do need to worry about!

> But there was an interesting Q&Q on the internals at the mailing
list. The
> developer of the hc08 module will respond to questions if you have any,
> he (at least was) talking to us on the cc6809 list.
>
> -- John.

I haven't hit any dead ends yet but you never know.  When I start
testing his assistance may be usefull.

I haven't done a lot of compiler work.  I looked at a lot of assembly
output when I was doing a lot of embedded systems work.  I had to mix
a lot of C and assembly writing device drivers and OS Kernels.
I did write a 64180 peephole optimizer for the Z-World Z80/64180 C
compiler and a 680x0 peephole optimizer for a free Pascal on the Amiga
in the early 90's.  Plus compiler construction is a requirement for a
Computer Science Major at the University I attended.





Brought to you by the 6809, the 6803 and their cousins! 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ColorComputer/

<*> To unsubscribe from this group, send an email to:
    ColorComputer-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/