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

[Bolt]

Что в них нужно подогнать под твой компиль?

Скорее компилятор надо подогнать под поддержку того, что нужно этим программам...

Eurofoot и Topolog пока по объёму сгенерированного кода в 64 килобайта не уложатся.
Также там есть readln (которого у меня пока нет) и работа с файлами (которых у меня пока тоже нет).

Попробовал life.pas. Что изменил:
- uses заменил на {$i};
- в строке 36 и 37 изменил обращение к random;
- закомментировал строку 61 (из-за READKEY, его пока нет) и строку 69 (из-за оператора NOT, что-то с ним не так).
Собралось 12135 байт. Но естественно не запустилось. Надо компилятор и библиотеки доделывать.

[Andrew771]

в данных прогах обращение к файлам можно заменить загрузкой (инициализацией) значений в массивы.

[Bolt]

Тем более не поместится.

В life.pas в процедуре FORMIROV первый цикл (который I, J, 80x24) выполняется около минуты.
Потом запнулось из-за (не)случайных чисел.
Займусь этим на следующей неделе.

[Bolt]

Псевдокод, каждая команда которого состоит из нескольких команд ассемблера (пи-код) или одной? Пи-код, на мой взгляд, проще оптимизировать, т.к. команды более обобщены. Я писал в статье об этом, тут со стр.52

Прочитал статью. Интересно.
У меня всё, в принципе, так же, только пи-код другой. String в нём кажется совсем лишний, у меня всё что можно перебрасывается на библиотечные подпрограммы, деление тоже написано на Паскале (system_divmod.inc). Сделано это чтобы на начальном этапе не заморачиваться написанием деления, строк и прочего под новый процессор, а когда будет добавлено переопределение операторов - вообще станет штатной функцией компилятора.

Пи-код находится между синтаксическим деревом и инструкциями современных процессоров, которые заточены под языки высокого уровня. При подгонке пи-кода он всё больше похож на синтаксическое дерево и всё больше соответствует одной строке ассемблера какого-нибудь x86 или ARM. Поэтому и думаю что он мне не нужен.
Сейчас, если внимательно посмотреть на сгенерированный для Z80 код, можно увидеть что он как бы транслирован с 32-битного процессора. Почти так и есть.

[Shiny]

Интересно, а выполнение пи-кода будет ли быстрее, чем скомпилированная программа?

[Bolt]

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

[Advertiser]

[Bolt]

Версия 0.2

Исправления и дополнения:
- константы-массивы (массивы констант?), пока только массивы байтов;
- удаление неиспользуемых подпрограмм (smart linking);
- исправлено размещение многомерных массивов в памяти;
- исправлены ошибки работы с boolean;
- написан wrapper для некоторых подпрограмм из бибилиотеки ZX Like Pascal;
- адаптирована "demo_lode_runner.prg" из ZX Like Pascal;
- адаптирована life.pas.

"Умная линковка" позволяет писать на Паскале библиотеки любого размера, в код будут включены только используемые подпрограммы.

В архиве бинарники win32 и linux64, библиотеки, файлы-примеры .pas и .tap.

bmpascal_v0.2.zip

life.pas не зависла, она работает, 20 секунд идёт инициализация и 60 секунд на итерацию

[Bolt]

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

Планы: оператор case, чтобы запустить demo_z. Так как код пока не оптимизирован и бинарник с картинками имеет объём около 60 килобайт, запускать будем в режиме Spectrum +3, отключая ROM. Следующим пунктом будет поддержка константных выражений в описаниях констант и типов.
Пример:

const
   c=20;
   size=c*5+4;
type
   tArray=[1..size] of byte;

Потом будет большая работа по внутреннему "тюнингу", после чего, надеюсь, удастся избавиться от приведения всей арифметики к 32 битам, что должно немного уменьшить размер кода и значительно увеличить его скорость.

Ещё очень нужны inline-подпрограммы. Но без оптимизации кода они смысла не имеют.

[Andrew771]

Потом будет большая работа по внутреннему "тюнингу", после чего, надеюсь, удастся избавиться от приведения всей арифметики к 32 битам, что должно немного уменьшить размер кода и значительно увеличить его скорость.

Bolt, у тебя сейчас кодогенерация происходит в пи-код или сразу в ассемблер?
Для выражений рекомендуют в книжках сначала определить максимальный используемый числовой тип данных в выражении и уже отталкиваться от этого, какое выражение - 8-битное, 16-битное, 32-битное и т.д.
Т.е., если у тебя в выражении максимальный тип byte, то всё выражение рассчитывается по 8-битному алгоритму.
В ZX Like Pascal везде 16-битные выражения, только есть отдельные оптимизации, превращающие в 8-битные, где надо.

[Bolt]

Bolt, у тебя сейчас кодогенерация происходит в пи-код или сразу в ассемблер?

В пи-код. Который пока никак не оптимизируется и вообще, как мне кажется, лишний, я уже объяснял почему.

Для выражений рекомендуют в книжках сначала определить максимальный используемый числовой тип данных в выражении и уже отталкиваться от этого, какое выражение - 8-битное, 16-битное, 32-битное и т.д.

Об этом я тоже думал, но можно сделать ещё круче Попытался, запутался, не осилил, отложил на потом, приведя всё к 32 битам.
Надо синтаксическое дерево и пи-код в порядок привести. В них сейчас не всё корректно заполняется, в результате работает "на честном слове". Знак-беззнак до сих пор кое-где не работает. Или, например, выражение (@a+n)^ обрабатывается правильно, а (@a+n+m)^ теряет тип указателя. А если поверх всего этого ещё оптимизацию наложить - вообще потом концов не найдёшь.