z80

Notes on using the z80, z180, r2k, r3ka, gbz80 and tlcs90 backends

crt0.o and --code-loc and --data-loc

The option argument to --code-loc specifies the location where sdcc will place your code. However the place where the startup code from crt0.o is placed is specified in it's source file crt0.s. The default crt0.s places the startup code at address 0. Thus specifying --code-loc 0 will cause problems since sdcc will try to place both your code and the startup code at address 0.

Example for the !ColecoVision with custom crt0.o and already compiled object files in the directory:

sdcc -mz80 --no-std-crt0 --code-loc 0x8080 --data-loc 0x7000 "../colecovision lib/bin/libcvu.lib" "../colecovision lib/bin/libcv.lib" "../colecovision lib/bin/crt0.o" *.o

The example uses two libraries. The program is to be placed into ROM, which is located at 0x8000, while RAM is located at 0x7000. Note that the argument to --code-loc is 0x8080, which leaves 0x80 bytes at 0x8000 for the startup code from crt0.o.

Writing efficient code

memcpy() (Does not apply to gbz80, which doesn't have ldir or equivalent)

Code generation for memcpy() is very efficient. Don't hesitate to use it. E.g. copying a structure (with at least two member variables) will be much more efficient using memcpy() than by assigning the members.

bool

The port has complete support for the _Bool/bool data type when compiling in c99 or sdcc99 mode. Use bool for condition variables, since sdcc will generate more efficient code than e.g. when using unsigned char.

signed vs. unsigned

The Z80 lacks an efficient signed comparison. Using unsigned variables will result in slightly smaller and faster code. On the GBZ80 the situation is even worse, resulting in a more substancial difference in code size and speed.

Notable command-line options

• --calle-saves-bc: Make called functions save bc.
• --codeseg=<name>: Use the provided name for the code segment.</name>
• --constseg=<name>: Use the provided name for the const segment.</name>
• --portmode=<mode>: Set the port mode for I/O to z80 or z180.</mode>
• --asm=<name>: Generate code for the selected assembler (rgbds, sdasz80, isas or z80asm). This option can reduce the efficiency of peephole optimization.</name>
• --no-std-crt0: Do not link the default crt0.rel. Use this when using a custom crt0.rel instead.
• --reserve-regs-iy (Does not apply to gbz80, which doesn't have iy): This option tells the compiler that it is not allowed to use register pair iy. The option can be useful for systems where iy is reserved for the OS.
• --dump-graphs: Dump the control flow graph, variable conflict graph and tree-decomposition of the control-flow graph in .dot format.
• --max-allocs-per-node=<number>: Set the maximum number of register assignments considered at each node of the tree decomposition. Higher values make sdcc slower, but tend to result in better code being generated. The default value is 3000.</number>

[Ragozini Arturo]

after the change in the parameter passing, the next big improvement could be to allow the asm code generation take into account the use of alternative registers and iyh/l ixh/l

https://sourceforge.net/p/sdcc/feature-requests/795/

[Philipp Klaus Krause]

Unlikely. Multiple SDCC developers are currently working on major improvements in standard compliance. That is a big improvement, and will be done in time for 4.3.0. I don't see use of the alternate register set arriving sooner.

iyl / iyh might arrive for 4.3.0 (if someone else fixes the support in the assembler, I'll implement support on the compiler side), but it is only a small improvement: Lets compare z80 to z80n. The latter has a few extra instructions, and officially supports the iyl / iyh stuff, so SDCC uses them:

Statistics on compiling and executing the regression tests:

Summary for 'ucz80': 0 failures, 24370 tests, 2949 test cases, 4550998 bytes, 801640429 ticks

Summary for 'ucz80n': 0 failures, 24317 tests, 2949 test cases, 4546390 bytes, 788709753 ticks

That's a 0.1% improvement in code size. Nice to have, but not "big". The reduction in runtime is clearly bigger at 1.6 %, but I suspect it is mostly due to the z80n barrel-shift instructions, not the iyl / iyh use.

[Ragozini Arturo]

Any time you can avoid the use of the stack for dynamic variables and use registers there will be a sensible speed gain. The gain is maximised when thanks to the use of extra registers you can completely skip the use of the stack (and use ixl/h for variables). Alternative register set can do a lot in avoiding the need of allocating variables on the stack.
One of the strongest point of the z80 against the 8080 is the presence of the alternative registers, I see that there are many restrictions in passing values between the two sets, but it is worth the effort. The access to variables in ram through (ix+n) is the slowest method on the z80 even if elegant and supported by many opcodes. Thus it should be used as last option when other solutions using registers are not sufficient.