Рапределение памяти при работе компилятора ЯВУ

[James DiGreze]

Сложно сказать насчёт стандартности, но более ли менее распространённая система iSDOS позволяет работать с винтами и довольно большими разделами (~30Mb). Система неплохо документирована. Правда там памяти под исполняемый код не густо, но можно работать с оверлеями и RAM-диском (должно быть ОЗУ 128К или более).

[Advertiser]

[Andrew771]

У меня проблема не в размере кода, а в размере данных, которые на части пока плохо делятся. Не исключаю вариант, что я не понимаю что-то очень простое.
140 килобайт исходника на данный момент при обработке дают в общей сложности 3 мегабайта структур, и это ещё не все задумки реализованы. Можно, конечно, разбирая исходник сразу код генерировать, я так уже делал - фигня получается

До сих пор не вкурю, какие-такие огромные данные ты собираешь хранить? Дерево разбора? Библиотеки процедур?
У меня в создаваемом компиляторе в памяти формируется только таблица констант, переменных и имен процедур, с несколькими параметрами. Занимает копейки. А код генерируется по-ходу. Но можно генерировать промежуточный код для последующей оптимизации. Промежуточный код тоже занимает немного, по-сути каждая команда байтов по 3-5 (если писать на Спекки).

[bigral]

Правда там памяти под исполняемый код не густо, но можно работать с оверлеями и RAM-диском (должно быть ОЗУ 128К или более).

вот бы глянуть пример работы с оверлеем

[James DiGreze]

Увы и ах, своего ничего не осталось после трагической гибели hdd с iSDOS.
Где-то в недрах тырнета должны попадаться обрывки документации, по крайней мере когда-то давно мне попадались.

[Bolt]

До сих пор не вкурю, какие-такие огромные данные ты собираешь хранить? Дерево разбора? Библиотеки процедур?
У меня в создаваемом компиляторе в памяти формируется только таблица констант, переменных и имен процедур, с несколькими параметрами. Занимает копейки. А код генерируется по-ходу.

Да, в основном это дерево разбора. Но его можно сократить на треть и больше, надо только подумать к чему приведёт удаление некоторых полей. Есть и другие мысли по поводу оптимизации дерева, в том числе использование промежуточного кода. Таблица имён действительно занимает копейки, килобайт 100, но это полная, хранить можно только видимые.

Кроме констант, переменных и процедур есть ещё таблица типов. Andrew771, какие типы поддерживает или будет поддерживать создаваемый компилятор? Указатели, массивы, структуры, указатели на структуры, многомерные массивы указателей на структуры...? У меня заложена поддержка всего этого, а ещё поддержка модулей, процедурных и файловых типов, полиморфных и inline-процедур, переопределение операторов, умная линковка, условная компиляция {$IFDEF}...{$ENDIF}, и сам уже не помню что ещё Всё это требует памяти. К генерации кода по ходу разбора может потом и вернусь, но только для того чтобы всё-таки запустить это в 64 килобайтах

[Максагор]

iSDOS позволяет работать с винтами и довольно большими разделами (~30Mb).

Поправочка - 16Мб

Увы и ах, своего ничего не осталось после трагической гибели hdd с iSDOS.
Где-то в недрах тырнета должны попадаться обрывки документации, по крайней мере когда-то давно мне попадались.

А что было и что погибло?

[Andrew771]

Andrew771, какие типы поддерживает или будет поддерживать создаваемый компилятор? Указатели, массивы, структуры, указатели на структуры, многомерные массивы указателей на структуры...? У меня заложена поддержка всего этого, а ещё поддержка модулей, процедурных и файловых типов, полиморфных и inline-процедур, переопределение операторов, умная линковка, условная компиляция {$IFDEF}...{$ENDIF}, и сам уже не помню что ещё Всё это требует памяти. К генерации кода по ходу разбора может потом и вернусь, но только для того чтобы всё-таки запустить это в 64 килобайтах

Поддерживаются только типы Byte, Word, String, а также одномерные и двумерные массивы из них. Почему так - вот моя позиция. У тебя-то конечно всё по-максимуму поддерживается. Но нужно ли это на Спектруме?

[Bolt]

На Спектруме может и не нужно, а вообще пригодится.

[Bolt]

Немного статистики.

4900 строк, 127000 символов.
17500 токенов, 60000 символов. (т.е. комментарии составляют половину текста)
900 идентификаторов, около 100 килобайт для хранения.
8200 узлов синтаксического дерева, около 600 килобайт для хранения.

Не могу понять одну вещь. Почему так? Это особенность FPC или так и должно быть?

const
   c1:array [1..10] of byte=(0,1,2,3,4,5,6,7,8,9);
   c2:string='qwe';
   c3='qwe';
var
   p:pointer;
begin
   p:=@c1; // Ok
   p:=@c2; // Ok
   p:=@c3; // Error: Can't take the address of constant expressions
end.

[Andrew771]

Не могу понять одну вещь. Почему так? Это особенность FPC или так и должно быть?

фиг знает. Видать, не нравится нетипизированная константа.

---------- Post added at 09:32 ---------- Previous post was at 09:30 ----------

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