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]


As I've read through all of this, I've noticed you've all left out a
possibility, and I'm wondering why.

Why can't you just make a C-compiler that compiles into machine code? If it
compiles to asm, then it is only obvious that it will have to be compiled
AGAIN to machine code, so why don't you just skip the middleman and go
straight to machine code.

Or, does this require too much time and/or programming experience?

Patrick Davidson wrote:

> 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: