reidrac wrote: ↑Thu Dec 27, 2018 2:15 pm
You misunderstood my post. The only reason why
I was using Z88DK was SP1. If I'm going to use the SDCC compiler in Z88DK, I rather use SDCC directly.
There is a big difference in sdcc on its own and sdcc within z88dk (called zsdcc). Many of the code generation bugs in sdcc have been addressed in zsdcc and the code generated is better. Usually you will see 5-10% difference in size, depending on what you are doing, on just the C code and it can go much higher if you are hitting expensive portions of the library. There are examples where zsdcc compiles to 40k whereas sdcc compiles to 60k when using things like 32-bit ints or floats.
The library in z88dk is much more comprehensive and standards compliant than sdcc. In addition, its written in assembly language whereas sdcc's is written in C. This leads to programs being smaller (see the edge case 40k versus 60k above) as well as faster. I do see a lot of people writing their own library code instead of using what comes with the compiler. On sdcc it doesn't make a difference because what it provides is in C already but in z88dk your program is being punished. If you're not using the library functions, you are still using compiler code for things like multiplication, division, reading/writing 32-bit / 64-bit integers (should you use such a thing). In sdcc, only 16-bit mult and div is in assembly language. In z88dk all of this is in assembly language including going up to 72-bit math.
The tooling around sdcc is very basic. The tooling around z88dk allows you to generate standard output forms for target machines like tap, sna, eg. The banking capabilities of machines is also built-in so z88dk can deal with that too without extra work.
The only reason to use sdcc on its own for zilog-related stuff is because you're used to it. Otherwise you are ending up with a more difficult toolset that produces poorer code