Re: [cc65] 65816 compiler revisited

Hi!

On Wed, Mar 30, 2005 at 11:07:15AM -0600, Chris Cureau wrote:
> I've gone through some past threads on this list regarding the code
> generation and memory management aspects of the compiler, and how it is
> specifically targeted to 65xx processors.  It looks like it would be a
> considerable bit of work to get the compiler to produce 65xx and 65816
> code from the same executable -- not impossible, but very probably messy
> work.

Some cleanup and restructuring would be needed.

> My question is whether it would be easier to create a separate compiler
> (a la cc816) that shares common functions with cc65.  The memory
> management and code generation could be separate in this way, and should
> not interfere too much with the way the compiler currently works.

While it would be easier to fork the compiler, it would have severe drawbacks
in the long run, so if it were me to decide, I would opt for one compiler. The
compiler would benefit from the restructuring needed to support more than one
CPU. It is easier to maintain, because you don't have two code bases. And, if
you just fork the compiler, and then want to add a third CPU, you have to
start from scratch. If you separate the machine dependent parts, and create a
clean interface, it is much easier to add another CPU the next time.

Apart from that, it's not just the compiler. The library needs as much work as
the compiler itself, if you want to do it right.

> Any ideas on this?  Or interest in working on this besides me? :-)

I'm of course interested, but there's not enough time. So don't count on me.
I've made a few small steps in direction of 816 support (see address sizes in
the assembler and compiler), but these are actually very small steps.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.