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

Татарин> Мысль же состоит не в том, что 8 бит должны быть запрещены, а работать с ними должно быть неудобно.

На практике почему-то при попытке реализации этой мысли оказывается, что 8 бит запрещены и работать с ними неудобно. Странно, да?

Татарин> Мысль была в том, что должно быть удобно работать с данными ЛЮБОЙ ширины, а не только произвольно выбранными 8 битами, каковую традицию установила ИБМ.

На практике оказалось, что 8 бит — самый удобный размер. См. эволюцию GPU. Чего уж там с форматами данных не изобретали, а закончилось тем, что память — это набор байтов, адресуемый линейно. См. Vulkan и DX12.

Практика — критерий истины.

Татарин>> Мысль же состоит не в том, что 8 бит должны быть запрещены, а работать с ними должно быть неудобно.
Sandro> На практике почему-то при попытке реализации этой мысли оказывается, что 8 бит запрещены и работать с ними неудобно. Странно, да?
?! Покажи мне на такую реализацию и мгновенно выяснится, что во-первых, в приводимой тобой конкретной реализации именно что "8 бит запрещены", а вовсе даже не удобно работать с любым размером, а во-вторых, "неудобство" сводится к тому, что, оказывается, "теперь же байт - не выбранный размер, как же жить?!"

Sandro> На практике оказалось, что 8 бит — самый удобный размер.
Нет.
Корректно формулируя: на практике оказалось, что если выбирать фиксированный размер, то в мире, в котором доминирует фиксированный размер 8 бит удобнее всего 8 бит.
Это, вообще говоря, банальность, и тут никакой практики не нужно. 100% предсказуемо, нет смысла спорить, нет смысла и говорить.

Татарин> ?! Покажи мне на такую реализацию и мгновенно выяснится, что ...

Несмотря на наличие инстукций работы с битовыми полями, работа даже байтам крайне неудобна. Analog/Intel BlackFin.
Я под неё писал. На ассемблере. Оптимальный по времени код. Который работает быстрее, чем общетеоретические оценки.

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

Считаю я такое программирование нормальным? Нет. Абсолютно нет.

Татарин> Мысль была в том, что должно быть удобно работать с данными ЛЮБОЙ ширины, а не только произвольно выбранными 8 битами, каковую традицию установила ИБМ.

Это невозможно без неоправданных усложнений.
А еще и почти бесполезно.

Татарин>> ?! Покажи мне на такую реализацию и мгновенно выяснится, что ...
Sandro> Несмотря на наличие инстукций работы с битовыми полями, работа даже байтам крайне неудобна. Analog/Intel BlackFin.
Sandro> Я под неё писал.
Я не понял. Это ж вполне обычная (в этом аспекте) архитектура с побайтовой адресацией. Почему ты её приводишь как пример в контексте?

Sandro> Считаю я такое программирование нормальным? Нет. Абсолютно нет.
? Ну, вообще говоря, оптимальный по скорости или плотности код как правило менее понятен, оптимальный по понятности - часто проигрывает по скорости и т.п. Это нормально, это вопрос оптимизаций.

Но сейчас не столько важна простота кодирования человеком, сколько простота генерации компилятором.
А 60 лет назад была не столько важна простота кодирования человеком, сколько скорость исполнения.
Это раз.

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

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

Татарин>> Мысль была в том, что должно быть удобно работать с данными ЛЮБОЙ ширины, а не только произвольно выбранными 8 битами, каковую традицию установила ИБМ.
П.З.> Это невозможно без неоправданных усложнений.
П.З.> А еще и почти бесполезно.
Объясни.

Что именно "невозможно" или требует "неоправданных усложнений"?
Сохранение пословной адресации + спецкоманда выборки определённо возможна и значительно проще аппаратно, чем побайтовая адресация.

Тогда к чему относятся утверждения?

Татарин> Объясни.

"Вот скажи".
А какая у тебя будет система кодирования текста?
Тоже с переменной длиной поля?

Татарин>> Объясни.
П.З.> "Вот скажи".
П.З.> А какая у тебя будет система кодирования текста?
П.З.> Тоже с переменной длиной поля?
? Так это ж от конкретного приложения зависит.

Но даже предполагая, что тексты всегда и везде используют 8 бит представления, всё равно получается лучше: спасена куча кодового пространства и проще аппаратура. Система в целом работает быстрее, да ещё и сверху бонусом 2-3 лишних бита адресного пространства.

П.З.>> А какая у тебя будет система кодирования текста?
П.З.>> Тоже с переменной длиной поля?
Татарин> ? Так это ж от конкретного приложения зависит.

То есть стандарт для представления текста не предполагается?

Татарин> Но даже предполагая, что тексты всегда и везде используют 8 бит представления, всё равно получается лучше: спасена куча кодового пространства и проще аппаратура. Система в целом работает быстрее, да ещё и сверху бонусом 2-3 лишних бита адресного пространства.

"Объясни"


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

В той ситуации никакой приличной альтернативы байту не просматривается ни в телескоп, ни в микроскоп.
Он (байт) даже был придуман с некоторым опережением.

Если вы сейчас видите что-то другое - так дерзайте.
Но сдается мне, что вы либо предаетесь самообману, либо пытаетесь кого-то обмануть.

П.З.>>> А какая у тебя будет система кодирования текста?
П.З.> П.З.>> Тоже с переменной длиной поля?
Татарин>> ? Так это ж от конкретного приложения зависит.
П.З.> То есть стандарт для представления текста не предполагается?
А он-то тут каким боком? Стандарт сам по себе. Мы же о процессоре, вроде, говорили?

Татарин>> Но даже предполагая, что тексты всегда и везде используют 8 бит представления, всё равно получается лучше: спасена куча кодового пространства и проще аппаратура. Система в целом работает быстрее, да ещё и сверху бонусом 2-3 лишних бита адресного пространства.
П.З.> "Объясни"
Что именно объяснять?

П.З.> ПС. По-моему никто не запрещает разрабатывать альтернативный протокол для (хотя конечно вопрос, кому это может понадобиться).
Какой ещё "протокол"? Протокол чего?

П.З.> В той ситуации никакой приличной альтернативы байту не просматривается ни в телескоп, ни в микроскоп.
П.З.> Он (байт) даже был придуман с некоторым опережением.
Блин, байту не нужны альтернативы. Байт не нужен как таковой. И вся "выдумка байта" в том, чтобы запороть нормальную работу с другими размерами.

Избранный размер не нужен, если можно нормально работать с любым.

Татарин> Блин, байту не нужны альтернативы. Байт не нужен как таковой.

No comment.
Потому что комментарий к этому может быть только неприличный.

Татарин> Избранный размер не нужен, если можно нормально работать с любым.

А если нельзя?
А если ты видишь "как", то покажи или объясни.

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

П.З.> Потому что комментарий к этому может быть только неприличный.
С возрастом становится сложно воспринимать что-то иное. Вплоть до мата - настолько вот сложно, да.

П.З.> Для обеспечения "нормальной работы с любым" любая "команда" обрастает дополнительными параметрами, описывающими этот "любой" размер и расположение поля.
99%+ байтовой выборки сейчас (и тогда, кстати) - строковая выборка по индексу, то есть выборка по [базa+index*размер_поля]. Оставшийся процент исключений - выборка из структуры. То есть, опять выборка по базе с нулевым индексом. Все эти потребности и закрываются ОДНОЙ командой.

П.З.> Это что, может как-то обеспечить упрощение и ускорение работы?
П.З.> Но не программирование в любом случае.
Фига-се, заявки.

Хорошо. Не будем толочь воду в ступе и перечислим ВСЕ байтовые операции пересылки на самой популярной нынче архитектуре (пока ещё; но уж точно одной из самых популярных уже 40 лет как).

88 /r MOV r/m8,r8 Move r8 to r/m8.
8A /r MOV r8,r/m8 Move r/m8 to r8.
A0 MOV AL,moffs8* Move byte at (seg:offset) to AL.
A2 MOV moffs8*,AL Move AL to (seg:offset).
B0+ rb MOV r8,imm8 Move imm8 to r8.
C6 /0 MOV r/m8,imm8 Move imm8 to r/m8.

Два вопроса:
1. Как с этим набором операций программисты справлялись до сих пор?
2. Чего тут не хватает для "упрощения программирования"©?

Татарин> Мысль же состоит не в том, что 8 бит должны быть запрещены, а работать с ними должно быть неудобно.
Татарин> Нет.
Татарин> Мысль была в том, что должно быть удобно работать с данными ЛЮБОЙ ширины, а не только произвольно выбранными 8 битами, каковую традицию установила ИБМ.

В процессоре общего назначения? Зачем? Битики экономим или что?

Татарин> Ты видишь разницу?

Я опять вижу, не более чем, священную войну c ИБМ. Почему - абзацем ниже.

Татарин> Представь себе 1 (одну) операцию выборки в регистр (и записи из, соотвественно), которой даётся базовый адрес, размер данных и индекс. Это ВСЁ, что необходимо для работы машины с данными любого размера меньше слова. Удобно в данном месте 8 бит? Ну, значит, выбираем из памяти по 8 бит. Только и всего.

Может ли слово содержать несколько битовых полей и может ли битовое поле пересекать границы слова? Спрашиваю потому что не понятно - что ты пытаешься доказать - что 2 (в 32 или 64бит архитектуре) больше 5/6ти или таки что больше 10/12ти.

Впрочем ИБМ аплодирует тебе стоя. Ты пытаешься продать ИБМ Stretch как процессор общего назначения в 2024м. Да тот самый Stretch где появился нелюбимый тобой 8ми битный байт. Который был не более чем максимальным аппаратным символьным типом. Ты чуть более экстремален, но сделаем скидку на прошедшие 70 лет. Итак разрядности целых чисел 1..64 бита. Символьный тип 1..8 бит. С полной аппаратной поддержкой т.е адресацией битов. Плавающая точка - классическая 64бита. Это тебя устроит? Числогрызер (суперкомпьютер) и универсальная машина в одной коробке. Но такую роскошь не потянула уже транзисторная схемотехника. Машина получилось дико дорогой. В первую очередь из за переусложненной универсальной части. Да и как суперкомп она проиграла чистому суперкомпу CDC 6600 в котором целочисленная арифметика эмулировалась и аппаратного символьный тип был кратный размеру слова. 6бит паковались в 60, программить на Фортране хватит и ладно. CDC все бросила на быструю плавающую арифметику. В результате ценник в 6 раз меньше и производительность в 3 раза больше.
Как ЭВМ общего назначения Stretch использовался только в паре с спецпроцессором для криптоанализа. В общем ИБМ пролетела со Stretch как фанера над Парижем.
Поэтому в следующем проекте машины общего применения требования к операндам быть любой размерности, откровенно говоря взятые с потолка, были выкинуты и минимальны операнд стал 8 бит. Почему именно 8? Символ в процессоре общего назначения (читай машина для бизнес применений) first class citizen наряду с целыми и вещественными. 6 мало для символа. 7 достаточно, но приводит усложнению реализации адресной арифметики, а значит 8. При таком решение логично следует слово кратное размеру символа. В результате 75я, равная по производительности Stretch, стоила заметно дешевле CDC. Это был не суперкомп, но по удобству использования для бизнеса CDC и радом не лежала. Вот и вся история. Стоимость железа и жесткая ориентация на предметную область победили красивые абстрактные рассуждения. Ну а если позже кто-то умудрился сделать байт ориентированные, ну например, DSP то ИБМ тут не при чем.

Татарин> Посмотри на безумие (именно безумие) которое пришлось наворотить после введения байт как избранного размера - огромное число специальных команд, специальную аппаратуру, адресующую не в размер шины, конструкции в компиляторах для выравнивания данных, огромный расход кодового пространства команд, а далее - и более, специальные байтовые регистры, команды для переделки данных 8-16-32 (а потом и -64). ЗАЧЕМ?

Давай посмотрим где на самом деле безумие. Вернее просто лишняя сложность добавляемая чтобы было красиво и теоретично. Только не надо тащить сюда тот темный лес который получился у Интел при сохранении аппаратной совместимости по адресации памяти с 8битными предшественниками и бинарной совместимости сначала при переходе с 16бит на 32, а потом на 64. Новый дизайн с чистого листа.
Байтовая архитектура, шина и регистры 64бита. OPcode 8/16/32/64 требует 2 бита на флаги размерности операнда, на OPCODE остается 6бит. Я вполне могу сделать простенький RISC с 16/16 регистров данных/адреса с 16 бит командами. Ты не можешь. Потому что флаги размерности операнда у тебя занимают 6 бит и (опционально) смешения операнда еще 6. Итого получается что любая команда работы с данными имеет 64 или 4к модификации, а в байтовой архитектуре только четыре. Как ты увидел перерасход пространства команд в байтовой архитектуре когда у тебя команд минимум на порядок больше получается? То что ты модификатор размерности записал как псевдо операнд команды ничего не меняет, у тебя будет 64 команды ADD вместо 4х в х86.
Да я видел твое сообщение ниже что будут чистые Opcode, а размер и смещение пойдут в регистры. А значения в этих регистрах телепатически возникнут? Если размер грузить нужно изредка, то смещение почти для каждой операции. В итоге имеем более сложный блок адресной арифметики и большее число команд которые надо выполнить для совершения одной операции.

И уточню. Я исключительно про топик - советский аналог S/360. Машину для научно-инженерных (не экстремальных) и финансовых расчетов, всяких экономическо-управленческих задач и СУБД где важна работа с текстом. А не машины для управление например прокатным станом. Там символьный тип данных можно и по остаточному принципу прилепить. Упаковать символы без зазоров в слов - весьма годный вариант. Но увы и ах символ скорее всего окажется 8ми битным.
А вот для чего может быть практически понадобиться символ переменной длинны, кроме скрещивания ужа с ежом, я придумать не могу.

Татарин> Но почему именно 8?

Потому что бизнес машине в 1964м нужно было работать с символами эффективно и дешево, а не как Stretch. Ну а ответ почему именно 8 я привел выше.
А вот точно ли есть необходимость иметь например 12 везде? Ведь когда людям нужно именно 12 бит (осциллограф например) то они берут специальный процессор на 12 бит, а в пользовательский интерфейс ставят проц общего назначения на 32 бита с байтами, а не тулят два одинаковых проца которые умеет все, от 1 до 32, правда?

Татарин> АЦП-ввод в те далёкие времена был от 1 до 10 бит, вывод на ЦАП - тоже от 1 до 12.
Татарин> Отвлекись от выбранной не-нами тупейшей "исторически обусловленной" дороги и попробуй объяснить мне логически: почему для ввода с 5-битного АЦП или вывода на 13-битную панель реле ты обязательно должен использовать байт? Не 5 бит - ты не можешь их ввести? не 13 бит? А именно байт?

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

Татарин> Почему 5-битный бод с перфокарты ты обязан вводить как байт, два раза, а потом паковать в 8 бит?

Ничего не понял. Бод это бит или символ в секунду. Если же не бод а символ то почему его не вводить в 8ми битном представлении если оно аппаратное для символа в процессоре.

Татарин> В чём тут глубокий смысл? Где удобство? Почему нельзя работать с 5 битами сразу?
Татарин> Не "доступ к символам маразм", а "недопущение нормальной работы с символами любого размера - маразм".

Наверно понял, могу только порекомендовать остыть и подумать. Число людей которые бы с удовольствием набили морду разработчику железа за то что символ введенный с перфоленты имеет одну разрядность, а с перфокарты другую и это надо учитывать при разработке программ не только ввода/вывода но и обработки данных скорее всего асимптотически приближается к числу разработчиков бизнес софта на планете Земля. И системщики бы подтянулись, потому что головной боли и им бы хватило.
Да и железячники бы не дали такое сделать. В конце 50х, когда появился байт с 8 битами, символы произвольной длинны в процессоре гарантированно раздували стоимость без практического выхлопа.

Татарин> При том, что обеспечение байтовой адресации в конечном итоге обошлось индустрии ОЧЕНЬ дорого, МНОГО дороже, чем одна простая инструкция индексирования и нормальная пословная адресация.

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

tarasv>> Видов сдвигов всего три, два в наличии. Нет циклического.
Татарин> В Альфе - да. Но в других процах возможны сдвиги через перенос, что РЕЗКО облегчает конструирование и обработку сложных битовых полей.

Нужные если данные не лезут в слово. Забудь про свою молодость с 8ми битниками. На серьезном 32х битном железе с 60х из коробки была доступна работа с 64х, а чуть позже и с 128 битным значениями в родном для процессора формате. В целом разрядность была ограничена числом регистров, память микрокоманд открыта и документирована, можно допиливать команды по желанию. ЕМНИП была ЕСка с эмуляцией Минска таким способом.

tarasv> Впрочем ИБМ аплодирует тебе стоя. Ты пытаешься продать ИБМ Stretch как процессор общего назначения в 2024м.
Нет. Соотвественно, все рассуждения о том, как был плох Stretch и как поэтому (sic!) неверны мои предложения теряют почву.

tarasv> Давай посмотрим где на самом деле безумие.
Вот давай.

tarasv> Только не надо тащить сюда тот темный лес который получился у Интел при сохранении аппаратной совместимости по адресации памяти с 8битными предшественниками и бинарной совместимости сначала при переходе с 16бит на 32, а потом на 64. Новый дизайн с чистого листа.
Интересно, что ты сразу, сходу отметаешь главное наследие ИБМ (и ЕС), ради которого убили свою разработку - CISC. И да, тут ты отметаешь именно CISC как принцип, а не его конкретную реализацию.

tarasv> Байтовая архитектура, шина и регистры 64бита. OPcode 8/16/32/64 требует 2 бита на флаги размерности операнда, на OPCODE остается 6бит... То что ты модификатор размерности записал как псевдо операнд команды ничего не меняет, у тебя будет 64 команды ADD вместо 4х в х86.
И сразу ошибка - в чём?
В том, что ты пытаешься взять худшее из обоих миров, при этом выкинув всё ценное. Разумеется, результат не катит.

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

Я предлагаю оставить только одно - load/store операции с произвольным размером данных, возможно даже не 2, а 4 опкода (с арифметическим дополнением старших бит и без). Только и всего. Возможно (если мы говорим о конкретно 60-х и бизнес-машинах) то с командой векторных операций (а не бесконечно плодащиеся SIMD с опять же фиксированным размером данных, как случилось в нашей реальности!) а-ля rep mov, repe stosb, etc в х86, широко применяемых и по сей день.
Вся арифметика (сравнения, логика, и т.п.) производится пословно, в самых обычных для машины данной размерности операциях. Это и есть естественный путь развития, расширения естественной для любой машины пословной адресации и обработки на данные меньшей размерности.

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

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

Смещение - суть индекс в векторной операции, это всегда и везде регистр, потому как в 99.99% случаев переменная. Для исключений с выборкой по конкретному индексу (нулевому) прогрузить регистр нулём нет беды.

Поэтому вместо 64 MOV (а потом ADD, а потом SUB, а потом CMP, а потом ещё чего-там-надо), которые видятся тебе, у меня 2 (или 4) "байтовые" (в частном случае) команды всего. Против твоего учетверения всего набора команд в твоём гипотетическом RISC или сложном выборе типа операнда у IBM/360 с безумным расходом кодового пространства. Байтовые загрузки в байтовые регистры. Раз байтовые загрузки в байтовые регистры - значит байтовая арифметика с байтовыми регистрами, так? И понеслось! И ради чего? Можешь объяснить?

Чем фентезийный код типа
mov rax, byte[adr]
mov rbx, byte[adr2]
cmp rax, rbx

хуже реального специализированного(!)
mov al, byte[adr]
mov ah, byte[adr2]
cmp al, ah

А ведь в большинстве машин "работа с байтами"© подразумевает именно такой подход.

Далее - а посмотри на реальную работу со строками. У тебя всё равно есть загрузка базы, у тебя всё равно есть загрузка индекса (а если ты или компилятор используете векторные команды на x86, у вас и альтернатив нет; а не использовать их глупо: rep movdw быстрее любой альтернативы), что ты экономишь?
Одну команду загрузку регистра размером? регистр, в котором хранится размер? Ещё что-то?
Ты только что просрал 75% кодового пространства, замутил огромный сложный декодер, обустроил замудрённые коммутаторы на регистровом файле и АЛУ ради этой "экономии"? И это ли не безумие? Офигеть.

Посмотри на альтернативу. Оставляем везде только слова. Оставляем загрузку произвольного поля по адресу, индексу и размеру. Добавляем к этому векторизацию, не префиксом, а командой повторения rep R (делать следующую команду пока (--R)!=0). Вся работа с байтами остаётся такой же или лучше, чем у ИБМ, но в дополнение получаешь...

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

Вот простой (вырожденный) пример булевых полей (только вот давай без "это такой редкий случай!"; ибо не редкий). Как ты реализуешь массив флагов и пробежишься по нему затем? Как массив слов (или - сейчас реже - байтов), а бегать будешь в цикле, прибавляя указатель. "Что такого-то? Все так делают".
И верно, потому что альтернатива - битовые поля, не поддерживаемые современными языками "прозрачно", с замороченной обработкой на границах, реализация чего на современном нам C(++), java, C# будет смотреться переусложнённо и уж точно почти нечитаемо. Ну сам представь:

1. int64 array_of_flags[HUGE_ARRAY_SIZE];
2.  
3. #pragma warning( push )
4. #pragma warning( disable : 1234567 ) // to suppress static cast warning
5. bool flag = (bool)((array_of_flags[idx >> 6/* log2(sizeof(*array_of_flags)) */] >> idx&0x3f) & 1);
6. #pragma warning( pop )

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

1.  
2. #pragma warning( push )
3. #pragma warning( disable : 1234567 )
4. array_of_flags[idx >> 6/* log2(sizeof(*array_of_flags)) */] = flag?
5.     (1 << (idx&0x3f)) | array_of_flags[idx >> 6] :
6.     (~(1 << (idx&0x3f)) & array_of_flags[idx >> 6];
7. #pragma warning( pop )

Красота же! И сразу всё понятно! Ну, как минимум, про кодера.

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

А почему компилятор не делает это прозрачно? А потому что это не натив. Может, у машины и есть сейчас способ скомпилять битовые поля красиво, но когда-то (спасибо байтовому подходу) не было, были созданы языки, и при всём при том, что все нормальные программисты понимают теоретически возможность побитовой реализации таких массивов, для большинства это - слепая зона. "Нет смысла и думать". И правильно, нет: код должен быть читаем, а это вот что?
В нормальном мире программист должен был указать массив булов, а машина - выделить кусок слов с достаточным количеством битов и адресовать их побитово.
mov R, [R1 + (R2*R3)бит]
И с поддержкой в языке

1. bool array_of_flags[HUGE_ARRAY_SIZE];
2. flag=array_of_flags[idx]

транслируемое в инструкцию выше.

Думаешь, высосаный из пальца пример? Исключительный и частный случай? Да нет.
Берём строку длиной n и начинаем её токенизировать, сопоставляя позициям ИД токенов (или наоборот, в зависимости от задачи). Длина строки известна, позиция в ней - log2(size), количество токенов известно, ИД токена log2(num)... казалось бы, массивы должны быть соотвественных размеров бит? Это крайне "массивная", времяжрущая операция при обработке xml, html (и вообще веба), всевозможных скриптов, текста, сериализации-десериализации данных в нутрёшках прог и сервисов... в общем, операции, жрущие ОГРОМНОЕ количество CPU в типовых задачах совеременности. Казалось бы, экономия памяти и шины памяти должна бы окупиться? Ну, если возможный прирост - десятки процентов и разы?
Ха. На современных процах - это дурь, мы оба это знаем.

Но это не дурь, если ты можешь выбирать удобный размер прямо по месту, как требуется, динамически, по старшему задействованному биту счётчика.
mov R, [R1 + (R2*R3)бит]

Там, где нормальная машина использовала бы 7 бит для ИД токена или там 18 бит для индексов строки, ты будешь использовать 64 бита. Это временные структуры - создал, поработал, выкинул, там никогда не будет переполнения, но ты будешь использовать 64 бит. И таких случаев, когда размер предопределён небольшим, но ты используешь байт или слово - абсолютное большинство, почти весь код из них. А почему так? А потому что вот.
Рациональных причин за этим нет, есть лишь исторические наслоения, каждое последующее вытекает из предыдущего. Нет нормального способа выбрать элемент из вектора с произвольным размером элемента - нет удобной аппаратной работы - нет поддержки в языках - нет использования.
Но при этом ты, конечно тащишь с собой кучу аппаратно-программного хлама с байтовой адресацией (по факту, не используемой ради ускорения, всё равно структуры адресуются пословно) и байтовой (и какой-там-ещё) арифметикой. Куча бессмысленных транзисторов, кодовое пространство занимает куча бессмысленных команд "под размер", память "используется" чуть ли не на половину под хранение никогда никому не нужных нулей в старших разрядах, проц занят бОльшую часть времени пересылкой в принципе, заведомо ненужных битов. У тебя машина горячее, на десятки процентов дороже и во многие разы(!) медленнее, чем могла бы быть при всех прочих равных просто потому, что занимается пересылкой и обработкой вечных нулей.

Но! Зато мы сэкономили регистр, в котором пришлось бы хранить при выборке размер.

tarasv> Ничего не понял. Бод это бит или символ в секунду.
Оффтопично: бод - это именно символ в секунду. Символ неопределённого размера - от 1 бита в последовательной шине типа i2, через 8 бит у Centronics до, допустим, 64 бит в 64-битной параллельной шине.
В общем, работа шины за такт.

Обычно это бит в секунду, да. Но не всегда.

Татарин> В общем, работа шины за такт.
Или не шины. Да, символы, оне тово, шибко разные бывают.

Например, такие.

Татарин>> В общем, работа шины за такт.
pokos> Или не шины.
Или не шины. Канала связи, в общем.

Татарин> mov R, [R1 + (R2*R3)бит]

Ага.
И вот именно чтобы этого не было, байт и изобрели.

Да!
Специально!
Именно!
Нарошно!
Для этого!

Чтобы этим г.ном моск не конопатить.

И нарот поддержал.

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

ПС. Есть ровно два "основных" объекта, "для которых фсё".
Это числовые данные и тексты.
Для первого машинное слово, для второго - байт
Всё, что сверх того - от лукавого.

Сугубо аПстрактная "машина" со словами/символами "произвольной длины" "интересна" - но не более того, притом слишком специфична и в силу этого "не имеет рынка сбыта".
А "эксперимент" сегодняшней эпохе нехарактерен.
К тому же все подобное прекрасно эмулируется на любом современном ВУ - а зачем она вам вообще?

tarasv>> Впрочем ИБМ аплодирует тебе стоя. Ты пытаешься продать ИБМ Stretch как процессор общего назначения в 2024м.
Татарин> Нет. Соотвественно, все рассуждения о том, как был плох Stretch и как поэтому (sic!) неверны мои предложения теряют почву.

Принимается. И как я понимаю претензии к размеру символьного типа сняты?

Татарин> Интересно, что ты сразу, сходу отметаешь главное наследие ИБМ (и ЕС), ради которого убили свою разработку - CISC. И да, тут ты отметаешь именно CISC как принцип, а не его конкретную реализацию.

Ни коим образом. Я только напоминаю что система команд х86 не может использоваться как пример дурного влияния прямого доступа к байтам. Она проектировалась с глубокой оглядкой на 8080 и при ее разработке никто и представить себе не мог что она пройдет через два увеличения разрядности и должна будет вмещать в себя все то что в ней сейчас есть. Ну и RISC потому что у тебя то-же он. Я ничего кроме RR и RI в твоих предложениях не вижу. RM и MM в них нет, да и похоже что твой подход для них очень проблематичен, так что разумно предположить что это load/store архитектура т.е. RISC.

Татарин> И сразу ошибка - в чём?

В том что я не телепат. Теперь я вот знаю что ты только про load/store.

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

Что значит нормальная в твоем понимании? Возможность грузить N бит одной командой а не двумя/тремя и только словные инструкции для любого размера данных в регистре, как в RISC-V или ARM например? И только из за этого весь этот поток эмоций?

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

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

Татарин> Я предлагаю оставить только одно - load/store операции с произвольным размером данных, возможно даже не 2, а 4 опкода (с арифметическим дополнением старших бит и без). Только и всего. Возможно (если мы говорим о конкретно 60-х и бизнес-машинах) то с командой векторных операций (а не бесконечно плодащиеся SIMD с опять же фиксированным размером данных, как случилось в нашей реальности!) а-ля rep mov, repe stosb, etc в х86, широко применяемых и по сей день.

Векторная это SIMD выполняемый параллельно. Cray-1 до кожной хаты? rep это самый обычный SIMD с одним исполнителем.

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

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

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

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

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

О чем это? О процессорах c кешами на кристалле? Никто не лезет за отдельными байтами в ОЗУ сейчас. И S/360 не лезла. Физическое ОЗУ в ней вообще невозможно адресовать побайтно. Не помню уже сейчас можно ли вытащить слово или только два. Адресация байта это абстракция для удобства программистов, не более того. Memory Control Unit грузил 2 или 4 слова за раз. При инкременте/декременте уже загруженного адреса обращение к памяти происходило если происходил выход за границы загруженного блока.

Татарин> Поэтому вместо 64 MOV (а потом ADD, а потом SUB, а потом CMP, а потом ещё чего-там-надо), которые видятся тебе, у меня 2 (или 4) "байтовые" (в частном случае) команды всего. Против твоего учетверения всего набора команд в твоём гипотетическом RISC или сложном выборе типа операнда у IBM/360 с безумным расходом кодового пространства.

Эпитеты указывают на то что ты или систему команд S/360 не видел или пишешь для тех кто ее не видел. Не надо это писать мне. Не смотря на правоверный CISC, наличие RR и RM клонов всех команд операций над данными, полный комплект команд работы со строками и двоично-десятичными числами в памяти ИБМ так и не смогла придумать что туда еще напихать. Opcode не только поместился в одном байте, но еще и 100 кодов остались свободными. И в 370 помещалось с запасом. Второй байт добавили в 390.

Татарин> Байтовые загрузки в байтовые регистры. Раз байтовые загрузки в байтовые регистры - значит байтовая арифметика с байтовыми регистрами, так? И понеслось! И ради чего? Можешь объяснить?

В МП - обратная совместимость. При переходе Интел от 8 к 16 на уровне слегка подшаманеных исходников. Откуда и короткий поинтер с .com программами. Может и неправильное решение но байт тут не при чем, он уж точно никак не повлиял на выбор спорной системы адресации, сплошной маркетинг. Дальше веселей, уже бинарная совместимость. От того что в 32 тебе придется иметь и 16 (со всеми рудиментами от 8), а в 64 и 32 и 16 ничто тебя не освободит. Только новый дизайн. Эппл вгрохала миллиарды в переходы и смогла потому что кроме нее Маки никто не выпускает. Для Интел эта дорога закрыта.

Татарин> Чем фентезийный код типа
Татарин> mov rax, byte[adr]
Татарин> mov rbx, byte[adr2]
Татарин> cmp rax, rbx
Татарин> хуже реального специализированного(!)
Татарин> mov al, byte[adr]
Татарин> mov ah, byte[adr2]
Татарин> cmp al, ah
Татарин> А ведь в большинстве машин "работа с байтами"© подразумевает именно такой подход.

Я напишу несколько отвлеченно. EBCDIC строки в S/360, как и положено в ортодоксальном CISC, сравниваются одной командой. До 256 байт в 360 и до 16Мб в 370. В RISC первый вариант. Второй это 8086 который кровь из носу должен был выглядеть как развитие 8080, никаких революций. Но в том что у микропроцессоров выросших из 8ми битных штанишек все по твоему мнению криво и косо виновата конечно Лужков ИБМ, а не маркетинг, обратная совместимость и желание экономить при работе с байтами такой ценный ресурс как регистры, а не разбрасываться ими налево направо как ты.
Ну и конкретика. Ты предлагаешь использовать 7 полных регистров чтобы сравнить две строки в первом примере вместо трех регистров во втором примере? Два назначения, два адреса, два смещения в слове и один размера. Я не ошибся в подсчетах?

Татарин> Одну команду загрузку регистра размером? регистр, в котором хранится размер? Ещё что-то?

При пословной адресации как ты это описал нужно два дополнительных регистра.

Татарин> Ты только что просрал 75% кодового пространства,

Ты же даже считать эти проценты не пробовал. Просто с потолка взял. При opcode 8 бит у тебя получилось 48 команд которым требуется размерность операнда. Откуда такое богатство? Их вроде в районе 20 должно быть.

Татарин> замутил огромный сложный декодер,

Сложность декодера зависит от того переменная ли длинна команды и насколько переменная и фактически не зависит от числа команд, ПЗУ оно и в африке ПЗУ.

Татарин> обустроил замудрённые коммутаторы на регистровом файле и АЛУ ради этой "экономии"? И это ли не безумие? Офигеть.

А у тебя байт из середины слова оказывается в младших битах регистра с помощью сильного колдунства и совершенно бесплатно? Или таки тем же самым железом туда захизивается которое ты только что так страстно отругал? Ты уверен что сдвиг на 63 разных значения аппаратно выйдет проще чем сдвиг на четыре разных значени. Ну или коммутатор у тебя не окажется изрядно побольше?

Татарин> Посмотри на альтернативу. Оставляем везде только слова. Оставляем загрузку произвольного поля по адресу, индексу и размеру. Добавляем к этому векторизацию, не префиксом, а командой повторения rep R (делать следующую команду пока (--R)!=0). Вся работа с байтами остаётся такой же или лучше, чем у ИБМ, но в дополнение получаешь...

Ничего не получаю если речь про байты. Ни уменьшения числа обращений к ОЗУ (ты просто не знал как адресация байтов работает в мейнфреймах), ни решения проблемы недостаточного числа opcode (этой проблемы просто нет, там на 40% пусто). В итоге ты предлагаешь всего на всего макро для LOAD/AND with mask/SHIFT(/if negative NORMALIZE). Самое смешное тут то что это макро (но без нормализации, символ беззнаковый) есть команда LE и все что нужно уже прошито в процессоре аппаратчиками. Мало байта есть 16 бит. Мало 32х есть 64. Если все это не лезло изначально в МП то не байт от ИБМ виноват, а ограничения существовавшей тогда технологии.

Татарин> Вот простой (вырожденный) пример булевых полей (только вот давай без "это такой редкий случай!"; ибо не редкий).

Это настолько стандартная структура данных что все украдено до нас. Весь остальной бред на тему того что профессиональные программисты это идиоты которые сами пишут булевы массивы приличных размеров на примитивных типах я поскипал. Для начала просто посмотри на реализации std::bitset и std::vector <bool> в С++ или BitSet в Java.

Татарин> Там, где нормальная машина использовала бы 7 бит для ИД токена или там 18 бит для индексов строки, ты будешь использовать 64 бита. Это временные структуры - создал, поработал, выкинул, там никогда не будет переполнения, но ты будешь использовать 64 бит.

Снова здорово на тему программеры идиоты и не знают арифметику и им срочно нужна подпорка в виде нормальной машины. Начнем с того что машина делает то что написал программист. Если в функциональной спецификации написано что токенов не может быть больше 128 то почему у тебя их счетчик не в char а сразу в long минуя еще short и int? В функциональной спецификации написано что строки могут быть в 4*10⁹ раз длиннее чем адресное пространство задачи в пользовательском режиме? Я уверен что нет. Так почему в твоем примере long, а не int? И что самое интересное если программер таки идиот и тулит везде long-и то чем ему поможет нормальная машина, он так и будет тулить везде long-и на любой машине.

Татарин>> Вот простой (вырожденный) пример булевых полей (только вот давай без "это такой редкий случай!"; ибо не редкий).
tarasv> Это настолько стандартная структура данных что все украдено до нас. Весь остальной бред на тему того что профессиональные программисты это идиоты которые сами пишут булевы массивы приличных размеров на примитивных типах я поскипал. Для начала просто посмотри на реализации std::bitset и std::vector bool в С++ или BitSet в Java.

Я и привёл это как пример более чем типичной стандартной структуры. А вот насчёт "бреда" и "идиотов"... А посмотри, насколько часто используется bitset. Про vector bool - а опять же, где и сколько?
При этом проблемы внутренней реализации никуда не деваются: чтение и, особенно, присваивание бита - довольно сложные времяёмкие операции, причём, либо более более сложной последовательности сдвигов ("вдвига" бита на позицию), чем в моём (псевдо)коде. В моём коде - там, вообще, бранч для простоты, с околонулевой эффективностью предсказания и сбросом конвеера. Всё, как мы любим.

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

tarasv> Снова здорово на тему программеры идиоты и не знают арифметику и им срочно нужна подпорка в виде нормальной машины. Начнем с того что машина делает то что написал программист. Если в функциональной спецификации написано что токенов не может быть больше 128 то почему у тебя их счетчик не в char а сразу в long минуя еще short и int? В функциональной спецификации написано что строки могут быть в 4*10⁹ раз длиннее чем адресное пространство задачи в пользовательском режиме? Я уверен что нет. Так почему в твоем примере long, а не int? И что самое интересное если программер таки идиот и тулит везде long-и то чем ему поможет нормальная машина, он так и будет тулить везде long-и на любой машине.
Вишь ли, это теоретические рассуждения. На практике, как мы оба знаем (или должны знать, если мы оба видели достаточно реального кода на плюсах в популярных приложениях), там везде будет int.
И в 64-бит архитектуре там будет тоже int, а не что-то иное (и не надо про Микрософт, который и для х64 принял что int=int32 везде, но ведь и так 32).

После знакомства с реальным, существующим кодом либо тебе придётся заявить, что "да, программеры идиоты и не знают арифметику!".

Либо пойти куда более сложным путём и начать реально думать над тем, почему же так получилось. А так получилось потому, что в любом коде, который резервирует вектора, для использования элементов эффективного (нет) размера придётся использовать темплейты и делать сложную конструкцию для инициализации нового типа. Более того, у тебя сам язык C (и не только С, а ещё и всё что из него выросло, отпочковалось, на С смотрело и подсматривало) диктует для всех целых int как "эффективное целое для данной архитектуры".
А почему? А потому что С - развитие В, дальнее развитие макроассемблера - при создании ориентировался, ессно, на реально существующие машины, где как тип данных есть слово. И ещё, как довесок, есть символ. И ещё позже впиленый "какой-то" short, который по сути в начале пути - тот же байтовый символ, но используемый как число, а не как символ.
В до-менеджед языках не существует возможности простой динамической типизации уже просто потому, что не существует аппаратуры, на которой это имело бы смысл. Если ты секунду подумаешь, то тебе должно стать ясно, что при таких вводных и не должно, и не может существовать подобных инструментов.
Далее несложно понять, почему программисты не используют динамическую типизацию и угрёбищный выбор из 8, 16, 32 и 64 битах при написании нынешних программ с существующим инструментарием. В общем-то, в реальном коде у тебя может быть (а может и не быть) в абсолютном большинстве случаев максимум один переход "через тип", с которым (кроме исключительных каких-то случаев) почти никогда не станут возиться, учитывая все замороки, проще взять тип "с запасом", причём, с таким запасом, чтоб не нарваться на переполнение при масштабировании решения.

Тут если нужно объяснять далее, то уже не нужно объяснять.
Практикующему кодеру это понятно интуитивно.

Да что там сейчас говорить о выборе между short и int? Всё исчерпывающе объясняет твой презрительный вопрос об "экономии битиков" парой постов выше. Вот тебе реальная позиция программиста, мотивацию и резоны которого ты, наверное, знаешь достаточно хорошо.

О том, что своевременная железная поддержка породила бы соотвествующий инструментарий более высокого уровня, ты не задумываешься, о том, что современные языки следствие аппаратуры - тоже. То, что весь стек нынешних технологий был бы совершенно иным, а "экономия битиков" глобальной с глобальным же выигрышем, ты не задумываешься, точно так же, как совершенно не задумываешься над "естественным" нынешним положением вещей. И точно так же не задумывался бы в альтернативной реальности, аллоцируя массив n-битных m-ной величины вызовом типа array = new int{n}[m].