|intermetrics z80 inefficiencies email@example.com (EATON, ROBERT) (1990-07-17)|
|Re: intermetrics z80 inefficiencies dwg@bpdsun1.UUCP (1990-07-18)|
|Re: intermetrics z80 inefficiencies firstname.lastname@example.org (1990-07-26)|
|From:||"EATON, ROBERT" <email@example.com>|
|Date:||Tue, 17 Jul 90 23:19:31 GMT|
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
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
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
Of course this is almost becoming a mute point since no-one uses a
z80 anymore and now we have bigger proms. :-).
[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]
Return to the
Search the comp.compilers archives again.