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]
The 68K precessor was orginally used for 5TB(terabyte) tape dirve machines.
Patrick Davidson wrote:
> 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.
References: