Осваиваем Hi-Tech C v3.09 для CP/M

Цитата:

---

Сообщение от Alcoholics Anonymous

На самом деле, вы, вероятно, можете получить 80% пути к идеальной компиляции, не прибегая к мегабайтам интеллекта. Это последние 20%, которые нуждаются в большом анализе и обработке. Sdcc имеет большую часть этого процесса, но он еще далек от совершенства, поэтому вы будете иногда видеть, как он избивается в сравнении с «более простыми» компиляторами.

---

Поддерживаю на сто процентов.

Эта фраза подтолкнула меня продолжить любительские суждения о кодогенерации вокруг Z80.

Если пойти дальше и начать рассматривать такие продукты как НТС v7.80 pl2 и SDCC. Первое что я бы их "в лоб" не сравнивал. НТС v7.80 pl2 и SDCC преследовал / преследует разную конечную цель. Это главная мысль.

От этого и с заядлым постоянством вспыхивающий тут холивар. Чем тоже грешил. Потому что не правильно позиционировал компилятор для себя. Конечно проще написать ???? и сказать "фу какая хрень".

Вернемся к кодогенерации. Оба компилятора успешно подошли к планке 90% эффективности генерирования кода.

НТС v7.80 pl2 коммерческий продукт с конечным финансированием и в дальнейшем товар, от которого получали прибыль. Остановился в своем развитии. И достаточно стабильным и прогнозируемым генерируемым кодом на выходе. Сужу на основе разбираемого мною дизассемблера НТС 3.09 с отключенной оптимизацией (о оптимизации чуть позже). Это мой выбор.

SDCC исследовательский (научный) продукт с открытым кодом. Который преследует цель превысить 90% планку эффективности генерирования кода. И как показала не прекращаемая многолетняя работа над ним, постоянное шатание (отсюда не совместимость в версиях) и как тут было написано "прибегая к мегабайтам интеллекта" - пока с переменным успехом. А так современный компилятор вполне работоспособен при правильном подходе к нему. Что бы я отметил. Не подходит для новичков и у профессионалов с ним периодический происходят трудности в использовании.

По поводу эффективных и не эффективных библиотек и ловли блох у каждого из компиляторов. Ставить одну библиотеку над другой и определенные ходы в кодогенерации, думаю, не стоит. Все они преследуют определенные цели в узких рамках Z80.

Ага, оптимизатор. Новичкам я бы посоветовал его отключить. У меня на начальном освоении компилятора с ним возникли большие трудности, я долго не мог понять, что происходить и отчего так выборочно "плющит" генерируемый код. Оптимизатор может исказить сгенерированный код после кодогенератора до неузнаваемости.

Ну и не все с этими оптимизаторами так просто

Цитата:

---

Сообщение от Alcoholics Anonymous

Я бы сделал то же самое, если бы работал в Hitech :) Существует больше шансов, что ошибки появятся с включенной оптимизацией, поэтому безопасным делом было бы скомпилировать компилятор с выключенной оптимизацией, если это так и было сделано.

---

Я почти уверен, что НТС 3.09 ушел в релиз с выключенной оптимизацией. Надо только вспомнить, найти папку с проделанной работай и проверить. У кого "заряжены" инструменты может сделать это и сам.

Ух, выговорился:)

Я не совсем согласен, что SDCC не подходит для новичков. Чем больше сообщество - тем лучше продукт, как правило. Даже новички могут получить от его использования свою пользу при подходе первого рода. И даже новички могут улучшить компилятор, дав, например, баг-репорт при подходе второго рода.

- - - Добавлено - - -

Было бы интересно увидеть новичка, ковыряющегося с эмулятором CP/M или DosBox и Hi-Tech C. :-)

По сути же наверно один z88dk даёт хотя бы генерацию в tap. А для SDCC же надо освоить хотя бы hex2bin.

Впрочем, пускай новички прокачивают опыт, тоже хорошо. Правда, мы об абстрактных новичках, я что-то их деятельности не наблюдаю.

Цитата:

---

Сообщение от 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.

[свернуть]

Alcoholics Anonymous, Ваши сообщения на форуме всегда очень подробны и интересны. Благодарю!

Alcoholics Anonymous, cпасибо. Очень полезные посты для понимания нюансов построения компиляторов для Z80.

- - - Добавлено - - -

z88dk уникальный проект, который рассчитан именно на Z80 платформу.

где бы раскопать процедурку printf? Получается .AS без печати.

Сижу, такой, дома, из-за этой псевдопандемии. перечитываю старые темы. наткнулся на эту. Хотелось бы прокомментировать пару моментов:

Цитата:

---

Сообщение от Alcoholics Anonymous

В evo.h я прокомментировал некоторые прототипы:

---

комментировать прототипы в SDK, в котором не используются стандартные библиотеки и заголовочные файлы, очень спорное действие. Все прототипы вами отключенные были полностью переписаны автором этого sdk. Например, memset(), в отличии от оригинального из библиотеки sdcc и других компиляторов делает вызов _FAST_LDIR, который в свою очередь:

Код:

---

;более быстрая версия ldir, эффективна при bc>12
;из статьи на MSX Assembly Page
;в отличие от нормального ldir портит A и флаги

_fast_ldir
        xor a
        sub c
        and 63
        add a,a
        ld (.jump),a
.jump=$+1
        jr nz,.loop
.loop
        dup 64
        ldi
        edup
        jp pe,.loop
        ret

---

Т.е. вы пишите, что "эти вызовы функций реализованы с помощью ldir, встроенного в код. Определение ваших собственных функций для замены этого ухудшит ситуацию." не вникнув в суть кода, а суть в том, что обычный ldir это 21 такт на байт, а реализация memset в sdk при BC>12 даёт около 19 тактов и менее (если не ошибаюсь, вплоть до 17 или 18 тактов на байт). таким образом memset из sdk наоборот - повышает производительность. весь sdk написан без использования (стоковых библиотек, за исключением некоторых функций, который обязательны при кодогенерации.

Цитата:

---

Обратите внимание, что это массив символов UNSIGNED.

---

во1х, это массив без объявления размера. во2х, 8ми битный (не 16). число отрицательное, 8ми битное, в HEX это будет 0xf0. в одном из своих постов я приводил в пример высказывание автора игры Robo: " нужно было явно задать размеры массивов mus_cnt и musnames.". Т.е. проблема - если массив без размера, то ошибка компиляции. При этом всё тот же Hi Tech съедает эти массивы и даже не давится и код работает. Размер массива можно подсчитать в момент компиляции исходя из его наполнения. Почему-то sdcc после версии 2.9.0 резко разучился это делать. кроме этого, сам же автор игры пишет: "бинарный код под этой версией SDCC получился слишком большой. Игра компилируется, но не работает.". Я тоже пробовал собирать на разных версиях sdcc, но какие-то проблемы постоянно всплывают. при последней попытке я даже не дождался конца компиляции и это на amd ryzen 5 1600x разогнанном. у меня тут эмулятор zxmak2 в visual studio собирается за 3 секунды, какая-то спектрум игра за пол часа не собралась.

далее тоже интересно (про кодогенерацию sdcc): https://www.msx.org/forum/msx-talk/d...ns-sdcc?page=5

Цитата:

---

look at vrampoke & vrampeek functions. SDCC generate some kind of lengtly code:
this segment
ld c, 1 (iy)
ld b, #0x00
ld a, c
and a, #0x3f
or a, #0x40
out (_port99), a
is simply extremely stupid.
ld c, then ld b, 00 then ld a, c (so first ld c could be ld a, .....

---

там есть и другие весьма детские болячки, которые просто годами не правятся.

хотя конечно, иногда пользуюсь этим компилятором (sdcc), но без фанатизма.

Столкнулся с проблемой. Линкер иногда (?) не находит в библиотеке метки, которые используются из других модулей.
Например, имеется модуль, в котором определена метка "udiv":

Код:

---

psect text
global udiv
udiv:
...

---

В другом модуле имеется обращение к этой метке:

Код:

---

psect text
global _foo
_foo:
...
call udiv
...

---

Если мы используем в си-исходнике функцию "foo":

Код:

---

foo();

---

то линкер запихнёт в выходной файл функцию "foo", но "udiv" не найдёт и вместо её адреса подставит в call нули.
Хотя модуль такой есть в библиотеке, и метка "udiv" как глобальная определена.

Кто-нибудь знает, как это побороть? А то, в общем-то, это ставит крест на компиляторе. Хотя на MSX его во всю юзают, и таких проблем, похоже, не испытывают.

Для работы использую cpm.exe из командной строки под Win10-64.

Код:

---

cpm.exe link.com -I -Z ...

---

Цитата:

---

Сообщение от Alcoholics Anonymous

компиляторы начинаются с препятствия - они уже решили, что локальные переменные будут в стеке, и они будут проиндексированы с индексным регистром.

---

Вот это, кстати, интересный момент.

Немногие задумывались, почему большинство компиляторов (в том числе для x86 или ARM) размещают локальные переменные в стеке.

А дело здесь в рекурсии. В языке C разрешена рекурсия - и поэтому компилятор исходит из того, что любая функция может быть рекурсивной. А для рекурсивных функций иного выхода и нет, кроме как организовать стек для хранения локальных переменных.

Иногда компилятор может доказать, что та или иная функция не вызывает сама себя - ни прямо, ни через другие функции. Для таких функций он может отказаться от использования стека, а для прочих - нет. Вызов функции по указателю - это один из случаев, когда компилятор всегда должен подразумевать возможную рекурсию, ведь он не знает, что будет вызвано. Будет ли код, вызывающий функцию по указателю, вызван впоследствии рекурсивно.

В этом смысле более эффективен Фортран, где рекурсия запрещена, и компиляторы имеют полную свободу оптимизации.

Рекурсия иногда нужна, поэтому лучшим решением я бы считал введение атрибутов для функций, которые программист не собирается вызывать рекурсивно. Аналогично тому, как в GCC можно задать функциям атрибут, что они никогда не возвращаются.

Цитата:

---

Сообщение от Barmaley_m

А дело здесь в рекурсии.

---

в повторной входимости (что касается не только рекурсии)