EC ЭВМ и ДВК. Решение о клонировании IBM и PDP - причины и последствия

tarasv> Массивы опять рулят, но не совсем. Ты сделав загрузку слова в регистр на 6% лучше чем классика (на 2 бита короче в кодовом). Но возможность классики использовать в данных байты и полуслова никуда не делась. А это, при равномерном распределении, почти два раза в ее пользу. Не самое реальное предположение, но явная дыра в методе с массивом слов есть.
Не совсем так. Ты опять думаешь "как сделать хуже?", а правильный подход в таких мысленных экспериментах - исходить из "у меня есть такая система, как бы я сделал там всё наилучшим образом?" А потом уже сравнивать результаты.
Доступ к любой переменной - это база, размеры переменной и индекс, причём база - одна на всех. Ну вот как регистр DS в x86 - ты же не считаешь катастрофой, что часть базы области данных (причём, ранее обязательно выровненная строго на 128 бит) постоянно сидит в регистре? Ну и тут более-менее постоянно она в регистре. Да, можешь счесть это недостатком архитектуры, совсем уж строго говоря, это и есть недостаток, в сравнении с сфероконической ИБМ/360 (и обязательно в вакууме, ибо на практике всё равно придёшь к базированию). Но с учётом реальной практики в имевшихся архитектурах это привычное необходимое зло.
И мы этот недостаток уже выписали, когда обсуждали количество занятых при выборке символа регистров. Да, он есть, уже стоИт отдельным пунктом. Поехали далее. А далее, имея ты спокойно выбираешь любую переменную (зная её размер) просто по индексу (не обязательно размера слова).
Возьми в регистр размер 8 - и вот привычная тебе побайтовая адресация от базы, индекс можешь рассматривать указателем. Возьми 16 - ну вот тебе частный случай полуслова, и опять же, никакого проигрыша в сравнении с ИБМ (или чем там ещё).

Да, тех же битовых полей, отталкиваясь от базы, ты сможешь адресовать в размер_слова меньше, чем адресуемого пословно пространства в машине всего. Ну и? Да, в 32-бит машине ты сможешь адресовать от одной базы не 128Гбит/16Гб (как пословно), а всего (при максимальном размере индекса) 4 миллиарда/500Мб булевых переменных, так и что? Ты вот прям серьёзно хочешь записать это в недостаток?

Ну и, очевидно, первое, что сделает любой вменяемый создатель компилятора для такой системы - просто
будет выделять место для переменных малого размера по возможности ближе к базе (статически - само собой, и динамически при работе с кучей). То есть, даже эти ограничения, если ты будешь на них настаивать, чисто умозрительные и реально не встретятся даже в исключительно редких приложениях, где данные занимали близко-к-100% всего адресного пространства (ещё и поищи такие! даже в исключительно короткий исторический период на "переломе эпох", когда 4Гб лимит 32-битной машины начал жать; про 32-битную машину в 1960-е или 64-битную в 2020-е и говорить же нечего).

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

То есть, реально, я могу принять твоё возмущение тем, что целый регистр занят под размер (причём, один и тот же размер, если ты работаешь с одним типом данных; мне же тут все уши прогудели тем, что кроме 8 бит и размеров-то не бывает? ).
Да, ладно, регистр (и его возможную загрузку - но тут нужно обсуждать) как бы и "профукали", обидно. Ещё в одном регистре сидит база для кучи и констант. Тоже жалко. Согласен. Но на этом и всё.


...

[показать]

...

tarasv> Принцип сохранения не обойдешь. Можешь даже не пытаться. Эффективный адрес у тебя 38бит.
Нет. Я не собираюсь обходить принцип сохранения, я собираюсь просто хорошо использовать что есть.

А есть у меня по факту реальный размер блоков данных, который никак не равен общему адресуемому пространству.[показать]


...
То есть, трюк в том, что когда ты адресуешь "обычным" указателем какой-то байт, у тебя в нём значимые лишь несколько бит, бОльшая часть оставшегося одинакова для всей программы/процесса, а часть бит (например, старшие биты в твоей 64-битной машине) - просто всегда бессмысленные нули.
Мой вопрос: а зачем таскать с собой эту информацию при каждой выборке? Оставь всю эту требуху в базовом адресе, не жалей регистр под базу. И оставь для загрузки только ценные, значимые биты. Их гораздо меньше.

mov r, (R1+R2*R3)
Заметь: и индекс может быть субсловным, у тебя экономия и на указателе, в сравнению с традицией (я это не рассматривал даже пока, ибо могли бы возниикнуть споры о практике - сколько бит тут можно сэкономить и т.п., но выигрыш тут опять же есть, куда уж без него?).

То есть, подводя итоги: да, ты тратишь регистры. Но эффективности выборки это не меняет. Расход памяти и пропускной способности шины меньше или равен ВСЕГДА. Типично - существенно меньше. А если он не меньше, то адресуем пословно, и он не больше.

tarasv> Кстати а где int - 64бита? И в LLP64 и в LP64 он 32. Разница в размере long - в винде(LLP64) 32, а в unix (LP64) - 64.
ILP64/SILP64, конечно. SILP64 - это реально экзотика, но вот ILP64 вполне себе встречается (64-бит Sparc, например).

Татарин> Заметь: и индекс может быть субсловным,...
Я тебе так скажу, дружище, любое твоё слово "может" означает, как минимум, один дополнительный мультиплексор.

Татарин>> Заметь: и индекс может быть субсловным,...
pokos> Я тебе так скажу, дружище, любое твоё слово "может" означает, как минимум, один дополнительный мультиплексор.
Не любое. И не в данном случае.

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

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

Татарин> Не любое. И не в данном случае.
Любое, особенно в данном случае. Ты ведь так ещё ничего и не нарисовал. А я такого в своей жизни нарисовался до отрыжки.

Татарин>> Не любое. И не в данном случае.
pokos> Ты ведь так ещё ничего и не нарисовал.
Претензия принята.

pokos> Любое, особенно в данном случае.
Индекс НИЧЕМ не отличается от любых других данных (собссно, о том, что он индекс, он узнаёт только уже в момент применения). НИЧЕГО дополнительного по сравнению с любыми другими данными для его загрузки не требуется.

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

Татарин> Не любое. И уж точно не в данном случае.

Есть время теоретизировать.
Сейчас время - рисовать!

Татарин> Доступ к любой переменной - это база, размеры переменной и индекс

База - пословная адресация, а индекс?

ПС.
Да, байт ИМЕННО для того, чтобы ЭТОГО не было.
Вот специально и сознательно.
Можно даже сказать, злонамеренно.
И именно для этого он оптимален.

Татарин>> Доступ к любой переменной - это база, размеры переменной и индекс
П.З.> База - пословная адресация, а индекс?
А индекс - "указатель" в выбранном размере. Хочешь побайтовую адресацию - возьми в регистр размер 8 и используй индекс как побайтовый указатель. Чем он, в общем-то и является по факту.

П.З.> ПС.
П.З.> Да, байт ИМЕННО для того, чтобы ЭТОГО не было.
Чего "этого"?
Во всех системах пришли к базированию для данных (и даже кода) процесса, иначе процесс размещения программы в памяти и динамического линкования усложняется и удорожается до безумия: если прогу разместить в другом месте памяти, все указатели плывут.

Поэтому так или иначе существуют инструменты, которые позволяют прибавить базу к побайтовому индексу. А в развитых системах (типа х86) их ещё и несколько разных и развитых по-разному, причём с наложением друг на друга.

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

- Давайте сделаем команду переменной длины? Будет компактный код!
- А давайте!
- Слово - слишком большое, в него помещаются все команды, и без выигрыша в размере, давайте тогда составной единицей команды сделаем субслово?
- Логично! Так и нужно!
- Субслово нужно взять размера... о! Размера символа же, всё равно нужно с ними как-то работать.
- Логично! Так и сделаем!
- Ну и давайте тогда и адресовать со сдвигом адреса влево на 3 бита - и команды адресуем, и с символами хорошо выходит?
- Ооо... Вообще хорошо. Звучит как план. Поехали!

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

Но "Шерлок давно уже забыл про табак, а вот Ватсон без трубки уже никак не может"©анекдот. И это г**но пропитало весь мир, включая, например, RISC системы, где это порождает только проблемы. Это породило целый пласт проблем, которые долго сложно и дорого решались и закрыло огромное количество возможностей сделать всё просто и красиво.

Татарин> А индекс - "указатель" в выбранном размере.

1) А если псевдобайт некратной длины по отношению к слову?
"Остаток" игнорируется или псевдобайт продолжается на следующее слово?
А чтобы его прочитать нужно двойное обращение к памяти?

2) А с какого бита начинается отсчет?
С того (словного) адреса, который база?
А при некратности?

Татарин>> А индекс - "указатель" в выбранном размере.
П.З.> 1) А если псевдобайт некратной длины по отношению к слову?
П.З.> "Остаток" игнорируется или псевдобайт продолжается на следующее слово?
П.З.> А чтобы его прочитать нужно двойное обращение к памяти?
Продолжается, конечно. Нужно, конечно.
А что, по-твоему, бывает сейчас на твоём АМД или Интел Коре когда ты выбираешь слово и оно (если скомпиляно с опцией без выравнивания, то в трёх случаях из четырёх), оказывается невыравненым на границу слов?

П.З.> 2) А с какого бита начинается отсчет?
П.З.> С того (словного) адреса, который база?
П.З.> А при некратности?
Именно с того. А какая разница-то? Да, с того же.

П.З.>> А при некратности?
Татарин> Именно с того. А какая разница-то? Да, с того же.

То есть "псевдоадресная сетка" при некратности сдвигается при перевыборе базы?

Татарин> Это ... закрыло огромное количество возможностей сделать всё просто и красиво.

Вижу сложности, но никакой простоты или хотя бы красивости.

ПС.
Да, и не вижу СМЫСЛА.
Вот под какие такие нерешаемые нетривиальные задачи нужен "байт" переменной длины?

Татарин> Не совсем так. Ты опять думаешь "как сделать хуже?", а правильный подход в таких мысленных экспериментах - исходить из "у меня есть такая система, как бы я сделал там всё наилучшим образом?" А потом уже сравнивать результаты.

Я не при чем в хуже, это был ты. Тебе с расчетом указали на несоответствие заявленных характеристик архитектуры реальности. Ты предложил решение, вернее "решение", которое я проанализировал и оно оказалось хуже чем то что было до него. Вот и все.

Татарин> Возьми в регистр размер 8 - и вот привычная тебе побайтовая адресация от базы, индекс можешь рассматривать указателем. Возьми 16 - ну вот тебе частный случай полуслова, и опять же, никакого проигрыша в сравнении с ИБМ (или чем там ещё).

Ты мне про однородные массивы не пиши. Я и так знаю что они у тебя хорошо работают и уже несколько раз тебе это писал. Недостаток как обычно - лишняя аппаратура. Для вычисления эффективного адреса необходимо умножение.

Татарин> будет выделять место для переменных малого размера по возможности ближе к базе (статически - само собой, и динамически при работе с кучей).

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

Татарин> даже в исключительно короткий исторический период на "переломе эпох", когда 4Гб лимит 32-битной машины начал жать; про 32-битную машину в 1960-е или 64-битную в 2020-е и говорить же нечего).

В те былинные времена, да и в менее былинные позже, разрядность адреса и разрядность слова выбирали отдельно и по потребностям, а не с потолка. И оптимизировали АЛУ и адресацию отдельно. У S/360 адрес 24х битный. И знаешь почему? Потому что 16Мб памяти весили тонн 15, жрали больше 100кВт и стоили крупную семизначную сумму.

Татарин> Нет. Я не собираюсь обходить принцип сохранения, я собираюсь просто хорошо использовать что есть.

И это работает только для целых. Ну и еще наверно перфокарт. А я вот экономно храню табель на диске id:16_len:8name_hours:8. (_ разделитель для читабельности) Сможешь придумать эффективную реализацию обработки таких записей?

Татарин> А есть у меня по факту реальный размер блоков данных, который никак не равен общему адресуемому пространству.[spoiler title="Для фантастических исключений..."] когда будет равным, это будет случаться и легко обходиться на границе блоков - а сколько возможно тех блоков? 32 раза на 32-битной машине, это как максимум

Ага =<32 кучи для целых, потом X куч для структур фиксированной длинны. ISAM в памяти в общем. Я чтото начинаю сомневаться что это взлетит.

Татарин> Мой вопрос: а зачем таскать с собой эту информацию при каждой выборке? Оставь всю эту требуху в базовом адресе, не жалей регистр под базу. И оставь для загрузки только ценные, значимые биты. Их гораздо меньше.
Татарин> mov r, (R1+R2*R3)

То что ты описываешь таким назидательным тоном это... догадался? Именно. Практически любой манфрейм. Включая IBM S/360. В команде в зависимости от метода адресации один, два и даже три регистра и смещение 12бит если надо.

Татарин> То есть, подводя итоги: да, ты тратишь регистры. Но эффективности выборки это не меняет. Расход памяти и пропускной способности шины меньше или равен ВСЕГДА. Типично - существенно меньше.

Конечно не всегда, а только на однородных массивах целых.

Татарин> А если он не меньше, то адресуем пословно, и он не больше.

32 всегда пролетает до 2х раза по памяти против микса 8/16/32 и на 40% против микса 16/32, разве нет?

Татарин> - Слово - слишком большое, в него помещаются все команды, и без выигрыша в размере, давайте тогда составной единицей команды сделаем субслово?
Татарин> - Логично! Так и нужно!
Татарин> - Субслово нужно взять размера... о! Размера символа же, всё равно нужно с ними как-то работать.
Татарин> - Логично! Так и сделаем!

Где в S/360 команды не кратные полуслову и их адресация по байтам? Нет ее? Тогда откуда взялось то что ты написал выше?

Татарин> Но "Шерлок давно уже забыл про табак, а вот Ватсон без трубки уже никак не может"©анекдот. И это г**но пропитало весь мир, включая, например, RISC системы, где это порождает только проблемы, породило целый пласт проблем, которые долго сложно и дорого решалось

То есть с бизнес и типа универсальными машинами 60х разобрались. Там твое предложение, учитывая имевшиеся аппаратные ресурсы, как на корове седло. Деньги потрачены, выхлопа нет. Баланс предприятия не посчитать, регистр короток. Кое какие ведомости можно посчитать, но дампом памяти не напечатать, не читабельно будет. Инженерам и научникам чаще всего нужна плавучка. Что остается? Оптимизирующий компилятор Фортрана, САПР для логических схем (принципиалкам уже нужна плавучка)?

>и закрыло огромное количество возможностей сделать всё просто и красиво.

Вообще прикольно читать слово "просто" написанное на процессоре в котором больше транзисторов чем во всех выпущенных S/360 вместе взятых про предложение напихать в S/360 не нужную для решения практических задач аппаратуру чтобы значит потом было красиво. Я думаю ты временем ошибся. Ты в курсе что что в младших S/360 не было физических регистров? 1024 дополнительных корпуса по тем временам было дорого для "заводской бухгалтерии". Тебе надо в 70е и ругать 801й. Правда он было 24 бита изначально, традиция не просматривается.
И это при том что, как показывают расчеты, красиво наступает только в 64битной архитектуре и для ограниченного круга задач дискретки.

tarasv> Я не при чем в хуже, это был ты. Тебе с расчетом указали на несоответствие заявленных характеристик архитектуры реальности. Ты предложил решение, вернее "решение", которое я проанализировал и оно оказалось хуже чем то что было до него. Вот и все.
Уф.
Твой "анализ" - не для моего решения, а для твоего, ты почему-то прицепился к нынешней реализации, и то, что ты придумываешь в качестве альтернативы (отдельные кучи под свой размер) заставляет меня дыбиться.

tarasv> Ты мне про однородные массивы не пиши.
Я не пишу про однородные массивы. Я пишу про кучу. Но вижу какой-то барьер просто. Вот давай с другой стороны: как сейчас?

В общем случае чтобы выбрать "из памяти" (с той же кучи) некоторого произвольного размера переменную, тебе нужны
1) размер элемента массива данных: сейчас память есть массив из 8-бит элементов, так что 8 бит замертво вколочено в аппаратуру,
2) индекс начального элемента переменной в массиве данных: ты привык называть это "указателем" или "адресом", он указывает номер байта, с которого начинается нужная тебе переменная,
3) начало массива: сейчас это либо аппаратный ноль (в системах попроще), либо старт сегмента данных процесса,
4) размер этой самой переменной: сейчас это явно или неявно прописано в кратных 8 битам единицах в коде команды.

Когда ты выбираешь 64-битный long, тебя же не беспокоит, что до этого на куче лежит строка, а то того - 16-битное целое, а до того - ещё строка, а до неё ещё массив 32-битных полуслов, а до него ещё указатели... и т.п. Ведь правда? У тебя есть номер начального элемента - байта, у тебя есть размер данных, которые нужно вытащить в регистр. (Указатель будет "домножен" на неявные 8, база будет взята неявно за 0). Всё.
И больше тебе ничего не нужно, чтобы система аллокации кучи работала: искала подходящие куски байт под запрошенный размер, выделяла память, освобождала. Так?

В альтернативе ВСЁ то же самое.
1) размер элемента массива данных задан в регистре,
2) индекс начального элемента данных - аналог указателя,
3) начало массива задано регистром базы,
4) размер выборки строго равен размеру элемента массива данных.

Ну и система аллокации считает свободную/занятую память побитно (и пословно), а не побайтно, только и всего. Я прошу мне выделить бит, система берёт первый попавшийся свободный бит и отдаёт мне "указатель" (он же битовый индекс, он же - тупо число бит от базы). Я прошу выделить мне 7 бит, система находит первые свободные 7 бит, которые находятся на кратном 7 расстоянии от базы, и отдаёт мне "указатель" (он же индекс, сколько 7-битовых значений нужно отсчитать от базы, чтобы взять нужные мне 7 бит).

Это одна и та же память. Как и с байтами, никакой разницы, все данные сидят вперемешку. Только с байтовыми значениями у тебя всегда всё выравнено на байт, а у меня небайтовые n-битные значения находятся на расстоянии n*m бит от базы.
Сильное ли это ограничение при выделении памяти? Нет. Только лишь в случае исключительно сильной фрагментации, и в этом случае байтовая система хуже - у неё другой расход и фрагментация наступает раньше. Есть ли непроизводительный расход памяти? Да, но на практике он минимален, потому что в реальном коде одиночные переменные на куче, конечно, встречаются, но памяти они почти не занимают, основной потребитель - большие структуры и массивы, а тут выигрыш. Больше ли работы системе аллокации с побитным учётом? Хм, да нет. Размер оперируемых целых на 3 бита больше, но это важно только если куча размером с физическую память. Давай для ясности этот случай всё-таки замнём.

tarasv> Я и так знаю что они у тебя хорошо работают и уже несколько раз тебе это писал. Недостаток как обычно - лишняя аппаратура. Для вычисления эффективного адреса необходимо умножение.
Умножение - да, это я понимаю и принимаю. Насчёт этого я серьёзно думаю.
Сдвиг в сравнении с умножением ГОРАЗДО дешевле, почти-бесплатен. Ограничить вариативность степенями двойки соблазнительно, и сразу же экономится место под указание размера.
Я ещё не уверен, пока ещё рисую.

tarasv> И это работает только для целых. Ну и еще наверно перфокарт. А я вот экономно храню табель на диске id:16_len:8name_hours:8. (_ разделитель для читабельности) Сможешь придумать эффективную реализацию обработки таких записей?
Не очень понял, про какую "обработку", но адресовать поле из пачки таких структур очень просто, идеальный вариант.
16-битное id - адресуется как 16-битное mov r, (база + 32 * индекс_структуры),
8-битное len - mov r, (база + 8 * (индекс_структуры « 2 + 2)),
8-битное name_hours - mov r, (база + 8 * (индекс_структуры « 2 + 3)).
Точно так же, как и с побайтовой адресацией выражение типа "индекс_структуры « 2 + 2" ты вычислишь заранее, до выборки. Всё то же самое.

tarasv> 32 всегда пролетает до 2х раза по памяти против микса 8/16/32 и на 40% против микса 16/32, разве нет?
Конечно, нет. Ты зря считаешь в "расходе" базу. База у тебя есть и так, и этак, просто "классически" ты о ней не думаешь - ну есть выделенный сегмент и есть, а то, что есть регистр(-ы), которые это обеспечивают, ты как бы и "забыл". Ну или в системах с полностью плоской памятью база аппаратно 0, но это порождает неудобства другого рода, и ты в многозадачной системе начинаешь складывать какую-то базу в коде или извращаться как-то ещё. Тут у меня ничего лишнего.

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

Татарин> Уф.

Оххх....

Татарин> Я пишу про кучу.

Будем разбираться с кучей. Только не будем валить доводы в кучу? А?

Татарин> 1) размер элемента массива данных: сейчас память есть массив из 8-бит элементов

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

Татарин> 2) он указывает номер байта,

И что тут такого вредного от байта? В любом случае индекс будет показывать "номер элемента".
Будь он байт или бит или 80 бит.

Татарин> 4) размер выборки строго равен размеру элемента массива данных.

Какая польза от этой красоты?
Цена вопроса (в вентилях) будет не нулевой.

Татарин> Я прошу мне выделить бит, система берёт первый попавшийся свободный бит

Указатель "весит" много больше бита. Позапрашиваем 50 бит - а памяти съестся...
напоминает реформу 61.
"для удобства, нам сказали, наши деньги меньше стали. Но пока привыкли, вроде, что-то больше их уходит"

tarasv>> Ты мне про однородные массивы не пиши.
Татарин> Я не пишу про однородные массивы. Я пишу про кучу. Но вижу какой-то барьер просто. Вот давай с другой стороны: как сейчас?

Потому что проблемы лезут. Я не нашел другого способа собрать все заявленные тобой характеристики вместе. Если все их сразу то все данные организуются только как массивы элементов одного размера. Да и то не уверен что нет дыр. Иначе чтото из заявленнaх тобой преимуществ придется выкинуть.

Татарин> И больше тебе ничего не нужно, чтобы система аллокации кучи работала: искала подходящие куски байт под запрошенный размер, выделяла память, освобождала. Так?
Татарин> В альтернативе ВСЁ то же самое.
Татарин> 1) размер элемента массива данных задан в регистре,

я уже не первый раз задаю этот вопрос, как он туда попал? Какое у него время жизни?

Татарин> 2) индекс начального элемента данных - аналог указателя,

То что ты называешь индексом это смещение. Разница в том что инкремент индекса дает осмысленное значение (если конечно не выход за границы массива). Инкремент смешения, в среднем, классическое UB.

Татарин> 3) начало массива задано регистром базы,
Татарин> 4) размер выборки строго равен размеру элемента массива данных.

В целом у тебя получилось копия 8086 с его сегментной памятью. Что адресует смещение - бит или слово? То есть какое из полезных свойств придется выкинуть - большая общая память или flat address mode и одной командой адресуется только 64Мб из 4Gb.

tarasv>> И это работает только для целых. Ну и еще наверно перфокарт. А я вот экономно храню табель на диске id:16_len:8name_hours:8. (_ разделитель для читабельности) Сможешь придумать эффективную реализацию обработки таких записей?
Татарин> Не очень понял, про какую "обработку", но адресовать поле из пачки таких структур очень просто, идеальный вариант.

Мы же все делаем нормально, не так ли? Строка ASCII или EBCDIC 7битная. Но твой код ниже полностью не рабочий даже без этого. Он читает мусор. Потому что ты пропустил 4 команды.

mov r, 16
Татарин> 16-битное id - адресуется как 16-битное mov r, (база + 32 * индекс_структуры),
mov r, 8
Татарин> 8-битное len - mov r, (база + 8 * (индекс_структуры « 2 + 2)),
mov r, 7
mov r, 8
Татарин> 8-битное name_hours - mov r, (база + 8 * (индекс_структуры « 2 + 3)).
Татарин> Точно так же, как и с побайтовой адресацией выражение типа "индекс_структуры « 2 + 2" ты вычислишь заранее, до выборки. Всё то же самое.

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

Татарин> Но и там, и там по "классике", у тебя требуется совершенно избыточный "полноценный" указатель, способный в пределе адресовать всю память, система опять бессмысленно занята перетаскиванием бессмысленных нулей.

Это если не завезли базовую адресацию. В мэйнфреймах 60х ее завезли в куче вариантов. В S/360 только база в памяти хранится как слово с лишними нулями. Но можно и как полуслово хранить. Длинна смешения в команде 12 бит, половина от полного адреса. Нужно больше - используй второй регистр для смешения, не нужно - сошлись на R0, доя вычисления адреса он считается нулем что бы там не лежало.

tarasv>>> Ты мне про однородные массивы не пиши.
Татарин>> Я не пишу про однородные массивы. Я пишу про кучу. Но вижу какой-то барьер просто. Вот давай с другой стороны: как сейчас?
tarasv> Потому что проблемы лезут. Я не нашел другого способа собрать все заявленные тобой характеристики вместе. Если все их сразу то все данные организуются только как массивы элементов одного размера. Да и то не уверен что нет дыр. Иначе чтото из заявленнaх тобой преимуществ придется выкинуть.
Это потому, что ты, скорее всего, а) абсолютизируешь (в смысле, отклонение от максимального выигрыша считаешь за "выигрыша нет") и б) уходишь от практики применения.

Ну вот смотри, что у нас обычно лежит на куче? Отдельные переменные? Ну, очень изредка бывает и так. Но если смотреть на потребляемую память, то на куче лежат массивы и структуры из массивов - строки, классы/структуры, массивы классов. Одиночные переменные нативных типов можно игнорировать: мало того, что редкий случай, но и потребление ими памяти ничтожно.

Первая моя предпосылка: в реальной работе "большие" данные (занимающие много памяти; то, на чём сильно проявляется экономия "битиков") - часто именно массивы, структурированные данные или массивы структурированных данных.

Поэтому когда ты начинаешь заводить 7-битные строки и встречаешься с требованием, чтобы их начало всегда было на кратном 7 расстоянии бит от базы, ты мало что теряешь. Давай, на каких-нить "неудобных" примерах наглядно. Допустим, у тебя 10 7-битных символов строка, которая начата от нуля и залезла (70 - размер_слова_64 = 6) 6 битами на следующее слово.
Далее нужно на куче разместить 31-битное целое,
- далее ещё одну 6-битную строку в 20 символов,
- потом 9-бит целое,
- и 40-бит целое.
Как это будет выглядеть?

Ну, с первой строкой ясно, у неё "указатель" будет 0. При имеющемся в регистре размере, загрузил нулевой индекс-указатель, получил первый элемент (ну или там второй, или какой там нужно, проинкрементировав указатель).

31-битное целое размещается с отступом от базы кратным 31. То есть, оно разместится в третьем от базы слове с отступом от базы в 93 бита. Биты с 71-го по 93-й остаются свободны. Биты с 93-го по 124 заняты 31-битным целым. Ты можешь обратиться к этому 31-битному целому по индексу-указателю 3.

Размещаем строку. У нас она должна размещаться со смещением от базы кратным 6. Начиная со 124-го у нас память свободна, и начиная со 126 по 186-й бит размещается эта строка. Индекс-указатель на неё 21.

9-бит целое. С 189-го бита размещено. Указатель - тоже 21 (так совпало).

40-бит целое. Со 198-го бита всё свободно, но мы размещаем его по границе 40 бит, начиная со 200-го бита (или четвёртого слова). С указателем 5.

...
Да, ты тратишь на границах этих данных биты. Всего в сумме в нашем примере ты потерял на требовании кратности 22+2+0+2 = 24 бита из 240 бит (30 байт) использованых. Если ты ЭТО имел в виду под "несохранением преимуществ", то да, они не сохраняются полностью. Но давай посмотрим на "байтовую" альтернативу?
Строка из 10 символов - 10 байт,
31-битное целое - 4 байта,
20 символов - 20 байт,
9-битное целое - 2 байта,
40-битное целое - 8 байт.

10+4+20+2+8 = 44 байта.
Пример чисто рандомный, нагенери других случайных примеров, давай посчитаем. Где-то будет и проигрыш, конечно. Но в целом выигрыш будет серьёзным.

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

Вторая моя предпосылка в том, что в каждый момент времени код работает с очень счётным числом сущностей. Если ты обрабатываешь строку, то это строка из одного типа символов. Если у тебя арифметика, то это арифметика над одинаковыми сущностями одинаковой размерности (ну, грубо говоря, ты редко складываешь тапочки с табуретками, у тебя под арифметикой табуреток в худшем пара типов - "большой" и "малый".
Загрузить же размер в начале метода или цикла не то чтоб прям "раздувает" код, как ты это показываешь.

То есть, по факту, для работы ты в основном грузишь индексы-указатели. Размеры грузятся один раз за долгое время - один раз за метод/функцию/подпрограмму, может. Может, и реже. Если у тебя в обрабатываемом тексте 7-битные символы (типичный компилятор), то нафига тебе грузить часто эту самую семёрку? Один раз положил, она там лежит. Всё.

tarasv> Это если не завезли базовую адресацию. В мэйнфреймах 60х ее завезли в куче вариантов.
Так я тебе про то и говорю, что по сути тут оно и есть. Ты всё равно никуда не уйдёшь от использования баз, так или иначе придётся. Так что регистр базы придётся задействовать и грузить время от времени что в лоб, что по лбу.