From: Mike McCarty (jmccarty_at_ssd.usa.alcatel.com)
Date: 2001-05-23 16:50:09
On Wed, 23 May 2001, Ullrich von Bassewitz wrote:
> On Wed, May 23, 2001 at 11:10:17AM +0200, groepaz wrote:
>
> Dreaming is of course allowed:-) But I've learned that in real life it is
> often a good idea to keep ones goals in mind. Having features just because "it
> does not hurt" will increase complexity and code size, will introduce more
> bugs and will absorb more man power. If my goal had been to support the
> complete GNU tool chain, it would have been better to start with a port of gcc
> to the 6502.
>
> cc65 is a small compiler that is targeted to the 6502 CPU. This has some
> drawbacks, but it is also its beauty. While it is nearly impossible to know
> the purpose of each gcc, gdb or gas module (not to speak from the other
> binutils), this is easy for cc65. Changing that would mean that one maintainer
> would no longer be enough - and while support is better now than some time
> ago, I'm still the only maintainer for all the tools. Also keep in mind that
> I'm maintaining cc65 in my spare time. Adding complex features just because it
> does not hurt having them would absorb time that is better spent on usable
> features (like library improvements, 65816 support and the like).
>
> Regards
>
>
> Uz
I second this opinion. I find that a small compiler often does a better
job than a big compiler for a small machine. This is due, partly, to
the fact that big compilers typically use a virtual machine with
unlimited registers for generating intermediate code. GCC does this,
for example. This means that the intermediate code is difficult to fit
into the real machine. Small compilers can use front ends which are not
all that demanding of the assumed machine. SMALLC, for example, assumes
one 16 bit accumulator
one 16 bit address register
an addressable stack
This maps easily to such machines as the Z80, 6502, and 68HC11, for
example.
GCC assumes much more of its virtual machine. This makes porting of the
compiler to generate code for small machines difficult at best. The
implementations for the 68HC11 that I am aware of implement "virtual
registers" in RAM, because the virtual machine is such a bad fit for
the physical machine. This means that when it spills registers, it does
memory to memory copies. Ugh! Moving data from one location in RAM to
another! It's better just to leave the variables in place IMO, and load
the registers with data only when it is being accessed.
I know of a port of SMALLC V2.2 to the 68HC11 with a decent peephole
optimizer, including code to remove redundant loads of index register X
from the stack pointer, which has been observed by me (in admittedly
limited code samples) to generate tighter code than the current GCC
port.
I have extensive experience with GCC generating code for the Z8001, and
found that a straightforward small compiler followed up by an assembler
which did peephole optimization consistently did a better job than GCC
for both code size and code speed.
Of course, with the really tiny compilers (not the one I used on the
Z8001) you don't get nice language features like structures and unions,
but I don't write large programs for the small machines, anyway.
Mike
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel <- They make me say that.
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:40 CET