I've thought about this subject a bit and I don't think a C compiler for Z80 would really be practical. The Z80 architecture is badly suited for C (or any other compiled language, really) for several reasons:

• in C, the normal way to pass arguments to a function is on the stack. On most modern processors, you have a stack-relative addressing mode, so this is fine. Z80 has no easy way to access elements of the stack below the topmost, so the only sensible way to pass things into a function is through registers. But the question of which registers are best to use is dependent on the function itself, and to some extent its callers. C requires standardized calling conventions in order to be able to have separate compilation of multiple source files; a compiler can't generate the code to call an external function if it doesn't know how that function expects its arguments passed.
• Register allocation on the Z80 is a very complicated problem. On most processors, registers have few if any differences between them - if it works on "R0", it works on "R7". On the Z80, every register has its own special purposes, so deciding what to put where becomes more complicated.
• When C programmers want an integer, they usually just type "int". This poses a problem for the Z80, since "int" has to be at least 16 bits long. On today's processors, 8-bit, 16-bit, and 32-bit operations are all the same speed, but on the Z80 anything bigger than 8-bit takes up more time and space.
• Also, in C integer types are signed unless you explicitly say "unsigned". More often than not, it doesn't matter whether a variable is signed or unsigned so programmers just use signed integers to save typing. Unsigned comparisons can be done easily on the Z80 (just use the carry flag), but signed comparisons require that the sign flag and parity/overflow flag be XORed together. Modern processors have conditional jump instructions that do just that; the Z80 doesn't.

I strongly doubt that a C compiler could ever produce Z80 code anywhere near as well as a person writing assembly could. As a result, C games would require a lot more memory, which is in short supply on the Z8-based calculators.

If you don't want programs that take up more space than they have to, that's probably a good idea.

Goplat: Believe I have been working on this for some time now and  I have already thought about everything you just said right there.

Let me address some things.

1. z8-GCC has still been in effect and is still being worked on, but it is not z8-GCC anymore because we are not using GCC.

2. C will most obviously not be as efficient as hand-written assembly, but it will provide smaller size than BASIC and much faster speed than BASIC

3. Let me answer you questions up there

Well first off I should address this by saying my development team and I are making a C compiler from the ground up which will support 68K and z80 as the first targets. It will be target-expandable meaning that the compiler will produce programs for any processor that you want to target it to through writing a backend.

Now let me talk about the problems that you have posed above.

1st problem: Calling conventions: There are numerous ways to pass arguments on the z80. Registers, stack, memory. These can be user defined or they can be chosen by the compiler. Secondly I don't think you know this but the z80 in effect actually has  14 8bit registers or 8 16bit registers.

8bit: a,b,c,d,e,h,l,a',b',c',d',e',h',l'
16bit: bc,de,hl,bc',de',hl',ix,iy

Now also another thing which you may or may not know is that ix, and iy can be used in almost every place that hl can be used which gives you 4 general purpose 16bit registers. So that is more than enough to pass parameters to functions as long as you do it smartly.

2nd problem: Register allocation: Basically what you just said is that is going to be more work for me. Well I don't care because I have been turning this over in my head and have came up with some very good algorithms.

3rd problem: Types: int defaults to short. Can you have a long int? Of course. Can you have a long long int? Of course. No need to worry there. It may take more time, but I see assembly programmers using them all the time. Remember it doesn't take that much more time. Maybe 2-4 cycles which isn't that much. You have 6 million cycles in a second on the z80 and 15 million possible on a z80 in the silver edition.

4th problem: Types: I still see no problem. What you are saying is all possible so I really don't see the point in that statement?

Now let me just say. Of course it will be more work to write a z80 target for our C compiler, but it will NOT make over-bloated or even close to unneeded bloating code. It will be aware that register to register loads are faster than constant or memory loads and that will make an effect. SSA trees will be used for other various optimizations internally in our compiler. Final pass peephole optimizations will also be made like the call-ret optimization.

Also remember that programmers will be allow to write there own assembly functions for their programs too.

Trust me Goplat. Anything you can throw at me has already been thought of. I would not continue with this project if it was not possible.

Oh and about that using more memory than it should?? That will not be a problem as programmers will have the option to use bcall()'s over the hand-written z80 assembly C functions provided in the Standard libraries if they truly need it.

One thing I can guarantee you is that the C games will not be as big as their BASIC counterparts and will most be much faster.