There is more to a compiler than just the compiler. There is the front end that makes the use of the compiler easy, the compiler itself, the libraries, the assembler/linker/librarian and the output generator. All of these things are independent. In terms of code size and performance, it is not the compiler that has most impact -- it is the libraries. All programs obey the 20-80 rule which means 20% of the code is executing 80% of the time. If you can make that 20% of the code very efficient, your program will perform well. That's why we write the libraries in machine code and not C. That's why you write the sprite engine in your games in machine code and not C.
In comparison between sdcc and z88dk, z88dk has a much better front end, its libraries are much better, the assembler/linker/librarian is comparable (I prefer the standard z80 opcodes in z80asm but that is not really material), the output generator does not exist in sdcc (the output generator takes the output binaries and processes them into a form required by the target, for example making .tap for spectrum, .sms for sega master system, .ihx for embedded systems, etc). It is sdcc's C compiler that is interesting.
These pieces are independent. This means we can replace one library with another (and we do, there are two C libraries in z88dk), one compiler with another (we do, there are two C compilers). We are currently experimenting with clang/llvm as a third C compiler (we can compile to .tap with clang now but some manual intervention is necessary and the code quality is not as good as sdcc or sccz80) and if anyone else comes up with a compiler we'd gladly plug that one in too. More interesting to us than clang/llvm for C compilation is using llvm to compile other languages like Fortran and Pascal. Then we'll get those to use the C library code and augment that with additional functions required by those languages. z88dk is a development kit for z80 computers not just a C compiler.
As for sdcc, its C library is very minimal and is written in C which makes it slow and big. There are many things missing from the sdcc library. For example there is no concept of FILE and the entire scanf side of stdio is missing. For the z80, the library has machine code implementations of 16 and 8 bit math as well as about 4-5 important functions from string.h (memcpy, strcpy,..). I really like the fact Philip turned memcpy and a few others into built-ins (the code will be inlined rather than called to a subroutine). These things will perform ok and are really important in C programs in general. Once you step out of this, you will see performance issues. The 32-bit math is about 1.7 times slower than z88dk. The 64-bit math is heading toward 3x slower than z88dk. Floats are 3x slower than z88dk and result in 40% larger code. This kind of comparison will pervade through the whole library. The is not a shortcoming of the compiler -- this is a shortcoming of the library which is independent of the compiler.
There is a reason why sdcc's library is written in C. sdcc targets 7 or 8 different microprocessors. A library written in C means it is portable to all 8 of those processors. Because there is only one body of code implementing the library, there is only one body of code to maintain. sdcc will never accept a processor-specific library into sdcc like z88dk's z80 library. They would require experts in each processor to maintain each separate library. The libraries would no longer be the same for each processor -- some processors would be better supported than others and people using sdcc would find it harder to use to target different processors because they would have to learn different libraries. The quirks of each, the level of support for each.
sdcc will also never target specific architectures. It will never support a separate code base for the dozens of z80 machines in existence.
z88dk is about doing all the things sdcc does not want to do. The solution is not to put z88dk into sdcc, it's to put sdcc into z88dk.
[свернуть]
Ответить с цитированием
Сообщение от Sayman
