Последний раз редактировалось PPC; 06.01.2021 в 21:50. Причина: Закрыл quote
Сравнивать BDS C и ACK неуместно. BDS C это даже не K&R. Какая разница, какое у BDS C качество кода, если им нельзя скомпилировать ничего кроме othello.c? ACK собирает исправно работающий uIP, это неплохое доказательство состоятельности его как компилятора.
Что до того, какой код генерит ACK. Почему бы просто не почитать то, что он генерит? startrek.c подойдет?
Без оптимизаций:
https://pastebin.com/Ti4chcvw
-O6:
https://pastebin.com/BTxMFibL
Больше игр нет
Сколько префиксов перед пабликами у стандартных функций, аж 3
У UDF - одно подчёркивание
Очень недурно на первый взгляд.
Мне понравилось как делается фрейм
call .probyte
.data -LOCAL
Рестарты на полную катушку, это здорово как засылка параметров в функции, все эти .fstoreX
Чуть напрягает
jmp .ret
по выходу
и знакомое
mov a,m
mov l,a
mvi h,0
Понравилась оптимизация в maneuver_energy e = e - n - 10
Компайлер сделал e = e - (n+10)
Aztec так не умеет
Но в общем - классно на первый взгляд, а в деталях надо смотреть более пристально.
тут беда не в компиляторах, а в i8080, которому до нормального процессора не хватает ни РОН ни способов адресации. Вот и получаются семь шапок из овчинки. Поэтому на Z80 обычно С ложится лучше (хотя тоже далеко не идеал из-за желания Z80 быть архитектурно близким к 8080). Даже не смотря на то, что индексные или альтернативные регистры в Z80 это плюс байт/префикс к команде и это казалось бы даст большую трату кода - но нет. Поэтому - да, смириться и искать компилер С для 8080, который хотя бы понимает ANSI, и синтаксис исходников сложных приложений пережовывает
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
PPC, если Вы вникнете в суть форумного (да и не только) общения, то поймёте, что общение (исключая родственных душ) это Вавилон: каждый говорит только о своём. Я пытался развить тему, что в ACK же ещё есть Модула-2 и Паскаль! Но это оказалось никому не интересно. По существу.
Так вот. Свою пользу от присутствия здесь я нахожу в том, что я рассказал вам, энтузиастам, работающим с кодом для процессора 8080, об идее передачи параметров внутрь функции без фрейма. Через глобальные переменные. Ведь компилятор может сам так делать. Потому что само наличие фрейма, ввиду отсутствия в 8080 аналогов команд ENTER/LEAVE или даже индексного регистра для адресации параметров на стеке, делает обращение к параметрам (и к локальным переменным) громоздким и неэффективным. Мой способ конечно специфический, обладает рядом ограничений, но всё-таки до него ещё не додумались авторы компиляторов Си для 8080.
- Функция не должна иметь локальных переменных. Гипотетический однопроходный компилятор способен это вовремя обнаружить.
- Функция не должна быть реентерабельной, т.е. иметь прямую или косвенную рекурсию. Гипотетический однопроходный компилятор будет иметь трудности с определением этой ситуации в момент принятия решения: генерировать фрейм или нет?
Это то, что было у меня на уме, когда я писал посты в эту ветку. А Вы же, PPC, принялись рассуждать о локальных переменных и о том как их лучше размещать на стеке, да и привели ещё и код. А это частности. Намного более любопытна задача: как определить на момент принятия решения "генерить ли фрейм" - рекурсивна ли эта функция? Я написал, что в однопроходном компиляторе это сделать почти невозможно. А Вы принялись опять "при чём тут многопроходность, я вот так размещаю лок. переменные на стеке". Это вообще разговор слепого с глухим. Но я не удивлён, потому что Вы о своём. Постарайтесь ухватить мой посыл хотя бы немного.
Не умаляя достоинств ivagor'а: дельный ответ по существу чего? Просто совпало? :-D
Извините за оффтоп, но в теме уже упоминались другие компиляторы C кроме ack, вот еще один
Kakos_nonos (19.01.2021), Oleg N. Cher (14.01.2021), svofski (14.01.2021)
О, вот это круто!
- - - Добавлено - - -
А под Windows может кто-нибудь собрать компилятор ACK? Буду премного благодарен!
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)