[z88dk-dev] benchmarks

[Philipp Klaus Krause]

On 12.11.2015 20:02, alvin (alvin_albrecht@...) wrote:

I have one example I'm not sure what is going on:

ld a,h
ex de,hl
ld hl,#_input + 1
xor a, a
ld (de),a
dec hl

"ld a,h" is not being killed by the peepholer even though there is an "xor a,a" following.


z80MightRead() in "peep.c" looks like it takes care of "xor a,a" properly:

if(!strcmp(pl->line, "xor\ta, a") || !strcmp(pl->line, "xor\ta,a"))
return FALSE;

Do you have a short, compileable example to reproduce the issue?

Philipp

[alvin]

On 12.11.2015 20:02, alvin (alvin_albrecht@...) wrote:

I have one example I'm not sure what is going on:

ld a,h
ex de,hl
ld hl,#_input + 1
xor a, a
ld (de),a
dec hl

"ld a,h" is not being killed by the peepholer even though there is an "xor a,a" following.


z80MightRead() in "peep.c" looks like it takes care of "xor a,a" properly:

if(!strcmp(pl->line, "xor\ta, a") || !strcmp(pl->line, "xor\ta,a"))
return FALSE;

Do you have a short, compileable example to reproduce the issue?

Philipp

I have to get back to work shortly but I'll try to put together some inline asm example later this afternoon.

I have narrowed it down: the peepholer is not crossing 'ex de,hl':

ld a,h
ex de,hl
xor a,a

I introduced a rule to push 'ex de,hl' downward like so:

ld a,h
xor a,a
ex de,hl

and then the extra "ld a,h" was eliminated.



------------------------------------------------------------------------------

[alvin]

I have narrowed it down: the peepholer is not crossing 'ex de,hl':

ld a,h
ex de,hl
xor a,a

I introduced a rule to push 'ex de,hl' downward like so:

ld a,h
xor a,a
ex de,hl

and then the extra "ld a,h" was eliminated.

I can't find any C code that will produce asm like the above in sdcc. I did try to inline it:

// sdcc -mz80 -S --peep-asm test.c

main()
{
__asm
ld a,h
ex de,hl
ld a,l
ld a,h
ld (#0000),a
__endasm;
}


--peep-asm is supposed to let the peepholer look into the inlined assembly. It does, sort of. If I remove the store to address 0, the last two loads to A are eliminated because they are dead for the ret. But other rules don't seem to be applied. The first load in the double load after the exchange should be eliminated.

Look at the asm source it looks like sdcc has stripped away tabs and replaced with spaces. I wonder if that confuses the peepholer so that it can't match the instructions with spaces rather than tabs.



------------------------------------------------------------------------------

[Philipp Klaus Krause]

On 13.11.2015 20:18, alvin (alvin_albrecht@...) wrote:

I have narrowed it down: the peepholer is not crossing 'ex de,hl':

ld a,h
ex de,hl
xor a,a

I introduced a rule to push 'ex de,hl' downward like so:

ld a,h
xor a,a
ex de,hl

and then the extra "ld a,h" was eliminated.

I can't find any C code that will produce asm like the above in sdcc. I did try to inline it:

No problem. Now that we know the issue is the ex de,hl that is something
I'll open a feature request for.

Philipp

[alvin]

I started to do some program size benchmarks:

http://www.z88dk.org/wiki/doku.php?id=t ... ogram_size

If you have any good ideas for large programs to compare let me know.



------------------------------------------------------------------------------

[Philipp Klaus Krause]

On 18.11.2015 07:02, alvin (alvin_albrecht@...) wrote:

I started to do some program size benchmarks:

http://www.z88dk.org/wiki/doku.php?id=t ... ogram_size

If you have any good ideas for large programs to compare let me know.

Operating systems:
* Contiki (you'll need an older version as the current one doesn't have
a Z80 port anymore. AFAIR 2.5 can be easily fixed to compiled for Z80).
* FUZIX

Philipp

[alvin]

Operating systems:
* Contiki (you'll need an older version as the current one doesn't have
a Z80 port anymore. AFAIR 2.5 can be easily fixed to compiled for Z80).
* FUZIX

I think we can shave quite a bit off the size of things in both Contiki and Fuzix but they both require a lot of time to understand the build process and structure.

I do have an interest in helping fuzix be more practical for most z80 systems (this means the binary size must come down) but I think it's going to involve a fork and there's still much to do within z88dk. The disk drivers really need to be finished before we can start calling the sdcc/z88dk combination a nearly complete C implementation.

Fuzix is adopting the unix stdio model completely but we went a different route to reduce program size by eliminating buffering at the stdio level and instead pushing a state machine to the driver to allow fast char at a time consumption using the driver's buffer. There's probably around 3k to save in the printf/scanf implementation alone but we'd have to rewrite the underside of our stdio functions first to fit with fuzix for that reason.

I wonder if we can easily add fuzix as a target for compiling user programs. I didn't really spot anything that documents what portions of the kernel is exposed to a user program and what lib functions are supposed to be supplied in user space.



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/ ... 1&iu=/4140