#2918 [z80]{z180] undocumented instructions

[Phillip Stevens]

Using this command line the ceilf.c file generates undocumented iyh instructions, for both z80 and z180.

sdcc -V --std-c99 -mz80 --less-pedantic --max-allocs-per-node100000 --opt-code-size -D__FUZIX__ -Ddouble=float --fverbose-asm -DBUILD_LIBM -I/opt/fcc/include/ -S ceilf.c -o ceilf.asm

```
:~/Z80/src/test_ceilf$ sdcc -V --std-c99 -mz180 --less-pedantic --max-allocs-per-node100000 --opt-code-size -D__FUZIX__ -Ddouble=float --fverbose-asm -DBUILD_LIBM -I/opt/fcc/include/ -S ceilf.c -o ceilf.asm

• /usr/local/bin/sdcpp -nostdinc -Wall -std=c99 -D__FUZIX__ -Ddouble=float -DBUILD_LIBM -I/opt/fcc/include/ -obj-ext=.rel -D__SDCC_STACK_AUTO -D__SDCC_CHAR_UNSIGNED -D__SDCC_INT_LONG_REENT -D__SDCC_FLOAT_REENT -D__SDCC=3_9_1 -D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 -D__SDCC_VERSION_PATCH=1 -D__SDCC_REVISION=11295 -D__SDCC_z180 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem /usr/local/bin/../share/sdcc/include/z180 -isystem /usr/local/share/sdcc/include/z180 -isystem /usr/local/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include ceilf.c
  ```

[Philipp Klaus Krause]

Which version of SDCC? I recently (about a week or two ago) made some chanegs in handling of iy in register allocation that might have introduced such a bug.

Philipp

[Phillip Stevens]

Using the SDCC_REVISION=11295.

Perhaps the question has been put before but, wouldn't it be better to restrict the use of any undocumented processor instructions to an active option rather than including them by default?

Perhaps --allow-undocumented ?

The issue is that (for example) FUZIX issues two processor types for z180. Z180 in the kernel, but z80 for user tools. This implies that undocumented z80 instructions could appear in a build actually meant for z180 processors.

This example is specific to FUZIX, but generally it means that something compiled with SDCC for z80 can't be run on a z180 or ez80 (?) with full confidence that it will work. I think that's a problem.

[Philipp Klaus Krause]

This use of undocumented instructions is a bug. Could be one of those that are actually documented in the eZ80 being emitted accidentially for z80 and z180.

However, so far I wasn't able to reproduce this issue using current SDCC [r11304] on my Debian GNU/Linux testing system (despite AFAIR there being no chnages that should affect z80/z180 between [r11295] and [r11304]).

Could you post the .asm file?

Philipp

[Phillip Stevens]

And the command line and verbose response again.

:~/Z80/src/test_ceilf$ sdcc -V --std-c99 -mz80 --less-pedantic --max-allocs-per-node100000 --opt-code-size -D__FUZIX__ -Ddouble=float --fverbose-asm -DBUILD_LIBM -I/opt/fcc/include/ -S ceilf.c -o ceilf.asm

/usr/local/bin/sdcpp -nostdinc -Wall -std=c99 -D__FUZIX__ -Ddouble=float -DBUILD_LIBM -I/opt/fcc/include/ -obj-ext=.rel -D__SDCC_STACK_AUTO -D__SDCC_CHAR_UNSIGNED -D__SDCC_INT_LONG_REENT -D__SDCC_FLOAT_REENT -D__SDCC=3_9_1 -D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 -D__SDCC_VERSION_PATCH=1 -D__SDCC_REVISION=11295 -D__SDCC_z80 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem /usr/local/bin/../share/sdcc/include/z80 -isystem /usr/local/share/sdcc/include/z80 -isystem /usr/local/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include  ceilf.c

using --reserve-regs-iy converts the ld iyh,l into a ix stack store.

[Phillip Stevens]

For interest, I pursued the FUZIX build by removing ceilf.c, until it also flagged floorf.c procucing similar ld iyh,l undocumented instructions.

:~/Z80/src/test_fuzix$ sdcc -V --std-c99 -mz80 --less-pedantic --max-allocs-per-node100000 --opt-code-size -D__FUZIX__ -Ddouble=float --fverbose-asm -DBUILD_LIBM -I/opt/fcc/include/ -S floorf.c -o floorf.asm

+ /usr/local/bin/sdcpp -nostdinc -Wall -std=c99 -D__FUZIX__ -Ddouble=float -DBUILD_LIBM -I/opt/fcc/include/ -obj-ext=.rel -D__SDCC_STACK_AUTO -D__SDCC_CHAR_UNSIGNED -D__SDCC_INT_LONG_REENT -D__SDCC_FLOAT_REENT -D__SDCC=3_9_1 -D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 -D__SDCC_VERSION_PATCH=1 -D__SDCC_REVISION=11295 -D__SDCC_z80 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem /usr/local/bin/../share/sdcc/include/z80 -isystem /usr/local/share/sdcc/include/z80 -isystem /usr/local/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include  floorf.c 

I'll add any further examples, as I find them.

Phillip

[Phillip Stevens]

copt.c has same ld iyh,h issue.

:~/Z80/src/test_fuzix$ sdcc -V --std-c99 -mz80 --less-pedantic --max-allocs-per-node100000 --opt-code-size -D__FUZIX__ -Ddouble=float --fverbose-asm -DBUILD_LIBM -I/opt/fcc/include/ -S copt.c -o copt.asm
/usr/local/bin/sdcpp -nostdinc -Wall -std=c99 -D__FUZIX__ -Ddouble=float -DBUILD_LIBM -I/opt/fcc/include/ -obj-ext=.rel -D__SDCC_STACK_AUTO -D__SDCC_CHAR_UNSIGNED -D__SDCC_INT_LONG_REENT -D__SDCC_FLOAT_REENT -D__SDCC=3_9_1 -D__SDCC_VERSION_MAJOR=3 -D__SDCC_VERSION_MINOR=9 -D__SDCC_VERSION_PATCH=1 -D__SDCC_REVISION=11295 -D__SDCC_z80 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__STDC_UTF_16__=1 -D__STDC_UTF_32__=1 -isystem /usr/local/bin/../share/sdcc/include/z80 -isystem /usr/local/share/sdcc/include/z80 -isystem /usr/local/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include  copt.c 

[Phillip Stevens]

rename.c has a load ld l,iyl and ld h,iyh pair.

Phillip

[Philipp Klaus Krause]

Thanks. While I still can't reproduce the issue, the asm source allowed me to track it down to a bug in code generation where indeed the ld instruction could be (depending on register allocation) used for iyl, iyh as if the target was eZ80. It should be fixed in [r11311]. Please test.

Philipp

[Phillip Stevens]

Tested the 4 test cases presented ceilf.c, floorf.c, copt.c, and rename.c.
The r11311 has fixed the issue.
Thanks. -> I'll update z88dk to propose migration to this version.
Phillip