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

Татарин> И продолжить линейку БЭСМ-6, но на новой элементной базе

Для начала пришлось бы "адресовать байт". А не слово. Для экономии дорогой памяти.
То есть, пришлось бы делать уже не БЭСМ. Нечто похожее, но иное.

Татарин>> И продолжить линейку БЭСМ-6, но на новой элементной базе
3-62> Для начала пришлось бы "адресовать байт". А не слово. Для экономии дорогой памяти.
3-62> То есть, пришлось бы делать уже не БЭСМ. Нечто похожее, но иное.
Развитие - само собой, и да, как и говорил, младшие модели чуть удобнее для масштабирования вверх, чем наоборот.

Но - нет. Это как раз "плохое послезнание", когда, по сути почти случайный, случившийся исторический выбор кажется неизбежным и наиболее верным.
Почему именно байт-то? КОИ-7 - это 7 бит, международные телетайпные коды (что крайне важно для обработки текста) - 5 или 6. Никакой нужды именно в байте нет, есть лишь нужда в обработке текста.
И аргументацию типа "8 бит хватало, а 6 - нет" отметаем сразу. 8-бит как раз заведомо не хватало, потому что алфавитов в мире больше одного латинского (это вот американцам было на всё остальное просто плевать). Глядя из 2023-го мы уже точно знаем, что потом перешлось переходить к 16-ти битам на символ, а глядя из 1960-го можно сказать, что и шести бит с указанием кодировки достаточно.

Но для системы команд БЭСМ существует несколько вполне очевидных чисто технических выходов (часть из них существовали уже и на тот момент, а другие были очевидны). Можно в комплексе.
SIMD, субадресация внутри слова, +управление переносом в быстром сумматоре (и умножителе) каким-нить флагом, что даёт возможность рассматривать слово как несколько переменных, упакованых в слово - от 48 по биту до 1 слова в 48 бит (кстати, вполне себе используется сейчас и очень выгодно для DSP, некоторые архитектуры просто даже возникли и оформились вокруг этой фичи).
Нужно было добавить флаг и несколько команд для побитовых операций (полезных и без того), и недостаток превращался бы в преимущество: например, 48-битное слово против 8-битного тратит на сравнение строки в 8-битной кодировке в 6 раз операций меньше, а в 6-битной - ажно сразу в 8 раз.
В нашей реальности этого не случилось, КМК, по причине замораживания линейки БЭСМ на их узкой, чисто расчётной специализации. Им просто никогда не пришлось обрабатывать тексты или много данных с низкой точностью, не та область. Но потребовалось бы - так псевдо-SIMD (или даже честный SIMD) прикручивается элементарно, и с большой пользой для всех видов вычислений.

Вообще, изначально более широкое слово в Стандарте имеет свои очень существенные преимущества.
Хотя бы просто из-за того, что это и более широкое командное слово, что сразу даёт возможность простого конвеера и блока декодинга. Не обязательно RISC в его сфероконической чистоте, но определённо выгоды от конвееризации простыми методами и с небольшой длиной конвеера, например. Преимущества любого уклона в CISC в компактности кода при человеческом кодировании всё равно бы нивелировались в 70-е, как только применение компиляторов и ЯВУ вообще стало бы массовым (а при написании в машинном коде ни о какой широкой компутеризации нельзя думать вообще).

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

(Чисто теоретически, можно было бы поставить в упрёк, что ширина слова - не степень двойки, но мы же знаем, что были успешными и DEC с 12-битным словом, да и как-то кроме чистой эстетики не могу себе представить, где и когда это может быть важным).

Iva> решение позволило закрыть кучу проблем "здесь и сейчас", а не в три-четыре пятилетки.
ИМХО, решение позволило ИМИТИРОВАТЬ закрытие кучи проблем. Поскольку проблемы, как уже говорилось, были не там, где их пытались решить.
Стандартный поиск потерянных ключей под фонарём, поскольку там лучше видно.

Aaz> ИМХО, решение позволило ИМИТИРОВАТЬ закрытие кучи проблем. Поскольку проблемы, как уже говорилось, были не там, где их пытались решить.

часть реальных проблем были реально закрыты.

а реальные глобальные проблемы - выход микроэлектроники на мировой уровень - они были неподъемны. И, закономерно, были не решены. Мечтать, конечно можно, но ...

Татарин> ...что были успешными и DEC с 12-битным словом
В АТС "Квант" процессор и вовсе имел чудное слово, называемое "олимпийский код".
Да что там далеко ходить, и ныне живые ПИЧки имеют размер команды от 12 до 32 бит.

Татарин>> ...что были успешными и DEC с 12-битным словом
pokos> В АТС "Квант" процессор и вовсе имел чудное слово, называемое "олимпийский код".
pokos> Да что там далеко ходить, и ныне живые ПИЧки имеют размер команды от 12 до 32 бит.
Сразу подумал о пикушках, но приводить их как пример для архитектуры общего назначения чуть постеснялся.

Татарин> Почему именно байт-то? КОИ-7 - это 7 бит,

Если немного подумать - то понятно что "маловато будет".
Но и так - 7 бит это не 36 или 48 бит, адресуемых одномоментно.

Татарин> SIMD, субадресация внутри слова, +управление переносом в быстром сумматоре

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

Татарин> 48-битное слово против 8-битного тратит на сравнение строки в 8-битной кодировке в 6 раз операций меньше, а в 6-битной - ажно сразу в 8 раз.

Только до mp3/4 потоковые операции были не слишком распространены. Так что выгода - теоретическая лишь.

Татарин> Им просто никогда не пришлось обрабатывать тексты или много данных с низкой точностью, не та область.

ВОт-вот. Хотя ОГАС, ГОСПЛАН, базы данных. Эксель.... ну да. Не на Консулах же.

Татарин> Вообще, изначально более широкое слово в Стандарте имеет свои очень существенные преимущества.

Когда есть относительно дешевый RAM.
А иначе - в 2-3 раза больше памяти уходит по сравнению с буржуинами. На те же задачи.

Татарин> Не обязательно RISC в его сфероконической чистоте,

А вот, видится мне, что он бы как раз оптимально зашел бы. В реалиях СССР.

Татарин>>> ...чуть постеснялся.
А все болгары залились/ краской и захотели слово под спойлер скрыт
По теме- Был ли в СССР 6502. В Болгарии производился Правец 8 6502 клон Apple II.
Как студент начал с ЕС и фортраном (1981 год) потом Правец 8. Студент теплотехники сдавал зачет по Ассемблере на 6502 . Зачет сдал и понял, что быт программером, это мое будущее.

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

Там память разная. И то что "фрейм регистров" - в разрядность АЛУ адресуется. Тоже вариант годный. Но снова не БЭСМ.

Татарин>> Почему именно байт-то? КОИ-7 - это 7 бит,
3-62> Если немного подумать - то понятно что "маловато будет".
А на что не хватит? См. UTF-8, который случился много позже, а мог бы раньше и назывался бы как-нить типа УКОИ-7.

3-62> Но и так - 7 бит это не 36 или 48 бит, адресуемых одномоментно.
Так я и говорю, что пойди в массы решение с переменным размером данных, у нас была бы (и казалась бы совершенно естественной) обработка строк с "некратной" битностью на символ.
Например, тем же текстам программ или человеческим текстам на большинстве алфавитов более чем достаточно 7 бит.

Татарин>> SIMD, субадресация внутри слова, +управление переносом в быстром сумматоре
3-62> Это тоже придется АЛУ допиливать и архитектуру переделывать.
Архитектуру не переделывать, а расширять.

Переделка АЛУ при этом минимальна и добавляет всего 1 гейт в полную цепочку исполнения.

3-62> И все еще удивлен, отчего у нас "не выстрелило" одно из массовых направлений - ПЛК. Там бы сразу стало понятно, что адресация должна быть до "наименьшей обрабатываемой единицы". В случае ПЛК - это до бита.
У нас выстрелило, но сильно позже. См., например, серию NeuroMatrix от "Модуля" - там на этом просто упор: большое слово, которое бьётся на слова определяемой битности - от 1 до максимума, при этом любая оперция - SIMD с возможностью тривиального использования всего слова.

Татарин>> 48-битное слово против 8-битного тратит на сравнение строки в 8-битной кодировке в 6 раз операций меньше, а в 6-битной - ажно сразу в 8 раз.
3-62> Только до mp3/4 потоковые операции были не слишком распространены. Так что выгода - теоретическая лишь.
Пересылка и сравнение строк и массивов, операции над массивами - чрезвычайно популярный примитивы с самой зари программирования. И в расчётном мире (числомолотилки освоили SIMD в первую очередь), и в программах общего назначения (перемещение бинарных блоков - куда без него?).
Ну и произвольная длина данных в слове упрощает очень многие вещи.

Татарин>> Вообще, изначально более широкое слово в Стандарте имеет свои очень существенные преимущества.
3-62> Когда есть относительно дешевый RAM.
И да, и нет. В смысле - да, в системах с малым размером слова память расходуется лучше, но - нет, преимущества по расходу памяти не столь велики как кажутся, и уж точно не кратны разнице в размере слов.
Размеры слова данных - вопрос кода. Тип "union" в С появился не просто так, а как раз наследник времён, когда об экономии памяти думали. Тут же, раз вопрос обязательно стал бы ребром, пришлось поддержать подобные штуки аппаратно.
Ну а преимущества малого размера командного слова раскрывает только CISC, и тут чудес-то нет: мало бит в команде - маленькие возможности кодировать команду, маленький регистровый пул (а то и вовсе всё крутится вокруг одного аккумулятора + добавочки), откуда следует большое количество команд на то же действие. В итоге экономия получается небольшой - ну, пусть даже будем считать что в 1.5-2, но какой ценой?
Усложнением декодера, увеличением задержки на команду (или усложнением-увеличением конвеера позже).

Очень частая ошибка (даже у знаюзих вроде, людей) при подобном сравнении - считать не код в целом, а команды. Вот смотри на код обращения к полю структуры/класса, чтобы прибавить 2 (я не помню, да и не знал никогда машкодов IBM360, поэтому как пример беру 8086 как типичный развитый CISC с 8-битным командным словом - предел экономии! ):
MOV AX, [BX+SI+struct1.field2]
ADD AX, 2
MOV [BX+SI+struct1.field2], AX

В коде -
8B 46 field2 offset

Круто, да? Компактно, и всё такое. Но. У тебя в BX (и только там) должен быть адрес структуры, в SI - базовое смещение, при этом в DS у тебя обязательно должен быть уже установлен верный сегмент.
То есть:
MOV AX, сегмент_данных
MOV DS, AX
MOV BX, адрес
MOV SI, смещение; #да можно и наоборот, пофиг
MOV AX, [BX+SI+struct1.field2]
ADD AX, 2
MOV [BX+SI+struct1.field2], AX

B8 XX XX # сегмент_данных
8E D8
BB XX XX # адрес
BE XX XX # offset
8B 46 XX XX # field2 offset
40
89 46 XX XX # field2 offset

Уже немного хуже, да?

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

Теперь вполне типичный RISC, RISC-V 32 бита (командное слово в 4 раза больше!):
lw t0, 0(x1) # загрузить указатель на структуру в регистр t0
lw t1, 8(t0) # загрузить значение поля field2 в регистр t1, используя смещение 8 байт относительно начала структуры, которое было определено на этапе компиляции
addi t1, t1, 2 # увеличить значение поля на 2
sw t1, 8(t0) # сохранить обновленное значение поля field2 обратно в структуру, используя тот же смещение

83 01 00 00 # lw t0, 0(x1)
83 09 08 00 # lw t1, 8(t0)
93 21 01 01 # addi t1, t1, 1
23 09 08 00 # sw t1, 8(t0)

При этом у RISC-V с формально в 4(!!!) раза более широким командным словом, огромным симметричным и прямо адресуемым регистровым пулом код короче, чем у 8086. То есть, у RICV-V запросто может и не потребоваться лезть в память за смещениями (да и реально часто не требуется у RISC).
Ладно, меня сейчас закидают тапками, покажут, как на 2 инструкции сократить код 8086, напомнят про оптимизирующие компиляторы, которые сейчас ещё и не такое выкрутят, но вот он факт как есть: разница по коду в целом на одной из самых частых операций - минимальна.

При том, что даже на самой заре вычислительной техники задачи обычно требовали больше памяти под данные, чем под код.
Чисто теоретически можно (как сейчас некоторые делают) рассматривать CISC-код с малым словом (и БОЛЬШОЙ кучей префиксов-суффиксов-постфиксов) как способ архивации команды и экономии полосы на шине память-процессор. На практике неизвестен ни один процессор, который получал бы выгоду от этого (а вот проигрыш может быть и типично бывает ОЧЕНЬ велик). Потому что - см. выше.
Да, можно найти код, где CISC будет компактнее (да и в целом по коду это так). Но выигрыш в размере кода ВОВСЕ не так велик, как кажется.
И уж точно не 3 раза, как поминается выше.

3-62> А иначе - в 2-3 раза больше памяти уходит по сравнению с буржуинами. На те же задачи.
Реально - даже близко не так.

Хотя как раз Факир цитирует какого-то горе-академика с примерно теми же рассуждениями.

Fakir> Ждут коллекционера - пока на Сотбис им наверное рано еще

В Музей компьютеров отдать в Переславле.

Татарин>> Минские предпочтительнее именно потому, что они маломощные. Тебе может показаться парадоксальным, но на том этапе развития масштабироваться вверх было сильно проще
Fakir> Насколько лично я понял из цитаты - масштабироваться вверх они не стремились. Значит, если и пошли бы вверх - то не очень скоро. А задач для больших (ну или средних) машин в те 5-10 лет у нас не было? Потребность в таких машинах была или нет? Если да - то какая, и кто бы её удовлетворял?
1. Что значит "не стремились"? Это ж СССР. Было бы постановление - стремились бы. Они или другие. БЭСМ - тоже не самозародился, была поставлена цель, выделены ресурсы. Ровно точно так же решалась бы задача высокопроизводительной машины с системой команд "Минска".
Нет, разумеется, при этом было бы очень много мата со стороны тех, кто был бы вынужден вместо свободы творчества приспосабливать технические архитектуру "Минска" на более производительные ниши, но кроме выбора системы команд уже тогда знали много ходов и трюков повышения производительности, а подобная задача бы их только стимулировала. В БЭСМ-6 (60000 отдельных транзисторов) уже была виртуальная память, аппаратная поддержка многозадачности, кэш (в том числе - отдельный кэш команд), конвеер декодирования. Эти решения переносятся на систему команд "Минска".
Понимаешь, система команд - да, задаёт совместимость, но она не полностью определяет архитектуру. И тогда это понимали, просто... просто запилить систему команд под свою задачу каждой команде казалось проще всего. Вот тут-то, казалось бы, и вмешаться той организующей силе, которая сувала свой нос, руку и член куда ни попадя, во все аспекты жизни, но...

Один из путей был просто выделение спецАЛУ для расчётов со своей системой команд, в то время как за процессором общего назначения оставалось управление процессом. В 50-60е этим не очень заморачивались (попытки были, в том числе в СССР с той же БЭСМ/Эльбрусом, но не очень прижились как массовое решение), потому что каждой гениальной команде казалось, что проще сплодить ещё одного своего зверя в зоопарке. Но вот когда победители в битве стандартов определились, это стало привычным делом. Есть процессор, а есть математический сопроцессор. Есть система команд х86, а есть дополнительно набор команд MMX, AVX, 3dnow, и что там ещё. Это не ухудшает общей совместимости, но даёт возможность использовать весь системный и бОльшую часть прикладного софта. Или вообще весь софт, если добавлен один уровень абстракции - в виде разных подключаемых библиотек на уровне софта, безусловных немаскируемых прерываний на уровне софта-железа, микрокод на уровне чистого железа и т.д. и т.п.
Варианты были, и они были известны. Собссно, тогда это всё по бОльшей части и придумали.
И да, точно так же, как сопроцессор к процессору могла разработать сторонняя фирма (к интеловским разрабатывали, даже несовместимые), вполне возможно было занять разработкой сверхпроизводительного и специализированного (специализированных) АЛУ другую контору. Были бы стандарты на шину и интерфейсы.
И это не моя выдумка - см. советские матсопроцессоры для машин архитектуры PDP-11.
И это вовсе не единственный путь.
Можно было, например, вынести числовой спецпроцессов вообще за пределы контура управляющей машины и обще системной шины, фактически, прикрутив отдельную ЭВМ-числомолотилку к некой ЭВМ общего назначения (с ОС, со всей требухой ввода-вывода и вот всем этим). В нашей реальности так случилось с видеокартами, которые считают 3д-сцены: слишком большой оборот данных, слишком много массивных вычислений, слишком высокие требования к перемолу чисел, чтобы использовать процессор общего назначения. Можно было было и так (и это не было каким-то супер-откровением и тогда), в этом случае вопрос сверхвысокой производительности полностью изолируется от вопроса с ОС. Компиляторы допиливать нужно было, но это опять же вопрос правильного выбора общей архитектуры. Люди, которые в бюджете 60 тысяч транзисторов запилили 48-битный процессор, с виртуальной памятью, развитой системой воода-вывода, прерываниями, прямым доступом в память кэшем и вот со всем этим, наверное (сарказмъ), справились бы с определением правильной границы и интерфейсов на ней, да и с написанием расчётных библиотек под спецпроцессор - тоже.

2. В нашей реальности, если ты не в курсе, низкопроизводительные машины вообще оставили сами себе на много лет. И ничего. Что такого катастрофичного для страны ты рисуешь в варианте "для "Ряда" взяли за основу "Минск", а БЭСМ развивалась сама по себе", "естественным" образом, под заказчиков, только без названия и единого брендинга?
Хуже, чем получилось в нашей реальности, уж точно никак бы не получилось, потому что в нашей реальности мы тоже были вынуждены развивать БЭСМ, только уже на остатки от пира и по-комсомольски превзнемогая трудности.

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

Fakir> Но ты не то что не отвечаешь на все эти - вполне органичные - вопросы практического характера, а они почему-то для тебя вообще как будто не существуют!
Потому что их не только для меня, их вообще не существует. И для ЛПР не существовало на тот момент: принимали же решение по ЕС, а не по комплексу из двух линеек ЕС+СМ. Ведь правда? Так всё, чем ты можешь напугать, в нашей реальности случилось, причём, в самом худшем варианте.
Так в чём, собссно, вопрос?

Fakir> У меня начинает возникать подозрение, что тогда перед ЛПРами вопрос стоял даже не в форме "решить это более или менее оптимальным образом", а "можем ли мы вообще как-то гарантированно сделать это в разумные не слишком большие сроки, не оставшись без штанов?"
Во-первых, подозрение у тебя возникать начало, а у них вопроса такого не было.
Почему? А очень просто - иначе б в СССР не продолжали бы клепать БЭСМ после создания ЕС, не затевали бы работ по клонированию других линеек и вообще не происходило бы очень многого из того, что в реальности происходило.
Во-вторых, это не было в том виде в котором ты себе это представляешь - мол, там за океаном есть Фичи и Софт(тм), а у нас нету, и вопрос - делаем ли мы своё или пытаемся передрать. Нет. Своё было, было железо, были примерно те же фичи, был примерно тот же софт, и всё это туда-сюда было где-то схоже.
Даже сторонники того решения (а они максимально предвзяты и даже местами откровенно и чётко лживы) в мемуарах указывают на отставание в 5-7 лет, что для этой области техники очень много, правда. Но всё же не 10-15 лет ГАРАНТИРОВАННОГО НЕУСТРАНИМОГО отставания, которое было прямым и явным, совершенно очевидным следствием решением копировать.
Почему - я уже неоднократно говорил. И да, это уже на уровне простой логики: копировать можно только после получения оригинала. А в момент получения оригинала в СССР, он уже продукт промышленной серии и отстаёт от уровня штатовских разработок на 5-7 лет. Добавь 5-7 лет на копирование и мы получаем то, что и получили в реальности: отставание в производительности за те же деньги в десятки-сотни раз, ибо за это время сменилось поколение.

Что тут непонятно? Какой именно конкретики тебе не хватает?
Привести пример с копированием DEC? или на клонах ИБМ тебе показать? Можем взять конкретную модель, мне легко.

Татарин>> 2. Писателей системного софта системно же рубим. Потому как "не нужны", у нас же "стандарт".
Fakir> Было кого рубить? Если верить цитатам выше - за системный софт вообще никто браться не хотел. Значит, или автор цитаты нам привирает, или что-то здесь не то. И рубить было попросту некого.
Да, конечно.
И для БЭСМ люди писали (и там-то как раз был нормальный, как потом во всём мире кроме СССР, процесс - когда системщики плотно работали и с железячниками, и с пользователями). Пакеты программ, может не были настолько "широки", как у ИБМ, но свои задачи закрывали "глубоко" и качественно. Я не могу сейчас сравнивать напрямую, но бОльшая часть функционала более поздних и "старших" ОС для "старших" машин БЭСМ закрывал с лихвой.
Для "Минсков" всё было похуже, но по сути - тоже отлично опять же в рамках их задач. А вне этих задач, задач в СССР, которые закрывались бы только ИБМовским софтом, просто не существовало.

Fakir> - Это утверждение - как бы не центральный момент в твоих рассуждениях.
Fakir> Чем его можно доказать? Или ну хотя бы подкрепить? Что вот экономии на софте не вышло, а системно написать кто-то вполне осилил бы?
Во-первых, наличие набора ОС и компиляторов для машин до-ЕС эпохи говорит само за себя однозначно. Тут как бы на этом и всё: вот оно, уже есть, богатое, именно то, что нужно в СССР, развивай далее и будет счастье. Тут не мне "подтверждать" нужно, а наоборот - покажите мне софтину или фичу, которую не могли написать, и в которой так крайне на тот момент нуждался в СССР в следующие 5 лет, что пустил под откос всю свою промышленность вычтехники.
М?
И что же это такое было, интересно?

Во-вторых, жизнь показала, что из всего богатства ИБМовского софта в вычцентрах СССР использовали потом... та-дам! да саму ОС, в общем-то, и всё. Ну, плюс всякие средства ввода-вывода, коммуникации и прочее, что даже не считаю. И то - не на полную. Если есть возражения (а могут быть, я этот мир застал самым-самым краешком, и то - скорее "туристом", так что по личным воспоминаниям работавших из первых рук) - опять же: ну покажите, что же именно там было такого офигенного, что нужно прям как бомба в 1945-м, пофиг на страну, пофиг на будущее - нужно здесь-и-сейчас? Что это было?

Татарин>> Реально объём тогдашнего системного софта невелик. И бОльшая часть системного софта ИБМ 360 в СССР была просто излишня. Да, вот прямо так. Посмотри лист прорывных фич ОС 360 (а они там некоторые реально прорывные) - зачем вот это вот в советском вычцентре 60-х? На-фи-га?
Fakir> - Даже допустим так. Виделось ли это так из 60-х? Сколько человек могло бы тогда с таким тезисом согласиться, если он вообще кому-то в голову приходил?
Не "даже допустим", а так. Вообще, типичный размер оперативки был порядка 1-2Мб, для младших моделей (модель 30) - вообще 8-30 килобайт. Как ты сам думаешь, каких размеров системное ПО, резидентно размещённое в оперативке, там могло бы быть? Мегабайт, наверное? Если что - ногами утолкаем или поверх друг друга код слоями уложим? Ну, ты помедитируй над этими числами.
И да, PCP как бы не уступала TR DOS на моём "Спектруме" (у того ещё 16кб ПЗУ было для базового ввода-вывода, и всё ж 8-битка была попроще, да и код Z80 один из рекордсменов компактности). TR DOS я видел, и опыт писания в машинных кодах имею. Нет, будучи школьником, я б такое за год не написал бы (2-3 - минимум)... но это совершенно точно не задача масштаба страны. И точно не вопрос триллионов рублей, которые Союз просрал этим решением.
Были ли в 60-е люди, которые могли оценить размер ОС в килобайтах и оценить время на написание сравнимого? Ну, как бы это так, вежливо... думаю, были. Это что касается размера основного софта.

Что касается плюшек, продвинутых фич и прочего вкусного... Вот опять же, согласись, что для принятия такого безумного решения, нужно быть уверенным, что там нечто такое, та-акое полезное, что вот оно просто необходимо. Просто за абстрактное "мож, у американцев там в этой куче софта и нам полезное найдётся" такие решения приниматься не должны. Так вот что ЭТО было?
Оно ведь потом, наверное, везде использоваться должно было интенсивно, чтобы оправдать этот просёр и размен (отставание в производительности в10-100 раз и функциональности до кучи лет на 10)? Оно должно же быть общеизвестным, чтобы любого пользователя ЕСки спроси ночью, и он да - вот такая фигня ж была, уж не знаю, как бы мы без этого жили! Пусть, мол, медленно и фигово, и на копии, но вот без этого софта - не, не жить нам, работать было бы нереально!
Ну, так ЧТО? в нашей реальности - ЧТО это было?

Fakir> Какие ресурсы (в людях и времени) понадобились бы на написание того, что осталось?
Так а всё уже было.
И да, БЭСМ-6 имела железные и софтовые фичи на уровне старших линеек ИБС 360. И улучшенный аналог MVP, и работу с виртуальной памятью, и многозадачность.
Сиди и пили себе далее спокойно. Будет там и вытесняющая многозадачность, и приоритетизация, и базы данных (когда появится железо для хранения тех БД), всё по мере надобности.
Нужно попроще - допиливайте "Минск" или отпиливайте куски от БЭСМ-6, перетягивайте новые машины на новую элементную базу, расширяйте архитектуру.

Fakir> Даже как видится сейчас - для любого ли вычцентра это справедливо (бОльшая часть не нужна). Или только для части машин/вычцентров?
Для любого советского вычцентра определённо куча ИБМовского софта была лишней.

Fakir> Понимаешь, все эти твои рассуждения - они ну очень общие. Насколько они надёжны и справедливы в контекстах - да фиг пойми, не будучи глубоко в теме.
Fakir> Будь я на месте условного зампредсовмина 60-х - я бы не смог понять не только смогут ли твои предложения решить проблемы страны, которые вотпрямща, а даже верны ли они на долгосрочном горизонте.
Fakir> Вот пока в этой ролевой бизнес-игре ты меня не убедил
Так понимаешь, беда-то в том, что это не то чтоб о них как-то хорошо говорит.

Это говорит о тебе плохо, уж извини, но вот...

Я могу вдаться в конкретику, насколько я её знаю, но насколько ты готов уходить в технические детали?
У меня такое ощущение сложилось, что в этом разговоре ты их как-то избегаешь. А у меня ДОФИГА есть чего сказать по поводу того безумия, которое творилось далее.

Fakir> - а теперь представь, что решили попробовать догнать путём своего пути (простите), затратили еще больше ресурсов, чем в Текущей Реальности, и... не получилось. Вероятность такого расклада ИМХО стремится к 100%, но и ты, вероятно, согласишься, что она как минимум ненулевая.
Нулевая. Строго нулевая в математическом смысле.

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

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

Всё, что нужно было - принять стандарт на линейку (пусть 2 линейки, пусть) и пустить в серию. ВСЁ.

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

...
Ха! Как бы не так!
В КПСС умудрились творчески выйти за рамки задачи "выбери худшее из советского", не просто расширить задачу нанесения вреда механистически до "выбери худшего из мирового", а найти новый креативный вариант засрать всё намертво и навсегда: сделать копирование чужого стандарта и гарантированного запрограммированного отставания промышленной политикой и стратегией!

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

Ладно, допустим (пусть даже так!) в какой-то момент был некий Софт с Фичами, в котором СССР отстал на 5-7 лет. Но разве это одномоментное отставание (с возможностью догнать, никаких проблем, просто больше программистов) - по твоим же рассуждениям - проблема?
Ты же считаешь не то, что допустимым, но и полностью нормальным запрограммированное отставание всей отрасли, включая железо, на 10-15 лет? ты же считаешь, что внешние рынки отрезаны (ну, с клонами-то - понятно, да)?
Почему же тогда "отставание в софте" (не "вообще", а в конкретном, системном, и мифическое по сути) в 60-е на 5-7 лет может быть проблемой?

...
И ведь это ещё не весь звездец.
Снова перечислить, что там было после выхода клонов ИБМ 360?
Что, каждый раз догоняли?
И не могли догнать?

Удивительно же, воистину, ну как так-то? Копируем устаревшую на 5 лет модель за 5 лет, и получаем выход на 10 устаревшей модели. Как же так получается? Да что ж за рукожопы-то такие в промышленности? Сплошное отставание, блин.

Вот тут простая логика, казалось бы? Если ты каждый раз откатываешься на буржуйское старьё, и тебе нужно время на разработку, ты гарантированно, уже по самой программе действий отстаёшь, так?
А если гарантированно всегда отстаёшь, то, наверное, никогда не догонишь?
Простая логика?

Не-ее, как показывает эта тема - не, нифига.
Отсталая лапотная Россия, необходимость "догонять" (через уничтожение своих разработок и копирование с отставанием? Не, нормально, это марксизм и диалектика), монгольское иго, царизм и ВМВ.

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

Татарин> А на что не хватит?

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

Татарин> Так я и говорю, что пойди в массы решение с переменным размером данных

А как это гостировать? Стандарт он должен был крепок и един!

Татарин> Архитектуру не переделывать, а расширять.

Разница велика ли?

Татарин> У нас выстрелило, но сильно позже.

И тоже как "копия ихнего".

Татарин> Тип "union" в С появился не просто так, а как раз наследник времён, когда об экономии памяти думали.

ИМХО - это для удобства обхода ограничений на операции с типом данных. Которые введены в языки высокого уровня для... защиты от.

Татарин> Ну а преимущества малого размера командного слова раскрывает только CISC

А еще, наверное, толстый техпроцесс ограничивающий количество элементов на кристалле.

Татарин> но какой ценой?

Работает и выпускается массово, а не "кремний в отходы". Мало?

Татарин> Усложнением декодера, увеличением задержки на команду (или усложнением-увеличением конвеера позже).

Татарин> Но у тебя же идёт код программы.

Это все известно. Спасибо.
Как и появление для удобства PUSHA/POPA.

Татарин> И уж точно не 3 раза, как поминается выше.

Если у вас нет "упакованной обработки" и надо хранить байт, а адресуется только 4 байта... то есть проблема с использованием памяти.

intoxicated> Во вторых из за слабой иновативности и креативности, т.е. создание и разрабатывание новых образцов.

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

как то в оборонке это смогли решить созданием НПО, когда завод подчинен конструкторам. Но дальше оборонки это плохо работало.
Скорее всего, так как оборонке ордена и машины выделялись в большем количестве, чем прочим.

Татарин> Будь Вы в теме, достаточно было бы сказать, как я сделал в начале - "копирование ЕС с ИБМ" и "зоопарк советских систем в конце Союза". То, что это г**но - самоочевидно для любого в теме, только тут и только вам приходится объяснять.

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

Татарин> При этом у RISC-V с формально в 4(!!!) раза более широким командным словом, огромным симметричным и прямо адресуемым регистровым пулом код короче, чем у 8086.
Дык. РИСЦ-5 начинался с РИСЦ-1, который начинался с пары диссеров по статическому и динамическому профилированию реальных программ и занятной идеи регистровых окон.
А 8086 начинался с убогого минимализьма 8080 и тащил его сквозь тернии к звёздам.
Милейший Z80 - тоже сын 8080, но с грамотным подходом к развитию, особенно спасает пара индексных регистров. Потому и полюбился всем.

Татарин> ... просто запилить систему команд под свою задачу каждой команде казалось проще всего.
Дык. Особенно, когда появились т.н. "микропроцессорные наборы" с ПЛМ микрокоманд, где можно было легко запилить вообще любую систему команд.
Татарин> ...каждой гениальной команде казалось, что проще сплодить ещё одного своего зверя в зоопарке.
Во-во. Это наше всё. Когда пошла мода на РИСЦ, в каждом журнале МПСС было по статье с очередным РИСЦ-процессором, сваянным из каких-нибудь ПЛМ и мелкой логики. В результате, никакого отечественного РИСЦ процессора широкого применения так и не родили. Думается, это потому, что не было нормального системного подхода, а было привычное копирование зарубежных подходов. Что тут удивительного, привычку пилить по зарубежным лекалам, к тому времени, воспитывали уже лет 20.

101> Я уже понял, что вы графоман, но меня интересует больше фактический материал, если вы не поняли.
Я уже понял, что Вы полностью игнорируете все аргумены и факты, что Вам не нравятся. А потом снова задаёте те же самые дебильные вопросы, на которые дан подробнейший ответ, и пишете так, как будто ничего до этого сказано не было.

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

101> Часть того, что вы декларирует не бьётся с тем, что я видел.
Значит, Вы либо ничего не видели, либо не понимаете, что видели, а все "видения" - отголоски коммунистического речекряка и вашего преступстопа. По нашему разговору, я склоняюсь ко второму.

Технической конкретики по этой "части" ведь Вы не приведёте?
Потому что не-графоман, так?

intoxicated> Опять сугубо ИМХО .... опять таки - это не из за воспринимания буржуйских стандартов. Проблемы во первых из за очевидной невозможности быстро разрабатывать и массово осваивать новейшие технологические процессы. Во вторых из за слабой иновативности и креативности, т.е. создание и разрабатывание новых образцов.

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

Да и сложнее там всё, непонятнее, с этими "искусственными мозгами".

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

Татарин>> Так я и говорю, что пойди в массы решение с переменным размером данных
3-62> А как это гостировать? Стандарт он должен был крепок и един!
А как "гостировали" Unicode c UTF-16 и UTF-8? Или, скажем, BCD?
Точно так же: определяем стандартом префикс, указывающий на кодировку (попросту, недостающие биты упакованных данных) и битность упакованных данных.

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


Татарин>> Архитектуру не переделывать, а расширять.
3-62> Разница велика ли?
Огромна и принципиальна. Вот у 80486 была инструкция CPUID, а у 80386 - не было. У Пентиума был MMX, А У 80486 - не было. И как это сказалось на общей совместимости линейки? Да никак, с точностью до этих инструкций.
Код младших продолжал бежать на старших, поздний код учитывал и учитывает наличие старых (и менее продвинутых) моделей, которые не имеют каких-то инструкций.
Совместимость по умолчанию снизу вверх - этого уже достаточно для большинства случаев, а сверху вниз - легко достижима незначительными усилиями (а если их ленятся прилагать, значит, и не нужна).
У нас есть, вообще говоря, прекрасный пример расширяемой архитектуры и кодсета перед глазами - х86 с наследником х64. В том числе пример прозрачного перехода на полностью бинарно-несовместимый код (с х86 на х64) без потери общей кодовой базы.

Совершенно другой пример - переход с БЭСМ на что-то из ЕС.

Татарин>> У нас выстрелило, но сильно позже.
3-62> И тоже как "копия ихнего".
Эээ... поначалу не догнал, но NeuroMatrix - очень оригинальная архитектура. И они делали оптимизированный для нейросетей процессор - в 0-е!
Я не знаю ни одной альтернативы той поры, не говоря уж о том, чтоб откуда-то скопировать.

Татарин>> Тип "union" в С появился не просто так, а как раз наследник времён, когда об экономии памяти думали.
3-62> ИМХО - это для удобства обхода ограничений на операции с типом данных. Которые введены в языки высокого уровня для... защиты от.
Эээ...
Ну да, сейчас-то оно так и используется всякими нехорошими товарищами. Но оригинальная мысль предполагала использование в виде чего-то типа
struct fields_tag {
unsigned int five:5;
unsigned int three:3;
};

typedef union some_reg_tag {
uint8_t raw;
struct fields_tag fields;
} s

тогда
five = 5; // валидные значения 0..31
three = 3; //валидные значения 0..7

Ну или там DWORD на байты поделить (наш случай ). Что-то вроде того, короче. Компилятор сам проводил все операции с битовыми масками и сдвигами, программисту об этом думать не нужно.
Как выяснилось на практике, программистам не нужно думать о всяких таких вещах по другой причине: память дешёвая, а программистам лень. Но инструментарий создавался в чуть иные времена, и он был.

Татарин>> Ну а преимущества малого размера командного слова раскрывает только CISC
3-62> А еще, наверное, толстый техпроцесс ограничивающий количество элементов на кристалле.
Так CISC всегда "жирнее" на кристалле, чем RISC той же или бОльшей производительности.
Это плата за декодирование.
Декодер с конвеером, усложнённый аппарат предсказания переходов, сложная система перевода инструкций во внутренний RISC, дополнительные уровни кеширования микроинструкций. В современном х86 - чёрт ногу сломит.
А RISC для раскрытия производительности требует большого размера команды (большой регистровый пул нужно чем-то кодировать, ну и максимальная симметрия кода даже при примитивных командах требует много места; конечно, можно сделать RISC и с маленьким командным словом, но он будет не очень функционален).

Татарин>> но какой ценой?
3-62> Работает и выпускается массово, а не "кремний в отходы". Мало?
80386 содержал 275 тысяч транзисторов. 32-битный RISC - вдвое-втрое меньше (при бОльшей производительности, потому что у 80386 эти транзисторы не просто сидят на кристалле, а находятся в цепочке сигнала и тормозят выполнение команды).
Тут как бы наоборот.

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

И это ж не единственный выход.
См. современные 64-битные процы (где физически, конечно, адресуется именно 8-байтное слово).
Или смотри набор команд SSE2: 256 бит слово не означает, что работа может идти только с 256-битными величинами.
Современные процессоры сочетают эти два метода работы с меньшими размерностями, но я с ходу могу назвать ещё с пол-дюжины (и, наверное, для тех времён, 48-бит слова и конкретно БЭСМ-6 будет проще и лучше ввести широкую аппаратную поддержку работы с битами/битовыми полями + арифметику переменной размерности а-ля 1879ВМ1).

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

Татарин> Современные процессоры сочетают эти два метода работы с меньшими размерностями,
А среди несовременных был такой IAPX 432, в котором ох как биты экономили. Канул из-за ненужной сложности.

Татарин>> Современные процессоры сочетают эти два метода работы с меньшими размерностями,
pokos> А среди несовременных был такой IAPX 432, в котором ох как биты экономили. Канул из-за ненужной сложности.
Там было много чудесатого, усложняющего и процессор, и разработку.

Чисто как пример, там была почти-строгая аппаратная типизация указателей. Казалось бы - хорошо, что накосячить нельзя, но на практике работа с указателями превращалась в гемморой.

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

...
Кстати, типичный пример попытки революции сверху ради "всего хорошего". Только Интел, в отличии от КПСС, не убивала финансирование эволюционных альтернатив.

Татарин> 80386 содержал 275 тысяч транзисторов. 32-битный RISC - вдвое-втрое меньше
"Проект «RISC» произвёл на свет процессор «RISC-I» в 1982 году. В нём было 44 420 транзисторов (для сравнения: в процессорах «CISC» того времени их было около 100 тыс.). «RISC-I» имел всего 32 инструкции, но превосходил по скорости работы любой одночиповый процессор того времени."
Конвейер у него имел всего две ступени, поэтому, будучи испечённым на отсталой фабрике, он по частоте работы делал все современные ему 32-битные процы, которые пеклись на самых передовых заводах. Заметим ещё, что операнды у него всегда проезжали через циклический сдвигатель, поэтому и с адресацией массивов вообще никаких проблем не было. Оставалось прикрутить грамотный менеджер памяти - и вот вам Sun 4, который при одноплатном исполнении вполне мог гордо именоваться "рабочей станцией".

Из советских же последователей буржуйских архитектур были и вполне годные и интересные изделия типа 1806ВМ2. В родном ВУЗе из него сделали персоналку и портировали UNIX. Оконная графика и все пироги ездили весьма шустро. Ксож, перестройка его убила.