ACK (Amsterdam Compiler Kit) для Вектора и 8080 вообще

[svofski]

ACK оказался не так уж и страшен. Собирается очень быстро и легко, компилирует почти нормальный Си (и еще кучу языков). uIP пришлось совсем чуть чуть подправить, но в общем можно сказать заработало из коробки.

Демо того же IoT-вебсервера, что был на ZPU, на сей раз в нативном исполнении:


Пухлость присуствует: нативный UIP.COM — 37003, тот же самый UIP.COM в варианте ZPU — 25488 это вместе с виртуальной машиной. Зато у ACK для CP/M практически полноценный комплект стандартных библиотек, printf() итд, работа с файлами.

Забавно, что целочисленный Мандельброт работает в 3 раза медленней, чем на ZPU, потому что там int32. sizeof(int) в нем 2 и долговязая арифметика тормозная.

[Advertiser]

[Oleg N. Cher]

ACK собирает под 8080, а не только под Z80? Интересно, не знал.

А на Модуле-2 там же тоже можно писать?

[svofski]

Oleg N. Cher, можно, но я пробовал только Си. Именно 8080 (среди прочих, список таргетов там внушительный). Ссылка на всякий случай https://github.com/davidgiven/ack

[Oleg N. Cher]

Тогда-с ждём игр под 8080-платформы на Модуле-2, раз на Обероне не хотите ;-)

[Error404]

ACK оказался не так уж и страшен. Собирается очень быстро и легко, компилирует почти нормальный Си (и еще кучу языков). uIP пришлось совсем чуть чуть подправить, но в общем можно сказать заработало из коробки.

Пухлость присуствует: нативный UIP.COM — 37003, тот же самый UIP.COM в варианте ZPU — 25488 это вместе с виртуальной машиной.

нативный Hitech-C: httpd.com 19кб
единственно, у меня был переписан printf для вывода только на экран (минус потоки STD), что сокращает бинарь на пару килобайт
ну и понятно, код Z80. Но любая операция с int32 - call в библиотеку (для чего была мысль опцией оптимизировать это в однобайтовые рестарты). Но работало с int32 достаточно быстро, по крайней мере FAT32 (который на int32 весь) не шибко тормозил

[Oleg N. Cher]

Hitech-C не собирает под 8080.

[svofski]

У меня эквивалент httpd.com еще с четырьмя килами дополнительных картинок и скриптов, но все равно понятно, что z80 дает возможность сгенерить код покомпактней. Тем не менее меня интересует именно 8080. Какой объем из этого — printf() итд я не знаю, потому что пока не нашел, как ack генерить map.

Доки вообще
http://tack.sourceforge.net/olddocs.html

Про генерацию кода для 8080
http://tack.sourceforge.net/olddocs/i80.html

[PPC]

Здорово! Я когда-то очень давно лет с 10 или более назад глядел на ACK, но потом что-то меня отвлекло и - не взялся.
Интересно поглядеть на то, как выглядит фрейм стека при вызове функции. Я тут недавно копался с Aztec C, пришёл в ужас. У них там процедура .csave для якобы уменьшения количества кода в стеке, это адъ. То, что она запихивает <BC> типа регистровую переменную, это норм. Но потом она образует фрейм для локальных данных за которым пихает предыдущий <SP> и адрес функции для размотки по выходу. Причём эта вся байда вызывается даже если нет локальных переменных: с нулями для оффсетов хотя достаточно было бы просто сделать pop b; ret; по выходу. Вот, где замедление...
Ну и да сканеры форматного ввода/вывода жуть сколько занимают. Я сразу отказался. Написал свой собственный консольный небуферизированный вывод без переадресации устройств: cputs, putch, getche плюс всякие putdec, putlx (для long) практически через прямые вызовы CP/M BIOS/BDOS по желанию. Только это сразу 4К сэкономило. А если всю conio на асме написать, наверное ещё кил можно срезать.

[Oleg N. Cher]

Интересно поглядеть на то, как выглядит фрейм стека при вызове функции.

Не стОит ожидать здесь чуда. Всё-таки Си есть Си: косвенная адресация, прицел на рекурсию со всеми вытекающими.

Я вот придумал для нереэнтерабельных функций такой механизм передачи параметров:

#define Func(a, b, c) par1 = a; par2 = b; par3 = c; Func_Impl();

где par1-par3 глобальные переменные, доступ к которым осуществляется эффективнее (прямая адресация), чем к стековым (косвенная адресация; для Z80 чаще всего через (IX+n) или (IY+n) ). А реализация функции Func_Impl() достаёт параметры из этих глобальных переменных и сама может вообще не иметь фрейма (на практике она его всё равно имеет - для работы с локальными переменными. Правда, в SDCC можно выключить фрейм для функции модификатором __naked).

Это несколько громоздко записывается, но даёт неплохой код, что особенно важно для проца 8080.

- - - Добавлено - - -

P.S. В SDCC для асмовых функций есть возможность записывать такие переменные-параметры прямо в машкод функции. Пример описания такой переменной (Pt3Player_mode) можно посмотреть здесь:

• https://github.com/Oleg-N-Cher/XDev/.../C/Pt3Player.c

[PPC]

Не стОит ожидать здесь чуда. Всё-таки Си есть Си: косвенная адресация, прицел на рекурсию со всеми вытекающими.
[COLOR="silver"][SIZE=1]

Ну я совсем чуда и не ждал как-бы, видимо просто не совсем точно выразился. Я, скорее, хочу надеяться на наличие у ACK оптимизатора, который сможет эффекивно выбрасывать ненужное в определённых ситуациях. Один из частных примеров (отсутствие локальных данных, когда стек можно пихать навалом на фрейм вызова) я уже привёл. Это очень простая для оптимизатора ситуация, почему Manx её не сделал, мне до конца не ясно. Видимо, настолько в восторге были от факта что удалось портировать yacc парсер на 8080, что об остальном позабыли.

Понятно, что лучший способ нивелировать фрейм на вызываемой стороне - это 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.