Wanted: Z80 cross-compiler for Sun (summary, questions)

[David W. Glessner]

Back in July, I asked:
> We need a C cross-compiler package (compiler, assembler, linker,
> etc.) for a Sun 3/60 that produces Z80 code for an embedded system.
> ...
> Also, how difficult would it be to modify the GNU compiler to
> produce Z80 code?

We haven't chosen a package yet.  Additional responses would be
appreciated. (hopefully like "I've got this port of GNU CC that blows
everyone out of the water!!!" :-)

I've tried SDSI's compiler.  It compiled our code, but I was
disappointed with the bulky code it produces.  I haven't evaluated
Microtek's or Hi-Tech's package yet.

I've attached the responses.
The names have been deleted to protect the innocent :-)


David		quintro!bpdsun1!dwg at lll-winken.llnl.gov
		uunet!tiamat!quintro!bpdsun1!dwg

-----

I was VERY! unhappy with an older version of Intermetrics Z80
compiler for the following reasons:
   1) Limited implementation of C
   2) High rate of compiler errors
   3) Relatively poor ROM support
   4) Relatively high price

On the other hand, Microtec's 68000 C compiler is excellent by
all measures.  Does this apply to their Z80 compiler? ...

----

	A good friend has a wife who works at Microtec. I get the
impression they are competent folks. I have no direct experience.

> Also, how difficult would it be to modify the GNU compiler to
> produce Z80 code?

	The _real_ question I wanted to answer. In short: "If you
have to ask you can't afford it". It undoubtedly _could_ be done,
but keep in mind that it takes a while to come up to speed on GCC, and
consultants charge about $100/hr. I wouldn't want to try doing something
as twisty as the Z80 in under 80 hours, as it took [[ name deleted ]] 5 hours
just to polish up my mostly working re-target for a very regular RISC.

	GCC believes in (among other things) a general-register machine
with a (relatively) large number of registers of a (relatively) small
number of "classes". This just doesn't describe the Z80 _I_ remember.
_BUT_ there is a working version for the 80386, a no_less_twisty machine.
So I assume it could be done, but I wouldn't want to do it. There _may_
however, be a masochist somewhere in your organization who wants to take
time off from re-writing Xchess in micro-code... :-)

----

I went thru this exercise last year (z80 c-compiler on a sun-3).
I evaluated the info, benchmarked the code, and finally
got the SDSI & Microtek products for evaluation.

Neither was up to snuff (explaination below).  Then I did a basic
port of gcc to z80 -- gcc really wants index registers. While
the Z80 does have something called index registers, they are far too
slow to be used as often as gcc required.

I ended up solving the problem by redefining it:  if a project needs
software written in 'C', I use a 68000.  I use the Z80 only when
the code is short enough to be written in assembly language.

[[ our latest project uses a 68000! ]]

HOWEVER:  If you find/port a good 'C' compiler, *please* let me
know.  We still have a number Z80-based controller systems in the
field & people are always wanted them to do new things.

BTW: I have written a good z80 cross-assembler, runs on a Sun-3 &
generates listings and `a.out' format code.  I also have the patches
required for gnu/ld to link it all together. Also an `a.out' ->
intel/moto hex translator.  Yell if you want them.


Results of my study:

1) Intermetrics product was written by an eng. who left the company
years ago.  Noone there now supports the product.  I was
also turned off by their literature.  Look, for instance, at the
example of the context switch code:  pathetic.

2) Hi-tek wasn't in the unix environment last year.

3) The SDSI package was quite complete -- the assembler/linker were
quite impressive. The c-complier accepted correct programs & generated
correct code.  However, the generated code which was mediore.  I was moving
code from a CP/M-80 system which had used the MANX native compiler.
The SDSI generated code was about 2x in length & 1.5x in speed.
Definitely hard to get execited about.

4) The Microtek package generated amazing code -- passed parameters
in registers & used the top-of-stack as scratch (as opposed to a stack
frame accessed via IX/IY).  It ommited context switch (register saving,
etc) whereever possible.  All-in-all amazing.

However, the Microtek compiler is written in *PASCAL* because the compiler
writer didn't know 'C' (I know, I talked with him & asked!).  This leads
to numerous problems, such as:

*) a program such as `` main () { printf ("Hello world\n"); } '' won't
compile because there is no type-specifier for the function `main'.
(It doesn't default to int).  Code must be translated.

*) there is *no way in the world* to declare something like this:

struct a {
	int astuff;
	struct b *bp;	<=== fails here
};

struct b {
	int bstuff;
	struct a *ap;
}

because `struct b' is undefined at the point marked.  Never mind that
it's legal 'C'.  My code had a lot of these in them.  Microtek's solution
was to use casts.  However, 

*) casts dont work.

Casts are not allowed on the left side of an expression.

*) many other language problems which I've forgotten.

*) Their compiler driver was wierd -- no support for stderr.  Messages
didn't come out in a format that could be parsed by emacs.  Also,
filenames had to be seperated by *COMMAS*.  Try convincing `make' to
do that!  Generally, a mess.


We had to reject the microtek product because it wouldn't compile even
a K&R I program.  Not even the first pgm in K&R I. (And by the way
when I complained -- I was told that what I found weren't bug, they
were `variations'.  Long live pascal!)

----

[[ response about a gnu cc port ]]

after what i've seen so far, i think that it would produce great code
with not any more work than any other gcc port. give it a shot. if you
get stuck on anything in particular, give me a shout.