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

[Oleg N. Cher]

Начал набрасывать письмо Филиппу Клаусу Краузе (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=32) (главному мэйнтейнеру кодогенератора Z80 для SDCC).

Просьба высказаться желающим. Предложения по кодогенерации обязательно проверяйте на свежей версии SDCC, потому что в ней много чего изменилось по сравнению со старыми версиями. Идеи, высказанные здесь на форуме и на форуме ZXDev (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=32), я оформлю и вышлю Филиппу.

[ZEK]

В pephole логику добавить возможность работать по байтово с компонентами 32/16 битных циферок, можно хорошо подрезать код для библиотек от большого брата,
а то
long a = 0x12345678;
a &= (char)0xFF;
выливается в 4 операции and вместо одной, не считаю загрузку всех 4х компонент при участии индексного регистра из стека в память и запись обратно, по 5 (или что то около того) инструкций на 1 байт 32 битной циферки, мегатормоз и куча памяти

[Barmaley_m]

Скачал версию от 20 августа. К кодогенератору имеются следующие замечания:

1) Инициализация данных. Объявив глобальную статическую переменную следующей инструкцией:

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

Я получил процедуру инициализации этой переменной вида:
ld hl, _s
LD (HL), 'H'
ld hl, _s+1
LD (HL),'e'
Что чрезвычайно неэффективно как по скорости исполнения, так и по занимаемой памяти. Более оптимальное решение - это сохранить исходное значение константы в сегменте инициализированных (константных) данных, а потом копировать с помощью LDIR.

---------- Post added at 03:59 ---------- Previous post was at 03:48 ----------

2) Деление на 2 переменной. Инструкция вида
k/=2
где k - стековая 8-битная переменная, привела к генерации кода:
LD A,(IX+6)
SRL A
LD (IX+6),A
Что лучше заменить на
SRL (IX+6)

3) Возведение в квадрат числа. Инструкция вида:
t*=t
где t - unsigned short, привела к генерации кода:
PUSH HL
LD C,(IX+4)
LD B,(IX+5)
PUSH BC
LD C,(IX+4)
LD B,(IX+5)
PUSH BC
CALL __mulint_rrx_s
POP AF
POP AF
LD D,L
LD E,H
POP HL
LD (IX+4),D
LD (IX+5),E
В этом коде, во-первых, нет необходимости загружать BC второй раз, потому что в него загружается одна и та же информация. Обе команды LD между PUSH BC можно выкинуть.
Во-вторых, после возврата из подпрограммы умножения, результат сначала копируется в регистр DE, а потом сохраняется на фрейм. Вместо этого можно сначала сохранить результат прямо из HL, а потом выполнить POP HL. Экономится две команды LD.

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


unsigned short mstrlen(const char* s)
{
unsigned short a = 0;
while(*s++)
a++;
return a;
}

Сгенерированный код:

;test.c:21: unsigned short mstrlen(const char* s)
; ---------------------------------
; Function mstrlen
; ---------------------------------
._mstrlen_start
._mstrlen
;test.c:24: while(*s++)
ld de,$0000
pop bc
pop hl
push hl
push bc

.l_mstrlen00101
ld a,(hl)
inc hl
or a, a
jp Z,l_mstrlen00103
;test.c:25: a++;
inc de
jp l_mstrlen00101

.l_mstrlen00103
;test.c:26: return a;
ex de,hl

.l_mstrlen00104
ret
._mstrlen_end

Что не оставляет желать ничего лучшего. Ну разве что можно было бы продублировать заголовок цикла, как это делается в некоторых современных компиляторах, но нельзя требовать всего сразу :)

[NovaStorm]

На правах "мимопроходил"...


1) Инициализация данных...
А почему, если у нас static данные в памяти уже лежат, нельзя просто забить на их инициализацию, зачем ещё копировать? Стандарт?


;test.c:24: while(*s++)
ld de,$0000
pop bc
pop hl
push hl
push bc

Это загрузка параметров функции?
Если у нас не PIC-код(а на спеке оно наверное так и будет), почему бы вместо push'ей не делать ld sp,#xx?

---------- Post added at 10:42 ---------- Previous post was at 09:37 ----------



ld hl, #2+0
add hl, sp
...
ret
А вот в таких конструкциях надо проверять, не лучше ли делать INC/DEC.

[Дмитрий]

А вот в таких конструкциях надо проверять, не лучше ли делать INC/DEC.
Вообще-то таким образом берется верхушка стека в HL, чтоб не делать что-то типа такого:



...
LD (bla+1),sp
bla: LD HL,0
...

[NovaStorm]

Вообще-то таким образом берется верхушка стека в HL, чтоб не делать что-то типа такого:
Я думал(так как там дальше ret) тот код восстанавливает стек перед возвратом из функции.

[Vitamin]

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

[NovaStorm]

Vitamin, про секции я вроде понимаю, но если указать const, изменять нам ничего не дадут?
>А исходные данные лежат в секции "только на чтение".
А почему R/W? Переменные ведь делятся на инициализированные и нет?

[Vitamin]

но если указать const, изменять нам ничего не дадут?
Ну да.


А почему R/W? Переменные ведь делятся на инициализированные и нет?
"А почему светофор красный? Крокодил ведь зеленый!" :)

[NovaStorm]

Тьфу, _не_ R/W. Чем чтение/запись определяется? Или это уже специфично и компиляторо-линкеро зависимо?

[Vitamin]

Чем чтение/запись определяется?
Объявлением. Если ты написал const, значит 100% не будешь туда писать (компилятор не даст). Сумел обмануть компилятор- ССЗБ. А если не написал- значит туда будут писать.

[Titus]

Сумел обмануть компилятор- ССЗБ.
Ты уж расшифровывай, такие сокращения у нас не в обиходе.

ССЗБ - Сам Себе Злобный Буратино.

[NovaStorm]

>такие сокращения у нас не в обиходе.
Зато на ЛОРе вполне себе употребимы =)

>Если ты написал const
Тут понятно, компилер может с константными данными извращаться как хочет, а если const нет? Вот как изначальном вопросе о надобности инициализации, зачем копировать, если данные уже лежат? Пиши - не хочу.

[Titus]

>такие сокращения у нас не в обиходе.
Зато на ЛОРе вполне себе употребимы =)
Не все здесь посещают ухогорлоноса.

[Vitamin]

Вот как изначальном вопросе о надобности инициализации, зачем копировать, если данные уже лежат? Пиши - не хочу.
Вот написал ты такое:


static char text1[] = "very long text string ...";
static char text2[] = ... //то же самое

и действующий по твоим заветам компилятор создаст две копии данных строки- использование общих данных будет невозможно. А при копировании сработает обычный string pooling.

[NovaStorm]

>компилятор создаст две копии данных строки
Дык в твоём примере это и подразумевается!
>обычный string pooling
Хотяяя... Как я понял погуглив(а попадалась увы одна *****я жаба), при string pooling'е если мы объявим char s1[]="bla-bla-bla";char s2[]="bla-bla-bla"; то они будут указывать на один адрес? Но тогда при объявлении их static как раз разные адреса и должны получиться?

[Vitamin]

Дык в твоём примере это и подразумевается!
Я имею в виду исходные данные для инициализации.

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

[Valen]

Кому реально нужно, есть "Feature request" и "Bugs" на трекере (http://sourceforge.net/tracker/?group_id=599) проекта.

[Error404]

Вот написал ты такое:


static char text1[] = "very long text string ...";
static char text2[] = ... //то же самое

и действующий по твоим заветам компилятор создаст две копии данных строки- использование общих данных будет невозможно. А при копировании сработает обычный string pooling.

Да, две копии. А разве не так и должно быть? Какое его сообачье дело, что я пишу в строках - разное оно или одинаковое? Зачем считать пользователя кретином, пишушим в разных строках одно и то же исключительно от невнимательности? Если я для второй строки захочу общих данных с первой, я напишу что-то типа
static char *text2 = &text1[0];
и не надо будет никакой самодеятельности компилятора.

Большинство CP/M-компиляторов С, кстати, такой идиотской инициализации как в SDСС не имеют, и десятки лет на них прекрасно программируют. Кстати, последний SDCC не может собрать работоспособный код из исходников, прекрасно собирающихся при помощи hitech C 3.09 образца 1986 года. Я в итоге от SDCC отказался - устал подбирать его какашки.

[Vitamin]

Да, две копии. А разве не так и должно быть? Какое его сообачье дело, что я пишу в строках - разное оно или одинаковое? Зачем считать пользователя кретином, пишушим в разных строках одно и то же исключительно от невнимательности? Если я для второй строки захочу общих данных с первой, я напишу что-то типа
static char *text2 = &text1[0];
и не надо будет никакой самодеятельности компилятора.
А как ты прокомментируешь возможность работы из пзу? Указатель на строку должен будет прямо в него указывать или таки в озу после предварительного копирования из пзу?

[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 не копался.)
Эта проблема решена в трекере (http://sourceforge.net/tracker/?func=detail&aid=3545453&group_id=599&atid=100599).

[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]

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

[Oleg N. Cher]

Ну, я имел ввиду связку C/C++ в этом контексте.
В принципе, всё относительно (зависит от компилятора и проч.), но да — Оберон и Паскаль компилируются быстрее, чем C/C++. К тому же последние логически подошли к "препроцессорному стандарту" — рекомендуется обозначать заглавными буквами не самое важное в программе (костяк там или структуру), а имена макросов — т.е. то, что может вызвать проблемы.

---------- Post added at 13:02 ---------- Previous post was at 12:49 ----------

(Это так, к вопросу о побочных эффектах от препроцессора, помимо медлительнности)

[Valen]

Исходники Дурака у меня собираются SDCC 3.2.0 #8008 (с ключиком --oldralloc) за 15 секунд (бинарник весит 32674 байта), а вот без него! 6 с половиной минут (32895 байт).

Тоже попадался на эту проблему. Особенно это проявляется при компиляции чужих больших файлов.


Или можете себе представить более объёмные исходники для Z80? (основнй модуль Дурака весит 2,3 тыс. строк)
Я всё тестирую на "SDCC framework for V6Z80P".
Там (http://v6z80p.svn.sourceforge.net/viewvc/v6z80p/trunk/Contributions/Valen/c_programs/) либы + примеры программ, это где-то 7,5 тыс. строк.

---------- Post added at 14:20 ---------- Previous post was at 14:10 ----------


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

[Oleg N. Cher]

Ответ Филиппа Краузе на моё письмо:

http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=32&p=97#p97

[Oleg N. Cher]

Я дал Филиппу ссылку на эту ветку форума, он ответил мне мейлом на некоторые посты.

>>
>> http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=_t&hl=ru&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fzx.pk.ru%2Fshowthread.php%3Ft%3D199 00
>>

This one is hard to read for me. I don't know any Russian, so I tried
the google translate with target languages set to English and German,
but still not everything makes sense to me in the translation. So I'll
just reply to a few postss:

Barmaley_m's post:

1) Yes, initialization using ldir would be more efficient. sdcc did have
something like this for z80 a few years ago, but I had to remove it back
then, since it had serious bugs that would not have been easy to fix. I
just created RFE #3565759 to ensure that this is not forgotten.

2) Judging from what the asm looks like, an assembler format other than
the default is used. This disables the peephole optimizer. In
particular, the division example would be optimized in the sugegsted way
by peephole 21b. Still for the example given, code generation could do
the job instead.

3) This is hard to do in the code generator, it is easier in the
peephole optimizer. I don't know if there already is a peephole for
this, but again, the peephole optimizer will only fully work using the
default asm format.

Error404's post:
I may be misinterpreting the google translation here, but it looks to me
as if it is claimed that some old HITECH-C compiler is better than sdcc.
Looking at my benchmarks
(https://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size), I see
sdcc (with --opt-code-size and a high value for --max-allocs-per-node)
generate substancially better code than the latest HITECH-C, or any
other current compiler targeting the Z80.

Oleg N. Cher's post (the one starting with "Понимаете, Valen"):
We do have some automated testing. In particular, the latest sdcc code
is automatically built, and test programs are compiled and run in
emulators, verifying the results. For the z80 port, 1547 test programs
are compiled, containing 6945 individual tests. The results can be seen
at http://sdcc.sourceforge.net/snap.php: The green dot in column "RT"
means all tests passed. We try to add a test there when we fix a bug, so
bugs don't reappear, and a large part of the gcc test suite is included
in our tests. Still, there are bugs in sdcc, and we need all the help we
can get in finding them. I especially want to encourage everyone to try
a current snapshort (or sdcc from svn) once in a while and report any
issues.

Philipp

[alone]

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

[NovaStorm]

>Но больше никакой так не тормозит.
Когда gcc компиляет что-то с бустом, возникают определённые сомнения, кто тормознее =)

[Vitamin]

Когда gcc компиляет что-то с бустом, возникают определённые сомнения, кто тормознее =)
А ты хрен с пальцем не сравнивай)

[Oleg N. Cher]

Благодаря Филиппу Краузе решена проблема "умной" линковки при работе с библиотеками в SDCC. Заметьте, возможность эта была и раньше, и даже в sdcclib, просто мы о ней не знали. Я решил не ковырять формат .rel и обошёлся более малой кровью — разработал утилитку для облегчения разрезания сишных исходников на кусочки. Подробнее об этом на форуме поддержки ZXDev в теме "Умная" линковка (smart linking) в ZXDev/SDCC (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=34).

[SfS]

Пожелания по кодогенерации. Желаю, чтобы секция .DATA вела себя как .DATA

[vinxru]

Любой сишный компилятор многоэтапный.

А зачем?

[SfS]

А зачем?

Затем, что делать мега программы, которые умеют всё и сразу, но плохо - это хуже, чем делать программы, которые умеют делать что-то одно, но хорошо:)

[Oleg N. Cher]

Пожелания по кодогенерации. Желаю, чтобы секция .DATA вела себя как .DATAА чего с ней не так?

---------- Post added at 22:23 ---------- Previous post was at 22:16 ----------


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

А сравнивать скорость SDCC и других компиляторов для Z80 смысла нет — последние не дают такого качества кода.

[Eltaron]

А чего с ней не так?
ну какой-нибудь (даже глобальный)
char* hello = "Hello, world!"
порождает код в духе


ld hl, #_hello
ld (hl), 'H'
inc hl
ld (hl), 'e'
inc hl
ld (hl), 'l'
итд


Так обычно секция .bss себя ведет. А в .data сразу должны лежать проинициализированные данные.

---------- Post added at 02:15 ---------- Previous post was at 01:32 ----------

А еще я в последнее время часто натыкаюсь на вот такие извраты


; char variable = 0;
; ...
ld iy, #_variable
ld a, (iy + 0)

Почему нельзя сделать ld a, (#_variable) - непонятно. Значение, загруженное в iy нигде больше не используется, так что тут не в оптимизации какой-нибудь дело.
С HL же подобное вообще сплошь и рядом


ld hl, #_variable
ld (hl), a

любая запись нового значения в переменную порождает такой код, даже если переменная в следующий раз используется только через 50 строк. LD (NN), A не у дел совершенно.

[SfS]

А чего с ней не так?


А то с ней не так, что когда я пишу глобальную или статическую переменную - то она должна сразу инициализировться в секции _DATA

Вместо этого - генерится огромный код, который инитит эту переменную. Дикость и глупость.




char a=2;


В ассемблере генерит




.area _DATA
_a::
.ds 1

.area _GSINIT
;cls.c:4: char a=2;
ld iy,#_a
ld 0 (iy),#0x02


Чо - руки отвалятся написать сразу



.area _DATA
_a::
.db 2


Экономия - время инициализации и куча памяти. Руки бы пооборвал...

---------- Post added at 06:41 ---------- Previous post was at 06:38 ----------



Так обычно секция .bss себя ведет.

Не. В секцию .bss помещаются неинициализированные данные. Которые по стандарту С забиваются нулём.

Но то, что вместо констант в секции .data генерится код - согласен - идиотизм...

[Oleg N. Cher]

Дикость и глупость.

Чо - руки отвалятся написать сразу

Руки бы пооборвал...

идиотизм...
Но-но, потише, лошадки. Филипп Краузе — такой же энтузиаст, как и мы. Ему не платят за разработку кодогенератора Z80 для SDCC.

Мне стыдно будет показать Филиппу эту ветку, насколько неблагодарно некоторые... гм... оценивают его труд. Обвиняя во всех смертных грехах. А Вы не думали о том, что может он просто ещё не добрался до этого направления работы?

Так что поменьше эмоций. Вам никто ничего не должен хорошо и безплатно делать. Мы здесь все никому ничего не должны. А Вы не принимаете промежуточные черновые варианты поведения кодогенератора за эталон?

[psb]

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

[Valen]

Руки бы пооборвал...
О, милости просим в репозиторий sdcc !
Сверкните там своей эрудицией и закомитте хотя бы один патч, решающий указанную вами проблему.

[psb]

О, милости просим в репозиторий sdcc !
http://lurkmore.to/%D0%A1%D0%BF%D0%B5%D1%80%D0%B2%D0%B0_%D0%B4%D0%BE% D0%B1%D0%B5%D0%B9%D1%81%D1%8F ?

[Vitamin]

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

И таки да, между критикой и наездом есть разнциа.

[psb]

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

[Vitamin]

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

Если тебе что-то не нравится в продукте- сообщи автору, это не так сложно. Критика на левом форуме, не выходящая за пределы "негодования" - признак того, что хочется лишь почесать языком, а не получить рабочий продукт.

[SfS]

Мне стыдно будет показать Филиппу эту ветку, насколько неблагодарно некоторые... гм... оценивают его труд. Обвиняя во всех смертных грехах. А Вы не думали о том, что может он просто ещё не добрался до этого направления работы?

Так что поменьше эмоций. Вам никто ничего не должен хорошо и безплатно делать. Мы здесь все никому ничего не должны. А Вы не принимаете промежуточные черновые варианты поведения кодогенератора за эталон?

Я критикую не Филипа - респект ему и уважуха, сам проект мне нравится. Иначе бы я просто не писал в эту ветку.

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

Во всех известных мне компиляторах C - в секцию .data помещаются уже инициализированные данные. И нигде код не генерится. Исключение - микроконтроллеры - но там слепок секции .data хранится в ПЗУ и при инициализации полностью копируется на своё место в ОЗУ.

Так что если кого задела моя ругань - извиняюсь.

Но если кто подскажет - где и как в исходниках SDCC генерится инициализация переменных - то скажу спасибо.

[psb]

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

и мотивацию тоже надо учитывать;) ее недостаточно для написания нормального репорта, а просто мнение выразить - пожалуйста.

[Eltaron]

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

Там на трекере всего порядка десяти открытых тикетов по z80. Филлип все читает, и довольно оперативно все фиксит. Про инициализацию там нет, правда, это скорее всего не специфичная для z80 вещь, для других архитектур sdcc наверняка генерит точно так же.

[psb]

для других архитектур sdcc наверняка генерит точно так же
и всем пофиг? или просто Филлип не может за это отвечать?

[Eltaron]

Что-то вообще странное с инициализацией у нас


char* hello1 = "Hello";
char hello2[] = { 'H', 'e', 'l', 'l', 'o', 0 };

void main() { }


По идее, первые две строки абсолютно равнозначны. Однако


.area _DATA
_hello1::
.ds 2
_hello2::
.ds 6

.area _GSINIT
;1.c:1: char* hello1 = "Hello";
ld hl,#__str_0
ld (_hello1),hl
;1.c:2: char hello2[] = { 'H', 'e', 'l', 'l', 'o', 0 };
ld hl,#_hello2
ld (hl),#0x48
inc hl
ld (hl),#0x65
ld hl,#_hello2 + 2
ld (hl),#0x6C
ld hl,#_hello2 + 3
ld (hl),#0x6C
ld hl,#_hello2 + 4
ld (hl),#0x6F
ld hl,#_hello2 + 5
ld (hl),#0x00

.area _CODE
__str_0:
.ascii "Hello"



для других архитектур sdcc наверняка генерит точно так же.
А ведь нет! Попробовал для ds390 (от балды), там все хорошо. Надо заводить тикет.

---------- Post added at 00:24 ---------- Previous post was at 00:03 ----------

Завел

[b2m]

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

[Eltaron]

Нифига. В первом случае присваивается указатель, во втором - каждый элемент массива.
Эмм... Ну да, приведенный код именно это и показывает.
Но вот почему? Что мешает массив тоже разместить в _CODE? То, что _CODE в ROM? Но тогда почему стринга размещена там, а не инициализируется в рантайме тем же способом?

[SfS]

Но тогда почему стринга размещена там, а не инициализируется в рантайме тем же способом?

потому что "Hello" - в данном случае - константа. А char* hello1 - переменная-указатаель.

Если ты напишешь

char a[10]="hello", то сгенерится



.area _DATA
_a::
.ds 10
;--------------------------------------------------------
; overlayable items in ram
;--------------------------------------------------------
.area _OVERLAY
;--------------------------------------------------------
; external initialized ram data
;--------------------------------------------------------
;--------------------------------------------------------
; global & static initialisations
;--------------------------------------------------------
.area _HOME
.area _GSINIT
.area _GSFINAL
.area _GSINIT
;cls.c:4: char a[10]="hello";
ld hl,#_a
ld (hl),#0x68
ld a,#0x65
ld (#_a + 1),a
ld a,#0x6C
ld (#_a + 2),a
ld (#_a + 3),a
ld a,#0x6F
ld (#_a + 4),a
ld bc,#_a + 5
ld a,#0x00
ld (bc),a



Я говорю - кодогенерация для инита переменных Z80 - очень сырая. Кто хорошо знает английский - напишите аффтору, еслти нет такой темы.

По-хорошему надо просто генерить



.area _DATA
_a::
.ascii "hello",0,0,0,0,0


И никакого кода

Если написать
const char a[10]="hello", то сгенерится всё верно, только в сегмент _CODE

[Eltaron]

Я говорю - кодогенерация для инита переменных Z80 - очень сырая. Кто хорошо знает английский - напишите аффтору, еслти нет такой темы.


Я писал, закрыли, потому что дубликат древнего http://sourceforge.net/tracker/?func=detail&aid=3299337&group_id=599&atid=350599

[Oleg N. Cher]

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

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

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

---------- Post added at 13:50 ---------- Previous post was at 13:12 ----------


Я критикую не Филипа - респект ему и уважуха
Да, тем более, Филипп подтвердил, что действительно трудится на внутренней мотивации (возможно, дополнительный стимул — ностальгия по ColecoVision). Господа, не будем забывать, что SDCC — это в первую очередь не программа, а люди.

On 16.09.2012 20:32, Oleg N. Cher wrote:
>> I have one more question for you. Brings the SDCC development work some
>> advantage or profit to you? Or your work is 'for fun' only?

I use sdcc myself (for some hobby retrogaming stuff), so you I get the
advantage of having a better compiler, as does any other sdcc user. I'm
just a PhD student at the university of Frankfurt, working on sdcc when
I have some time to do so.

>> I heard that company Zilog presently releases Z80-based microcontrollers
>> on the base of the Z80 command system. Can be they are interested in
>> commercial support for improvement to code generation in development of
>> SDCC?

Zilog considers the Z80 a legacy product. They do have some current
products based on the eZ80, which is somewhat similar to Z80 and other
architectures, which are wuite different. Zilog has their own C compiler
supporting the eZ80 and the other architectures. sdcc currently does not
support the eZ80 or any other current Zilog architecture.

Philipp

[Barmaley_m]

По-хорошему надо просто генерить



.area _DATA
_a::
.ascii "hello",0,0,0,0,0


И никакого кода

Если написать
const char a[10]="hello", то сгенерится всё верно, только в сегмент _CODE
Обсуждалось же на первых страницах этой темы, я первым поднял вопрос инициализации данных. Для сегмента инициализированных, но неконстантных данных, необходим код инициализации, как минимум - в виде LDIR. Потому что если начальные значения этих данных размещаются в ПЗУ, то сами данные должны размещаться в ОЗУ, т.е. по другим адресам.

С другой стороны, эту проблему можно отнести не к компилятору, а к загрузчику исполняемых файлов. То есть компилятор генерирует сегмент инициализированных данных и заполняет его чем надо, а уж как эти значения попадут в ОЗУ - проблема загрузчика. Если это ось - то в исполняемом файле код инициализации не нужен, ось сама загрузит файл и разместит где надо сегменты; а если это ПЗУ - то в ПЗУ должен быть упрощенный загрузчик, который инициализирует сегмент данных.

[psb]

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

[Valen]

Обсуждалось же на первых страницах этой темы, я первым поднял вопрос инициализации данных. Для сегмента инициализированных, но неконстантных данных, необходим код инициализации, как минимум - в виде LDIR. Потому что если начальные значения этих данных размещаются в ПЗУ, то сами данные должны размещаться в ОЗУ, т.е. по другим адресам.
Всё верно.
(Просто как-то это мимо ушей люди пропускают.)
Изначально, компилятор затачивался под ColecoVision, там четкое разделение на ROM/RAM.
Вот включили приставку, выполняется ROM, он и должен инициализировать RAM и потом уже начать выполнять собственно main().

(Другими словами, нужна более эффективная инициализация сегмента инициализированных данных.
Тикет на это есть.)

[Oleg N. Cher]

sdcc не единственный компилер, и не лучший (имхо) вот уже много лет.
Смотря какие критерии. Для Z80 доминирующий критерий один — качество кода. А какой же компилер по-вашему лучший? Только без софистики, давайте объективные данные, с указанием версий, а лучше всего бенчмарки. (Тему "хайтек си рулез" мы уже обсудили в этой ветке раньше.)

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

Если кто-то из "критиков" претендует, буду рад увидеть список реализованных Вами проектов.

[psb]

я не претендую, но лично мне субъективно больше понравился iar. по качеству кода, ага. доказывать ничего не буду, смотрел их уже давно (а проблемы, как видно, остались те же).

[SfS]

Всё верно.
(Просто как-то это мимо ушей люди пропускают.)
Изначально, компилятор затачивался под ColecoVision, там четкое разделение на ROM/RAM.


Спасибо. Я об этом не знал.

---------- Post added at 22:30 ---------- Previous post was at 22:26 ----------


я не претендую, но лично мне субъективно больше понравился iar. по качеству кода, ага. доказывать ничего не буду, смотрел их уже давно (а проблемы, как видно, остались те же).

ИМХО, сравнивать некорректно. Ибо цена у ИАРа очень кусявая...

А по кодогенерации - да. ИАР лучше.

[psb]

ИМХО, сравнивать некорректно. Ибо цена у ИАРа очень кусявая...

а мы здесь бизнесов не делаем и живем в россии;)

[SfS]

а мы здесь бизнесов не делаем и живем в россии;)

Я в плане того, что у иара команда разработчиков, которые за это деньги получают. А у SDCC - всё добровольно.

[psb]

А у SDCC - всё добровольно.
вот поэтому никаких претензий, никаких нагнетаний. просто факт есть факт. и альтернатива как бы есть, если ну очень надо.

[Oleg N. Cher]

psb, если бы Вы критиковали глючность SDCC, я бы ещё понял. Но Вы утверждаете (причём абсолютно голословно), что у iar лучше код, хотя сравнивали давно, и так далее. Этим самым Вы распускаете на форумах мифы, в которые верят новички. Вы вредитель, psb.

[psb]

Вы вредитель, psb.
хорошо, но и от вас я опровержений не слышал. мне щас ковырять и искать правду здесь не до сук. то, что я здесь увидел, однозначно говорит, что дела не очень у sdcc уже долгое время - это моё личное мнение. и я не верю, что по качеству кода он скоро переплюнет iar.

[Oleg N. Cher]

Мало ли во что Вы верите. Давайте тестировать на бенчмарках. Хотя бы на этом: http://colecovision.eu/stuff/testbench.tar.gz. У Филиппа не было под рукой iar, но Вы сами знаете как за рубежом относятся к ворованным продуктам. Поэтому в списке протестированных компиляторов iar не присутствует. Но Вы можете наблюдать прогресс развития кодогенерации SDCC (http://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size).

Притом я не сомневаюсь, что Вы сумеете накопать частный случай, где iar покажет небольшой выигрыш перед SDCC, однако в остальном SDCC уже не тот, что был. У меня есть проект Дурак (http://zx.oberon2.ru/durak.htm), и я уже несколько лет, собирая его разными версиями SDCC, наблюдал всё более качественную кодогенерацию, конечно не всегда она улучшалась линейно, но в целом если взять 2.x.x и теперешнюю 3.2.1, то получится очень впечатляющая разница. Несколько килобайт в Дураке выиграно на одной только кодогенерации. А Вы, видимо, не смотрели кодогенерацию новых версий SDCC, и по привычке переносите свои старые суждения iar vs SDCC в настоящее время, не потрудившись их как следует проверить. Мне бы не было так грустно, если бы я сам когда-то, начиная программировать на Си для Z80, не купился на такие заверения про HITECH-C на данном форуме. А когда сопоставил кодогенерацию — увидел сам. Поэтому распространение мифов такого рода считаю полезным пресекать.

[psb]

и по привычке переносите свои старые суждения iar vs SDCC в настоящее время, не потрудившись их как следует проверить.
спасибо, капитан очевидность! я так и сказал сразу, что не в курсе особо, дело было давно.


У меня есть проект Дурак, и я уже несколько лет, собирая его разными версиями SDCC, наблюдал всё более качественную кодогенерацию
ну раз у вас оружие наготове, вы не могли бы такой тест провести с iar'ом? или вы плохо относитесь к ворованным программам и не знаете где взять iar?

[Oleg N. Cher]

Да, не знаю. Не искал. А какая там нынче последняя его версия?

[psb]

Да, не знаю. Не искал.
т.е. вы не знаете, не пробовали, но это я тут мифы распространяю...


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

[NovaStorm]

А какая там нынче последняя его версия?
4.06A кажется.

[Error404]

Мне бы не было так грустно, если бы я сам когда-то, начиная программировать на Си для Z80, не купился на такие заверения про HITECH-C на данном форуме. А когда сопоставил кодогенерацию — увидел сам. Поэтому распространение мифов такого рода считаю полезным пресекать.

У меня был такой опыт. Проект - webserver из штатных примеров uIP v1.0.

HitechC (v3.09 1988 год выпуска, freeware) - 18кб и код работает.
SDCC 3.х.x (3 месячной давности) - код 26кб (это в лучшем случае, когда я прошел по всем граблям разных вариантов инициализации констант, по началу было более 30к) и код не работает (разваливается где-то посередине выполнения), хотя и компилируется без ошибок.

В отсутсвие нормального отладчика, дебажить выход SDCC чтобы понять отчего его код не работает, как-то не было желания.
Так что поосторожнее с распространением мифов. :)

[ZEK]

ритом я не сомневаюсь, что Вы сумеете накопать частный случай, где iar покажет небольшой выигрыш перед SDCC
наоборот sdcc частный случай где уделывает

cvu_vinb.c - 9
galois_lfsr.c - 19
get_tile.c-104
huffman_iterative.c - 136
huffman_recursive.c - 154
init_loop.c - 43
insertion_sort.c - 126
memcpy_compression.c - 67
memtovmemcpy.c - 60
play_music.c - 417
sdcc_mullong.c - 203
set_screen_mode.c - 50
set_sprite_x.c - 79
z88dk-mktime.c - 278

TOTAL - 1745 у SDCC 2703

можешь фразу: SDCC лучший в мире кодогенератор С для Z80 засунуть в свой зад, лучший открытый - да.

[Oleg N. Cher]

Я как раз предлагаю распространять не мифы, а объективную информацию. Хотя опыт показывает, что если кому-то в данный момент положить на всё, кроме самоутверждения, то это его состояние по жизни. И надежд на улучшение мало. Про прочих с задами я промолчу. Error404, SDCC мог сдублировать проинициализированные массивы, да мало ли. Наконец, где ключики компиляции? Вобщем, будет или детский сад, или нет.

[jerri]

Oleg N. Cher, опять умничаешь :)

ZEK, а ты грубишь
добрее надо быть

[psb]

то это его состояние по жизни.
да вам-то виднее, о чем речь...

[jerri]

Я как раз предлагаю распространять не мифы, а объективную информацию. Хотя опыт показывает, что если кому-то в данный момент положить на всё, кроме самоутверждения, то это его состояние по жизни. И надежд на улучшение мало. Про прочих с задами я промолчу. Error404, SDCC мог сдублировать проинициализированные массивы, да мало ли. Наконец, где ключики компиляции? Вобщем, будет или детский сад, или нет.

А разве ключи компиляции влияют на работоспособность полученной программы?

[Eltaron]

А разве ключи компиляции влияют на работоспособность полученной программы?
--oldralloc да
в новом аллокаторе пофикшены какие-то баги
например, у меня есть код, который ведет себя совершенно по-разному при обычной компиляции, и при --oldralloc

[jerri]

Eltaron, это чо за шаманство?

[Eltaron]

Eltaron, это чо за шаманство?
Аллокатор регистров. Старый глючный, но быстрый, а новый жутко медленный, но вроде бы правильно работающий.

[Oleg N. Cher]

Ключики влияют на размер программы, о чём сейчас и спор.

Так вот, о мифах. В своих высказываниях насчёт того, что у SDCC лучшая кодогенерация, я опирался на мнение Филиппа Краузе, сделанный им набор тестов (http://colecovision.eu/stuff/testbench.tar.gz) и список проверенных на этих тестах компиляторов (https://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size). Согласитесь, это уже что-то более существенное, чем субъективные высказывания в стиле "я шото откомпилировал и шото сравнил". Филипп согласен, что IAR имеет качественную кодогенерацию, но указывает на то, что нужно тестировать компиляторы в равных условиях. В связи с этим он просит желающих скомпилировать в IAR данные тестовые программы, но чтобы компилятор не использовал недокументированные инструкции процессора и чтобы все функции были реентерабельными, если это конечно возможно в IAR. Этого, по его словам, будет достаточно, чтобы добавить результаты в таблицу тестов.

Ну и планка рекорда поднята. :)


I do not have access to the IAR compiler. Soonly included the free
z88dk compiler, and some non-free compilers that have time-limited
evaluation versions.

I already saw it in the discussion you mentioned earlier, and was about
to write to you about them. The IAR results are impressive in terms of
code size. When I made the benchmark
http://colecovision.eu/stuff/testbench.tar.gz years ago, I did choose
files, where HITECH-C performed much better than sdcc. And then worked
on improving sdcc until it was better than HITECH-C for them. So the IAR
results set a kind of new goal to reach for sdcc.

For including the results on the comparison page I would like to also
have a version compiled with comparable options to sdcc: No use of
undocumented instructions, and all functions compiled as reentrant.

[psb]

So the IAR
results set a kind of new goal to reach for sdcc.
достойная цель! что ж, подождем.


но чтобы компилятор не использовал недокументированные инструкции процессора
а это еще почему? сейчас уже давно все документировано.

[Oleg N. Cher]

Информация о таких инструкциях конечно доступна. Но данный набор инструкций в многочисленных документах по Z80 называется недокументированным. (Zilog мог в новых версиях процессора убрать поддержку этих инструкций. Не знаю, правда, насколько это актуально в данный момент). Но Вы ж видите, для Филиппа это имеет значение. Хотя во встроенный асм включить эти инструкции он согласился.

И сам SDCC генерирует только документированные инструкции. Если интересно по каким причинам они избегают недокументированных, могу спросить. (Может по идеологическим причинам, а может просто нигде не понадобились).

[psb]

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

[ZEK]

(что-то не верю в это
Использует, там параметр есть.

[Oleg N. Cher]

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

P.S. Списался с IAR, попросил сделать IAR Embedded Workbench for Zilog Z80 безплатным хотя бы для некоммерческого использования, ну раз уже не продают, так чего хоронить. Ага, щаз.

Dear Oleg,
Thanks for your email!

I've now checked the issue and due to this is a product we do not longer support we can offer you an
PC locked license of EWZ80 version 4.06 ( from the year 2001) without support.

For the amount of 1715 EUR
Payment: In advance

Please do check if this version would be ok and also if you would need any further information or would like
to place an order.

Best regards,
Liselott Lundeborg Sales Manager Sweden - Key Account Manager Nordic
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Website: www.iar.com

[NovaStorm]

>without support
>For the amount of 1715 EUR
Петросяны #%я =)

[Oleg N. Cher]

Забыл добавить:
>PC locked
(залоченный на один комп, как я понимаю)

[Shadow Maker]

А вы типа хотели, чтобы вам плоды сотен человекочасов за спасибо отдали? Кто еще петросяны...

[psb]

А вы типа хотели, чтобы вам плоды сотен человекочасов за спасибо отдали?
это называется "ни себе, ни людям". они в любом случае не получат ничего. но и не потеряют, разрешив некоммерческое использование.

[siril]

P.S. Списался с IAR, попросил сделать IAR Embedded Workbench for Zilog Z80 безплатным хотя бы для некоммерческого использования, ну раз уже не продают, так чего хоронить. Ага, щаз.

5 лет назад то же самое говорили =) тоже им предлагал зафриварить хотя-бы =)

[Oleg N. Cher]

Господа, подскажите вот какую вещь.

Как с помощью препроцессора передать символ # вовнутрь тела макроса?

Я придумал способ передавать параметры функций через регистры. Сразу скажу про ограничение этого способа. Он не позволяет передавать вычисляемые в рантайме выражения, только константы, числа известные на этапе компиляции. Проблема в том, что SDCC-ассемблер требует везде, где подразумевается числовой литерал, писать перед ним # (в sdasz80 это не обозначитель шестнадцатеричного числа), и опускать # нельзя. Получается, что без # невозможно нормально написать даже DB(DEFB). А препроцессор напротив считает # сугубо служебным символом и ругается на любые попытки передавать его в теле макроса.

Т.е. хочу, чтобы если встретилось BORDER(4), оно превращалось в:

LD A,4
CALL 0x229B
но в SDCC-асме так будет ошибка. Надо:

LD A,#4
CALL 0x229B
Так что при попытке скомпилировать код:

#ifndef Basic_fastcall_BORDER
import void BORDER (BYTE color);
#else //Basic_fastcall_BORDER
#define BORDER(color) __asm \
LD A,#color \
CALL 0x229B \
__endasm;
#endif
SDCC выдаёт ошибку:

Basic.h:13:29: error: '#' is not followed by a macro parameter
Пробовал различные комбинации скобочек, по совету Филиппа пробовал такое:

#define id(x) x

#ifndef Basic_fastcall_BORDER
import void BORDER (SHORTINT color);
#else //Basic_fastcall_BORDER
#define BORDER(color) __asm \
LD A,id(#)color \
CALL 0x229B \
__endasm;
#endif
Пробовал даже диграфы и триграфы (http://en.wikipedia.org/wiki/Digraphs_and_trigraphs). Не подошли (не понимаю тогда зачем они вообще нужны).

Есть ли решение?

[Eltaron]

#define hash #
#define id(x) x
#define BORDER(x) ld a,id(hash)x


void main()
{
BORDER(5)
}

[Oleg N. Cher]

Всё-таки удалось выспросить у IAR триальную версию Embedded Workbench for Z80. Филипп, как и обещал, добавил её в список.

Thanks.

I have compiled the benchmark using IAR 4.06A (optimizing for code size,
without use of undocumented instructions), and added the results at

http://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size

Philipp