Языки программирования

[Vitamin]

Спасибо, интересное исследование. Значит sdcc... Но вот меня смущает, что на sdcc.sf.net постоянно упоминается "freeware", несмотря на его GPL'ность.
А по поводу переменных, наверное в реальных проектах будет много глобальных статических, чтобы компилятор их просто клал в память, не извращаясь со стеком или IX/IY.

Фриварный он и есть- сорцы в комплекте, доки тоже.
Проверил статические переменные- те же яйца, только в профиль.
Частично решить проблему получается с использованием встроенного peephole-оптимизатора. Пишется файл автозамен и код весьма и весьма легчает, но это не панацея, ибо оптимизация использования регистров (в частности, IY) бывает приводит к ошибкам постоптимизации.
Так что надо ковыряться в части кодогенератора- он в сорцах отдельно лежит, я правда не разобрался еще в нем.
А вообще- приятное впечатление произвел, весьма.

[maximk]

Все-таки мне кажется, что тест несколько синтетический.

Например, умножение на 1, деление на нее же - в чем смысл? Разве кто-то напишет так в программе? Ну, хорошо, а если константное выражение? Ну, это дело поправимое. Да, читаемость снизиться, но до асма будет далеко.

Или, например, цикл который можно убрать. Ну дык пусть программер и уберет. Не всегда видно? Дык, хороший стиль программирования предполагает, что все видно. В конечном счете при кривых исходниках самому же будет хуже.

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

[NovaStorm]

Vitamin, разницу free/freeware думаю тебе объяснять не надо. Но он GPL и ладно.
Dynamic C http://www.rabbitsemiconductor.com/products/dc/ Z80 поддерживает, никто не в курсе?
++
"Andrew S. Tanenbaum created MINIX at Vrije Universiteit in Amsterdam" и компилилась она их же ACK. Кстати MINIX3 до сих пор им собирается.

[Vitamin]

Все-таки мне кажется, что тест несколько синтетический.

Предложи свой. Который будет естественным, в котором не будет "синтетических" циклов, "синтетических" присваиваний, "синтетических" разыменований указателей и т.п.

Например, умножение на 1, деление на нее же - в чем смысл? Разве кто-то напишет так в программе? Ну, хорошо, а если константное выражение? Ну, это дело поправимое. Да, читаемость снизиться, но до асма будет далеко.

Ну вот тебе две строчки исходников:
const float var = (100.0 + 13.0) / 100.0; //(base + addition) / percents
и
const float var = 1.13; //(base + addition) / percents

как ты по второй строке (не глядя на первую) скажешь что чему ты принимаешь? никак- разворачиваем выражения для своей пользы. И просто очень приятно, когда тупой компилятор не догадывается свернуть это безобразие...
А насчет умножения на 1. Тоже имеем код
#define COEFF 4
...
int t = var * COEFF;

Хорошо, если компилятор свернет умножение на константу. А то есть такие индивиды, что и не сворачивают, даже если COEFF=1

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

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

Или, например, цикл который можно убрать. Ну дык пусть программер и уберет. Не всегда видно? Дык, хороший стиль программирования предполагает, что все видно. В конечном счете при кривых исходниках самому же будет хуже.

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

[Vitamin]

Vitamin, разницу free/freeware думаю тебе объяснять не надо. Но он GPL и ладно.
Dynamic C http://www.rabbitsemiconductor.com/products/dc/ Z80 gподдерживает, никто не в курсе?

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

[maximk]

Но это не выход.

На самом деле ты прав, но есть одно но. Мы имеем дело с процессором, который поддерживается постольку-поскольку. То, что под популярный gcc так и не написали backend для z80 показательно. Оно никому не надо. И поэтому то, что есть - ценно.

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

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

И второй момент. Логично желание иметь хороший компилятор под Z80 на самом спектруме. Но ресурсы машины таковы, что супер-мега компилятор на ней просто не сделать, и тогда такие вещи, как умножение на 1 - это мелочи, это не суть важно. Да, хотелось бы, но не так чтобы очень.

А мы, как часто бывает на форуме (и как было с динамическим компоновщиком) быстро скатываемся в область сферических коней в вакууме, типа, да ну нет, это отстой, вот надо делать вот как!

[Vitamin]

На самом деле ты прав, но есть одно но. Мы имеем дело с процессором, который поддерживается постольку-поскольку. То, что под популярный gcc так и не написали backend для z80 показательно. Оно никому не надо. И поэтому то, что есть - ценно.

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

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

Я не питаю иллюзий по поводу того, что С будет использоваться для написания прог. Но что оттачивать идеи на ЯВУ гораздо удобнее, чем на асме (особенно имя готовы библиотеки для работы с плавающими числами или ввода-вывода) это факт.

И второй момент. Логично желание иметь хороший компилятор под Z80 на самом спектруме. Но ресурсы машины таковы, что супер-мега компилятор на ней просто не сделать, и тогда такие вещи, как умножение на 1 - это мелочи, это не суть важно. Да, хотелось бы, но не так чтобы очень.

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

А мы, как часто бывает на форуме (и как было с динамическим компоновщиком) быстро скатываемся в область сферических коней в вакууме, типа, да ну нет, это отстой, вот надо делать вот как!

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

[caro]

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

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

И второй момент. Логично желание иметь хороший компилятор под Z80 на самом спектруме. Но ресурсы машины таковы, что супер-мега компилятор на ней просто не сделать, и тогда такие вещи, как умножение на 1 - это мелочи, это не суть важно. Да, хотелось бы, но не так чтобы очень.

А мы, как часто бывает на форуме (и как было с динамическим компоновщиком) быстро скатываемся в область сферических коней в вакууме, типа, да ну нет, это отстой, вот надо делать вот как!

Золотые слова.
По этой причине я и убрал с форума последнюю версию C Warp,
поняв что кроме охаивания ничего хорошего не услышу
Мне он нравится уже потому, что работает на моем любимом Спекке,
хоть и генерит страшно "монструозный" код

[psndcj]

Я не питаю иллюзий по поводу того, что С будет использоваться для написания прог.

если появится кросс-компилятор, генерящий боле-менее адекватный код, то лично я бы начал его использовать в наших следующих демах. Несмотря на всеобщее мнение, что демо выжимают из машины невозможное, критическогл по времени кода не так уж и много - процентов 20-40, все остальное занимает управление и менеджеры данных и событий - их выполнение на асме занимает ничтожное время (до 10-15% прерывания), а написание их на pure asm занимает до 80% времени!!! Конечно я говорю по своему опыту, у кого-то все совсем наоборот - но логику на асме писать очень напряжно, в отличие от раскрытого и линейного демо-кода...

[NovaStorm]

Увы =( "Dynamic C runs on a PC and connects to the processor though a serial connection to the Rabbit Microprocessor core module."
Только для кроликов. А там система команд отличается.