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

[Barmaley_m]

Я думаю, надо объединять процедуры и данные, принадлежащие каждому оверлею, чтобы при каждом вызове или использовании указателя не было этих накладных расходов. Во времена 16-битного 8086-кода (дос, винда 3.11) в си и паскале были же разные типы вызовов и указателей - Near и Far. Первые были дешевыми в использовании, вторые - дорогими. И вообще, если данные лежат в другой странице - то может быть эффективнее скопировать их в общую область памяти, чем переключать страницы при доступе к каждому байту.

[Bolt]

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

Видимо, на портирование компилятора на спектрум придётся забить и делать только кросс.

[Andrew771]

Есть HiSoft Pascal, работает на Спектруме 48к, сделан еще в начале 80х.

[Bolt]

Нет xor. Целые только integer. Нет string. Нет процедурных типов. Нет приведения типов. Указатель на указатель нельзя. Не понял есть ли в нём получение указателя "@".
Зато можно делать так:

type item=record value:integer; next:^item; end;

Free Pascal на это ругается Error: Type "item" is not completely defined и я его в этом не понимаю.

Ну и, скорее всего, никакой оптимизации кода и "умной линковки" там нет. Но штука очень интересная.

p.s. Написал, а потом нашёл документацию к другим версиям. Стало ещё интересней.

[Andrew771]

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

[Bolt]

Нет, у меня если и будет, то нечто универсальное и кроссплатформенное, которое может скомпилировать само себя. Начиналось с кросс-компилятора для 8-битных микроконтроллеров.

[Advertiser]

[Andrew771]

тогда тебе можно заглянуть сюда: http://zx-pk.ru/showthread.php?t=18472

[Bolt]

Заглядывал. Олег не хочет заниматься генерацией машинного кода, я не хочу использовать прослойку в виде Си. Потом несложно будет приделать backend хоть для Си, хоть для LLVM.

[Barmaley_m]

Можно, конечно, разбирая исходник сразу код генерировать, я так уже делал - фигня получается

А кстати, так поступали почти все компиляторы времен 8-битных ЭВМ. Даже компилятор Microsoft Visual C++ "пожирает" структуры по мере обработки исходника. Об этом я читал в статье, где обосновывалась невозможность экспорта из него AST программы.

Я бы решал задачу по частям. Сначала сделал наиболее простым образом кросс-компилятор без ограничений по ресурсам. А потом уже пытался его оптимизировать по памяти, стремясь в конце концов уложиться в память ZX. Кстати, 140 килобайт исходника на Спектруме - это как-то многовато. Такой исходник даже сам по себе в 128К памяти не влезет. Большие программы обычно разбиваются на части с раздельной компиляцией, тогда памяти хватает.

[ZXMAK]

Кстати, 140 килобайт исходника на Спектруме - это как-то многовато. Такой исходник даже сам по себе в 128К памяти не влезет. Большие программы обычно разбиваются на части с раздельной компиляцией, тогда памяти хватает.

на мой взгляд 140 кб исходника это маленькая библиотечка