Если это не встроенная система, то чаще всего процессорная плата z80 припаивается к материнской плате, а аппаратное обеспечение вокруг нее не может обеспечить более высокую тактовую частоту, поэтому замена процессора более быстрым вариантом не подходит большинству людей. Небольшие вещи, которые Олег рассказывает обо всех, складываются. Например, несколько небольших вещей, которые мы сделали в z88dk (например, callle и fastcall linkage), добавили к сохранению 1k в 40k скомпилированной программе. Нечего чихать. Эти другие коммерческие компиляторы также делают много мелких вещей, и у кого больше успехов, можно реально измерить только путем сбора тестовых примеров.Цитата:
Сообщение от Error404
Я бы согласился с вами, что скорость не является проблемой номер один для компилятора, но приятно быть быстрее, другие приоритеты равны. Скорость не совсем неуместна, как вы предполагаете; Если бы это было так, вы были бы довольны программированием в основном. Цель состоит в том, чтобы быть достаточно быстрым (и, во-вторых, так быстро, как это разумно, учитывая ограничения). Я считаю, что скомпилированный размер программы гораздо более важен, если компилятор может удовлетворять удовлетворительной скорости. Например, существует около 40 игр, написанных на C для спектра (около 30-35 или около того с z88dk), и в любой нетривиальной игре размер памяти является проблемой. Любые разумные средства для уменьшения размера компиляции могут способствовать качеству игр.
Скрытый текст
Unless it's an embedded system, most often the z80 cpu is soldered onto the motherboard and the hardware around it cannot accommodate higher clock rates so replacing the cpu with a faster one is not an option for most people. The small things that Oleg talks about all add up. For example, several small things we did in z88dk (callee and fastcall linkage, for example) added up to saving 1k in a 40k compiled program. That's nothing to sneeze at. These other commercial compilers also do many small things and who's had more success can really only be measured by trying to compile test cases.
I would agree with you that speed is not really the number one concern for a compiler but it is nice to be faster, other priorities held equal. Speed is not totally irrelevant as you suggest however; if it was, you would be satisfied with programming in basic. The goal is to be fast enough (and secondarily as fast as is reasonable given constraints). I find that compiled program size is much more important once the compiler can meet satisfactory speed. For example, there are about 40 games written in C for the spectrum (about 30-35 or so with z88dk) and in any non-trivial game the memory size is a problem. Any reasonable means to get the compile size down can contribute to the quality of games produced.
[свернуть]
Sdcc 2.9x давным-давно перед некоторыми существенными изменениями в генераторе кода z80 в sdcc. Я бы тоже не использовал 2.9x, однако нынешний sdcc намного лучше. У него все еще есть некоторые ошибки, особенно окружающие доступ к статическим переменным и --reserve-regs-iy, но они были решены в z88dk (не sdcc).Цитата:
По первому пункту у SDCC все было очень грустно (по крайней мере в последней версии SDCC что я использовал - 2.9х - заведомо исправный код компилировался без ошибок и варнингов, но не работал, а проходить 25кб консольным отладчиком - нуегонафиг), тогда как Hitec тот же код собирал и он работал (при в полтора меньшем размере кода на выходе). Возможно, сейчас стало получше, но эксперимениты с любительскими клонами SmallC я завязал.
Главная проблема с sdcc заключается не в переводчике языка, а в библиотеке. Библиотека минимальна и написана на C. Любой, кто использует sdcc, останется с впечатлением, что многое отсутствует и будет разочаровано скоростью и объемом памяти. Опять же, проблема не в самом компиляторе. Когда вы разрешаете sdcc использовать библиотеки языков ассемблера z88dk, его производительность улучшается в несколько раз.
Конечно, я все еще вижу много возможностей для улучшения в компиляторе, но я вижу, что в каждом компиляторе, который я тестировал (hitech cpm 309, hitech cpm 750, iar 406a, z88dk / zsdcc, z88dk / sccz80, sdcc).
Скрытый текст
sdcc 2.9x is a long time ago before some significant changes in the z80 code generator in sdcc. I wouldn't have used 2.9x either, however the current sdcc is much better. It does still have some bugs especially surrounding access to static variables and --reserve-regs-iy but these have been solved in z88dk (not sdcc).
The main issue with sdcc is not in the language translator, it's in the library. The library is minimal and written in C. Anyone using sdcc will be left with the impression that a lot is missing and will be disappointed with speed and memory size performance. Again, the problem is not in the compiler itself. When you allow sdcc to use z88dk's assembly language libraries its performance improves by several times.
Of course, I still see a lot of room for improvement in the compiler but I see that in every compiler I've been testing (hitech cpm 309, hitech cpm 750, iar 406a, z88dk/zsdcc, z88dk/sccz80, sdcc).
[свернуть]
Справедливо, если вам нужен только ANSI-компилятор. Но я просто скажу, что не очень справедливо сравнивать z88dk / sccz80 (небольшой c-компилятор в z88dk) с другими компиляторами c. Эти другие компиляторы застыли в своем развитии ~ 20 лет назад. Sccz80 никогда не прекращал развиваться, поэтому вы можете рассматривать его как самый доступный небольшой компилятор c.Цитата:
По второму пункту тоже очевидно: ANSII компилятор (т.е. как я понимаю Z88dk сразу выпадает) с максимум полдюжиной ключей и готовым выхлопом под наиболее распространенныю платформу для которой есть 100500 эмуляторов (CP/M) куда как проще освоить и дальше видоизменять {адреcа посадки и чего угодно},
Z88dk также содержит zsdcc, который является улучшенным sdcc-z80. Это компилятор ANSI с исправлениями некоторых ошибок sdcc и многими оптимизациями глазок, которые улучшают вывод кода. Большие улучшения также возникают из-за использования z88dk-интерфейса и его задней части, что упрощает компиляцию программ и позволяет настраивать таргетинг на различные машины z80, просто изменяя переключатель компиляции. Он также получает доступ к библиотечным языкам ассемблера z88dk. Эти вещи улучшают производительность sdcc.
Скрытый текст
Fair enough if you only want a reasonably ansi compiler. But I'll just say it's not really fair to compare z88dk/sccz80 (the small c derived compiler in z88dk) with the other small c compilers. Those other compilers froze in their development ~20 years ago. sccz80 never stopped developing so you can regard it as the most advanced small c derived compiler available.
z88dk also contains zsdcc which is an improved sdcc-z80. That is an ansi compiler with fixes for some of sdcc's bugs and many peephole optimizations that improve the code output. Large improvements also come from using z88dk's front end and back end which makes it easy to compile programs and makes it possible to target different z80 machines just by changing a compile-line switch. It also gets access to z88dk's assembly language libraries. These things improve sdcc's performance a great deal.
[свернуть]
Они (sdcc) не обращали внимания на эффективную реализацию некоторых структур данных. Оптимизация компиляторов гораздо сложнее изнутри и может потреблять гораздо больше памяти при анализе кода, чем любой компилятор, который может работать только в 64-разрядной системе. Лично, время работы компилятора - это не моя основная проблема, если я получаю что-то хорошее с другого конца. Это может иметь значение во время разработки, если оно замедляет работу, но вы всегда можете снизить уровень оптимизации, чтобы ускорить процесс или правильно разбить исходный код, чтобы вы могли использовать make-файл.Цитата:
чем компилер с дикой кучей ключей и "изкоробки" не компилирующий в среду, которую должен знать и уметь любой уважающий себя компилер для Z80 (что тоже говорит о кругозоре авторов). А так то конечно да - имея под попой PC986 с биллионами байт памяти и биллионами же герц тактовой казалось бы не написать нормальный компилятор С?! Да за пояс заткнем эти CP/M c их 64кб, дискеткой в 400кб и смешным процессором. :))) #скоро
Скрытый текст
They (sdcc) didn't pay attention to efficient implementation of some data structures. Optimizing compilers are much more sophisticated internally and can consume a great deal more memory in doing code analysis than any compiler that is restricted to run on a 64k system. Personally, the compiler's running time is not my main concern as long as I get something good out the other end. It can matter during development if it slows you down but you can always reduce the optimization level to speed things up or properly partition your source code so that you can make use of a makefile.
[свернуть]
Hitech cpm v309 libf не является надежным. Он дает только точные результаты с плавающей запятой для + - * /. У всего остального есть большие ошибки. Я нашел это, когда выполнял несколько тестовых программ, содержащих операции с плавающей запятой. BTW, Hitech msdos v750 не может даже + - * /, все операции с плавающей точкой прослушиваются.Цитата:
Вот тут лежит моя адаптация UZIX где в качестве компилятора использован HitechC v3(+эмулятор+make). Там же есть библиотеки в исходниках (libc, libf),
Я обнаружил, что у Hitech cpm v309 была самая быстрая реализация 32-битной плавающей библиотеки, но, как уже упоминалось, она хороша только для + - * /.
Скрытый текст
Hitech cpm v309 libf is not reliable. It only produces accurate floating point results for +-*/. Anything else has large errors in them. I found this while running several benchmark programs containing float operations. BTW, Hitech msdos v750 cannot even +-*/, all float operations are bugged.
I did find that Hitech cpm v309 had the fastest 32-bit float library implementation but, as mentioned, it is only good for +-*/.
[свернуть]
Я бы не согласился. Конечно, Fuzix сложнее, чем Uzix, потому что, помимо всего прочего, он должен поддерживать разные архитектуры, включая различные графические и текстовые терминалы с различными разрешениями. Uzix не так амбициозен. Однако я согласен с тем, что Fuzix будет намного меньше и быстрее, если использовать, например, z88dk / zsdcc. Но это потребует значительных изменений, чтобы добиться улучшений, потому что z88dk работает на уровне языка ассемблера, но Fuzix в настоящее время ориентирован только на C. Например, все заголовки z88dk используют атрибуты низкого уровня для изменения связи вызова функций вызова и сохранения информации о регистрации для вызова В функции языка ассемблера в библиотеке. Сейчас нет способа разместить это в системе сборки Fuzix.Цитата:
Кстати из смешного, FUZIX (который не сложнее Uzix) где компилятором взяли SDCC, AFAIK собирается только одной определенной версией этого чудесного компилятора, с набором костылей (к компилятору понятно).
Скрытый текст
I would disagree. Fuzix certainly is more complicated than Uzix because, among other things, it has to support different architectures including different graphics and text terminals with varying resolutions. Uzix is not as ambitious. However I do agree that Fuzix would be a lot smaller and faster if it used, say, z88dk/zsdcc. But it would require a lot of changes to gain improvements because z88dk operates at the assembly language level but Fuzix is currently geared only to C. For example, all of z88dk's headers use low level attributes to change function call linkage and register preservation information for calling into the assembly language functions in the library. There is no way to accommodate this in Fuzix's build system now.
[свернуть]
