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

[Oleg N. Cher]

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

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

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

[Advertiser]

[Valen]

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

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

Или можете себе представить более объёмные исходники для Z80? (основнй модуль Дурака весит 2,3 тыс. строк)

Я всё тестирую на "SDCC framework for V6Z80P".
Там либы + примеры программ, это где-то 7,5 тыс. строк.

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

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

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

[Oleg N. Cher]

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

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

[Oleg N. Cher]

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

>>
>> http://translate.google.com/translat...hp%3Ft%3D19900
>>

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/sd...%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.

[SfS]

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

[vinxru]

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

А зачем?