Есть ли у вас ссылка на полной программе, чтобы проверить? Ни один из программ в этой дискуссии не будет полным - часть исходного кода была отрубили по некоторым причинам.
Скрытый текст
Do you have a link to a complete program to test? None of the programs in that discussion is complete -- some of the source code has been chopped off for some reason.
[свернуть]
В общем, люди не используют компиляторы должным образом. Например, вы не должны использовать встраиваемые ASM с SDCC, потому что это мешает локальной оптимизации. Вы можете получить некоторые странные код из SDCC как статических нагрузок не избежать, если встроен ASM вставляется в C коде. С sccz80 (родной компилятор z88dk), а на самом деле со всеми компиляторами, лучше Код производительности должны использовать глобальные или локальные статику, если это разумно. Особенно с sccz80 это может сделать большую разницу в производительности. Оптимизация должна быть положить на макс, и многие люди не знают, как это сделать. С sccz80 Это -O3 и SDCC, который заходящего --max-allocs-per-node на что-то высокое (как 200000). Обычно вы можете получить лучший код из SDCC, запрещая использование слишком гу, добавив --reserve-regs-iy.
Скрытый текст
In general, people are not using the compilers properly. For example, you should not be using inlined asm with sdcc because it interferes with peephole optimization. You can get some weird code out of sdcc like dead loads not being eliminated if inlined asm is inserted into C code. With sccz80 (z88dk's native compiler) and actually with all the compilers, best performance code should be using globals or local statics if that is reasonable. Especially with sccz80 this can make a big difference in performance. Optimizations should be put on max and many people don't know how to do that. With sccz80 that's -O3 and with sdcc that's setting --max-allocs-per-node to something high (like 200000). You can usually get better code out of sdcc by forbidding use of iy too by adding --reserve-regs-iy.
[свернуть]
sccz80-сгенерированный код никогда не будет самым быстрым. Причина он пытается реализовать компилятора операции, используя вызовы подпрограмм, чтобы быть наименьшим. При том, что в сочетании с языка ассемблера библиотеки, где производительность, как предполагается, пришли, результат маленький и быстрый код. sccz80 сгенерированный код, как правило, меньше, чем SDCC или HITECH, иногда с большим отрывом, но sccz80 требует программировать для компилятора, а не делать вид, что это 32-битная платформа с кодом. Вы можете видеть, что в некоторых крупных программ, составленных мы. Например, clisp.c - это Lisp interpretter> 1200 строк в C - компилирует 27000 байт под sccz80 и 32000 байт под HTCv7.50. startrek.c (> 2100 строк в C) доходит до 41000 байт под HTCv7.50 и 32600 байт под z88dk + SDCC. Последнее особенно связано в основном с более библиотек z88dk так размер кода похож на HTC и SDCC если код библиотеки исключены.
Скрытый текст
sccz80-generated code is never going to be the fastest. The reason is it's trying to implement compiler operations using subroutine calls in order to be the smallest. When that is combined with assembly language libraries, where the performance is supposed to come from, the result is small and fast code. sccz80 generated code is normally smaller than sdcc or hitech, sometimes by a large margin, but sccz80 requires you to program for the compiler rather than pretend it's a 32-bit platform with the code. You can see that in some of the large programs we compiled. Eg, clisp.c -- a lisp interpretter > 1200 lines in C -- compiles to 27000 bytes under sccz80 and 32000 bytes under HTCv7.50. startrek.c (> 2100 lines in C) comes to 41000 bytes under HTCv7.50 and 32600 bytes under z88dk+sdcc. The latter especially is due mainly to better libraries in z88dk since code size is similar for HTC and sdcc if library code is excluded.
[свернуть]
Версия z88dk на sourceforge (1.10) не является текущей. Текущая версия может использовать SDCC, как компилятор, улучшить свой код несколько, и поставить на ассемблере библиотеки из z88dk. Это то, что, кажется, превосходит все остальное большую часть времени в скорости, размер кода и полноты. Я очень заинтересован в поиске, когда эта комбинация не так хорошо, другие компиляторы, чтобы увидеть, где некоторые очевидные улучшения могут быть сделаны.
Скрытый текст
The version of z88dk at sf (v1.10) is not current. The current version is able to use sdcc as compiler, improve its code somewhat, and supply assembly language libraries from z88dk. This is what seems to be outperforming everything else most of the time in speed, code size and completeness. I'm very interested in finding out when this combination does not perform as well as other compilers to see where some obvious improvements can be made.
[свернуть]