Oberon space

Это связано с архитектурой x86. Там для сдвигов влево и вправо используются разные команды. При этом, величина сдвига помещается в регистр cl (8 бит), но процессор учитывает только младшие 5 бит. Т. е. величина сдвига всегда в диапазоне 0..31. Не знаю как в ARM, но в реализации Astrobe тоже есть LSR.

Так это можно решить на этапе трансляции. При чтении второго параметра проверить его на знак и в зависимости от знака подставить правильную команду процессора. А в языке программирования будет только одна предопределённая процедура.
Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...

Это может быть невозможно в виду несуществования реализации модуля на момент раздачи разработчикам необходимых интерфейсов.

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

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

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

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

Как эффективно совместить локальные записи и закрытые элементы.

Делать то же самое, что делается и сейчас, только вынести работу с интерфейсами наружу.

Как я понимаю - проблема в наследовании, да? То есть, какой-то интерфейс использует для одного из своих типов в качестве базового тип из другого интерфейса. И необходимо, чтобы в расширенном типе присутствовали переменные, объявленные в базовом типе.

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

А такой вариант пробовали?

Выделяется довольно большой кольцевой буфер. Единым куском памяти.
Туда с начала и почти до конца (как придётся) пишутся данные из сети. В TCP/IP размер пакета может меняться, поэтому заранее предугадать или задать его нельзя. Или не желательно. Поэтому, очередной пакет пишется туда, где окончился предыдущий пакет. Когда в буфере заканчивается место или размер остатка будет делать работу сети не эффективной, то переходить к началу буфера.

Для обработки буфера будет использоваться два курсора. Первый отмечает позицию, следующую сразу за последней распознанной лексемой, а второй указывает на текущий обрабатываемый символ. У первого курсора два назначения: с одной стороны он не даёт перезаписать ещё не обработанные данные, а с другой - указывает, откуда следует начать повторный разбор лексемы, если потребуется.

В какой строчке происходит лишнее чтение блока?

Я бы сказал, что это чтение, которого можно избежать, а не "лишнее".first = first->next;Перед этой строчкой мы получаем адрес блока, в который будем писать, а в этой строчке читаем текущий "пустой" блок и достаём из него адрес следующего блока, чтобы положить его в условленное место - переменную first. Чтобы записать восемь блоков, нам потребуется прочитать восемь пустых блоков. Не совсем пустых, конечно: в них хранятся адреса. Но ничто не мешает хранить адреса сгруппированными отдельно (например, в другом блоке). Восемь сгруппированных адресов по восемь байт - это одна строка кэша. И одно вспомогательное чтение ОЗУ на восемь записей.

И я не знаком со всеми процессорными оптимизациями, но мне кажется, что пока вышеуказанная строчка не исполнится, то процессор будет стоять (если конвейер опустел и не принимать во внимание мультитрединг). И так на каждое получение свободного блока. Или я что-то упускаю?

Если распределяется 128 для 64, то можно адрес на вторую часть от 128 поместить в список свободных 64 таким образом, чтобы эти вторые 64 были отданы первым же запросом на размещение объекта. Минус подхода - усложнение проверки при возврате куска в пул свободных кусков. Если возвращаем первую половинку, то нужно проверить, что вторая половинка не занята, забрать из пула размещённый адрес на вторую половинку и вернуть блок. При возврате второй половинки проверить, не обнулена ли первая, и если обнулена, то вернуть блок.

Списки организуются на памяти самих же свободных объектов.

Если я правильно понял, и имелось в виду, что из 64 байт 8 байт выделяется под адрес на следующий объект, в котором заняты тоже только 8 байт для адреса, то идея не очень, по-моему.

В общем, если по полной воспользоваться советом Дизера, то можно получить следующее:

1. Выделять память блоками, кратными 2Q. Например, блок будет содержать 64 элемента 2Q.
2. Завести массив указателей на блоки (из пункта 1) и битовую карту на ячейки массива (в случае 64 элементов будет достаточно одного 64-битного числа).
3. У блока есть структура. Нулевой элемент блока служебный. Остальные используются для выделения памяти.
4. Спецификация служебной части блока:
   4.1. первый элемент - адрес или индекс свободной ячейки в этом блоке.
   4.2. битовая карта занятых ячеек блока.
   4.3. адрес и/или индекс блока в массиве блоков (из пункта 2).
   4.4. адрес битовой карты массива блоков.
   4.5. тип данных (размер Q или 2Q)

Часть данных, которые я загнал в служебную область, может оказаться избыточной. Или что-то придётся подправить.

Допустим, у нас уже есть блок (из пункта 1), и мы хотим выделить память. Назовём этот блок активным. Выделение памяти происходит только в активном блоке. Одновременно активным для данного типа данных может быть только один блок. Мы смотрим в самое начало блока (без какого-либо смещения) и узнаём позицию свободной ячейки. Забираем эту позицию себе и записываем в начало блока увеличенный адрес. Размер блока фиксирован, поэтому момент заполнения блока проследить легко. Что если блок закончился? Когда выделять новый блок: сейчас или отложить до момента, когда придёт запрос на выделение нового объекта? Я бы отложил выделение нового блока, потому что могут оказаться полезными две оптимизации. Одна над текущим активным блоком, а вторая - концепция полупустых блоков. Также, вместе с увеличением адреса свободного блока установим и битик в нашей карте. Карта и адрес свободного блока находятся в одной кеш-линии, поэтому двукратного обращения к ОЗУ для получения двух этих значений быть не должно.

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

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

Вместо массива из пункта 2 можно просто побить большой кусок памяти на блоки и считать всё это массивом блоков. Или вместо списка блоков использовать стек адресов на свободные блоки.

список пустых блоков можно использовать как для Q, так и для 2Q. Но допускаю, что это не критично. Вполне возможно, что Вы и так всю доступную память выделяете.