[comp.compilers] intermetrics z80 inefficiencies

rdeaton@ab.com (EATON, ROBERT) (07/18/90)

Hello,
	I have been running shy on code space for a z80-based embedded system.
This has forced me to begin converting some of the 'C' code, compiled with the
Intermetrics z80 compiler, to assembly code to save space.  If I get creative,
I can reduce the amount of code/function by about 2/3.  Just as an example of
how inefficient it is look at the following:

if (pete-> friend == JOE) 
000d   ED4B          7>  |           LD       BC,pete		<----
0011   111900            |           LD       DE,#25
0014   C5                |           PUSH     BC		<----
0015   E1                |           POP      HL		<----
0016   19                |           ADD      HL,DE
0017   4E                |           LD       C,(HL)
0018   79                |           LD       A,C
0019   FE01              |           CP       #1
001b   C2            6>  |           JP       NZ,il_1 

	See, for example, lines 1, 3 and 4.  Why didn't it just load 'pete'
into HL to begin with, instead of loading it into BC and then push/pop into
HL?

	As I've been looking at the way it compiles code, a question occurred
to me.  Does it do these weird things just in case I use an esoteric 'c'
instruction; as opposed to a simple instructions (whatever that means)?  In
other words, does it do these backflips just in case I use a weird 'c'
instruction, that it wouldn't have to do if I used a less complex subset of
'c'?

	Maybe a compiler could have two versions.  A more efficient version
that can only be used with a subset of 'c' instructions, and a more bulky
version for more complex instructions.  I realize this seems picky, but our
code is mostly just 'if,then,else' structures and is very time/space
critical.

	Of course this is almost becoming a mute point since no-one uses a
z80 anymore and now we have bigger proms. :-).

Bob Eaton

rdeaton@ab.com
[I have no direct experience with Intermetrics compiler, but it is my
impression that it was written a long time ago.  Modern compilers should
have no trouble loading values into the right registers. -John]
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.

dwg@bpdsun1.UUCP (David W. Glessner) (07/19/90)

In article <1990Jul17.231931.513@esegue.segue.boston.ma.us> "EATON, ROBERT" <rdeaton@ab.com> writes:
>	I have been running shy on code space for a z80-based embedded system.
>This has forced me to begin converting some of the 'C' code, compiled with
>the Intermetrics z80 compiler, to assembly code to save space.

Have you looked at a different compiler?

Last summer, I asked about Z80 cross compilers for a Sun 3 on
comp.lang.c.  One person was "VERY! unhappy" with an older version of
Intermetrics C for the z80 because:
	1) Limited implementation of C
	2) High rate of compiler errors
	3) Relatively poor ROM support
	4) Relatively high price
Another claimed that support from Intermetrics was poor.

Others suggested Microtec, SDSI, and possibly trying to port gcc.

We purchased a source license to HI-TECH Z80 C and ported it to the Sun
3/60.  We haven't tested the HI-TECH package extensively, but we're
quite pleased so far.

Following are the results after coverting some of our Z80 C code from
Eco-Soft C (CP/M based) to HI-TECH (Sun based).

			HI-TECH		Eco-Soft
	ROM space         36718           44831
	RAM space          8272            8428

Note that ROM space includes about 8000 lines of assembly files.

Here is the assembler output for a test program similar to your example.

	global	_func
	global	_ptr
	global	_noptr
	psect	text
;test.c: 1: struct { char a[25]; char friend; } noptr, *ptr;
;test.c: 2: void func(void)
;test.c: 3: {
_func:
	push	iy
;test.c: 4: 	if (ptr->friend == 1) ;
	ld	iy,(_ptr)
	ld	a,(iy+25)
	cp	1
	jp	nz,l3
;test.c: 5: 	if (noptr.friend == 1) ;
l3:
	ld	a,(_noptr+25)
	cp	1
	jp	nz,l2
;test.c: 6: }
l2:
	pop	iy
	ret	
	psect	bss
_noptr:
	defs	26
_ptr:
	defs	2
	psect	text
	end


HI-TECH's address is:
	HI-TECH Software
	P.O. Box 103, Alderley, QLD, 4051,
	AUSTRALIA

	Tel:	+61 7 300 5011
	Fax:	+61 7 300 5246
	E-mail: hitech@hitech.ht.oz.au

--
David	WB9VGB	quintro!bpdsun1!dwg@lll-winken.llnl.gov
		uunet!tiamat!quintro!bpdsun1!dwg
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.

mikeh@inmet.inmet.com (07/27/90)

It was recognized several years ago that Intermetrics needed to strengthen
its 8-bit compiler line to compete in the marketplace.  This was achieved
when Intermetrics merged with Whitesmiths Ltd. in December 1988, giving
Intermetrics a new line of state-of-the-art 8-bit compilers.  These compilers
are as good or better than any found in the marketplace today. Below is the
same source code as posted in the previous note compiled with the Whitesmiths
z80 compiler.

   /*********************************************************************/
   Here is the equivalent C & asm listing of the Whitesmiths z80 compiler
   /*********************************************************************/

		.psect	_text
	;    1  struct { char a[25]; char friend; } noptr, *ptr;
	;    2  
	;    3  void func(void)
	;    4             {
	_func:
	;    5             if(ptr->friend==1);
	   	ld	hl,(_ptr)
		ld	bc,25
		add	hl,bc
		ld	a,(hl)
		cp	1
	;    6             if(noptr.friend==1);
		ld	a,(_noptr+25)
		cp	1
	;    7             }
		ret 
		.psect	_bss
	_ptr:
		.byte	[2]
	_noptr:
		.byte	[26]
		.public	_ptr
		.public	_noptr
		.public	_func
        	.end

	
   /*****************************************************************/
	Please contact us if you have comments or questions.

	Intermetrics Inc.
	733 Concord Ave.
	Cambridge, MA 02138
	617-661-0072
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.