Перепрём Паскалечку на язык родных о'Син

[spamsink]

 Невзирая на сильное пересечение аудиторий разных бэсмовских форумов, напишу и здесь: проект https://github.com/leobru/pas2c-metamorph посвящен переделке компилятора Паскаль-Монитор в компилятор Си.

Ограничения, вызванные спецификой архитектуры:

• Разрядность целых - 48 бит, но работающий диапазон значений для арифметических операций - 41. Сравнение "меньше 0" проверяет не старший бит, а 41-й. 
• Для unsigned более или менее эффективными полноразрядными могут быть только сложение и вычитание; желательны два режима: быстрый с использованием СЛЦ (ARX) невзирая на риск циклического переноса, и аккуратное сложение по модулю 2^48. Умножение и деление будут, соответственно, медленным и безумно медленным.
• Применение сдвигов влево к целым числам может приводить к UB (полезна будет опция явного зануления 48-42 разрядов).
• Т. к. стек растет вверх, компиляция vararg functions потребует двух frame registers.
• Объявление register будет полезно только для словных указателей и (в будущем) для "unsigned short". Регистровый unsigned short будет 15-битный. 

Ограничения, вызванные спецификой платформы/системы программирования:

• При раздельной компиляции для глобальных переменных linkage по умолчанию будет static. Это позволит более эффективное обращение к этим переменным с помощью базового регистра. Глобальные переменные, требующие обращения из нескольких файлов, должны будут быть объявлены как  extern везде и быть одной длины (ср. фортрановский common block).
• У main (поначалу?) не будет параметров. 
• Работа с файлами будет рудиментарная. 
• Последовательность байтов в слове будет для совместимости - от старшего к младшему.
• Пребразование между (int*) и (char*) - номинальное. *(int*)charPtr обратится к слову, где-то в котором находится указываемый символ. Обращение *(char*)intPtr, если intPtr не был получен из char*, пойдёт в никуда (прочитается 0, запись не приведет к изменению памяти). 
• Использование вложенных функций, минимизируя необходимость передавать параметры, экономит много памяти. Это, возможно, стоит сохранить. 

Если что забыл, буду добавлять.

 Что пока не сделано

Comments

[vak]

Про charPtr неясно. Лучше скажи, в каких битах лежит адрес, а в каких смещение.

[spamsink]

Всё будет так, как мы знаем: адрес в младших битах для МОД, смещение в старших для СД. Инкремент-декремент с помощью СЛЦ оказывается довольно дешевым по количеству команд (хотя на БЭСМ-6, возможно, неэффективным из-за длинных переносов).
Вычитание указателей превращается в сложную процедуру, но это довольно редкая операция.

[vak]

Ага, хорошо.
У меня сохранился текст дипломной работы про порт PCC на Эльбрус-Б. Там описан в том числе выбор представления указателей. Надо будет переформатировать и выложить. Оказывается, groff плохо понимает кодировку UTF-8.

[x86128]

Т. к. стек растет вверх, компиляция vararg functions потребует двух frame registers.

Интересно почему так?

[spamsink]

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

[vak]

Можно начать с моих старых csv и cret.

https://github.com/besm6/pcc/blob/master/pcc-libs/csu/elbrous-b/csv.s

[spamsink]

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

Опять же, поскольку у нас нынче строгий ANSI C, в передаче количества параметров нет необходимости, кроме как для varargs-процедур, объявленных с ...

[x86128]

хитро!

[spamsink]

В принципе, в проекте есть вещи, которые можно делать параллельно и независимо, если распределить фронты работ.

Хотя, конечно, я понимаю, что писать хоть на машинно-специфичном Паскале, хоть на столь же машинно-специфичной меняющейся каждый день безумной смеси Паскаля и Си охотников мало.

[vak]

Я когда-то пробовал проделать аналогичный фокус: компилятор BCPL превратить в компилятор языка B. При этом компилятор написан на самом себе, как обычно. Каждая итерация правок выглядела так:

1. Изменяем синтаксис входного языка, чтобы стало ближе к B и дальше от BCPL.

2. Добиваемся, чтобы откомпилировался простой тест новой фичи.

3. Изменяем исходник самого компилятора, чтобы его можно было откомпилировать (самим собой).

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

И так десять тысяч вёдер. Трудоёмко получалось. В конце концов кто-то добыл и выложил родные исходники компилятора B от Томпсона. Необходимость в моих мучениях отпала.

[spamsink]

Ну да, тривиальные синтаксические изменения я так и делаю, с той лишь разницей, что у меня два компилятора.

Пока была преимущественно дешевая косметика. Дальше надо будет выносить вычисление константных выражений из генератора кода, переписывать парсер объявления переменных и типов, и парсер выражений, приписывать генератор кода для побочных эффектов, и т. п.

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

[vak]

Подумалось: если прикидывать в перспективе перенос Юникса на БЭСМ-6, скажем NetBSD, то такой Си компилятор не будет в помощь. Перспективнее смотреть на GCC тогда уж. Пусть и старой версии 2.95, но ядро он сможет обработать.

[spamsink]

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

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

[vak]

Дело даже не в оптимизации, а просто не сможет (1) скушать исходник ядра NetBSD и (2) слинковать нужный бинарник.

[spamsink]

Понятное дело, что дубнинский загрузчик будет неадекватен. Я-то делаю, чтобы в МС "Дубна" можно было сказать, грубо говоря,

*С
 программа на С
*EXECUTE

И не сильно более того.

[vak]

Вполне благородная задача сама по себе, совершенно согласен.

[spamsink]

К сожалению, под dubna у меня процесс не заработал. Возможно, что-то не в порядке в библиотеке. Пока пользуюсь dispak; вернёшься - будем разбираться, как добавлять к dubna дополнительное системное ПО.

[x86128]

Есть на примете где можно почитать как делали препроцессоры для Си?

С компилятором понятно какие там "вызовы" и как его можно сделать. Вот с препроцессором как-то не очень понятно, по спецификации можно сказать как оно должно быть, а вот по реализации не совсем ясно.

[vak]

Не уверен, что найдётся где почитать про препроцессоры. Делались они как-то наобум. Качественных реализаций мало. Десять лет назад alexfru делал компилятор SmallerC для RetroBSD и решал проблему компактного надёжного препроцессора. Он остановился на этой реализации:

https://github.com/RetroBSD/retrobsd/tree/master/src/cmd/cpp

[x86128]

Спасибо! Посмотрю

[iyak2]

Кажется, есть еще препроцессор встроенный в cc(c command), см. функции expand(),getline() в https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/cc.c или https://www.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c . Но там древнее или иное написание, решетка(#) через пробел. На первый взгляд, очень похоже, что так.

P.S. Еще про раннее упоминание препроцессора Си. Немного написано в C reference manual(Dennis Ritchie,1975) в главе 12, и в Programming in C − A Tutorial(Brian W. Kernighan). Но там, кажись, изначально было только #define и #include.

[x86128]

вот такой талмуд нашелся https://gcc.gnu.org/onlinedocs/cpp.pdf

[iyak2]

Впечатляет. Для тех, кто решит покопаться внутри GCC, наверное, могут попрощаться с месяцами и даже годами своей жизни, если сразу занырнут не поискав путь от простого к сложному. Мое впечатление и предубеждение даже от ранних версий, подкрепляемые словами мэйнтейнера GCC на OpenBSD Mark Espie (https://habr.com/ru/articles/31277/), что слишком он замудренный.

Цитата Mark Espie: "...(3) Весь дизайн GCC извращён настолько, что никто не может даже выделить front-end и back-end компилятора (от меня: истинная правда, помниться, как мы занимались с gcc любовью в попытках научить понимать его нерегистровые архитектуры). Он корявый, начиная с дизайна (broken by design), так как GPL'ный народ боится, что коммерческие организации смогут украсть backend или frontend и прицепить их к закрытым языкам или кодогенераторам (от меня: странный вывод, однако). Возможно, это правда. Но это не позволяет создавать интересные инструменты, такие как анализаторы промежуточного кода. И это так же не позволяет использовать backend'ы для старых архитектур c новыми компиляторами."
Начать с GCC, это путь не для человека, а для хорошо организованных групп программистов.

Путь же для человека - это проторенный путь от мэтров(Ритчи, Томпсон). Их подход, неявный, это то, что один человек может вполне освоить за разумное время все то, что они насоздавали. Это мнение.

Например, на освоение и переписывание Early C(last1120, c0) под MSDOS 16 bit вполне можно обойтись 3 месяцами. На генератор кода для выражений (с1) пока незнаю. Но посмотрим. СС(last1120) изучается за пару дней. Но все еще зависит от здоровья, психологического состояния, интеллекта, конечно.

[vak]

Хорошая документация.