Ищу Си для Z80

[Vovoi]

Ха ...
Так что мой компилятор будет всё учитывать ...

Не надо все лепить в кучу, поработай с "Hisoft C", имхо не стоит реализовывать сразу всйо. Если ты писал на асме проги для Спека, то сам знаешь какие операторы и команды необходимы в первую очередь. Во всяком случае, в компиляторе спектрум-бэйсика я не рвался сразу реализовывать весь его словарь. Да хотя бы потому, что лишней памяти-то нет.

зы:
А кто-нибудь (в 1993-2002гг.) помышлял о том, чтобы написать Си-компилер на Спеке?

[Vladson]

А кто-нибудь (в 1993-2002гг.) помышлял о том, чтобы написать Си-компилер на Спеке?

Помышлял, но дальше мыслей дело не дошло...
(В итоге упирался в "вилку", либо совместимость с оригинальным Си, либо скорость откомпилированного кода. Компромисс мне кажется не возможен...)

[Barmaley_m]

Компромисс возможен в виде настроек компилятора.

Например, в MS Visual Studio 2005 есть такие режимы компиляции кода, работающего с дробными числами: Fast (быстрый код) и Precise (точный, или совместимый). "Точный" код не является более точным в математическом смысле - он более точный лишь в смысле совместимости со стандартом Си.

Так, например, если идут вычисления с числами одинарной точности (float), то быстрее всего их провести на стеке сопроцессора в двойной точности, а результат перевести в одинарную. Такой код генерирует компилятор в случае опции "Fast". В случае "Precise" он будет после каждой операции огрублять числа до одинарной точности. И точность меньше, и быстродействие, зато - по стандарту.

А вообще я присоединяюсь к той точке зрения, что если кто-то желает произвести на свет хороший кросс-компилятор С для Z80, то надо брать существующие open-source проекты и отталкиваться от них. Создание компиляторов - сложная задача, и даже самый талантливый и амбициозный человек потерпит неудачу, если задумает одним махом создать хороший компилятор.

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

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

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

[Vladson]

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

Согласен с этой точкой зрения, полностью поддерживаю...

[Sayman]

если нужон Си именно для спектрума и на спектруме, то это наверно только под ЦПМой можно найти. их там с пяток примерно..+ под тырдосом была какая то сятина..забыл название.

[Higgins]

Под CP/M есть BD Software C compiler. Лучший, на то время. Кому нужно, легко найдет исходные тексты, благо они выложены автором.

К слову, написан на ассемблере i8080. Товарищу, собравшемуся писать компилятор должно быть интересно оценить размер кода. И это не просто без поддержки C99, но даже без плавучки и прототипов функций.

Теперь что касается соответствия ANSI/ISO и оптимальности целевого кода. Можно, конечно, ради этой оптимальности отойти от стандартов и заточить язык так, чтобы он удобнее ложился на целевую платформу, но:

1) это будет небольшим прогрессом, если сравнивать с макроассемблером и

2) это очень мало поможет в части качества кодогенерации.

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

[alone]

Никто не замерял результаты dhrystone у разных компиляторов C для Z80? А то в интернетах только один результат приведён: http://www.csa.ru/CSA/Benchmarking/dhrytbl.shtmr

[MakSer]

С для AVR и PIC (8бит) имеют весьма эффективный код хорошо оптимизированный.
Разница между чисто на асме не очень велика как в плане быстроты так и в плане размера, микроконтроллеры имеют ресурсы примерно такие же как и Спек. Кстати для AVR используется портированный GCC.
Естественно сам компиляторы работают на ПЦ. и генерят готовые прошивки.
Вот если б такой компилятор для z80...

[psb]

уже тут говорили, скажу еще раз.
1. у авр куча регистров, как минимум поэтому его сложно адекватно сравнить с z80 (в плане компилятора си).
2. у пика вообще ппц архитектура. может компилер и "делает все возможное", но так или иначе, вменяемый компилятор си там не возможен. мне такое чудо как hi-tech picc для 16х пиков на спеке даром не надо.

Вот если б такой компилятор для z80...

а IAR чем не устраивает?

[MakSer]

А MicroC? Он считается самым лучшим компилятором для PIC, правда сам PIC убогий.
Насчет AVR, плотно пользуюсь CodeVisionAVR, изучал генерируемый листинг на Асме.
Там используются в основном несколько регистров, а большинство (2-24) из 32 для хранения переменных. AVR не чистый RISC процессор. и регистры другие используются по разному, например, R31,R32 как HL, так, что не сильно то ушел от Z80. Единственно: у AVR простая команда выполняется за 1 такт, и при 16МГЦ тактировании получается 16000000 операций в секунду! Но все же код получается компактный. Кстати нашел я порт GCC для Z80, в ввиде патча, че с ним делать и как использовать непонял.