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

[Bolt]

Кто-то называет выбранный мною подход трансляции Оберона в Си читерским, но я не верю в разработку кодогенератора приемлемого качества одной персоной на голом энтузиазме за разумный срок.

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

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

[Advertiser]

[bigral]

У меня цель - сборка под разные платформы, ...

Как по мне дак самое главное в этом магическом "разные платформы" именно адресуемое пространство, сегодня 99.999% литературы по алгоритмам предпологают бесконечное адресное пространство, а это значит что для запуска их нужен процессор у которого отсутствует лимит адресов (такого процессора нету, но наблюдается тенденция увеличения битности адреса в процессорах по мере возрастания размера обрабатываемых данных).

Короче, отвечая в лоб, если хочется чтобы твой компилер был одинаковый для всех, то сначала уровняй всех. Например напиши для всех 1 виртуальную машину, и компилер пиши для этой машины. Ну и тут вопрос скорости, он вторичный в плане теории, но первичный на практике, так как мы уже видели и запуск ARM linux на avr 8bit и запуск x86 windows3.0 на mcs-51, но тормоза свели эти проекты в область чисто академического интереса.

Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m

[Bolt]

Как по мне дак самое главное в этом магическом "разные платформы" именно адресуемое пространство, сегодня 99.999% литературы по алгоритмам предпологают бесконечное адресное пространство ...
Короче, отвечая в лоб, если хочется чтобы твой компилер был одинаковый для всех, то сначала уровняй всех. Например напиши для всех 1 виртуальную машину, и компилер пиши для этой машины.

Для меня в этом магическом "разные платформы" главное - переносимость на уровне исходного кода. Язык высокого уровня и есть то, что позволяет писать, не задумываясь о том, на чём это будет запускаться.
Виртуальная машина тоже позволяет абстрагироваться от конкретного процессора. Создать такую виртуальную машину и писать программы на ассемблере для неё я уже пробовал, следующим этапом стал Паскаль. Который в том числе сможет генерировать код для виртуальной машины.

Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m

Нет, не пагубна. Практичность/академичность действий понятие относительное. Например, вычисление тройных интегралов и числа Пи до 100-го знака на 8-битных процессорах может использоваться для тестирования процессоров и математических библиотек. Вполне практическое применение.
Мне интересна работа и устройство компиляторов и процессоров, Andrew771 делает инструмент под конкретную платформу, Oleg N. Cher'у нравится Оберон, кто-то запускает ARM Linux на 8-битных процессорах, а кто-то может заняться добавлением функций в дизассемблированную программу или написанием кодогенератора для FPC/GCC/etc.

В моем компиле точно есть (дописываю на днях):
...

Это всё на уровне псевдокода? В момент генерации или отдельным проходом? Где и как при этом хранится псевдокод?

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

[Bolt]

Отсюда вопрос - не пагубна ли сама идея: "сборка под разные платформы"? смысла практического ведь НЕТУ? Но вот под конкретную платформу сделать хороший инструмент, нужный людям! куда как более востребованное занятие, не зря народ жаждит update-a borland pascal под cp/m

А вот объясните мне, в чём фишка (сложность?) Паскаля под CP/M? В его принципиальном отсутствии? Он действительно так нужен? Его сложно написать? Почему? CP/M какая-то особенная?

[Andrew771]

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

Видимо, оптимизированная компиляция. Другое дело, какой уровень оптимизации приемлем для Спека. В моем компиле точно есть (дописываю на днях):
- свёртка констант;
- упрощение выражений перекидыванием операндов из стека в регистры (удаление лишних push/pop);
- быстрое умножение и деление на числа степени 2, а также быстрое умножение на некоторые часто используемые числа;
- удаление повторных присваиваний и чтений переменных;
- удаление повторных расчетов индексов массива.

[Kakos_nonos]

запуск x86 windows3.0 на mcs-51

Можно по-подробнее про это? Стало интересно.

[bigral]

Можно по-подробнее про это? Стало интересно.

http://www.fleasystems.com/flea86.html

[esl]

JFYI
дизассемблед и фиксед версия турбо паскаля

http://www.cirsovius.de/CPM/Projekte.../TURBO-en.html

там вообще у чувака КУЧА разных рабочих дасмов.

[Andrew771]

Это всё на уровне псевдокода?

Да.

В момент генерации или отдельным проходом?

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

Где и как при этом хранится псевдокод?

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

[Bolt]

Да, вот именно так у меня и было. Работало. Но таким способом получается хороший код для простых процессоров, а, например, для x86 или ARM с их заковыристыми адресациями такой метод просто не видит операции, они "рассыпаются" в псевдокоде. Или же программу надо писать "простыми словами", а не вот так

if node^.nodeargs[i]^.resulttype<>nil then
	typ1:=node^.nodeargs[i]^.resulttype^
else begin
	typ1.flags:=node^.nodeargs[i]^.resulttypeflag;
	typ1.size:=4;
end;

Надо что-то изменить в структуре псевдокода, пока не пойму что.

---------- Post added at 00:11 ---------- Previous post was at 00:01 ----------

Кодогенератор FPC вообще жжот, для надёжности проверяет индекс массива два раза и копирует один байт при помощи movsb:

# [210] typ1.flags:=node^.nodeargs[i]^.resulttypeflag;

        movzbl  -860(%ebp),%eax
        decl    %eax
        cmpl    $9,%eax
        jbe     .Lj3685
        call    FPC_RANGEERROR
.Lj3685:

        movzbl  -860(%ebp),%eax
        movl    %eax,%edx
        decl    %eax
        cmpl    $9,%eax
        jbe     .Lj3686
        call    FPC_RANGEERROR
.Lj3686:

        movl    -884(%ebp),%ecx
        movl    12(%ecx,%edx,4),%eax
        leal    -40(%ebp),%edi
        leal    69(%eax),%esi
        cld
        movsb