Компилятор языка Паскаль - планы на будущее

[Error404]

AlCo предлагает разработать Оберон-компилятор чтобы работал на самом Спеке, я пока отбрыкиваюсь, вроде странная задачка.

Почему нет?
В CP/M есть отличный компилятор ANSI C - Hitech C. Сделайте опять же нативный Z80-транслятор с Оберона на С.

Если не нравится Hitech C (например из-за того что он для CP/M, хотя Алоне все равно для АТМ пишет же), есть несколько компиляторов С в исходниках. Да и на спеке наверное есть С-компилеры (правда, из 90-х помнится что спековские компилеры были слабоваты, возможно из-за отсутствия нормальной ОС)

---------- Post added at 12:32 ---------- Previous post was at 12:21 ----------

Vadim, я когда начал писать компилятор тоже с теорией компиляции не был знаком. Была мысль прикрутить к FPC нужный кодогенератор, но FPC со стороны исходников мне не очень понравился. Я решил пойти по пути написания компилятора с нуля.

Доработать Turbo Pascal под CP/M? А толку? Даже если разобраться в декомпилированных исходниках и умудриться доработать, то это так и останется компилятор, "прибитый гвоздями" к конкретному процессору и ОС.

Компиляторы компиляторами, а смотрели вы например трансляторы (не интерпретаторы!)? Например, Innerfuse Pascal Script 3? Это скриптовый Object Pascal движок вида "Дельфи внутри Дельфи", на входе скрипт (т.е. программа на паскале), на выходе некий байт-код для executar-а (модуля-исполнителя байткода). Есть "дизассемблер байт-кода". Лет двенадцать назад я был просто фанатом IPS3 (версия 3 - последняя Free OpenSource, остальные платные), писал на нем программы в тысячи строк. Работало быстро и без косяков, все в исходниках, язык - практически полный Object Pascal.

[Advertiser]

[Bolt]

Компиляторы компиляторами, а смотрели вы например трансляторы (не интерпретаторы!)? Например, Innerfuse Pascal Script 3? Это скриптовый Object Pascal движок вида "Дельфи внутри Дельфи"...

Нет, не смотрел, но в курсе, что такое есть.
По описанию это вообще не то, что мне нужно.

[Sayman]

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

[Error404]

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

lex/yacc может быть? На них парсеры для чего угодно делали, от ЯВУ до игрушек диалоговых.
Книжек про них не знаю, но статей прогугливается очень много.

[Barmaley_m]

по написанию парсеров?

Попробуй GNU Bison. Бесплатно и сердито. Правда, я ни разу на нем ничего не делал, там надо осваивать, доки читать.

просто конфиги получаются у меня навороченные,

Для конфигов лучше всего задействовать стандартный формат типа XML или JSON. Парсеров полно, качай и пользуйся.

[Sayman]

надо было сразу пояснить видимо. я не использую сейчас кое-либо яву. конфиги которые нужно распарсить уже существуют в определённом формате в оригинале на ПЦ, а мне под спринтера нужно тоже самое. по сути, конфиги имеют вид стандартных ini файлов с секциями типа [section] и далее строки с параметрами. есть секции вида [sect type n], где n какое-то целое число. и т.д. нашёл несколько исходников ini парсеров. но они все , конечно, на си. уже глаза в кучу...

[Error404]

Попробуй GNU Bison. Бесплатно и сердито. Правда, я ни разу на нем ничего не делал, там надо осваивать, доки читать.

Бизон это и есть yacc, переписанный линупсовыми "улучшайзерами". В комплекте с бизоном обычно используют flex (аналог lex)

[Alex Rider]

Наверняка ведь парсишь эти ini'шники в структуры. Напиши на PC утилиту, которая будет парсить их в двоичное представление этих структур, а в Спринтер загружай уже готовый к употреблению файл.

[Andrew771]

И еще индуктивность переменных тоже никак не учитываю. Так что, если встретится например:
Код:
for i:=1 to 100 do
a[i]:=i;
то на каждой итерации цикла будет рассчитываться заново адрес в памяти для ячейки a[i], хотя можно было всего лишь прибавить смещение к предыдущей ячейке. Здесь нужно уже анализировать весь поток от начала до конца цикла, а вдруг еще внутри есть другие циклы и ветвления. Пока не стал заморачиваться.

Кстати, заметил в Delphi (в Паскале вроде нет), что внутри цикла for и даже внутри него во вложенных циклах запрещено изменять счетчик цикла. Т.е. получается, что компилятору проще оптимизировать индуктивные переменные (у нас a[i]), не надо анализировать изменение где-то глубоко внутри цикла счетчик i. Ну нинаю, изменение счетчика внутри цикла - дурной тон, но в принципе не должен быть запрещен, как и оператор goto. Ну просто иногда позарез надо его менять (или переходить), иначе логика получается навороченной с кучей условий со многими флагами. Я такое не запретил у себя. Пусть лучше компиль мучается с оптимизацией, чем программист на нем.

[Bolt]

А по-моему правильное ограничение, это не тот цикл, в котором можно прыгать туда-сюда. Сказано 10 раз, значит 10. При необходимости можно воспользоваться циклами while, repeat, или выйти из for при помощи break.