Кодогенерация SDCC: пожелания об улучшении компилятора

[Barmaley_m]

Потому что это не константная переменная с гарантированным для первого обращения значением. А значит лежит в секции, доступной на чтение-запись. А исходные данные лежат в секции "только на чтение". Хочешь сразу ссылаться на нужную секцию- подскажи компилятору (я вот только не помню, в С можно const писать или только в новом стандарте).

Совершенно верно. Можно писать const. Если заменить объявление переменной на:

static const char s[] = "Hello world!";

то компилятор не сгенерирует код, инициализирующий этот массив (строка будет просто храниться в исполняемом образе). Забивание строки в массив, в который разрешена запись - это поначалу была такая ошибка в моей тест-программе, но в связи с тем, что результат компиляции оказался интересным (с той точки зрения, чтобы его улучшить), я решил обратить внимание именно на этот случай.

На самом деле можно в исполняемом файле иметь сегмент инициализированных данных, доступных на чтение/запись. Тогда даже LDIR не понадобится, но возникнут проблемы, если кто-то захочет скомпоновать файл для размещения в ПЗУ. Тогда придется генерировать как минимум инициализирующие LDIRы, которые бы скопировали исходные значения этих данных из ПЗУ в ОЗУ. Размещение программы в ПЗУ - это далеко не праздная задача. Люди делают прошивки, люди делают на базе Z80 отдельные устройства (как я в 1997); в конце концов, некоторые контроллеры памяти позволяют защитить области ОЗУ от записи. Поэтому генерация кода, работоспособного в ПЗУ - это важное свойство компилятора.

[Oleg N. Cher]

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

На Дураке выигрыш по размеру кода с версией SDCC 3.2.0 #8008 больше 600 байт! Сами понимаете, что это значит для Z80. Проблема же в том, что он перестал работать... Думаю, приоритетнее будет выловить баги, чем обфичивать. Повторюсь, я не встречал ни одной 100%-корректной по кодогенерации версии SDCC. Это проблема прямо.

Ещё у меня вопросик к гуру. Я конечно напишу его Филиппу, но позже. Может кто-то раньше ответит. Версия SDCC 3.2.0 в асмовых функциях не генерирует фрейма входа:

          PUSH    IX
          LD      IX,#0
          ADD     IX,SP

И, как я понимаю, это сделано для того, чтобы дать программеру больше свободы в принятии решения, каким способом лучше доставать параметры из стека. Что ж, дело хорошее. Но хотелось бы сохранить работоспособность кода и для старых версий SDCC. Поэтому на ум приходит что-то такое:

void myfunc (int p1, int p2, ...)
{
#if SDCC_VER > 3.1.x
  __asm
          PUSH    IX
          LD      IX,#0
          ADD     IX,SP
  __endasm;
#endif
  ...
}

Можете ли подсказать что должно быть вместо #if SDCC_VER > 3.1.x ?
Т.е. вопрос сводится к тому, с какой версии это дело началось, видимо.

[Valen]

Думаю, приоритетнее будет выловить баги, чем обфичивать.

Это сто процентов.

Повторюсь, я не встречал ни одной 100%-корректной по кодогенерации версии SDCC. Это проблема прямо.

Да, это проблема.
Вероятно добавление тестов может что-то решить.
Самая засада, это когда sdcc генерит корявый код "потихому". (без ошибок и предупр.)

Ещё у меня вопросик к гуру. Я конечно напишу его Филиппу, но позже. Может кто-то раньше ответит. Версия SDCC 3.2.0 в асмовых функциях не генерирует фрейма входа:

(Гуру себя не считаю, в сорцах sdcc не копался.)
Эта проблема решена в трекере.

[Oleg N. Cher]

Понимаете, Valen, они ведь не тестируют каждую новую версию (или, так скажем, релиз) на какой-то сложной программе (типа как я на Дураке), которую достаточно будет исполнить, и сразу выяснятся возможные косяки. С симулятором, прокручивая все биты в голове, не так уж и натестишься. Поэтому активная бригада бета-тестеров — это то, что нужно проекту SDCC. Тут было сказано за безбажность фирменного компилятора HiTech C 3.09 образца 1986 года. Прекрасно! Я рад, что он так хорош. Но для нас с вами это тупиковый путь. Потому что всё закрыто, платно и не совершенствуется. Нам остаётся только SDCC.

Значит появился ключик для отключения оптимизации фреймов входа? Полезно. А я уже вышел из положения таким манером:

#if (__SDCC_REVISION > 8000)
          PUSH    IX
          LD      IX,#0
          ADD     IX,SP
#endif

хотя можно было бы и #ifdef __SDCC (c версии 3.2.0 все зарезервированные макросы начинаются с __). Но это примерное решение конечно (просто сложно вычислить билд, с которого началась эта фича).

Хочу обратить ваше внимание на одну интересную вещь. Прочёл в доке.

The most efficient way to use libraries is to keep separate modules in separate source files.The lib file now should name all the modules .rel files. For an example see the standard library file libsdcc.lib in the directory <installdir>/share/lib/small.

Более того, "using sdcclib to Create and Manage Libraries is deprecated - must use sdar to Create and Manage Libraries". Что это? Путь к смартлинковке? Маленько извратный, но наверное это он! Т.е. надо распотрошить все функции по отдельным исходникам, и тогда они будут прилинковываться независимо друг от друга, как это сделано, например, в стандартной библиотеке z80.lib

[Barmaley_m]

Модульная компоновка была реализована еще в компоновщике L80 под CP/M. Библиотеки таких языков, как Фортран, содержат много модулей как раз для того, чтобы исключить из исполняемого файла те модули, точки входа которых не используются. Поэтому, чем меньше размер модулей - тем больше их можно исключить при компоновке, тем меньше размер исполняемого файла.

[Valen]

Т.е. надо распотрошить все функции по отдельным исходникам

Да, в идеале так и нужно (это обычная практика).
При создании своей либы,
одна ф-ция на один модуль.
Потом все модули положить в либу.

И уже при юзании либы, к коду юзера будут линковаться только те ф-ции, которые он вызывает в своём коде.

---------- Post added at 14:42 ---------- Previous post was at 14:40 ----------

using sdcclib to Create and Manage Libraries is deprecated - must use sdar to Create and Manage Libraries

Чем лучше sdar, тогоже sdcclib, ещё не разбирался.

[alone]

Очень медленно компилирует большие исходники.

[Oleg N. Cher]

Да, в идеале так и нужно (это обычная практика).
При создании своей либы,
одна ф-ция на один модуль.
Потом все модули положить в либу.

И уже при юзании либы, к коду юзера будут линковаться только те ф-ции, которые он вызывает в своём коде.

Всё же остаётся пара проблем.

Во-первых, ручное распотрошение логически целостного модуля на части (лишь потому, что так удобнее библиотекарю) — это дополнительная работа. Во-вторых, я уже столкнулся с ситуацией, когда нормально распотрошить не удаётся. Пример: в библиотеке есть ассемблерная функция, вовнутрь которой есть переходы по JP из других функций.

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

Вопрос. Удастся ли автоматически сконвертировать готовый .lib, созданный из одного исходника, таким образом, чтобы он был аналогичен созданному из кусочков исходников, распотрошенных по функциям? (полумера конечно, но надо же с чего-то начать...)

[Oleg N. Cher]

По поводу скорости компиляции SDCC. Исходники Дурака у меня собираются SDCC 3.2.0 #8008 (с ключиком --oldralloc) за 15 секунд (бинарник весит 32674 байта), а вот без него! 6 с половиной минут (32895 байт). Сам офигел, старый компилер быстрее компилил. Удивительно, но от нового аллокатора раньше пользы было больше. Не буду утверждать наверняка, но, похоже, принцип работы аллокатора основан на пошаговом выяснении, какие регистры более экономно выделять, простым путём перебора с повторной множественной компиляцией. Идея очень интересная, но хорошо, что он опциональный.

Если смущает и 15 секунд (ну просто хочется быстрее), вспомним, что SDCC гибридный компилятор, который программу сначала препроцессит, потом парсит, строит деревья, генерит кучу служебной инфы. Наконец целевой код, не код, а асм! Потом пипхольная оптимизация. Вобщем, многоэтапный. Если его ускорять, надо менять всю структуру компилятора, избавляться от лишних звеньев. Даже если от Филиппа это и зависит, полагаю, всё равно не планируется. Выскажу крамольную мысль. На каком-то этапе мы можем получить безбажную версию SDCC. Это может произойти когда Филипп забьёт на SDCC окончательно. Вот тогда желающие и вылижут баги. Но и развиваться перестанет.

Наконец, Си язык медленно компилируемый. Особенно это было заметно в эпоху старых машин. Но и сейчас со мной согласятся те, кто устанавливал большой софт из исходников или пересобирал ядро Linux. Дело и в препроцессировании, и в многочисленной обработке текстовых заголовков *.h, и в множественных промежуточных представлениях кода с поэтапной оптимизацией.

Но не расстраивайтесь. Разве бывалого спектрумиста напугаешь 15 секундами? Или можете себе представить более объёмные исходники для Z80? (основнй модуль Дурака весит 2,3 тыс. строк) Наконец, Вы уверяли, что в Си есть модульность. Вот и воспользуйтесь ею. Маленькие модули, раздельная компиляция.

я не встречал ни одной 100%-корректной по кодогенерации версии SDCC.

Песенка со смыслом.

Sung to Beatles "Let it Be"

When I find my code in tons of trouble, Friends and colleagues come to me, Speaking words of wisdom: Write in C.
As the deadline fast approaches, And bugs are all that I can see, Somewhere, someone whispers: Write in C.

Write in C, write in C, Write in C, oh, write in C. LISP is dead and buried, Write in C.

I used to write a lot of FORTRAN, For science it worked flawlessly. Try using it for graphics! Write in C.

If you've just spent nearly 30 hours Debugging some assembly, Soon you will be glad to Write in C.

Write in C, write in C, Write in C, yeah, write in C. Only wimps use BASIC. Write in C.

Write in C, write in C Write in C, oh, write in C. Pascal won't quite cut it. Write in C.

{ Guitar Solo }

Write in C, write in C, Write in C, yeah, write in C. Don't even mention COBOL. Write in C.

And when the screen is fuzzy, And the editor is bugging me. I'm sick of ones and zeros, Write in C.

A thousand people swear that T.P. Seven is the one for me. I hate the word PROCEDURE, Write in C.

Write in C, write in C, Write in C, yeah, write in C. PL1 is 80s, Write in C.

Write in C, write in C, Write in C, yeah, write in C. The government loves ADA, Write in C.

[Vitamin]

Наконец, Си язык медленно компилируемый.

По сравнению с ассемблером, все языки медленно компилируемые.
А по сравнению с С++, С очень быстро компилируемый...