Re: A86: What C-compilers have we got? [82/83/83+/85/86]

[Prev][Next][Index][Thread]

Re: A86: What C-compilers have we got? [82/83/83+/85/86]




On Tue, 14 Nov 2000, Henk Poley wrote:

> 
> But maybe it's now to us to actually DO something.
> "Wishlist" (so far):
> 1. Make a compiler with a higher language.
> 1.1. Or chose one from the existing ones, presumably a freeware
>        compiler

Unfortunately, this isn't a good idea.  I've looked at several, and most
of them generate worse code than TISCO (which is itself not good).

> 1.2. Doesn't has to be C 'as is'. Also a very good macro-assembler
>       could do the job.

What is the job?  We already have macro assemblers, but the more complex
things (like expressions of significant size, nested control structures,
etc.) are not well done with macros.  Even if the control structures are
implemented with macros, macors just expand, they don't optimize, so the
resulting code would probably be much worse than a compiler.

> 1.2. Maybe another 'selfmade' language is usefull, because it can be
>        especially adepted to the 'Ti-enviroment'.

I don't see how this would help us.  C is already a widely used and very
flexible language.  You might think C generates too 'large' programs from
seeing what some C library is like, but this is completely separate from
the language (stuff like printf() is *not* part of the C language at all!)

To deal with the "TI-environment" it is of course needed to deal with
bytes and pointers and such at a low level, but that's what C does.

> 2. Make it size(!) optimizing, as good as we can.
>     (this can also be done with an other program, not especially
>      made for optimizing compiler output)

I'm not sure what the "other" program would be.  But, more important than
optimizing compiler output with a second program is to have a good
compiler to begin with (as the most significant optimizations would be
part of the code generation process itself).

> 2.1. Not only with a peephole optimizer, but also some more
>       difficult ones like dead code elemination (and others).

Dead code elimination is the least important.  Though, here, I think
you're referring to 'dead code elimination' as leaving out functions that
are never used, while as a compiler optimization it normally refers to
removing code like "if (0 == 1) { ... }".

More important optimizations include efficient use of registers, and more
complex things (try looking in GCC docs to see all of what it does).

> 2.2. Don't make the crt0.asm file to large, so you can make very
>       small programs (the file is for the included header + standard
>       subroutines)

It shouldn't need to be of any significant size at all.

> 2.3. Don't calculate with 16bit registers only.

Of course.  TISCO already does this, but most others don't.
 
> 3. Let it be able to use all possible memory(-holes) on the Ti's

This really takes no, or almost no, extra effort for the compiler.  It's
simply a matter of allocating data structures to those places.

> 4. Don't bother the Assembly-lists about it, make an new list

If you can convince ticalc.org to make a separate list for discussing C
program on the Z80 calculators, I will write about it there, not here.

Note that C programming is commonly discussed on Assembly-89, and though
some people complain about that, it doesn't seem to be a huge problem.

Since a C compiler is used to produce assembly code anyway, it certainly
does relate to assembly, so I don't think this is such a bad place to
discuss it.  Evaluating or especially writing a compiler involves a lot of
dealing with assembly.

And now, my final recommendation on what should be done:

The best way to get a good Z80 compiler is to add Z80 as a new target to
GCC.  The good results it's given on the 68K calculators show that it can
work for us (even though the 68K calculators have larger memory, GCC code
is *not* especially large).  While GCC is designed for CPUs with lots of
registers, it is probably possible to make it work on the Z80.  It has
already been made for the i386 architechture, which has fairly limited
registers, and partially supports the 8086, which has a lot of limits on
its registers.  Of course, it will take a little bit of effort to add Z80
support to GCC, but this should probably give the best results.
Follow-Ups: References: