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

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

Цитата:

---

Сообщение от Bolt

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

---

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

Цитата:

---

Сообщение от James DiGreze

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

---

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

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

Цитата:

---

Сообщение от Andrew771

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

---

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

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

Цитата:

---

Сообщение от James DiGreze

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

---

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

Цитата:

---

Сообщение от James DiGreze

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

---

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

Цитата:

---

Сообщение от Bolt

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

---

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

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

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

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.

---

Цитата:

---

Сообщение от Bolt

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

---

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

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

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