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

Цитата:

---

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

Почему вы исключаете такую возможность в принципе?

---

Интуитивно отвергаю, потому что я имею опыт работы с компиляторами, написанными на ЯВУ. И опыт работы с ЯВУ на Z80. Но хорошо, я, быть может, не совсем прав, потому что вопрос этот не для гадания, надо взять и узнать это точно.

Я верю Alcoholics Anonymous, когда он пишет про то, что в Hi-Tech C есть баги. Проверять, опять же, не проверял. У меня есть ещё желание собрать игру Dash с помощью Hi-Tech C v3.09. Почему именно Dash, а не другие игры? Потому что переносить библиотеки ZXDev с SDCC на Hi-Tech C это трудоёмкая и кропотливая работа. Это к вопросу о переводе проекта с одного компилятора на другой. Всегда трудоёмко. А Dash не использует библиотеки ZXDev.

Цитата:

---

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

Толсто.

---

Зато правда.

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

Второй род отношений - это общее понимание как это должно быть устроено, что хорошо, что плохо, где можно упростить, а что является излишеством. Размышление идёт в контексте собственных исследований, которые помогают выстроить понимание средства и его недостатков. Человек исследует средство с чистого листа, не по аналогии, как проектировщик-железячник, старается смотреть на него с позиций гармонии. Тогда недостаткам ищутся объяснения, человек вкладывается в полюбившееся средство, тратит своё время на то, чтобы сделать его лучше. И такое отношение встречается гораздо реже.

Так вот, тут выступают за первый способ. Тогда Hi-Tech C можно рассматривать, если не смущают его баги, просто для ускорения работы, нежелания изучать другие, открытые компиляторы и вкладываться в их разработку. Но если смотреть на перспективу (я верю в будущее z88dk и SDCC, их разрабатывают КАЖДЫЙ ДЕНЬ), то Hi-Tech C не подходит, ведь он совсем не развивается. Так что из нас каждый по-своему прав, кто-то в нежелании переводить проект под другой компилятор, а кто-то из-за нежелания столкнуться с багами в закрытом компиляторе. Ну а мне ещё и фич SDCC в хайтехе не хватает...

Ну, вот нормальный ответ, без предвзятого отношения.

Цитата:

---

Сообщение от Oleg N. Cher

Так вот, тут выступают за первый способ.

---

И это не мудрено. Все держится на любителях. Коих большинство. И это отрицать глупо. Разбираться в чужом коде почему оно не работает, желания мало. Лучше это время потратить на свое творчество.

Цитата:

---

Сообщение от Oleg N. Cher

И опыт работы с ЯВУ на Z80. Но хорошо, я, быть может, не совсем прав, потому что вопрос этот не для гадания, надо взять и узнать это точно.

---

Фига тут узнавать. Вот листинг CGEN с IDA. С остальными программами из пакета HTC аналогичная ситуация.
В этом листинге при быстром рассмотрении мало чего понятно, хотя и при детальном тоже. Можно увидеть четко стандартный старт HTC для СР/М программы, функцию main, стандартные библиотеки HTC, характерные подпрограммы для HTC csv и cret захода и выхода из функции.

Мне вот интересно на чем шла разработка HTC на машине с Z80 или на какой-то более продвинутой машине.

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

Отреверсил функцию main на 80% с попаданием 98% в оригинальный код. А дальше для меня начался темный лес. И это не мудрено я до сих порт значок "*" путаю:)

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

Вся это работа была проделана просто из спортивного интереса. Если бы за это взялся профессионал, то возможно мы бы получили еще один компилятор Си. Таки у HTC есть потенциал, если его умудрились запихнуть в скромные рамки платформы на Z80.

Цитата:

---

А мужики то не знают.

---

и действительно, мужики-то и не знают:
http://zx-pk.ru/threads/18587-xonix-...l=1#post483953
http://zx-pk.ru/threads/20220-projec...l=1#post790095
и твой же пост: http://zx-pk.ru/threads/6844-ishchu-...l=1#post702277
сейчас сам проверил на последней версии sdcc. xnx собрался, с матами и перематами, долго. Запускается, вроде даже надписи все на своих местах...
И вообще, как то люто ненавидит этот новый sdcc массивы без явного указания размера. Бред. Постоянные какие то "переполнения" у него. Да. Это прекрасный компилятор, очень и очень.:v2_wacko:
...
чё-то анреал какой-то. воткнул ключ --max-allocs-per-node200000 и пипец, он завис чтоли, этот sdcc? уже минут 10 чёто мухрюет там... ощущение. что я сижу на древней 286, а не на 8ми ядернике. это типо прикольно, таким компилятором пользоваться))))

Угу. В SDCC и ещё куча других недостатков, и о них можно писать целые толмуты. Однако же перед тем, как юзать 200000, поюзай меньшее число. Надо же знать логику этого, чтобы пользоваться грамотно. А массивы без указания размера моветон. Кстати, а хайтек как, хавает?

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

Я чего-то думаю, что SDCC сделает код получше хайтековского без всяких там --max-allocs-per-node

Филипп честно предупредил меня, что SDCC оптимизирован для использования на Win7 и выше. В XP, которой я до сих пор пользуюсь (старенький ноут на одноядерном проце + один из первых двухъядерных атлонов) компиляция в разы медленее. Тем не менее, жить можно.

Не буду развивать тему, что кто хочет найти недостатки - тот найдёт их всегда. Восприятие у чела такое, везде какашки видит, кроме своего любимого туалета.

Цитата:

---

Сообщение от Oleg N. Cher

OrionExt, компилятор Hitech C не может быть написан на Си. Я скорее поверю, что он написан на PL/M.
Доказательства в студию. Хотя бы упоминание об этом хотя бы где-то. Дизассемблер, наконец. Честно, упаривает, когда распространяют ничем не обоснованные слухи.

---

Мне нравятся такие категоричные утверждения
а загрузить и посмотреть вера не позволяет?

https://www.dropbox.com/s/ywa2fv8tag...t%20C.idb?dl=0
на, смотри адрес запуска #6270
люди так не пишут - а вот компилятор С вполне.

Цитата:

---

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

и действительно, мужики-то и не знают:
http://zx-pk.ru/threads/18587-xonix-...l=1#post483953
http://zx-pk.ru/threads/20220-projec...l=1#post790095
и твой же пост: http://zx-pk.ru/threads/6844-ishchu-...l=1#post702277
сейчас сам проверил на последней версии sdcc. xnx собрался, с матами и перематами, долго. Запускается, вроде даже надписи все на своих местах...
И вообще, как то люто ненавидит этот новый sdcc массивы без явного указания размера. Бред.

---

Я нашел xnx-evo в последнем выпуске evo sdk.

У меня тоже не было проблем с компиляцией.
https://drive.google.com/file/d/0B6X...ew?usp=sharing

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

Скрытый текст

I found xnx-evo in the latest evo sdk.

I didn't have any problems compiling it either.
https://drive.google.com/file/d/0B6X...ew?usp=sharing

In evo.h I commented out some prototypes:

[свернуть]

Код:

---

//заполнение памяти заданным значением

//void memset(void* m,u8 b,u16 len) _naked;

//копирование памяти, области не должны пересекаться

//void memcpy(void* d,void* s,u16 len) _naked;

//генерация 16-битного псевдослучайного числа

//u16 rand16(void) _naked;

//установка цвета бордюра, 0..15

---

Это имеет смысл в версии 2.9, но приведет к ухудшению кода в новых версиях sdcc. Причина: sdcc теперь попытается встроить несколько строковых функций, включая memset () и memcpy (). Если вы посмотрите на сгенерированный ASM с новой компиляцией, вы увидите, что эти вызовы функций реализованы с помощью ldir, встроенного в код. Определение ваших собственных функций для замены этого ухудшит ситуацию.

Я сделал то же самое для rand (). Я подозреваю, что это лучше реализовано в библиотеке компилятора, но я не проверял, чтобы реализация evo-sdk точно знала. Sdcc теперь использует генератор xars Marsaglia, который работает очень быстро, даже несмотря на то, что он реализован в C. В основном я это сделал, потому что z88dk реализует эту функцию в ASM.

В main.c я изменил некоторые заголовки:

Скрытый текст

This made sense in 2.9 but will result in worse code in newer versions of sdcc. The reason is sdcc will now try to inline several string functions including memset() and memcpy(). If you look at the generated ASM with a new compile you'll see these function calls implemented with ldir inlined in the code. Defining your own functions to replace this will make things worse.

I did the same for rand(). I suspect this is better implemented in the compiler's library but I did not check evo-sdk's implementation to know for sure. sdcc now uses a Marsaglia xor generator which is very fast even though it's implemented in C. Mainly I did it because z88dk implements this function in ASM..

In main.c I changed some of the header includes:

[свернуть]

Код:

---

//#include <evo.h>
#include <string.h>
#include "evo.h"

---

Угловые скобки предназначены для заголовков, найденных в системном каталоге. Это не то, где evo.h находится в моих компиляциях, поэтому я изменил это на кавычки. Я также добавил string.h для получения библиотек memset () и memcpy ().

Я не могу скомпилировать бинарный файл, потому что мне придется исправлять остальную часть SDK, чтобы она была совместима с более новой версией sdcc. Но я могу перевести на asm и посмотреть, появляются ли какие-либо ошибки.

Скрытый текст

Angle brackets are for headers found in the system directory. That's not where evo.h is in my compiles so I changed that to quotes. I also added string.h to get the library memset() and memcpy() .

I can't compile to a binary because I'd have to fix up the rest of the SDK to be compatible with a newer version of sdcc. But I can translate to asm and see if any errors pop up.

[свернуть]

sdcc -mz80 -S main.c -D_naked= (~1-2 minutes)
sdcc -mz80 -S --max-allocs-per-node200000 main.c -D_naked= (~14 minutes)

Вы можете выбрать, хотите ли вы быстро компилировать или оптимизировать. В этой программе не так уж много различий, потому что большинство переменных являются статическими. «-Dnaked =» заключается в том, чтобы устранить атрибуты «_naked» во всех функциях C в main.c. Вещи больше не делаются так в new sdcc.

Вы можете увидеть выходные файлы .asm в .zip выше. Беглый осмотр я не обнаружил.

Скрытый текст

You can choose if you want a fast compile or a highly optimized one. In this program there isn't too much difference because most variables are statics. The "-Dnaked=" is to eliminate the "_naked" attributes on all the C functions in main.c. Things are no longer done this way in new sdcc.

You can see the output .asm files in the .zip above. I did not spot any problems with a cursory examination.

[свернуть]

Цитата:

---

Постоянные какие то "переполнения" у него. Да. Это прекрасный компилятор, очень и очень.:v2_wacko:

---

Это потому, что программист допустил ошибку или просто проигнорировал это. Компилятор правильный. Все эти жалобы касаются кода, подобного этому:

Скрытый текст

This is because the programmer has made a mistake or he's simply ignoring this. The compiler is correct. All those complaints are about code similar to this:

[свернуть]

Код:

---

const u8 levelData1[]={
IMG_PIC1,PAL_PIC1,MUS_LOOP1,85,
 9,10,-16,16,
28,10, 16,16,
255
};

---

Обратите внимание, что это массив символов UNSIGNED. Но программист ставит отрицательные числа там. Эти отрицательные числа представляют собой 16-разрядные целые числа. Например, -16 представляется как 0xffea. Затем компилятор пытается поместить 0xffea в 8-разрядный беззнаковый символ. Он делает все возможное, используя только младший байт и выдавая предупреждение, чтобы сообщить вам, что оно это сделало.

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

Немного позже в компиляции вы увидите еще одно предупреждение о потере указателя CONST. Это связано с тем, что программист неявно преобразовал указатель CONST в обычный указатель. Опять же, это предупреждение правильное, и оно испускается, потому что это еще один распространенный тип ошибки. Но в этом случае нет ошибки.

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


Я сделал ту же компиляцию с zsdcc, но на этот раз zsdcc будет использовать «-reserve-regs-iy», что подразумевается «-clib = sdcc_iy». В результирующем коде есть два места, где z88dk исправляет ошибки в sdcc. В z88dk предпочтительнее использовать «-reserve-regs-iy», потому что это приводит к значительно меньшему коду в целом, когда применяется агрессивный набор гласных z88dk.

Скрытый текст

Notice that this is an UNSIGNED char array. Yet the programmer is putting negative numbers in there. These negative numbers are 16-bit integers. For example, -16 is represented as 0xffea . The compiler then tries to fit 0xffea into an 8-bit unsigned char. It does its best by using only the least significant byte and emitting an warning to let you know it has done so.

So all those warnings are the fault of the programmer. sdcc is right to warn about it -- these types of errors can often turn out to be bugs. In this case these aren't bugs.

A little later in the compile you will see another warning about a pointer losing CONST. This is because the programmer has implicitly casted from a CONST pointer to a regular pointer. Again, this warning is correct and it is emitted because this is another common type of bug. But in this case there is no bug.

Beginners may find the warnings disconcerting or annoying but for the experienced they can be invaluable for tracking down difficult to find bugs. The fact that other compilers may not report these things as warnings is a weakness of those other compilers.


I did the same compile with zsdcc but this time zsdcc will use "--reserve-regs-iy" which is implied by "-clib=sdcc_iy". In the resulting code there are two places where z88dk fixes up bugs in sdcc. In z88dk it's preferable to use "--reserve-regs-iy" because it leads to much smaller code in general when z88dk's aggressive peephole set is applied.

[свернуть]

zcc +z80 -vn -a -SO3 -clib=sdcc_iy main.c -D_naked= --c-code-in-asm (~1-2 minutes)
zcc +z80 -vn -a -SO3 -clib=sdcc_iy --max-allocs-per-node200000 main.c -D_naked= --c-code-in-asm (~16 minutes)

(Целевой компьютер «+ z80» не имеет большого значения для перевода в .asm. Это повлияет только на то, какие заголовки доступны из библиотеки).
(The target machine "+z80" does not matter much for a translation to .asm. It will only affect what headers are available from the library).

Цитата:

---

...
чё-то анреал какой-то. воткнул ключ --max-allocs-per-node200000 и пипец, он завис чтоли, этот sdcc? уже минут 10 чёто мухрюет там... ощущение. что я сижу на древней 286, а не на 8ми ядернике. это типо прикольно, таким компилятором пользоваться))))

---

Да, это медленно. Команда sdcc не рассматривала лучшие структуры данных в своей первой попытке с этим новым генератором кода. Имейте в виду, что то, что делает sdcc за кулисами, гораздо сложнее, чем, скажем, HTC.

Просто уменьшите число «max-allocs-per-node» или вообще исключите этот параметр (по умолчанию используется «max-allocs-per-node3000»). В этой программе это не имеет большого значения.

Я использую 200000 для релизов и когда я ищу способы улучшить вывод кода. Для меня вполне приемлема длинная сборка для выпуска. Для развития вы можете пойти ниже. Я не думаю, вместо этого я правильно разбиваю проект на множество исходных файлов и использую make-файл, так что только файлы, которые я изменяю, перекомпилируются. Таким образом, количество кода, который компилятор должен пережевывать, меньше и вывод генерируется быстрее.

Кстати, Philip at sdcc использует 1000000, когда он запускает тесты. Я не могу использовать этот номер на этом ноутбуке, так как для больших программ он будет исчерпан. Я также считаю, что разница не слишком велика между 200000 и 1000000. Из-за этого мы принимаем 200000 в качестве магического числа и фокусируем усилия на улучшении вывода кода для этого уровня. Я думаю, что Fuzix принял наш номер 200000 тоже, но в прежние времена это было 500000, я верю.

Скрытый текст

Yes it is slow. The sdcc team did not consider better data structures in their first attempt with this new code generator. Keep in mind that what sdcc is doing behind the scenes is much more sophisticated than what, say, HTC is doing.

Just reduce the "max-allocs-per-node" number or eliminate the option altogether ("max-allocs-per-node3000" is the default). In this program it doesn't make a huge difference.

I use 200000 for release builds and when I am looking for ways to improve the code output. A long build for a release is perfectly acceptable to me. For development you may want to go lower. I don't though, instead I properly partition a project into many source files and use a makefile so that only files I change are recompiled. This way the amount of code the compiler has to chew on is smaller and output is generated more quickly.

By the way Philip at sdcc uses 1000000 when he runs benchmarks. I can't use that number on this laptop as it will run out of memory for large programs. I also find the difference is not too much between 200000 and 1000000. Because of this we adopt 200000 as the magic number and focus efforts to improve code output for this level. I think Fuzix has adopted our 200000 number too but in earlier days it was 500000 I believe.

[свернуть]

Компилятор Hi-Tech C v3.09 достаточно "простой" (пусть будет в кавычках). В этом я думаю его сила. Он не ищет в коде Си того, чего там нет. С другой стороны эта "простата" иногда вылазит боком в неэффективный код. Но, зная особенности компилятора и Z80, эти несуразицы можно свисти к минимуму. Чем, похоже, и пользовались авторы этого компилятора.

После недели втыкания в дизассемблер HTC 3.09 я уже мог на лету в голове получать си код. Вот загрузка n-го количества параметров в функцию, вот if then переход, а вот оператор case.

Если мне не изменяет память, HTC 3.09 создавался с выключенной оптимизацией. При включённой оптимизации мне не удавалась после рекомпиляции получить 98% оригинального кода.

Хотя не все там так просто. Похоже, использовались безусловные переходы, что не приветствуется. Натыкался на код, который я не смог раскусить (ассемблерная вставка?)

Все выше сказанное не принимайте за истину. Мне просто было интересно проделать кусочек этой работы и приоткрыть завесу тайны самого эффективного компилятора Си на платформе СР/М Z80:)

Цитата:

---

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

Компилятор Hi-Tech C v3.09 достаточно "простой" (пусть будет в кавычках). В этом я думаю его сила. Он не ищет в коде Си того, чего там нет. С другой стороны эта "простата" иногда вылазит боком в неэффективный код. Но, зная особенности компилятора и Z80, эти несуразицы можно свисти к минимуму. Чем, похоже, и пользовались авторы этого компилятора.

---

Результаты, которые получает HTC, очень впечатляют и вдвойне, если учесть, что он работает на 64-килобайтной машине. Как уже упоминалось в предыдущем посте, было бы целесообразным проект разобрать и понять этот компилятор с целью сделать его способным ориентироваться на машины z80 в целом. Отделите его от CP / M и подключите его к более общим и современным библиотекам, и там есть большой потенциал. Я думаю, любой, у кого есть реальная машина z80, с удовольствием сможет запустить такой компилятор на самой машине.

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

Скрытый текст

The results that HTC gets is very impressive and doubly so when considering it runs on a 64k machine. As was mentioned in a previous post, it would be a worthwhile project to disassemble and understand this compiler with the aim of making it able to target z80 machines generally. Detach it from CP/M and connect it to more general and modern libraries and there is a great a deal of potential there. I think anyone with a real z80 machine would love to be able to run such a compiler on the machine itself.

In reality, you can probably get 80% of the way to an ideal compile without resorting to megabytes of intelligence. It's the last 20% that needs a lot of analysis and processing. sdcc has the most of this going on but it is far from perfect yet so you'll occasionally see it getting beat in comparisons with "simpler" compilers.

[свернуть]

Цитата:

---

Если мне не изменяет память, HTC 3.09 создавался с выключенной оптимизацией. При включённой оптимизации мне не удавалась после рекомпиляции получить 98% оригинального кода.

---

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

Скрытый текст

I would have done the same if I worked at Hitech :) There is a greater chance for bugs to appear with the optimization enabled so the safe thing to do would be to compile the compiler with optimization off, if that's how they did it.

[свернуть]

Да, примерно так же я декомпилировал игру, скомпилированную из Бейсика. Начинаешь улавливать, чего да как, появляется чутьё, где какая Бейсик-команда была. :-)

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

да ковырять тут надо не столько сам компилятор, сколько его оптимизатор, файл optim.com. Вот его бы подправить и было бы хорошо, ещё лучше, наваять его под венду.