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 Sun, 12 Nov 2000, Adam Thayer wrote:

> So you are saying that I can't compare two processors based on the 
> differences in their instruction sets as well as the available data 
> bus, BECAUSE of those differences? 

> I fully realize that one cannot 
> compare the 68k/Z80 with the PPC, but that wasn't the point. But the 
> 68k was designed to go in the first Macs (128k/512k models) and was 
> quite capable of handling C and other higher level languages. 

Though this is mostly irrelevant, I have to point out that the 68K was
*not* by any means designed for the Mac.  The 68000 processor was first
made available in 1979, five years before the Mac.

> The reason why C faulters on the Z80 is because of the lack of
> registers and addressable memory. Rule of thumb is: the more registers
> you can use for math, the less push/pop ops get used, and your code
> can actually be SMALLER (although this is not commonly thought of)
> compared to one without those registers. I myself am bound to the
> endless push/pop when I am trying to track 6-7 16-bit values on my 86,
> something I never had a problem with on the 68k.

All of these limitations affect assembly programs as well as C programs,
so they don't provide any reason that C should be considered a worse
choice on the Z80 than on other processors.  

Also, having more registers does not really make code smaller.  Even
though equivalent programs may use fewer instructions on the 68K than the
Z80, that doesn't make the 68K versions smaller; many instructions on the
Z80 processor only take one byte, while the smallest 68K instructions are
two bytes in size (considering how many combinations of registers could be
used on the 68K, the instructions simply couldn't be fit into one byte).

The best solution to not being able to store enough 16 bit values is to
use 8 bit values instead (not always practical, unfortunately).

> No, I am referring to the actual registers located on the CPU. the 
> Z80 has: A, F, H, L, B, C, D, E (and these can be paired up), IX, IY, 
> SP, PC and a couple internal ones you aren't even supposed to know 
> about. However, the 68k chips have A0-Ax and D0-Dx, where X is the 
> number of data/address registers minus one. As I said, I believe this 
> is somewhere from 8-12, maybe more...

There are 8 registers of each type on the 68K, meaning the registers are
numbered D0-D7 and A0-A7.  However, A7 also functions as the stack
pointer, so you really should count only 15 registers total.

> I was talking about why C isn't used on the Z80, and I think you have 
> gotten a bit confused by my comment. C isn't being used on the Z80 
> because of the limitations that the Z80 and TI imposes on memory and 
> CPU speed.

Why is this a special disadvantage for C?  Assembly programs must face the
same limitations on memory and CPU speed.
 
> 6Mhz is just a tad low for a high-level language (obviously apparent,
> even in BASIC) to operate at 'acceptable' realtime speeds without size
> overhead. Also, since the Z80 is limited to 64k addressable at any one
> time (which the 68k is NOT limited to)  and since TI has 32k of that
> in use, you can really only use around 24k of runtime space, very
> constraining for something like C.

Any consideration of TI's Basic langauge is completely meaningless when
discussing assembly or C.  Basic does not run slowly just because it is a
high level language.

Also unclear why 24K is too little runtime space for C, but sufficient for
assembly.  Remember that 'runtime space' includes not only code, but
permanent data such as text and graphics, and temporary data such as
screen buffers, which are no larger in C than in assembly.

In reality, the only way that space limitations would be a problem for C
only is if C code were much larger than the assembly equivalent.  That is
the case right now, but only because the current compilers we have are not
very good (that's also why current C code on the Z80 is very slow).

Of course, there's no reason to think that C compilers always generate
poor code.  The TI-GCC compiler on the 68K shows clearly that compilers
can generate code which is both small and fast.  While the 68K does have a
larger addressable memory space than the Z80, that's not very relevant
here.  The larger memory use of 68K programs is mostly due to having a
larger screen, and thus larger image buffers and images.  C code on the
68K aren't that much larger than assembly equivalents.

The Z80 is of course very different, but its differences affect assembly
and C alike, so if assembly programmers can deal with it, why can't any of
them write a compiler that deals with it?  Register limitations are
survivable, as assembly programmers know.  The only thing that would
really cause problems with C code is the inability to efficiently access
variables on the stack, which is where local variables and C parameters
must be kept if they don't fit in registers.  In this case, the solution
is just to make variables global (as assembly programmers do); this will
require a change in C programming style from what is normal, but that's
it.

Of course, preparing a highly-optimizing C compiler for the Z80 is a
massive undertaking.  It will be a lot harder than making TIGCC, as they
had the advantage that their CPU is already supporter by GCC.  However,
making a good Z80 compiler is still possible, and certainly would be very
useful.
Follow-Ups: References: