Ну я совсем чуда и не ждал как-бы, видимо просто не совсем точно выразился. Я, скорее, хочу надеяться на наличие у ACK оптимизатора, который сможет эффекивно выбрасывать ненужное в определённых ситуациях. Один из частных примеров (отсутствие локальных данных, когда стек можно пихать навалом на фрейм вызова) я уже привёл. Это очень простая для оптимизатора ситуация, почему Manx её не сделал, мне до конца не ясно. Видимо, настолько в восторге были от факта что удалось портировать yacc парсер на 8080, что об остальном позабыли.Сообщение от Oleg N. Cher
Понятно, что лучший способ нивелировать фрейм на вызываемой стороне - это link register либо что-то типа 8086 инструкций ENTER/LEAVE. Но за неимением такового нужен гибкий генератор входного/выходного кода. На это и уповаю.
Просто для 8080, в отличие от z80, совсем нет более-менее современных С компиляторов, всё K&R. Насколько я могу понять, ACK клэймит совместимость c X3.159. Я не смотрел, какая цифра после 159, надеюсь 26 или выше. Но в любом случае, это уже ANSI.
Тут на форуме winxru делал ANSI-совместимый кросс-компилятор, но кажется забросил. Замечательно, что svofski поднял тему ANSI-совместимых альтернатив. Язык C-это наше всё - самое то быстро писать CP/M-совместимые утилиты, даже если там вообще 0 оптимизаций. PL/I меня лично как-то меньше привлекает несмотря на то что да, код он сгенерит эффективней чем C.
Ответить с цитированием