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

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

Татарин>> И сразу ошибка - в чём?
tarasv> В том что я не телепат. Теперь я вот знаю что ты только про load/store.
Нет, многократно повторялось и уточнялось одно и то же.

tarasv> Что значит нормальная в твоем понимании? Возможность грузить N бит одной командой а не двумя/тремя и только словные инструкции для любого размера данных в регистре, как в RISC-V или ARM например? И только из за этого весь этот поток эмоций?
Двумя-тремя ты не обойдёшься, скорее, речь о десятке+ (напиши псевдокод по индексации и присваиванию 5-битного целого в память и из - ну, поймёшь, о чём я)... И да. Именно из-за этой "мелочи" весь "поток эмоций". Потому что эта "мелочь" в корне огромной ветки технических решений, определяющих облик нынешней техники. Не лучшим образом сформированной ветки. Та самая палеоценская бабочка из-за которой будущее выглядит радикально иначе, только цепочка причин и следствий куда более проста. "Влияние ширины жопы лошади на форм-фактор космических ракет"©, что-то типа.

tarasv> Векторная это SIMD выполняемый параллельно. Cray-1 до кожной хаты? rep это самый обычный SIMD с одним исполнителем.
Векторная - это SIMD с не-фиксированным размером вектора. Да, именно так, rep - это вариант SIMD, только с произвольным размером тех "MD".

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

Татарин>> Если ты аккуратно повспоминаешь применение байтовой (допустим) арифметики на х86, то ты с удивлением обнаружишь, что собссно, байтовость арифметики не используется почти нигде, а в большинстве случаев переполнение с переносом - по сути ошибка, особая ситуация. Исключения же - крайне редки, и по сути являются хаком.
tarasv> До Unicode беззнаковая байтовая арифметика без всяких хаков использовалась любой программой обработки текстов на русском, французском, испанском и тд языках.
Ещё раз перечитай то, на что ты отвечаешь.
Да, использовалась (и используется, и будет). Но что в ней от специфично байтовой арифметики, а что просто от целой? В каких местах та же арифметика после загрузки символа не может вестись в размерности слова?
Я утверждаю, что таких мест в реальном коде нет или ничтожно, пренебрежимо мало. Можешь привести примеры обратного?

tarasv> О чем это? О процессорах c кешами на кристалле? Никто не лезет за отдельными байтами в ОЗУ сейчас.
Я именно про это самое. Никто не лезет за байтом.
Любая реальная работа идёт со словом.
Поэтому нет никакой существенной практически разницы между выборкой байта или произвольного размера целого, разница только немножно в арифметике вычисления и выдачи адресов плюс сдвига на нужное число бит. Всё.

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

tarasv> Ну и конкретика. Ты предлагаешь использовать 7 полных регистров чтобы сравнить две строки в первом примере вместо трех регистров во втором примере? Два назначения, два адреса, два смещения в слове и один размера. Я не ошибся в подсчетах?
Уф, ошибка, конечно, но я согласен принять часть вины за неё, раз уж сам написал [addr] (хотя imm там же не было, вроде, правда? я даже не подумал, что ты решишь, что сравнение символов строк можно делать выборкой по константным адресам). Если уж, действительно, брать сравнение символов из двух строк, то на х86 будет что-то типа
mov al, es:[si]
или
mov al, [cx]; инициализацию ds оставим за скобками, да?
или
mov eax, [rbx + rsi*imm]
Последнее, кстати, реально существующая и массово используемая удобная инструкция х86-64, и чем она от мной предлагаемого
mov R, [R1 + R2*R3(бит)]
? Тем, что трёхбитный imm в реальной исторически сложившейся интел-амдешной архитектуре включен в опкод?
Серьёзно?

Так что 4 против 7. Или даже 5 против 6, в зависимости от компилятора, является ли это константными строками, как компилятор их расположил (потому как база может быть той же), его внутренние соглашения вызова и адресации, вот это всё.
Или даже 7 против 7, если брать реально существующую доминирующую архитектуру и некоторые (практически значимые и популярные) случаи и слегка натянуть.
То есть, разница - да, есть, и вроде как не в пользу "переменного размера". Но она на практике минимальна: ну, на тот самый размер, плюс-минус, остальное - просто сложная адресация, которая применяется вовсю и без того.

Будешь настаивать на бОльшей разнице? Можно. Но заметь: она обусловлена лишь бОльшим количеством инструкций load/store в альтернативах, то есть, сравнение изначально нечестное и даже бредовое.
Считаешь это критичным?
Давай добавим ещё пару инструкций выборки, если так нужно.

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

tarasv> А у тебя байт из середины слова оказывается в младших битах регистра с помощью сильного колдунства и совершенно бесплатно? Или таки тем же самым железом туда захизивается которое ты только что так страстно отругал?
Именно железом, "которое я отругал". Но, во-первых, его не больше для поддержки любого размера, а, внезапно, МЕНЬШЕ. Во-вторых, это затрагивает только и исключительно спецкоманды спецадресации полей, и никак не затрагивает остальные команды (в отличие от байт, где под байты "пилится" вся система).

tarasv> Ты уверен что сдвиг на 63 разных значения аппаратно выйдет проще чем сдвиг на четыре разных значени.
Абсолютно уверен. Если это сдвиговый регистр делает, то ему, знаешь ли, всё равно, сдвигать только на 1, 2, 4, 8 или ещё и на 2, 3, 5, 6, 7, 9..63. Тут экономия на размерности счётчика сдвига, но это уже даже не экономия на спичках, а экономия на побелке, которая коптится выбросом их сажи.
Но зато эта процедура только в одном месте - на конкретных операциях load/store, а не затрагивает ВСЕ операции с памятью. Разницу видишь?

Татарин>> Посмотри на альтернативу. Оставляем везде только слова. Оставляем загрузку произвольного поля по адресу, индексу и размеру. Добавляем к этому векторизацию, не префиксом, а командой повторения rep R (делать следующую команду пока (--R)!=0). Вся работа с байтами остаётся такой же или лучше, чем у ИБМ, но в дополнение получаешь...
tarasv> Ничего не получаю если речь про байты.
ЕСЛИ РЕЧЬ ПРО БАЙТЫ.
Если речь исключительно про них (а это не так, много раз говорилось что борьба - за возможность нормальной работы с размером "по месту"), ты получаешь, как минимум, учетверение-увосьмерение адресуемой пословно, а не побайтно памяти. За что, знаешь ли, дважды шла целая война на переходах "за 64кб" и "за 4Гб", именно вот "за пару лишних бит", и которые вообще никогда лишними не бывают - см. например, наличие и дальность "ближних" переходов в разных архитектурах. Получаешь естественно, со всеми выгодами.
И без потерь.
Ты получаешь экономию кодового пространства. Минимум один бит (а то и два). Но и один бит - это удвоение кодового пространства для соотвествующих команд, им можно очень хорошо распорядиться.
Ты получаешь экономию времени на выборке команд (как минимум, на CISC, из-за естественного выравнивания команд на слово при пословной адресации).
Ты экономишь сколько-то аппаратуры в самых критичных точках - при работе с памятью.

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

А главное - получаешь способность нормально и "плавно"(!), бесшовно переходить между размерами, динамически, прямо в коде, как результат иного развития ЯВУ и подхода к распределению и использованию памяти.

tarasv>> Ты уверен что сдвиг на 63 разных значения аппаратно выйдет проще чем сдвиг на четыре разных значени.
Татарин> Абсолютно уверен. Если это сдвиговый регистр делает, то ему, знаешь ли, всё равно, сдвигать только на 1, 2, 4, 8 или ещё и на 2, 3, 5, 6, 7, 9..63.
Мнээээээ.... Извините, что вмешиваюсь в ваш высокоинтеллектуальный спор, но в проце RISC I операнды всегда проходили в АЛУ через сдвигатель, который умел двигать от 0 до 32 за один такт.

tarasv>>> Ты уверен что сдвиг на 63 разных значения аппаратно выйдет проще чем сдвиг на четыре разных значени.
Татарин>> Абсолютно уверен. Если это сдвиговый регистр делает, то ему, знаешь ли, всё равно, сдвигать только на 1, 2, 4, 8 или ещё и на 2, 3, 5, 6, 7, 9..63.
pokos> Мнээээээ.... Извините, что вмешиваюсь в ваш высокоинтеллектуальный спор, но в проце RISC I операнды всегда проходили в АЛУ через сдвигатель, который умел двигать от 0 до 32 за один такт.
Не очень понимаю, к чему это общеизвестное в узких кругах дополнение и в чью пользу аргумент, но... ну да. И?

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

Татарин> ...сдвиг требуется только при конкретных операциях загрузки-выгрузки, а не всегда-везде.
Я к тому, что сдвиг в RISC I есть всегда и везде, когда используется АЛУ, просто чаще всего он равен нулю.

Татарин>> ...сдвиг требуется только при конкретных операциях загрузки-выгрузки, а не всегда-везде.
pokos> Я к тому, что сдвиг в RISC I есть всегда и везде, когда используется АЛУ, просто чаще всего он равен нулю.
Это я понял. Я не понял, какие ты видишь из этого конкретные следствия в конкретном контексте нашего "высокоинтеллектуального спора"©?

Татарин> Это я понял. Я не понял, какие ты видишь из этого конкретные следствия в конкретном контексте нашего "высокоинтеллектуального спора"©?
Например, что поле для количества сдвигов в команде уже есть. Конечно, чтобы добавить ещё и маску, скорее всего, придётся от РИСЦ подхода отказаться...
С дугой стороны, Сеймур наш в своём векторном АЛУ это сделал, и вышло не так, чтобы очень навороченно. По сути, все эти ваши битовые кунштюки - сиречь наиболее примитивный вид матричных операций типа сборки и разборки.

Татарин>> Это я понял. Я не понял, какие ты видишь из этого конкретные следствия в конкретном контексте нашего "высокоинтеллектуального спора"©?
pokos> Например, что поле для количества сдвигов в команде уже есть. Конечно, чтобы добавить ещё и маску, скорее всего, придётся от РИСЦ подхода отказаться...
pokos> С дугой стороны, Сеймур наш в своём векторном АЛУ это сделал, и вышло не так, чтобы очень навороченно. По сути, все эти ваши битовые кунштюки - сиречь наиболее примитивный вид матричных операций типа сборки и разборки.
Так это именно моя точка зрения: конкретный фиксированный байт впендюрили зря (могли в ту же цену впендюрить и произвольный размер), а главное "байтовость" - впендюрили НЕ ТУДА (на работу с памятью вообще, а не на работу с символами). Вот нафига байтовость RISCу при выборке команд? или при работе со словами?

Сделали ложное обобщение там, где не нужно, и наоборот - фиксировали частность там, где можно и нужно было оставить возможность более общей работы.

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

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

Первый тезис абсолютный бред, второй - "ноу коммент" за некомпетентностью.

Татарин> В технике совершенно не редкость, когда какие-то довольно случайные, нетехнические, обстоятельства прокладывают колею...
Как по мне, история с байтом была совершенно не случайна.
Более того, как человек, нюхнувший оптимизацию процов, могу сказать, что размер нонешнего байта был прекрасно обоснован и технически, и экономически.
Пока экономили каждую ланпу/транзистор, байты бывали и по 6 бит. Как стали экономить микросхемы, байт стал степенью двойки, которую и стали экономить. Минимальная степень, пригодная для обработки цифробукв - 3. Всё крайне логично.
Теперь, когда лишний миллион ключей на кристалле - не проблема, можно легко сделать произвольный размер данных. Но это нужно только в узких применениях, до такой шибкой специализации индустрия процов пока не дошла. А экономить кремний нынче не принято, нет такой задачи. Нынешняя задача - увеличение объёмов продаж.

pokos> Теперь, когда лишний миллион ключей на кристалле - не проблема, можно легко сделать произвольный размер данных. Но это нужно только в узких применениях, до такой шибкой специализации индустрия процов пока не дошла. А экономить кремний нынче не принято, нет такой задачи. Нынешняя задача - увеличение объёмов продаж.
Ну, я не вижу смысла повторять аргументацию выше полностью, но да
- произвольный размер, если его оставлять только в загрузке/выгрузке данных, требует МЕНЬШЕ аппаратуры в сравнении с побайтовой адресацией, и
- в узких применениях переменное поле может быть абсолютно необходимо, но нужен переменный размер почти везде.

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

Татарин> - произвольный размер, если его оставлять только в загрузке/выгрузке данных, требует МЕНЬШЕ аппаратуры в сравнении с побайтовой адресацией
Это тебя кто-то обманул. Шина у тебя фиксированного размера всегда. Нарисуй мне схему загрузки произвольного размера по фиксированной шине. Не забудь пальцем показать, в котором месте оборудования получается меньше, чем при фиксированном размере в байт.

Ещё прикольнее было бы посмотреть на выгрузку такого кунштюка.

Татарин>> - произвольный размер, если его оставлять только в загрузке/выгрузке данных, требует МЕНЬШЕ аппаратуры в сравнении с побайтовой адресацией
pokos> Это тебя кто-то обманул. Шина у тебя фиксированного размера всегда. Нарисуй мне схему загрузки произвольного размера по фиксированной шине.
? Кэш же. Слова, затронутые полем - в спецкеше на время выполнения именно этой команды загрузки-выгрузки.
Общение с внешней памятью или "нормальными кешами" - только словами, на полную ширину шины, как обычно.

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

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

Татарин> ? Кэш же.
Какая разница? У него шина резиновая, что ли?

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

pokos> Что ты мне баки бьёшь? Схему нарисуй, пальцем покажи. Тогда дальше поедем.
Ты меня прям озадачил. В том смысле, что именно нарисовать - это прям проблема, хоть на бумажке рисуй и фотай. Ни одного векторного редактора под рукой, да и запарюсь рисовать... О чём-то более специализированном и речи не идёт.

Татарин> Векторная - это SIMD с не-фиксированным размером вектора. Да, именно так, rep - это вариант SIMD, только с произвольным размером тех "MD".

Слово векторная популяризировала Cray. Размер вектора ограничен потому что это RR операция. А не RM или MM как rep.

Татарин> Могут.

То есть для хранения адреса целого всегда требуется двойное слово. Великолепный дизайн для 64 года.

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

Ладно что ты не знал как работает MCU, не все программисты это знают. Ты на систему команд S/360 вообще смотрел?

tarasv>> Ну и конкретика. Ты предлагаешь использовать 7 полных регистров чтобы сравнить две строки в первом примере вместо трех регистров во втором примере? Два назначения, два адреса, два смещения в слове и один размера. Я не ошибся в подсчетах?
Татарин> Уф, ошибка, конечно, но я согласен принять часть вины за неё, раз уж сам написал [addr]

Мне совсем не интересно какие способы раздуть потребности в регистрах ты можешь выдумать. В flat memory model для сравнения строк байтов требуются три регистра. "Нормальной машине" семь. За раздувание адреса вдвое неожиданно приходится таки платить.

Татарин> Последнее, кстати, реально существующая и массово используемая удобная инструкция х86-64, и чем она от мной предлагаемого
Татарин> mov R, [R1 + R2*R3(бит)]
Татарин> ? Тем, что трёхбитный imm в реальной исторически сложившейся интел-амдешной архитектуре включен в опкод?
Татарин> Серьёзно?

Она кардинально отличается пиаром. Интел не заявляла что добавлением этой команды сожмет пространство команд или еще что кардинальное сделает. А ты заявил что у твоей серебряной пули лучше все - расход памяти меньше, скорость работы выше, пространство команд меньше и даже что она положительно влияет на сознательность и профессионализм программистов. Когда тебе написали что пространство команд будет больше ты решил засунуть 6бит в 64бит регистр. Итого для любой операции с памятью тебе нужно три полных регистра. Великолепный дизайн для 64 года.

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

Она минимальна пока ты работаешь с однородными массивами. Но ты навредил куче.

Татарин> Считаешь это критичным?

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

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

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

Ты забываешь про "незначительные" детали и даты.
Железо проще это вот так
M 1111 1111 1111 1101 zzzz zzzz zzzz zzzz
R zzzz zzzz zzzz zzzz 1111 1111 1111 1101
ничего кроме микрокода команды для работы MCU не нужно.

а не вот так
M zzz1 1111 1111 1111 101z zzzz zzzz zzzz
R 1111 1111 1111 1111 1111 1111 1111 1101
микрокод системы команд предложенной тобой тут почти бесполезен, нужно передать в MCU результат вычисления над содержимым регистров.

Даже сейчас это пожалуй выглядит не очень, в 60е это утопило Stretch.

В целом можно подвести итоги.

Плюсы
Большее располагаемое адресное пространство при равной ширине адресной шины.
Удобная и быстрая работа с большими массивами примитивов включая биты.
Возможна экономия памяти при работе с массивами мелочи. Иногда очень существенная экономия. (только если программист эту мелочь запроектировал, ЯВУ могут автоматизировать работу с битами, не более)
Недостатки
Только косвенно-индексная адресация с переменным инкрементом для всего кроме вещественных (а кто-то писал что не Stretch).
следствие 1 - удвоение размера указателя.
следствие 2 - худшая производительность и большая потребность в памяти при работе с кучей.
Нет обратной бинарной совместимости при росте разрядности.

Ну и теперь об твоей священной войне. Допустим, 62год, ты приходишь к Амдалу и пытаешься его убедить что твоя архитектура лучше. Я конечно совсем не Амдал, но ответы я знаю.

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

Это будет работать медленнее потому что программа будет занимать больше памяти чем набор из команд в одно, два или три полуслова. Команды формата SS размером в 3 полуслова используются не часто, RR и RS примерно пополам. Только RS имеет размер слова. Излишний расход памяти с командами в слово будет заметным. Потерю производительности нужно считать, но она будет однозначно.

Татарин> Ты экономишь сколько-то аппаратуры в самых критичных точках - при работе с памятью.

Мы только что сильно упростили MCU по сравнению с 7030 которая была построена на принципах очень похожих на предлагаемые и где регистр можно было грузить с любого бита в слове. Вы предлагаете вернуть назад все что мы выкинули?

- Всего то пару сотен логических элементов добавить, да на кристалле их... Ой сорри Джин.

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

Видете-ли в чем дело, у нас несколько другие проблемы с обеспечением поддержки финансовых расчетов. Целы числа удобны для некоторых их видов. Экономные по памяти расчеты с максимальными суммами меньше 20млн долларов, но больше 650 долларов конечно будут востребованы. Я согласен, неплохо иметь некий промежуточный вариант, например 167тыс но без серьезного усложнения аппаратуры. Однако мы уже провели анализ и пришли к выводу что BCD от 2 до 16 значащих цифр хороший компромисс. ALU несколько сложнее и скорость вычисления ниже, однако потери памяти меньше бита на цифру и покрыты потребности всех наших пользователей. Ваше предложение не покрывает расчеты с суммами допустим в 40млн, а это далеко не редкость.

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

- А как же хтмл который везде!

Джин тянется к карманной машине времени.

- сорри Джин это на 30 лет в будущем

Татарин> И экономию шины памяти. Что определяет реальную производительность сейчас.

Если вы об адресной то мы и так используем только 24бита из 32х. На большие объемы памяти у пользователей нет денег. Гмм... (Джин таки заглядывет в карманную машину времени) О! году так в 85м это может стать проблемой, но машины времени часто врут, особенно карманные.
А если вы о шине данных то как адресация только слова может ускорить ее работу? Ферритовая память состоит из банков с разрядность 64бита и MCU читает два слова за один такт если банк один и четыре слова если банков 2 или 4.

Где-то тут вы и попрощались. ЯВУ это не к Амдалу. Кстати насколько я помню рассматривался вариант адресации ниблами. Но указатель на цифру в числе не имеет почти никакого смысла, в отличии от указателя на символ в строке.

Татарин> А главное - получаешь способность нормально и "плавно"(!), бесшовно переходить между размерами, динамически, прямо в коде, как результат иного развития ЯВУ и

Другое развитие это как в PL/1 и Cobol для вещественных с фиксированной точкой но для целых? Есть в С и Ada. Не скажу за Ada, не работал. В С я практически не видел использования bit fields за пределами предельно однозначных спек как например заголовки сетевых протоколов. С _BitInt пока не сталкивался, не те задачи.
Ну и практические соображения. Единственное что можно жестко внедрить через ЯВУ это boolean=1 bit. Все остальное требует не столько развития ЯВУ сколько развития мозгов программистов. Если программер сейчас присваивает индекс символа в строке в int64 то наличие условно uint:14 на качестве его кода никак не скажется.

Татарин> подхода к распределению и использованию памяти.

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

Татарин> Ну, я не вижу смысла повторять аргументацию выше полностью, но да

Её не было. Как можно повторять то, что ты не сказал?

Татарин> - произвольный размер, если его оставлять только в загрузке/выгрузке данных, требует МЕНЬШЕ аппаратуры в сравнении с побайтовой адресацией, и

Больше. Произвольный размер требует намного больше аппаратуры — в разы!

Не согласен? Рисуй схему АЛУ хотя бы, чтобы показать, как оно будет. Ну или устройства чтения-записи, если переменный размер только там.

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

Да практически нигде он не нужен. Исключением является только особые случаи с хранением специфически форматированных данных. Например, массив источников света в рендере Doom 2016, там для компактности используются 12-битные индексы, например.
А так — байт рулит и заруливает всё.

Татарин>> Ну, я не вижу смысла повторять аргументацию выше полностью, но да
Sandro> Её не было. Как можно повторять то, что ты не сказал?
То, что не сказал нельзя. То, что ты не читал - можно.

Вот, например:
Sandro> Не согласен? Рисуй схему АЛУ хотя бы, чтобы показать, как оно будет.
- раз 5-7 уже повторил (в том числе и ещё один раз отдельным постом), что АЛУ не затрагивается. ТОЛЬКО загрузка-выгрузка. Все операции идут со словом.
Собссно, отдельные "субсловные" операции и модификация АЛУ для работы с субсловами - это по вашим же словам аномалия, "результат маркетинга"©tarasv, а значит - зачем нам это в "чистой" архитектуре?

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


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

Легко проверить. Для этого пойдём обратным путём: а сколько в прикладных применениях реальных данных, для которых целое лежит точно в диапазоне от 0 до 18 квинтиллионов или от -9 квинтилионов до 9 квинтиллионов? Почему чуть ранее огромное количество данных, за редким исключением, для которых сейчас используется 64-битное целое, точно так же занимало 32-бит целое? В мире случилось что-то глобальное, из-за чего всех счётных величин в 2000-2010 года стало приблизительно на 18 квинтиллионов больше?
Ладно, это риторические вопросы.

Вот тебе практический вопрос: почему максимальное число секунд от 1970-го года принято именно за 4 миллиарда? Почему такая заморока перейти к бОльшему числу секунд?
Почему чуть ли не в половине бухгалтерских систем у тебя может быть 255 копеек в одном рубле или
центов (название намекает, да?) в евро? Почему другая большая доля бухсистем использует для хранения копеек 2 байта? это запас на случай нетривиальных финансовых реформ? Почему и зачем ВДРУГ наиболее широкораспространённым стандартом стало 8-битное представление цвета (в том числе внутреннее, межсистемное, для обработки, в том числе для типографского CMYK), когда любой не то что даже врач, но просто любой человек тебе скажет, что 256 градаций для цвета - недостаточно? А, мы "экономили битики"? Тогда почему и откуда сейчас именно 32-битное RGB-представление цвета с неравномерным распределением битов по цветам?
Вне байтового мира это бессмыслица.
Откуда взялся именно 24 бит звук, когда этой точностью РЕАЛЬНО даже сейчас не обладают (и уж точно не обладали) ни АЦП, ни, тем более, аудиотракты, а скорее всего, по фундаментальным соображениям никогда и не будут обладать? Почему ранее было именно (долгое время избыточное) 16? а до того явно недостаточное 8-битное представление?
Вот возьми (развёрнутые) битмапы, видео- и аудиоданные (которые из-за байтовости приобретают размер чудовищный для текущего железа или наоборот строго недостаточный). Наверное, это небольшие, маленькие объёмы в памяти, атипичный ничтожный редкий частный случай массива, ради которого совершенно не стОит беспокоиться?

Почему автомобилей на складе может быть до 4 миллиардов, точно так же как и гвоздей? Ты уверен, что это отражает реальный мир?
Почему и зачем координаты на экране Виндовс (да и Х-ов уже до кучи) могут быть в пределах именно 4 миллиардов точек? Почему долгое время количество открытых файлов или оконных хендлеров не могло превышать именно 65535? Это нечто "естественное", верно?

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

Компактность представления (экономия памяти и шины) - это лишь часть проблемы. Вторая - это мышление огромного числа программистов, для которых тип и размерность целого стало чем-то фиксированным и святым, а переход к целым вычислениям бОльшей размерности (как от 16 к 32 или от 32 к 64) - эпохальное событие, требующее перепиливания всего и вся.

Беда.

Которую ты даже не видишь.

В общем, тут нужно... остановиться.

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

Я не согласен с тобой по абсолютному большинству утверждаемых тобой частностей, но беда в том, что это не несогласие типа "нет, наоборот", а несогласие "да нет же, ну не так же! не на то возражаешь! вот как надо-то!"
И поверх этого "не так" наворачивается та, очевидная уже мне, проблема, что люди настолько ПРИВЫКЛИ, что просто не могут представить себе вещи иными. Я, вообще, примерно представляя себе, с кем говорю, ожидал иного, у меня были завышенные ожидания.

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

Даже хорошо подумав, я могу назвать назвать лишь единичные случаи, где наоборот - частный размер приходится ровно "в аккурат". Всё остальное же - чистый переразмер с разной долей "авось" и "а почему бы и нет?" - от малого до дичайшего (как с bool, который в C(++) == int == слово), и мне очевидно до степени когда это можно постулировать.

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

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

Поэтому мне нужно подумать,
а) как цельно изложить и чем аргументировать концепт, показать возможное состояние всего альтернативного стека - от железа до ЯВУ и программирования,
б) нарисовать критичные куски железа.

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

Татарин> а) как цельно изложить и чем аргументировать концепт

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

Fakir> Канторович, 1960:
Ещё одно доказательство, что 2х2=4, и задержка с ЕС на 5-8 лет стОила стране миллиарды и убила отрасль.

Татарин> Потому что а) мне нужно представить весь концепт в целом, и б) свою реализацию системы системы выборки на железном уровне, чтобы разговор шёл более-менее предметно.
Вот, хорошо бы, да. Было бы очень даже неплохо. Заместо писанины многих буков.
Я-то себе твою схему представляю, местами, даже в деталях. Особенно ввввесело будет с выгрузкой твоего кунштюка в ОЗУ.
Да, и вопрос-то тут, скорее, не в схеме, как таковой, а в её продаже капиталистам. Что-то у меня есть большие сомнения по рыночной перспективе этой схемы. Ну, и не только у меня, видимо, потому что на рынке такой системы в продаже я не вижу даже в наше просвещённое время всеобщего глиномеса.

pokos> потому что на рынке такой системы в продаже я не вижу даже в наше просвещённое время всеобщего глиномеса.

Тут, может быть, иной эффект проявился.
Вспоминая нулевые - ПК был твой комп. С упором на ХДД. Все значимое хранилось там.
Потом потянулся интернет. Придумались облака. И, сдается мне, сегодня больше приложений отказывается работать без коннекта, чем тех, что могут работать оффлайн.

И вот в это торжество "быстрой передачи данных" (и наросших на процесс "синих писалок") и вкладывался капитал. Растущий рынок же. Быстро растущий. Чем раньше в него впрыгнул - тем больше бабла нарубил.

3-62> Тут, может быть, иной эффект проявился.
И это тоже, конечно.

Fakir>> Канторович, 1960:
Татарин> Ещё одно доказательство, что 2х2=4, и задержка с ЕС на 5-8 лет стОила стране миллиарды и убила отрасль.

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