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

Среди различных глупостей, которыми я занимаюсь, есть компилятор Паскаля. Задача: запустить его на Спектруме 48к или подобной платформе. Допустим, у этой платформы всё-таки есть некий дисковый/флэш накопитель с произвольным посекторным доступом.

В данный момент с использованием динамического распределения памяти на различные структуры при компиляции требуется раз в 50 больше памяти, чем занимают исходники. Понятно, что как ни уменьшай использование памяти, в 48 кБайтах компилятор работать не сможет. Как реализовать "виртуальную память" на несколько мегабайт? Самое простое что приходит на ум: хранить все структуры в одном временном файле на диске, а для ускорения работы потом прикрутить кеширование.

Другой вопрос: есть какие-то "серьёзные" компиляторы (не кросс-компиляторы) для Спектрума с поддержкой указателей, массивов, структур, объектов, "умной линковки" и прочего?

IMHO, если нужен серьёзный компилятор, используй cp/m. Cp/m на разных машинах предоставляет разный объём ОЗУ для программ (в т.ч. компилятора). Нужна такая машинка, которая предоставляет максимум ОЗУ, почти все 64 Кб, для этого она должна не держать в ОЗУ процессора видеопамять. По этой причине многие разновидности cp/m на базе спектрума не подходят, потому что они держат видеоОЗУ в начале третьего (если считать с 0) банка, и поэтому не могут предоставить программам более 48 кб. Сюда относятся скорпион, хоббит. Про профи и атм не знаю, как там реализовано...

А какие компиляторы под CP/M есть?
Но всё равно мне это просто чтобы посмотреть что бывает. Речь идёт не о запуске просто какого-то компилятора, а о написании собственного, который мог бы запуститься и на 32 килобайтах, и не только на Z80.

Не, я тут прикинул размеры, а ещё оказалось что FPC как-то интересно память распределяет... В общем, когда мой компилятор сможет собирать сам себя и будет кодогенератор для Z80, тогда и надо будет пытаться запихнуть его в 32к.

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

Но решить задачу всеже можно, главная предпосылка к решению это то что в каждый единичный момент времени программа работает всего лишь с 1-й процедурой которая манипулирует только к ней относящимися структурами данных. А это значит что для speccy48 можно писать процедуры которые вместе с ихними данными занимают: (49152-6912-стэк-диспечер) байтов памяти. Стэк может быть и 1кб а диспечер должен уметь делать замену "текущей" процедуры на "вызываемую" или на "вызвавшую". Понятное дело что "вызовы" и "возвраты" в такой схеме будут тормозить выполнение алгоритма по сравнению с работой того же кода в "бесконечном адресном пространстве", кроме того алгоритмы работы с "длинными массивами" или рекурсию прийдется отправить на мусорку. Но зато такой способ не потребует больше НИКОГДА расширять адресное пространство процессора (хотя если адресное пространство УЖЕ 64bit... то следующего "расширения" ждать прийдется еще очень долго)

То есть грузить в память по одной процедуре/функции? В этом что-то есть. И даже рекурсию в мусорку можно не отправлять. Можно сделать ещё круче: замутить виртуальную машину, саму машину в RAM, а память виртуальной машины на диске.

У меня проблема не в размере кода, а в размере данных. Препроцессор и лексический анализатор уже почти отдельная программа, думаю, можно и дальше компилятор делить на отдельные процессы, которые будут обмениваться данными через файлы. Проблема в том, что при работе получается много структур, которые хранить в RAM негде, а на диске медленно и неудобно. Перехватил в FPC GetMem() для подсчёта расхода памяти, получилось где-то в 50-100 раз больше исходника. То есть если сам компилятор сейчас килобайт 100, то ему для компиляции самого себя потребуется мегабайт 10, а то и больше, для хранения типов, идентификаторов и прочего.

В общем, как я уже написал, надо сначала разобраться с алгоритмами, пусть даже им потребуется "бесконечное адресное пространство". А потом может и вообще отказаться от идеи запуска в 32 килобайтах.

Цитата:

---

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

А какие компиляторы под CP/M есть?

---

К примеру: http://www.cpm.z80.de/binary.html Но это далеко не всё, что существует под cp/m...

Цитата:

---

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

А какие компиляторы под CP/M есть?

---

Мне очень понравился Turbo Pascal 3.0 под CP/M. Быстрая компиляция, проблем с нехваткой памяти не было. Легок в использовании.

Типа опрос.
1. Какие есть компиляторы Паскаля, работающие прямо на Спектруме? Что в них нравится и что не нравится?
2. Нужен ли ещё один такой компилятор? :)
3. Если нужен, то какой - со всеми прибамбасами, в том числе с поддержкой модулей (units), или так, сотню-другую строк скомпилировать?
4. Или запилить кросс-компилятор под Windows/Linux и не заморачиваться?

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

Код:

---

LD HL,procedure_address
CALL MANAGER_CALL

---

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

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

Чтобы не портить регистры, можно использовать такой подход:

Код:

---

CALL MANAGER_CALL
DW procedure_addr
DB procedure_page

---

Менеджер посмотрит откуда произошел вызов и прочитает адрес процедуры и номер страницы памяти. А при возврате добавит к значению в стеке 3, чтобы управление вернулось на следующую инструкцию. Минус - такой код тяжелее будет отлаживать в отладчике, т.к. DW и DB будут рассматриваться дизассемблером как инструкции.
Тут есть простор для фантазии. Можно адрес процедуры и номер страницы загонять в стек перед вызовом. Правда все это увеличивает размер кода производящего вызов.

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