Сообщение от
OrionExt
Вернемся к кодогенерации. Оба компилятора успешно подошли к планке 90% эффективности генерирования кода.
Я думаю, что это слишком великодушно 
Мой ручной код asm намного лучше, в 3 раза меньше и быстрее в сложных функциях. Частично причина заключается в том, что все эти компиляторы начинаются с препятствия - они уже решили, что локальные переменные будут в стеке, и они будут проиндексированы с индексным регистром. В очень небольших функциях, как sdcc, так и HTC могут покончить с этим. Это совершенно противоположное тому, что происходит, когда я пишу сборку от руки. Я начинаю с того, что не хочу использовать индексные регистры, если мне это не нужно. Это одно решение вносит большой вклад в разрыв между компиляторами и людьми при написании кода z80.
Учитывая ограничение стекового фрейма, производительность компилятора обычно не ужасна. Иногда я приятно удивлён кодом sdcc, который появляется в небольших плотных циклах с 8-битными величинами. Иногда я вижу нечто, что производит обратное впечатление: P Эти вещи я стараюсь исправить в пост-обработке. HTC более шаблонный и предсказуемый в своем поколении кода. Это редко будет действительно плохой код, но вы редко будете так что-то действительно умный. Когда я вижу вывод sdcc, ясно, что генератор кода z80 не рассматривает множество опций и не требует правильного использования индексных регистров (поэтому z88dk может получить намного лучший код из sdcc с помощью -reserve-regs- Iy "). Имейте в виду, что современный компилятор разделен между интерфейсом, в котором происходит весь анализ, и фоновым объектом, где лежит генератор кода. Это генератор кода, который, как я считаю, все еще имеет возможности для улучшения.
Скрытый текст
I think that is being much too generous
My hand written asm code is much better, in the range of 3x smaller and faster in complex functions. Part of the reason is all these compilers begin with an impediment - they have already decided local variables will be on the stack and they will be indexed with an index register. In very small functions, both sdcc and HTC may do away with this. This is quite the opposite to what happens when I write assembly by hand. I begin by saying I don't want to use the index registers unless I really have to. That one decision contributes a great deal toward the gap between the compilers and humans when writing z80 code.
Given the stack frame constraint, the compiler performances are not usually terrible. Sometimes I am pleasantly surprised by code sdcc comes up with in small tight loops involving 8-bit quantities. Sometimes I see something that makes the opposite impression :P These things I try to fix up in post-processing. HTC is more formulaic and predictable in its code generation. It will rarely be really bad code but also you will rarely so something really clever. When I see sdcc's output, it's clear that the z80 code generator is not considering many options and doesn't cost the use of index registers properly (this is why z88dk can get much better code out of sdcc with "--reserve-regs-iy"). Keep in mind a modern compiler is divided between a front-end where all the analysis happens and a back-end where the code generator lies. It's the code generator that I believe still has room for improvement.
[свернуть]
По поводу эффективных и не эффективных библиотек и ловли блох у каждого из компиляторов. Ставить одну библиотеку над другой и определенные ходы в кодогенерации, думаю, не стоит. Все они преследуют определенные цели в узких рамках Z80.
Компилятор C состоит из двух частей - переводчика языка и библиотеки. Оба одинаково важны, чтобы позволить программисту выполнить что-либо. Вы можете попробовать делать программы с GCC без GLIBC, но вы не очень далеко. Аналогично попытайтесь построить что-нибудь с помощью Visual Studio, не связывая время выполнения c microsoft или его код win32 gui. Библиотека является неотъемлемой частью компилятора, и поэтому стандарт C определяет, что должно быть там, как минимум. Если компиляторам не хватает больших порций, их полезность уменьшается.
На z80 библиотеки приобретают новое значение, поскольку компиляторы не могут генерировать почти такой же хороший код, как ассемблер, написанный руками.
Я могу показать вам результаты нескольких тестов, которые показывают, какой код библиотеки различий может сделать. Zsdcc будет использовать библиотеку языков ассемблера, а sdcc будет использовать свою собственную библиотеку, написанную на C. Имейте в виду, что zsdcc - это sdcc с некоторыми улучшениями, так что это почти сравнение равных.
Скрытый текст
A C compiler has two parts - the language translator and the library. Both are equally important to allow a programmer to accomplish anything. You can try to make programs with GCC without GLIBC but you won't get very far. Likewise try to build anything with Visual Studio without linking microsoft's c runtime or its win32 gui code. The library is an essential part of the compiler and that's why the C standard specifies what has to be in there at minimum. If compilers are missing large portions, their usefulness is decreased.
On the z80, the libraries take on a new importance because the compilers are not able to generate nearly as good code as hand written assembler.
I can show you a few benchmark results that demonstrate the difference library code can make. zsdcc will be using an assembly language library and sdcc will be using its own library written in C. Keep in mind zsdcc is sdcc with some improvements so this is almost a comparison of equals.
[свернуть]
PI BENCHMARK (mainly testing 32-bit integer math)
Код:
Z88DK March 2, 2017
zsdcc #9833 / new c library / small int math
6246 bytes less page zero
cycle count = 5278798872
time @ 4MHz = 5278798872 / 4*10^6 = 22 min 00 sec
*****
SDCC 3.6.5 #9842 (MINGW64)
6844 bytes less page zero
cycle count = 8700157418
time @ 4MHz = 8700157418 / 4*10^6 = 36 min 15 sec
SDCC implements its 32-bit math in C.
Это на 63% медленнее, а дополнительные 600 байтов исходят из того факта, что 32-битная математика sdcc написана на C.
Если мы сможем принять большой размер кода, zsdcc может быть скомпилирован с использованием библиотеки с быстрыми целыми числами:
Скрытый текст
That's 63% slower and an extra 600 bytes coming from the fact sdcc's 32-bit math is written in C.
If we can accept a large code size, zsdcc can be compiled using a fast integer library:
[свернуть]
Код:
Z88DK March 2, 2017
zsdcc #9833 / new c library / fast int math
8997 bytes less page zero
cycle count = 1739403552
time @ 4MHz = 1739403552 / 4*10^6 = 7 min 15 sec
Это теперь в пять раз быстрее, чем sdcc. И снова основное различие - библиотека.
Еще один большой результат - математика с плавающей запятой. Это из ЭТАПЫ WHETSTONE:
Скрытый текст
That's now five times faster than sdcc. Again the main difference is the library.
Another large result is in floating point math. This is from the WHETSTONE BENCHMARK:
[свернуть]
Код:
Z88DK March 2, 2017
zsdcc #9833 / new c library / math48 float package
24 bit mantissa + 8 bit exponent (internally 40+8)
6153 bytes less page zero
cycle count = 916537242
time @ 4MHz = 916537242 / 4x10^6 = 229.1343 seconds
KWIPS = 100*10*1 / 229.1343 = 4.3643
MWIPS = 4.3643 / 1000 = 0.0043643
*****
SDCC 3.6.5 #9842 (MINGW64)
24 bit mantissa + 8 bit exponent
14379 bytes less page zero
cycle count = 2184812093
time @ 4MHz = 2184812093 / 4x10^6 = 546.2030 seconds
KWIPS = 100*10*1 / 546.2030 = 1.8308
MWIPS = 1.8308 / 1000 = 0.0018308
SDCC implements its float library in C.
Sdcc более чем в два раза медленнее с плавающей библиотекой, написанной на C (и посмотрите на разницу в размерах). Это намного хуже, чем то, что появляется на поверхности. В z88dk математическая библиотека внутренне реализует 48-битное число с плавающей точкой с 40-битной мантиссой. Библиотека sdcc должна иметь дело только с 32-битным плавающей точкой и 24-битной мантиссой. Это значительное преимущество в производительности. Плавающая библиотека sdcc должна иметь более чем у z88dk. На самом деле цифры должны быть наоборот.
Эти два теста показывают очевидную разницу, поскольку большая часть времени выполнения находится в коде библиотеки, а не в коде, генерируемом компилятором. В большинстве программ время выполнения будет не столько доминировать с помощью библиотечного кода, сколько преимущество в производительности библиотеки.
По крайней мере, столь же важным, как скорость выполнения, является размер программы. В больших программах существуют очень большие различия в размере кода между sdcc и zsdcc. Частью этого является улучшение генерации кода (улучшение размера кода на 5-10%, хотя есть случаи с краями до 50%), но большая часть кода библиотеки. Я видел экономию 10 тыс. И более на больших скомпилированных программах, главным образом из-за различий в размере кода библиотеки. В программе размер, HTC и другие, как правило, избивают SDCC. И снова это обычно сводится к размеру кода библиотеки. У HTC и других есть свод библиотечного кода, реализованного в ассемблере, тогда как sdcc имеет очень мало этого. В этих сравнениях z88dk также выигрывает у HTC и других в размере кода, в значительной степени благодаря тому, что z88dk имеет намного больший объем библиотечного кода, написанного на ассемблере.
Постобработка кода не вносит такой же вклад в экономию средств. Я считаю, около 5-10% размера является типичным. Воздействие на время выполнения может быть больше, если преобразования происходят внутри циклов. Одной из важных функций этих преобразований является исправление некоторых ошибок генерации кода sdcc, что позволяет нам надежно использовать «-reserve-regs-iy» и получать улучшенную генерацию кода из самого sdcc.
Скрытый текст
sdcc is more than twice as slow with a float library written in C (and look at the size difference). It's much worse than what appears on the surface. In z88dk, the math library internally implements a 48-bit float with a 40-bit mantissa. sdcc's library only has to deal with a 32-bit float and a 24-bit mantissa. That's a significant performance advantage sdcc's float library should have over z88dk's. In fact the numbers should be the other way around.
These two benchmarks show an obvious difference because most of the running time is in the library code rather than the compiler-generated code. In most code, execution time won't be dominated so much by library code but this library performance advantage will penetrate everywhere.
At least as important as the execution speed is the program size. In large programs there are very big differences in code size between sdcc and zsdcc. Part of it is better code generation (~5-10% code size improvement although there are fringe cases up to 50%) but a larger part is the library code. I have seen savings of 10k or more on large compiled programs mainly due to differences in library code size. In program size, HTC and others tend to beat sdcc as well. And again this is usually down to library code size. HTC and others do have a body of library code implemented in assembler whereas sdcc has very little of this. In these comparisons, z88dk also beats HTC and others in code size due in large part to the fact z88dk has a much larger body of library code written in assembler.
The post-processing of code doesn't contribute as much to savings. I find around 5-10% size is typical. The impact on running time can be larger if the transformations happen inside loops. One important function of these transformations is to fix some of sdcc's code generation bugs that allows us to reliably use "--reserve-regs-iy" and get improved code generation out of sdcc itself.
[свернуть]
SDCC...Что бы я отметил. Не подходит для новичков и у профессионалов с ним периодический происходят трудности в использовании.
Я не уверен, что я полностью согласен с этим. Его проще использовать в том смысле, что он лучше соответствует стандартам и может компилировать больше программ, чем другие компиляторы z80. Запуск на современной машине, а не, скажем, CP / M отнимает искусственные ограничения на размер программы.
По сравнению с HTC и IAR, чего ему действительно не хватает, это несколько стандартных crts. Я видел, что многие люди борются с этим просто потому, что они не знали, как писать crt. После компиляции у вас есть .ihx-файл, который легко превратить в двоичный файл с помощью HEX2BIN. Кроме этого, я бы оценил его равным в простоте использования с IAR и HTC 309 (без учета ограничений, введенных CPM). У HTC 750 есть простая IDE, которая может понравиться некоторым пользователям, но я нахожу только отягчающей.
Z88DK имеет преимущества перед всеми этими компиляторами: - передний интерфейс позволяет легко смешивать c, asm, макросы и т. Д. Он может хранить отдельные библиотеки для любой машины z80 с выделением из строки компиляции. Крошки уже сделаны. Постобработка включает в себя шаг с использованием «APPMAKE», который может превращать выходные двоичные файлы в COM, ROM, TAP, DSK, независимо от цели. Одна строка для компиляции любого количества исходных файлов в требуемую форму вывода, и для экспертов есть много вариантов. ZSDCC работает внутри этой инструментальной цепи, поэтому «SDCC» также можно использовать в этом простом режиме.
Скрытый текст
I'm not sure I'd wholly agree with that. It's easier to use in the sense it has better standards conformance and can compile more programs than the other z80 compilers. Running on a modern machine instead of, say, CP/M takes away artificial limits on program size.
In comparison with HTC and IAR what it is really lacking is a few more standard crts. I've seen many people struggle with it simply because they did not know how to write a crt. After a compile you have an .ihx file which is easy to turn into a binary with HEX2BIN. Other than that I'd rate it equal in ease of use with IAR and HTC 309 (ignoring the limits introduced by CPM). HTC 750 has a simple IDE that some may like but I only find aggravating to use.
Z88DK has usage advantages over all these compilers :- the front end makes it easy to mix c, asm, macros, etc. It can hold separate libraries for any z80 machine with selection from the compile line. The crts are already made. The post processing involves a step using "APPMAKE" that can turn the output binaries into COM, ROM, TAP, DSK, whatever the target needs. One line to compile any number of source files to the required output form and there's a lot of options in between for experts. ZSDCC runs inside this toolchain so "SDCC" can be used in this easy manner too.
[свернуть]
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
