OberonCore

В исходных текстах классического Оберона, в модуле OBC, есть константа MaxExts = 7. Если я правильно понимаю она задаёт допустимое число расширения типа. В книге "проект Оберон", об этом косвенно тоже упоминается (стр. 257) "base таблица указателей на дескрипторы основных (базовых) типов (7 элементов)".

Кто нибудь может пояснить почему так сделано? т.е. почему не 20-ть, например? А так же интересует зачем это ограничение? С чем это связано?

Расширение типа это одно из новшеств Оберона, подразумевается, что программа может "не ограничено" расти. Как же ей расти тогда. Кроме точной информации приветсвуються любые теории, т.к. нужно разобраться в вопросе.

Важная особенность реализации Оберона - быстрая проверка типа (IS/WITH).
Это достигается тем, что каждый дескриптор типа хранит таблицу всех своих базовых типов.

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

Но это приводит к тому, что в дескрипторе типа должен быть массив ARRAY maxExt OF Type.
Дальше идёт соображение банально экономии памяти.

В КП/ББ сделана глубина до 16.

Реально на практике редко бывает глубже 2-4. 5-6 - исключения в сложных приложениях.

Особенно учитывая принципы современной архитектуры, где используется расширение только от ABSTRACT (тогда у вас 1-3 уровня ABSTRACT и скрытая реализация, от которой уже расширений нет).

Странно, что вам показалось мало.

Спасибо за ответ. Если в реальных задачах число расширений не превышает 3,4 тогда понятно. Я такой статистики не знал. Ещё раз спасибо.

Так не количество расширений, а глубина! Это же разные вещи.
Хранится список "вверх" - к базовым типам. А не список расширений.

Если не сложно поясните пожалуйста.
Вот есть некий тип T, который я расширяю. Он для моего типа базовый, а мой тип это первое расширение в глубину.
Если я или кто то расширит тип T снова, то это будет "количество" расширений. А если я буду расширять свой тип ещё раз, то увеличу глубину до двух.
Все расширения типа T будут иметь в дескрипторе одну (из семи) ссылок на базовый тип, а расширение моего типа будет иметь две записи базовые, тип T и моё расширение (первое) типа T.

Вроде правильно понял?

Всё правильно!

Есть ещё вопрос, проясните пожалуйста.
В русском варианте книги написано (стр. 352)
"Дескриптор типа содержит - в дополнение к информации, сохраняемой для использования сборщиком мусора, - таблицу тэгов всех основных типов. На пример, если тип R2 - это расширение R1, которое является расширением R0, то дескриптор R2 содержит тэги R1 и R0, как показано на рис. 12.4. Таблица имеет 7 фиксированных входов."
В английском варианте написано 3 фиксированных входа, что сохранилось на рисунке. Вероятно есть ещё какой то вариант текста или переводчик сверялся с текстом программы.
Тогда почему не поменяли рисунок? Наверное проглядели.
Дальше, на рисунке дескриптор типа R0 не имеет базовых типов (что правильно т.к. он сам по себе тип, свой собственный). Дескриптор R1 имеет одну ссылку на базовый тип (подразумевается R0), которая указывает, почему то, на него самого. Дескриптор R2 имеет две записи. Первая, ссылка на R1, вторая снова на самого себя (хотя должна быть на R0).
Вопрос, это просто опечатки, или я чего то не понял?

Большую часть текста без картинки сложно ответить.

Последний же вопрос - да, так и должно быть, чтобы тип стоял в списке своих же базовых. Это позволяет нужные сравнения для IS проделывать и т.п.

Картинки русского и английского вариантов с рисунком.

Входы в таблицу... пока не перевел мысленно на английский (entries), не понял, что речь о строках, элементах. И правда, на картинке Entries.

Вопрос в стрелках на рисунке. Если я правильно понял, то от R2 должно быть три стрелки. Одна на себя, вторая на R1, третья на R0. От R1 две стрелки, одна на себя, вторая на R0. От R0 одна на себя.
То что в дескрипторе не семь позиций для базовых типов а три, более менее понятно. В английском тексте было три, в русский текст перекочевал рисунок с тремя.

Проверка типа сравнивает адреса описателей (дескрипторов) типа. У переменной есть скрытый префикс (он же адрес описателя), про тип компилятор всё знает. По моему как раз для p IS T смотреть содержимое описателя (дескриптора) типа не нужно. Наверное для WITH это надо. Что бы одинаково обрабатывать весь список расширений, без исключений.

Нет, для конструкций языка, т.е. IS , WITH и охрана типа, таблица базовых типов в описателе (дескрипторе) типа не нужна. Все три оператора, это одна процедура. Так как все молчат напишу свои предположения, т.к. вроде бы появилась ясность в этом вопросе. Таблица указателей на базовые типы нужна исключительно для сборщика мусора. Тип Т0 из модуля М0, может расширятся в модуле М1 типом Т1. Потом модуль М0 может быть выгружен. Адреса описателей типа хранятся в области констант модуля, описатели это элементы кучи, но их утилизировать нельзя, пока есть модуль М1. Так как описатели не дублируются, то для информации о типе Т1, нужен описатель Т0. Для этого каждый описатель и содержит таблицу базовых типов. Если я не прав, поправляйте.
Насколько мне известно, книги "Построение компиляторов" и "Проект Оберон" созданы из конспектов лекций, многие тонкости реализации не очевидны. Голову можно сломать. Но на безрыбье и рак рыба.

Забыл добавить, если я всё правильно понял, то наличие в таблице базовых типов самого себя - опечатка. Тем более что в тексте "то дескриптор R2 содержит тэги R1 и R0, как показано на рис.", явно сказано, только R1 и R0. Ни каких R2.

TYPE
B = POINTER TO RECORD END;
E1 = POINTER TO RECORD (B) END;
E2 = POINTER TO RECORD (E1) END;

VAR a: B; e2: E2;
...
NEW(e2);
a := e2;
...
IF a IS E1

С таблицей базовых типов в паспорте (описателе) типа этот IS сводится, условно, к
Type(a).base[Type(E1).depth] = Type(E1)
А как вы предполагаете реализовать вот этот IS Без таблицы базовых типов?

Я не настолько хорошо разбираюсь в этом вопросе, что бы давать ответы. Наоборот, что бы разобраться, я пытаюсь тут спросить. Прошу иметь это в виду. На ваш вопрос могу ответить, процитировав Вирта из книги. "Проект Оберон..." стр. 353.
IF p IS P2 THEN (* р - указатель на запись т.е. адрес, по смещению (допустим) -4 скрытый префикс - адрес описателя (дескриптора) типа, допустим 100 *)
Т.е. по факту для проверки типа мне нужно сравнить этот адрес (100) с адресом описателя P2.
Вот код который он приводит
58 MOVD -4 (-8 (SB)), R7
62 CMPD 8(R7), 8(SB)
66 BNE 7
........
73 EXIT 00

SB - это указатель начала области констант, перед ним область данных. -4(-8(SB)) - минус 8 смещение до переменной р, минус 4 это скрытый префикс - читай адрес описателя - читай 100. Записывает его в R7.
Дальше сравнение описателя типа P2 (он третий в примере , 0, 4, 8 ) поэтому восьмёрка смещение. Далее он !!! действительно смотрит в таблицу ( почему такое смещение мне не ясно), хотя адрес описателя в регистре R7 уже есть. Почему? Мне не понятно, поэтому и спрашиваю.
Например CMPD R7, 8(SB) было бы достаточно, для сравнения адреса 100 (переменная p), с адресом описателя P2.
Если вы сможете объяснить зачем имея адрес в скрытом префиксе его дублируют в таблице базовых типов (даже не логично, как он может сам для себя быть базовым), я был бы вам очень благодарен.
С уважением.

В вашем примере я бы взял скрытый префикс переменной, на которую указывает а. Это должен быть адрес описателя типа, остаётся сравнить его с адресом описателя типа Е1. Адреса описателей типа находятся в модуле в области констант. Как то так. Повторюсь я не очень в теме.

Давайте проясним: в моем примере верно следующее:
(a IS E1) = TRUE
при этом фактический тип а - E2, а формальный тип а - B (обычно их называют динамическим и статическим, но мне больше нравится формальный и фактический).

Поэтому просто сравнить адрес описателя a с адресом описателя E1 - можно, но это не IS, а точное соответствие, т.е. утверждение "переменная а указывает на значение фактического типа E1". Такие условия в обероне невозможно проверить. Но, поскольку такая необходимость исключительно редка - есть в модуле Services, кажется, процедура, которая позволяет проверить точное совпадение.
a IS E1 - означает "переменная а указывает на значение фактического типа E1 или любого его расширения". Для проверки этого более сложного условия как раз и нужны перечни базовых типов в паспортах-описателях.

И дополнение. В ББ паспорта типов находятся не в области констант модуля, а в специальной дескрипторной области. Конечно, для программиста это незаметно, но нужно вот для чего: при выгрузке модуля его область констант аннулируется, а дескрипторная область - никогда. Поскольку в динамической памяти неопределенно долго могут оставаться переменные, чей паспорт-описатель будет указывать в эту дескрипторную область даже после выгрузки модуля. Если бы эту область аннулировали вместе с константами, то вскоре произошел бы аварийный останов, т.к. нарушилась бы целостность памяти. (Впрочем, даже при этом предусмотрительном способе авост почти неизбежен: ведь в паспорте типа указатели на типовые процедуры, которые в области кода, которая при выгрузке модуля аннулируется).

Интересно, чем обуславливалось именно такое количество указателей на дескрипторы предков?
У меня в системах, кстати, если длина пути в графе наследования превышает 3-5, то это - уже "звоночек" присмотреться к архитектурным решениям. Имеется в виду длина пути "моей" части. Сколько было классов-предков в "библиотечной" части - меня, часто, не интересует.

Благодарю за ответ и пояснения. Откровенно говоря я не знал что IS так работает (был уверен что (a IS E1) = все что угодно, но не TRUE. Иначе что же это за тест типа). В сообщении о языке и книгах есть противоречия и недосказанность. Но думаю у вас есть опыт, так что попробую переварить это.
Придётся поставить BlackBox или XDS и провести эксперимент.