dwg@bpdsun1.uucp (David W. Glessner) (10/14/89)
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@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.