любопытный гибрид — СМ-1600. Это двухпроцессорный комплекс: рядом с СМ-4-совместимым процессором (то есть архитектурой PDP-11) стоял второй, понимавший систему команд М-5000
Ну, во-первых, скорей, с СМ-1420-совместимым: у СМ-1600 и MMU выдавало 22-разрядный физический адрес, а не только 18-разрядный, как у СМ-4, и полноценный FPU был, чего у СМ-4 не было (на ней были только четыре команды так называемого набора FIS -- вещественные сложение-вычитание-умножение-деление для 32-разрядных чисел, лежащих в вершине стека; FPU же работал с 32- и 64-разрядными вещественными, которые могли быть в его регистрах и памяти).
А во-вторых, там весьма любопытно с ОС было. На СМ-1600 перенесли ДОС с М-5000. Сама система и все прикладные задачи крутились на спецпроцессоре, но ввод-вывод полностью отличался, поэтому в этой самой ДОС его переделали: когда надо было выполнить ввод-вывод, ОС на спецпроцессоре кидала прерывание основному процу с системой команд PDP-11, и он уже выполнял все операции по вводу-выводу, а завершив их, кидал ответное прерывание.
Точно планировали сделать поддержку спецпроцессора в ОС-РВ (наш клон RSX-11M), чтобы на СМ-1600 можно было крутить как задачи от М-5000, так и родные PDPшные -- но, похоже, сделано это так и не было.
Строго говоря, вполне возможна ситуация, когда любые целочисленные типы (char, short int, int, long int, long long int) имеют идентичный размер. Стандарт ограничивается лишь требованием, чтобы каждый последующий тип был не меньшей ширины, чем предыдущей, и что int должен быть как минимум 16 разрядов.
Выравнивание -- тоже отдельный вопрос. По умолчанию выравнивается по смещениям, кратным размеру типа, но это поведение можно изменить.
512 бит! Слова за счёт параллельных трубок :) На самом деле, в разумных пределах вибрации и прочая не особо-то мешали: трубки залиты до отказа, плескаться ртути негде, поэтому распространение звука особо не страдает.
Вот у меня примерно тот же самый вопрос, а точнее: что, код режима пользователя может выполнять операции записи прямо в регистры устройств, в частности, контроллера памяти? Если нет, то ничего поменять не удастся. Если да -- то это показывает кривизну используемой ОС, которая не должна давать такую возможность приложениям. (Вот драйверы и прочие модули режима ядра такое творить могут, да -- но это другое).
Ну так это сейчас лишь для собственного любопытства, а "в древности" линии задержки (но таки ртутные, а не воздушные) использовались для хранения информации весьма часто. Собственно, их применению в вычислительной технике окончательно наступил конец лишь с появлением ферритовой памяти, которая быстро вытеснила все предшествующие конструкции.
На обычном коде без DSP-инструкций это были бы CMP + ветвление на каждый отсчёт
Строго говоря, и обычными средствами можно обойтись без переходов, используя команду IT, но, понятно дело, в специализированных случаях специализированные средства эффективнее -- команды DSP не просто так ввели.
ачем промышленность выпускала 2 совершенно идентичные с программной точки зрения машины
Таких случаев у нас 100500. В частности, в рамках АСВТ производились и IBMовские мэйнфреймы, и HP2100, и PDP-11 -- но они же производились и в рамках ЕС ЭВМ и СМ ЭВМ. А были ещё, как Вы указали, всякие разные "Электроники".
Но мне кажется (проверять лениво), что Электроника-100/25 -- это уже не СМ-4, а куда более современный вариант PDP-11...
Относительно СМ-1420 - я могу ошибаться, но именно там появилась поддержка I-Space/D-Space,
Нет, не было там разделения на пространства команд и данных, функционально MMU у СМ-4 и СМ-1420 идентичны, за исключением ширины физического адреса. Из известных мне советских машин деление на пространства кода/данных, а заодно поддержку трёх, а не двух режимов процессора, а соответственно, шесть, а не два набора регистров APR имела лишь СМ-1425, построенная уже на, по сути, микропроцессоре, а не на рассыпухе (основа процессора -- 2 микросхемы, ещё пара дюжин микросхем -- шинные формировали, тактовый генератор и всё такое вспомогательное; в проце СМ-1420 порядка 700 микросхем, включая 20 секций К1804ВС1, 18 ПЗУ КР556РТ5, содержащих микропрограммы, и так далее).
именно конфигурацию СМ-4 + ДВК-2 в качестве терминала я видел своими глазами)
Технически это возможно, но почти бессмыслено на практике: производительность ДВК-2 сопоставима с производительностью СМ-4, а то и превосходит её (сам микропроцессор К1801ВМ2, являющийся основой ДВК-2, может выдавать 1 млн оп/с -- против 700 тыс у СМ-4; команды EIS он тоже поддерживает), у последней два реальных достоинства -- наличие MMU, а значит, возможность гонять полноценную RSX-11M (ОС-РВ), а не только примитивную RT-11, и команды набора FIS (4 операции с вещественными 32-разрядными числами). Но в то же время ДВКшка -- это ПК, в твоём полном распоряжении, а СМка -- коллективного пользования...
Может, как предположили в комментариях, Вы видели похожий на ДВК терминал -- такие были, только не помню, какие (я их только видел, но не работал с ними).
Отдельное спасибо за Ваш труд
Всегда пожалуйста :) Если вдруг обнаружите какие-нибудь косяки, просьба сообщить, чтоб я внёс исправления. Полума -- хорошо, а полтора -- лучше (с)
Вообще-то -- не клонов. Архитектура (система команд и т.п. вещи) -- да, DEC PDP-11, но схемотехника -- своя.
И если машины СМ-1 и СМ-2 были вещью в себе
В каком смысле "вещью в себе"? Это тоже машины с буржуйской основой -- HP 2100; эта же архитектура лежит и в основе нескольких моделей АСВТ.
по проверенному пути реверс‑инжиниринга
Реверс-инжиниринг не требовался: принципиальные схемы разных моделей PDP-11 были доступны, так что, при желании, их можно было воспроизвести 1:1. Но по крайней мере часть советских СМок (включая СМ-1420) -- это таки свои разработки.
Огромные стойки размером с пару платяных шкафов, требующие отдельного помещения с кондиционированием
Обычные 19" стойки, насколько помню. Кондиционирование обязательным не было -- зависело от площади помещения и от количества периферии. Это не ЕС ЭВМ, где один только процессор мог жрать ннадцать кВт. У, скажем, процессора СМ-2420.01, основы СМ-1420, потребление -- 700 Вт, у всей машины со включёнными дисками и прочей периферией -- вряд ли свыше 5 кВт, а зачастую и меньше (повторюсь, сильно зависит от состава периферии).
Она работала на частоте около 1–2 МГц, поддерживала до 256 КБ оперативной памяти (в базовых версиях и того меньше — 128 КБ на магнитных сердечниках!) и имела общую шину интерфейс ИМК (советский аналог UNIBUS).
1) СМ-4 выдавала порядка 700 тыс. простых оп/с; тактовая частота смысла лишена, поскольку это не конвейерный процессор, где при заполненном конвейере основная масса команд имеет эффективное время выполнения 1 такт.
2) 248 Кбайт оперативы максимум: физическое адресное пространство 256 Кбайт, но старшие 8 Кбайт отведены под регистры устройств, и оперативы там нет.
3) Аббревиатуру ИМК не встречал; во всей документации, что видел, советский UNIBUS именуется ОБЩАЯ ШИНА.
Здесь появилась аппаратная поддержка плавающей запятой, диспетчер памяти, расширяющий адресное пространство до 4 МБ, и — вершина инженерной мысли тех лет — возможность подключения «винчестеров» ИЗОТ (советские аналоги дисков DEC RK05 или RM02) объемом целых 5 или 29 Мегабайт! Диск представлял собой тяжелую «кастрюлю» со сменными магнитными блинами, которую нужно было аккуратно вставлять в накопитель.
1) У СМ-4 есть поддержка с плавающей запятой в виде набора команд FIS -- четыре основных операции над 32-разрядными вещественными числами, лежащими в вершине стека. У СМ-1420 -- уже полноценный FPU, обрабатывающий 32- и 64-разрядные вещественные числа и имеющий свои регистры. Тем не менее, говорить об "аппаратной поддержке" как появившейся в СМ-1420, некорректно.
2) Диспетчер памяти (советское название MMU) был и у СМ-4 -- без него адресовать можно всего 64 Кбайта (из которых 8 Кбайт идёт под периферию). Только у СМ-4 он формировал 18-разрядные физические адреса, а у СМ-1420 -- 22-разрядные; плюс, для нормального использования последнего в самой памяти был преобразователь адресов, чтобы периферия, работавшая по DMA, тоже могла добраться до всего объёма памяти (периферия висела на UNIBUS, а у неё адрес всегда 18 бит).
3) Обозначения дисков... сомнительны. Насколько помню, у DEC были RK02 ёмкостью порядка 2,5 Мбайт, RK06 на 13-14 Мбайт (этот у нас превратился в СМ-5408, если правильно помню), RP-что-то-там на 29 Мбайт. Ну и "винчестерами" они точно не были, ключевая особенность "винчестера" -- объединение собственно накопителя информации (пластин с магнитным покрытием) с приводами, головками и прочей электроникой. В этих же дисках дисковод -- отдельно, магнитные пластины -- отдельно, так что это больше похоже на гигантский жёсткий "флоп", а не на "винт".
терминал вроде ВТА-2000 или ДВК
ДВК -- это не терминал, а персональный компьютер, по своей сути, только на архитектуре LSI-11 или PDP-11, а не на интеловской. Собсно, об этом говорится ниже, но вот чтоб ДВК использовали как терминал к СМке... впервые слышу.
Так вопрос именно про использование дополнительных колец в CPU
Скорей даже, для чего они используются и что это даёт по сравнению с простым разделением "пользователь/супервизор" ("задача/ядро", "кольцо 3/кольцо 0" и т.д. -- термины разные, суть одна). Если, как я в комментарии выше написал, эти несколько уровней защиты использовать на 80286 или IA-32 в комбинации с сегментацией и шлюзами вызова, ощутимая польза возможна, а вот без них сомнительно...
Но, возможно, была многозадачной. Многопользовательские возможности для ПК в те времена смотрелись как ненужные -- это не мини-ЭВМ 1970-80-х, где с одной машиной посредством нескольких терминалов одновременно работают действительно несколько пользователей. А вот многозадачность полезна даже для единственного пользователя. Я вот дико плевался от MS DOS, поскольку, имея громадное ОЗУ в 640 Кбайт, я не мог параллельно запускать несколько задач (а на СМ-4 с 248 Кбайтами, не говоря уж от СМ-1420 с 2 Мбайтами -- мог, при этом с машиной работало ещё несколько человек).
Вот где пригодился бы асинхронный ввод-вывод, но в Унихе его не было (хотя абсолютно во всех многозадачных ОС 1960-70-х он был в обязательном порядке и, более того, является основной любого ввода-вывода -- в силу асинхронной природы самих операций), в Линухе сравнительно недавно завезли громоздкий и переусложнённый IO_URING, который, судя по Хабру, далеко не везде поддерживается, а стандарт POSIX, предусматривающий, в т.ч., и асинхронщину (без неё реально тяжко сделать многие вещи, требующие более-менее реального времени), Линух не поддерживает.
Однако многие ранние компьютеры вообще не имели привычной нам байт-адресуемой памяти
Не многие, а вообще все действительно ранние. Деление машинного слова на 8-битные байты, а заодно чёткое и официальное отделение архитектуры (грубо говоря, системы команд) от реализации (физическое воплощение), что открыло дорогу программной совместимости "снизу вверх", изобрела IBM в Системе 360 (1964 год), о чём ниже пишет автор, но и после неё появлялись машины без такого деления (например, знаменитая линейка мини-ЭВМ HP 2100, 1967 г., с 16-битным словом, но на байты не делившемся и из-за этого весьма неудобная для, например, обработки символьной информации).
В то время в IBM активно использовался старый 6-битный стандарт кодирования BCD (Binary Coded Decimal). 6 бит дают всего 64 возможные комбинации
Строго говоря, как указано в одном из комментариев выше, BCD -- это чисто кодирование десятичных цифр 0-9 четырьмя битами с комбинациями 0000-1001; остальные комбинации использовались для представления знака. Но 6-битные символьные кодировки действительно были и использовались.
Благодаря тотальному доминированию IBM System/360 на рынке, восьмибитный байт в считаные годы стал международным стандартом
Не было никакого тотального доминирования. Например, небезызвестный Дейкстра поливал и IBM, и Систему 360 грязью и вовсю расхваливан мэйнфреймы Burroughs, в которой работал -- и которые были нагромождением целой кучи нелепиц, выглядевших теоретически красиво, но на практике создававших лишь кучу проблем (виртуальная память на основе сегментов переменной длины, безадресная стековая система команд, определение типа информации в машинном слове с помощью обязательного поля тэга -- и никаких тебе байтов). В итоге и машины Burroughs, и все другие архитектуры мэйнфреймов проиграли конкуренцию и сошли со сцены, а сами компании зачастую исчезли или сменили профиль деятельнсти -- но это было уже в 1980-х.
Байты же стали доминировать благодаря их удобству: 256 символов было достаточно для представления основных алфавитов (да, иероглифические оставались за бортом, но тогда думали о нуждах, в первую очередь, США, во вторую -- Европы, а Японию, и тем более Китай с Кореей никто в расчёт не брал), а заодно в одном байте можно было хранить две десятичные цифры в BCD и оперировать прямо ими, что очень важно для экономических расчётов.
Аполлон-11 — когда у нуля есть знак
Весь раздел вызывает определённые сомнения, особенно в плане знака.
Да, представление целых чисел в обратном коде вызывает появление двух нулей -- положительного и отрицательного, поэтому уже давно для целых чисел используют дополнительный код (в частности, он был и в Системе 360).
Однако научные расчёты обычно требуют операций с плавающей запятой -- а там для представления значащей части (мантиссы) по-прежнему используется прямой код, поэтому у любого современного компьютера будет два вещественных нуля и две бесконечности -- положительная и отрицательная. Соответственно, задача тем или иным образом это учитывать не является уникальной для Аполлона, она вполне актуальна и сегодня, но обычно не требует дополнительных усилий (сравнение вещественного нуля с нулём даст "истину" независимо от знаков этих нулей).
Затем, как известно, наступил «тихий бум» клонирования западных технологий, преодолеть который смогли лишь единицы самобытных ЭВМ и микрокомпьютеров. А о «Сетуни» незаслуженно забыли.
Ну, о старом вообще постоянно забывают, а помнят лишь увлечённые темой люди или профессионалы в соответствующей теме.
Троичная система имела определённые преимущества, но недостатков для чисто электронной реализации у неё куда больше -- поэтому она и не "взлетела" (два состояния "транзистор открыт/транзистор закрыт" отслеживать куда проще и надёжнее, чем три состояния).
Что же касается "самобытных ЭВМ", то СССР уже в 1960-е прилично отставал от Запада, а с системным ПО был вообще полный швах: нормой у нас было программирование не на ассемблере даже, а прямо в машинных кодах. Собственно, именно желание получить кучу готового системного ПО и трансляторов в итоге и привело к решению копировать архитектуру Системы 360; своё системное ПО для отечественных машин -- тех же БЭСМ-6 и "минсков" -- стало по-настоящему появляться лишь в 1970-е и под влиянием западного ПО.
Сами же наши ЭВМ 1960-х годов в общем и целом были вполне на уровне, но ничего шедеврального из себя с инжерерной точки зрения не представляли -- вполне обычные машины в своих классах.
Дальнейшее нарастание проблем связано не с этим, а с тем, что от копирования архитектуры (т.е. системы команд, грубо говоря, что и требовалось для обеспечения совместимости и возможности использовать готовое ПО) перешли к копированию всего подряд на физическом уровне вместо разработки своего "по образу и подобию". Скажем, были полностью свои микропроцессоры с системой команд PDP-11/LSI-11 (серия 1801), но зачем-то скопировали и DECовские микросхемы (например, серия 1811, хотя их полно было). Соответственно, кучу ресурсов тратили на, по сути, перерисовывание кристаллов, хотя сложные вещи типа процессоров куда проще сделать с нуля самим -- что и делали успешно, когда такая возможность была.
Ну а если "зреть в корень", то проблема была в советской социалистической экономике с абсолютной государственной монополией на всё. На Западе любая фирма могла что-то попытаться сделать на свой страх и риск и на свои деньги -- а дальше уже "рыночек решал". У нас всё упиралось в госфинансирование, т.е. за "близость к телу"; на энтузиазме и скромных ресурсах, имеющихся под рукой, можно было сделать лишь мелочь вроде той же "Сетуни" -- и то под крылом госконторы и с одобрения его руководства.
Операция деления чисел типа float на архитектурах тех лет была невероятно «дорогой» и занимала десятки тактов процессора
Она и сейчас дорогая, если сравнивать с другими операциями. Да, за счёт 100500 млрд. транзисторов процесс можно несколько ускорить, но деление всё равно остаётся самой медленной операцией.
В 2005 году, когда исходники Quake III были опубликованы, Кармак признался, что взял этот код из чьих-то старых наработок.
Я лично встречал быстрое приближённое вычисление корня на 8-разрядном микропроцессоре 8080 году эдак в 1992 или 1993-м; числа с плавающей запятой там сделали трёхбайтовыми, исходя из требуемой для задачи точности. Правда, что за алгоритм это был, я понятия не имею.
Дело в том, что права доступа к файлам в Linux состоят из трех групп (владелец, группа, остальные), и внутри каждой группы есть ровно три флага: чтение (r), запись (w) и исполнение (x).Каждая группа — это идеальный трехбитный триплет.
На самом деле, не это было первопричиной.
UNIX, как мы его привыкли знать, появился на 16-разрядной PDP-11 (более ранние версии на, кажется, 18-разрядной PDP-7 ещё не были "этим" Унихом, сначала была вообще однозадачная примитивнейшая UNICS). У архитектуры PDP-11 имеется восемь регистров и восемь видов адресации, поэтому коды команд очень удобно записывать именно в восьмеричной системе счисления. Например, команда ADD R3,@R4 имеет машинный код 060314 (четыре старших бита -- 06 -- задают сложение; 03 -- регистровая адресация с регистром 3, 14 -- косвенная регистровая адресация с регистром 4).
Соответственно, в мире PDP-11 восьмеричная система применялась везде, и даже там, где это, в общем-то, не требовалось. Например, в самой развитой из операционных систем DEC, RSX-11, внешние устройства задавались двумя буквами с последующим номером в восьмеричной, а не десятичной системе, например, TT10: обозначает терминал № 8, а ему предшествует TT7:.
Так что использовать восьмеричную систему и для маски прав доступа или ещё чего подобного было для привыкших к PDP-11 обычным делом. Лично я не исключаю даже, что сам набор прав искусственно подогнали к трём битам, чтобы записывать было удобно.
Unix Epochalypse
Подобное вообще регулярно случается. Можно, например, вспомнить про "проблему 2000-го года". Где-то была информация, что из-за использования 32-битного счётчика миллисекунд в каком-то авиационном ПО пришлось выпустить специальное предписание полностью обесточивать бортовую аппаратуру самолётов на стоянках, чтобы при каждом вылете счётчик начинал работу с нуля -- иначе за месяц с небольшим возникало переполнение и связанные с этим проблемы (а современная бортовая электроника жрёт настолько мало, что на стоянке её могли и не отключать -- аккумуляторов ей на месяцы хватит, а не на полдня до следующего вылета).
Аналогичная проблема была и с часами IBMовских мэйнфреймов, введёнными в Системе 370 (в Системе 360 был лишь примитивный таймер, кидающийся прерываниями): они 64-битные, но миллисекунды прибавляются, если память не изменяет, к 51-му биту (старшим битом является нулевой -- на этих машинах биты нумеруются слева направо, а не более привычным способом справа налево), поэтому полный цикл часов -- опять-таки, если память не подводит -- равен 144 годам, при этом за точку отсчёта было принято начало 1900-го года. Но в z/Architecture этой проблемой озаботились заранее и к 64-разрядным часам добавили т.н. индекс эпохи: сначала он равен 0, затем 1 и так далее. Так что техническую базу для преодоления проблемы там создали, необходимые изменения в ОС наверняка давно уже внесли. А вот с прикладным ПО могут, в принципе, возникнуть проблемы -- это уж от разработчиков зависит, а также способа использования.
JavaScript использует стандарт IEEE 754. На каждое число выделяется ровно 64 бита памяти.
Вообще, стандарт IEEE 754 не требует, чтоб число было непременно 64-битным; более того, 32-битные вещественные числа куда более распространены. Хотя конкретно JavaScript, вполне может быть, использует именно 64-битные числа двойной точности.
При сложении двух уже округленных чисел погрешности суммируются, и на конце появляется лишняя четверка
Во многих случаях дело не в "сложении погрешностей", а в принципиальной невозможности точно представить значение конкретного числа в ограниченном числе разрядов. Десятичную дробь 1/3 в десятичной системе записать точно тоже невозможно: будет 0,3333.... с бесконечными тройками (математик напишет на бумаге 0,(3), но в вычислительной технике такой трюк невозможен). А вот в троичной системе это число было бы записано точно, но многие точные десятичные стали бы неточными, и т.д.
Всё-таки более старым системам не надо было рисовать тонну хай-рез (по тому времени) графики для интерфейса, поэтому сравнение так себе
Вот насчёт графики я как раз ничего не сказал, и она объективно требует под себя весьма много ресурсов -- и ОЗУ, и вычислительной мощи. Но моё категорическое несогласие с автором статьи связано с его отношением к многозадачности и т.п.: эти вещи не требуют сколько-нибудь значительных ресурсов и легко могли быть реализованы хоть на 68000, хоть на 8088 в IBM PC -- лишь бы памяти было не совсем уж мало (как показывал опыт RSX-11 и OS/360, примерно 64 Кбайт было бы достаточно).
Объективно просто процессоры того времени еле-еле моги тянуть соответствущие нагрузки без дополнительных со-процессоров с условно-приемлемой производительностью. А ещё хуже всё было в плане оперативной памяти.
Производительность какой-нибудь IBM 360/30 (аж 30 тыс. простых операций типа целочисленного сложения в секунду) или даже IBM 360/40 была, конечно, категорически недостаточна для серьёзной многозадачной работы (работали, но в пакетном режиме и больше за счёт совмещения вычислений и ввода-вывода: пока одна задача дожидается очередную порцию данных, вторая считает), вот на какой-нибудь 360/65 уже вполне можно было жить. Но 68000 или 8088 производительней не только младших моделей середины 1960-х, но и многих других намного более мощных машин той поры -- однозначно обскачет эти микропроцессоры только 360/91, первая в истории суперскалярная с внеочередным выполнением команд, и, наверное, 360/85; остальные старшие модели мэйнфреймов на целочисленных операциях будут, вероятно, примерно сопоставимы по скорости -- хотя и сильно выигрывать на плавающей запятой, если к микропроцессорам не прикладывать внешний FPU. Большинство же мини-ЭВМ вроде семейства PDP-11, где многозадачность и многопользовательское использование в 1970-х было нормой жизни, такие же или более медленнные. При большом желании можно попробовать провести более точное сравнение с конкретными цифрами.
Что касается памяти, то, пока она была ферритовой, это было проблемой; именно поэтому IBM, создавая 32-разрядную Систему 360, предусмотрела лишь 24-разрядный адрес, занимавший младшие три байта машинного слова: 16 Мбайт памяти в первой половине 1960-х казалось недостижимо гигантским объёмом (упомянутая выше модель 360/30 комплектовалась объёмом от 8 до 64 Кбайт, модель 40 -- до 256 Кбайт, и даже самые мощные редко имели больше мегабайта). Однако появилась полупроводниковая память -- и этот объём был достигнут очень быстро, пусть и за большие в те годы деньги; к середине 1970-х даже у PDP-11, которые мини-ЭВМ, а не мэйнфреймы, нормой было 248 Кбайт, а старшие модели (главным образом, PDP-11/70) нередко комплектовались 2 Мбайтами.
В общем, повторюсь: если разработчики нашли достаточно производительности и памяти для графики -- что действительно требовало много для того времени ресурсов, -- то уж внедрить многозадачность было элементарной и очень дешёвой вещью.
RSX-11M -- бабка Винды -- была многозадачной многопользовательской; многопользовательской была и первая коммерческая система виртуальных машин -- IBM VM/370 (1971 год), а также её полуэкспериментальный предок для модели 360/67. Многопользовательским было диалоговое расширение TSO (time sharing option) для OS/360 -- а это конец 1960-х... В общем, абсолютно ничего нового в плане собственно ОС Apple не принесла в этот мир вообще. Насчёт GUI -- возможно, что-то и было, но к ОС как таковой это относится весьма косвенно.
кооперативная многозадачность, которую придумал легендарный Энди Херцфельд в 1985 году
И вытесняющая, и кооперативная многозадачность существовали в 1960-е годы.
В спартанских условиях, когда вся работа зиждилась на процессоре а-ля Motorola 68000, нужно было экономить каждый байт и кооперативный подход здорово помогал в этом! Например, не прерывая программу насильно и передавая управление только тогда, когда программа сама вызывала системную функцию в отсутствии новых кликов. Это делало переключения редкими и почти не нагружало слабоватый процессор.
68000 был намного мощней, чем большинство мэйнфреймов 1960-х годов и мини-ЭВМ 1970-х, памяти даже у ранних Маков было тоже не меньше -- однако и на мэйнфреймах, и на мини-ЭВМ успешно использовалась вытесняющая многозадачность. Дополнительная нагрузка от неё крайне незначительна.
"Выдуманный человек-месяц"
В русском переводе книга Брукса называется "Мифический человеко-месяц".
Ну, и SMM, и виртуализация -- это другое™, речь о бесполезности именно колец защиты.
В действительности, польза могла бы быть в комбинации с использованием сегментов для реализации механизма множества адресных пространств и вызова программ, функционально аналогичного мэйнфреймам IBM (там это реализовано по-другому, отдельными механизмами, но это уже второй вопрос). Но для ПК польза от этого не очень-то велика (хотя можно было бы сделать, скажем, графическую подсистему не в ядре самой ОС, а на промежуточном уровне, и позволить через шлюзы вызывать её прямо из прикладных программ, а ей -- при необходимости обращаться прямо к адресным пространствам прикладных программ, не дёргая постоянно ОС, а значит, получив приличный выигрыш в скорости).
Хм... А Бах и Моцарт в этом точно разбирались?
Ну, во-первых, скорей, с СМ-1420-совместимым: у СМ-1600 и MMU выдавало 22-разрядный физический адрес, а не только 18-разрядный, как у СМ-4, и полноценный FPU был, чего у СМ-4 не было (на ней были только четыре команды так называемого набора FIS -- вещественные сложение-вычитание-умножение-деление для 32-разрядных чисел, лежащих в вершине стека; FPU же работал с 32- и 64-разрядными вещественными, которые могли быть в его регистрах и памяти).
А во-вторых, там весьма любопытно с ОС было. На СМ-1600 перенесли ДОС с М-5000. Сама система и все прикладные задачи крутились на спецпроцессоре, но ввод-вывод полностью отличался, поэтому в этой самой ДОС его переделали: когда надо было выполнить ввод-вывод, ОС на спецпроцессоре кидала прерывание основному процу с системой команд PDP-11, и он уже выполнял все операции по вводу-выводу, а завершив их, кидал ответное прерывание.
Точно планировали сделать поддержку спецпроцессора в ОС-РВ (наш клон RSX-11M), чтобы на СМ-1600 можно было крутить как задачи от М-5000, так и родные PDPшные -- но, похоже, сделано это так и не было.
Строго говоря, вполне возможна ситуация, когда любые целочисленные типы (char, short int, int, long int, long long int) имеют идентичный размер. Стандарт ограничивается лишь требованием, чтобы каждый последующий тип был не меньшей ширины, чем предыдущей, и что int должен быть как минимум 16 разрядов.
Выравнивание -- тоже отдельный вопрос. По умолчанию выравнивается по смещениям, кратным размеру типа, но это поведение можно изменить.
512 бит! Слова за счёт параллельных трубок :) На самом деле, в разумных пределах вибрации и прочая не особо-то мешали: трубки залиты до отказа, плескаться ртути негде, поэтому распространение звука особо не страдает.
Вот у меня примерно тот же самый вопрос, а точнее: что, код режима пользователя может выполнять операции записи прямо в регистры устройств, в частности, контроллера памяти? Если нет, то ничего поменять не удастся. Если да -- то это показывает кривизну используемой ОС, которая не должна давать такую возможность приложениям. (Вот драйверы и прочие модули режима ядра такое творить могут, да -- но это другое).
Ну так это сейчас лишь для собственного любопытства, а "в древности" линии задержки (но таки ртутные, а не воздушные) использовались для хранения информации весьма часто. Собственно, их применению в вычислительной технике окончательно наступил конец лишь с появлением ферритовой памяти, которая быстро вытеснила все предшествующие конструкции.
Строго говоря, и обычными средствами можно обойтись без переходов, используя команду IT, но, понятно дело, в специализированных случаях специализированные средства эффективнее -- команды DSP не просто так ввели.
Причём боль не всегда от ноги...
Таких случаев у нас 100500. В частности, в рамках АСВТ производились и IBMовские мэйнфреймы, и HP2100, и PDP-11 -- но они же производились и в рамках ЕС ЭВМ и СМ ЭВМ. А были ещё, как Вы указали, всякие разные "Электроники".
Но мне кажется (проверять лениво), что Электроника-100/25 -- это уже не СМ-4, а куда более современный вариант PDP-11...
Нет, не было там разделения на пространства команд и данных, функционально MMU у СМ-4 и СМ-1420 идентичны, за исключением ширины физического адреса. Из известных мне советских машин деление на пространства кода/данных, а заодно поддержку трёх, а не двух режимов процессора, а соответственно, шесть, а не два набора регистров APR имела лишь СМ-1425, построенная уже на, по сути, микропроцессоре, а не на рассыпухе (основа процессора -- 2 микросхемы, ещё пара дюжин микросхем -- шинные формировали, тактовый генератор и всё такое вспомогательное; в проце СМ-1420 порядка 700 микросхем, включая 20 секций К1804ВС1, 18 ПЗУ КР556РТ5, содержащих микропрограммы, и так далее).
Технически это возможно, но почти бессмыслено на практике: производительность ДВК-2 сопоставима с производительностью СМ-4, а то и превосходит её (сам микропроцессор К1801ВМ2, являющийся основой ДВК-2, может выдавать 1 млн оп/с -- против 700 тыс у СМ-4; команды EIS он тоже поддерживает), у последней два реальных достоинства -- наличие MMU, а значит, возможность гонять полноценную RSX-11M (ОС-РВ), а не только примитивную RT-11, и команды набора FIS (4 операции с вещественными 32-разрядными числами). Но в то же время ДВКшка -- это ПК, в твоём полном распоряжении, а СМка -- коллективного пользования...
Может, как предположили в комментариях, Вы видели похожий на ДВК терминал -- такие были, только не помню, какие (я их только видел, но не работал с ними).
Всегда пожалуйста :) Если вдруг обнаружите какие-нибудь косяки, просьба сообщить, чтоб я внёс исправления. Полума -- хорошо, а полтора -- лучше (с)
Вообще-то -- не клонов. Архитектура (система команд и т.п. вещи) -- да, DEC PDP-11, но схемотехника -- своя.
В каком смысле "вещью в себе"? Это тоже машины с буржуйской основой -- HP 2100; эта же архитектура лежит и в основе нескольких моделей АСВТ.
Реверс-инжиниринг не требовался: принципиальные схемы разных моделей PDP-11 были доступны, так что, при желании, их можно было воспроизвести 1:1. Но по крайней мере часть советских СМок (включая СМ-1420) -- это таки свои разработки.
Обычные 19" стойки, насколько помню. Кондиционирование обязательным не было -- зависело от площади помещения и от количества периферии. Это не ЕС ЭВМ, где один только процессор мог жрать ннадцать кВт. У, скажем, процессора СМ-2420.01, основы СМ-1420, потребление -- 700 Вт, у всей машины со включёнными дисками и прочей периферией -- вряд ли свыше 5 кВт, а зачастую и меньше (повторюсь, сильно зависит от состава периферии).
1) СМ-4 выдавала порядка 700 тыс. простых оп/с; тактовая частота смысла лишена, поскольку это не конвейерный процессор, где при заполненном конвейере основная масса команд имеет эффективное время выполнения 1 такт.
2) 248 Кбайт оперативы максимум: физическое адресное пространство 256 Кбайт, но старшие 8 Кбайт отведены под регистры устройств, и оперативы там нет.
3) Аббревиатуру ИМК не встречал; во всей документации, что видел, советский UNIBUS именуется ОБЩАЯ ШИНА.
1) У СМ-4 есть поддержка с плавающей запятой в виде набора команд FIS -- четыре основных операции над 32-разрядными вещественными числами, лежащими в вершине стека. У СМ-1420 -- уже полноценный FPU, обрабатывающий 32- и 64-разрядные вещественные числа и имеющий свои регистры. Тем не менее, говорить об "аппаратной поддержке" как появившейся в СМ-1420, некорректно.
2) Диспетчер памяти (советское название MMU) был и у СМ-4 -- без него адресовать можно всего 64 Кбайта (из которых 8 Кбайт идёт под периферию). Только у СМ-4 он формировал 18-разрядные физические адреса, а у СМ-1420 -- 22-разрядные; плюс, для нормального использования последнего в самой памяти был преобразователь адресов, чтобы периферия, работавшая по DMA, тоже могла добраться до всего объёма памяти (периферия висела на UNIBUS, а у неё адрес всегда 18 бит).
3) Обозначения дисков... сомнительны. Насколько помню, у DEC были RK02 ёмкостью порядка 2,5 Мбайт, RK06 на 13-14 Мбайт (этот у нас превратился в СМ-5408, если правильно помню), RP-что-то-там на 29 Мбайт. Ну и "винчестерами" они точно не были, ключевая особенность "винчестера" -- объединение собственно накопителя информации (пластин с магнитным покрытием) с приводами, головками и прочей электроникой. В этих же дисках дисковод -- отдельно, магнитные пластины -- отдельно, так что это больше похоже на гигантский жёсткий "флоп", а не на "винт".
ДВК -- это не терминал, а персональный компьютер, по своей сути, только на архитектуре LSI-11 или PDP-11, а не на интеловской. Собсно, об этом говорится ниже, но вот чтоб ДВК использовали как терминал к СМке... впервые слышу.
Скорей даже, для чего они используются и что это даёт по сравнению с простым разделением "пользователь/супервизор" ("задача/ядро", "кольцо 3/кольцо 0" и т.д. -- термины разные, суть одна). Если, как я в комментарии выше написал, эти несколько уровней защиты использовать на 80286 или IA-32 в комбинации с сегментацией и шлюзами вызова, ощутимая польза возможна, а вот без них сомнительно...
Ну, про 32-разрядную и я в курсе, хотя с ОС/2 никогда не работал; интересно в этом плане про самую первую официально доступную версию узнать.
В корпорации не успели провернуться шестерёнки, ранее стоявшие в позиции "компьютер персональный == единственный пользователь".
Но, возможно, была многозадачной. Многопользовательские возможности для ПК в те времена смотрелись как ненужные -- это не мини-ЭВМ 1970-80-х, где с одной машиной посредством нескольких терминалов одновременно работают действительно несколько пользователей. А вот многозадачность полезна даже для единственного пользователя. Я вот дико плевался от MS DOS, поскольку, имея громадное ОЗУ в 640 Кбайт, я не мог параллельно запускать несколько задач (а на СМ-4 с 248 Кбайтами, не говоря уж от СМ-1420 с 2 Мбайтами -- мог, при этом с машиной работало ещё несколько человек).
Вот где пригодился бы асинхронный ввод-вывод, но в Унихе его не было (хотя абсолютно во всех многозадачных ОС 1960-70-х он был в обязательном порядке и, более того, является основной любого ввода-вывода -- в силу асинхронной природы самих операций), в Линухе сравнительно недавно завезли громоздкий и переусложнённый IO_URING, который, судя по Хабру, далеко не везде поддерживается, а стандарт POSIX, предусматривающий, в т.ч., и асинхронщину (без неё реально тяжко сделать многие вещи, требующие более-менее реального времени), Линух не поддерживает.
Не многие, а вообще все действительно ранние. Деление машинного слова на 8-битные байты, а заодно чёткое и официальное отделение архитектуры (грубо говоря, системы команд) от реализации (физическое воплощение), что открыло дорогу программной совместимости "снизу вверх", изобрела IBM в Системе 360 (1964 год), о чём ниже пишет автор, но и после неё появлялись машины без такого деления (например, знаменитая линейка мини-ЭВМ HP 2100, 1967 г., с 16-битным словом, но на байты не делившемся и из-за этого весьма неудобная для, например, обработки символьной информации).
Строго говоря, как указано в одном из комментариев выше, BCD -- это чисто кодирование десятичных цифр 0-9 четырьмя битами с комбинациями 0000-1001; остальные комбинации использовались для представления знака. Но 6-битные символьные кодировки действительно были и использовались.
Не было никакого тотального доминирования. Например, небезызвестный Дейкстра поливал и IBM, и Систему 360 грязью и вовсю расхваливан мэйнфреймы Burroughs, в которой работал -- и которые были нагромождением целой кучи нелепиц, выглядевших теоретически красиво, но на практике создававших лишь кучу проблем (виртуальная память на основе сегментов переменной длины, безадресная стековая система команд, определение типа информации в машинном слове с помощью обязательного поля тэга -- и никаких тебе байтов). В итоге и машины Burroughs, и все другие архитектуры мэйнфреймов проиграли конкуренцию и сошли со сцены, а сами компании зачастую исчезли или сменили профиль деятельнсти -- но это было уже в 1980-х.
Байты же стали доминировать благодаря их удобству: 256 символов было достаточно для представления основных алфавитов (да, иероглифические оставались за бортом, но тогда думали о нуждах, в первую очередь, США, во вторую -- Европы, а Японию, и тем более Китай с Кореей никто в расчёт не брал), а заодно в одном байте можно было хранить две десятичные цифры в BCD и оперировать прямо ими, что очень важно для экономических расчётов.
Весь раздел вызывает определённые сомнения, особенно в плане знака.
Да, представление целых чисел в обратном коде вызывает появление двух нулей -- положительного и отрицательного, поэтому уже давно для целых чисел используют дополнительный код (в частности, он был и в Системе 360).
Однако научные расчёты обычно требуют операций с плавающей запятой -- а там для представления значащей части (мантиссы) по-прежнему используется прямой код, поэтому у любого современного компьютера будет два вещественных нуля и две бесконечности -- положительная и отрицательная. Соответственно, задача тем или иным образом это учитывать не является уникальной для Аполлона, она вполне актуальна и сегодня, но обычно не требует дополнительных усилий (сравнение вещественного нуля с нулём даст "истину" независимо от знаков этих нулей).
Ну, о старом вообще постоянно забывают, а помнят лишь увлечённые темой люди или профессионалы в соответствующей теме.
Троичная система имела определённые преимущества, но недостатков для чисто электронной реализации у неё куда больше -- поэтому она и не "взлетела" (два состояния "транзистор открыт/транзистор закрыт" отслеживать куда проще и надёжнее, чем три состояния).
Что же касается "самобытных ЭВМ", то СССР уже в 1960-е прилично отставал от Запада, а с системным ПО был вообще полный швах: нормой у нас было программирование не на ассемблере даже, а прямо в машинных кодах. Собственно, именно желание получить кучу готового системного ПО и трансляторов в итоге и привело к решению копировать архитектуру Системы 360; своё системное ПО для отечественных машин -- тех же БЭСМ-6 и "минсков" -- стало по-настоящему появляться лишь в 1970-е и под влиянием западного ПО.
Сами же наши ЭВМ 1960-х годов в общем и целом были вполне на уровне, но ничего шедеврального из себя с инжерерной точки зрения не представляли -- вполне обычные машины в своих классах.
Дальнейшее нарастание проблем связано не с этим, а с тем, что от копирования архитектуры (т.е. системы команд, грубо говоря, что и требовалось для обеспечения совместимости и возможности использовать готовое ПО) перешли к копированию всего подряд на физическом уровне вместо разработки своего "по образу и подобию". Скажем, были полностью свои микропроцессоры с системой команд PDP-11/LSI-11 (серия 1801), но зачем-то скопировали и DECовские микросхемы (например, серия 1811, хотя их полно было). Соответственно, кучу ресурсов тратили на, по сути, перерисовывание кристаллов, хотя сложные вещи типа процессоров куда проще сделать с нуля самим -- что и делали успешно, когда такая возможность была.
Ну а если "зреть в корень", то проблема была в советской социалистической экономике с абсолютной государственной монополией на всё. На Западе любая фирма могла что-то попытаться сделать на свой страх и риск и на свои деньги -- а дальше уже "рыночек решал". У нас всё упиралось в госфинансирование, т.е. за "близость к телу"; на энтузиазме и скромных ресурсах, имеющихся под рукой, можно было сделать лишь мелочь вроде той же "Сетуни" -- и то под крылом госконторы и с одобрения его руководства.
Она и сейчас дорогая, если сравнивать с другими операциями. Да, за счёт 100500 млрд. транзисторов процесс можно несколько ускорить, но деление всё равно остаётся самой медленной операцией.
Я лично встречал быстрое приближённое вычисление корня на 8-разрядном микропроцессоре 8080 году эдак в 1992 или 1993-м; числа с плавающей запятой там сделали трёхбайтовыми, исходя из требуемой для задачи точности. Правда, что за алгоритм это был, я понятия не имею.
На самом деле, не это было первопричиной.
UNIX, как мы его привыкли знать, появился на 16-разрядной PDP-11 (более ранние версии на, кажется, 18-разрядной PDP-7 ещё не были "этим" Унихом, сначала была вообще однозадачная примитивнейшая UNICS). У архитектуры PDP-11 имеется восемь регистров и восемь видов адресации, поэтому коды команд очень удобно записывать именно в восьмеричной системе счисления. Например, команда ADD R3,@R4 имеет машинный код 060314 (четыре старших бита -- 06 -- задают сложение; 03 -- регистровая адресация с регистром 3, 14 -- косвенная регистровая адресация с регистром 4).
Соответственно, в мире PDP-11 восьмеричная система применялась везде, и даже там, где это, в общем-то, не требовалось. Например, в самой развитой из операционных систем DEC, RSX-11, внешние устройства задавались двумя буквами с последующим номером в восьмеричной, а не десятичной системе, например, TT10: обозначает терминал № 8, а ему предшествует TT7:.
Так что использовать восьмеричную систему и для маски прав доступа или ещё чего подобного было для привыкших к PDP-11 обычным делом. Лично я не исключаю даже, что сам набор прав искусственно подогнали к трём битам, чтобы записывать было удобно.
Подобное вообще регулярно случается. Можно, например, вспомнить про "проблему 2000-го года". Где-то была информация, что из-за использования 32-битного счётчика миллисекунд в каком-то авиационном ПО пришлось выпустить специальное предписание полностью обесточивать бортовую аппаратуру самолётов на стоянках, чтобы при каждом вылете счётчик начинал работу с нуля -- иначе за месяц с небольшим возникало переполнение и связанные с этим проблемы (а современная бортовая электроника жрёт настолько мало, что на стоянке её могли и не отключать -- аккумуляторов ей на месяцы хватит, а не на полдня до следующего вылета).
Аналогичная проблема была и с часами IBMовских мэйнфреймов, введёнными в Системе 370 (в Системе 360 был лишь примитивный таймер, кидающийся прерываниями): они 64-битные, но миллисекунды прибавляются, если память не изменяет, к 51-му биту (старшим битом является нулевой -- на этих машинах биты нумеруются слева направо, а не более привычным способом справа налево), поэтому полный цикл часов -- опять-таки, если память не подводит -- равен 144 годам, при этом за точку отсчёта было принято начало 1900-го года. Но в z/Architecture этой проблемой озаботились заранее и к 64-разрядным часам добавили т.н. индекс эпохи: сначала он равен 0, затем 1 и так далее. Так что техническую базу для преодоления проблемы там создали, необходимые изменения в ОС наверняка давно уже внесли. А вот с прикладным ПО могут, в принципе, возникнуть проблемы -- это уж от разработчиков зависит, а также способа использования.
Вообще, стандарт IEEE 754 не требует, чтоб число было непременно 64-битным; более того, 32-битные вещественные числа куда более распространены. Хотя конкретно JavaScript, вполне может быть, использует именно 64-битные числа двойной точности.
Во многих случаях дело не в "сложении погрешностей", а в принципиальной невозможности точно представить значение конкретного числа в ограниченном числе разрядов. Десятичную дробь 1/3 в десятичной системе записать точно тоже невозможно: будет 0,3333.... с бесконечными тройками (математик напишет на бумаге 0,(3), но в вычислительной технике такой трюк невозможен). А вот в троичной системе это число было бы записано точно, но многие точные десятичные стали бы неточными, и т.д.
Вот насчёт графики я как раз ничего не сказал, и она объективно требует под себя весьма много ресурсов -- и ОЗУ, и вычислительной мощи. Но моё категорическое несогласие с автором статьи связано с его отношением к многозадачности и т.п.: эти вещи не требуют сколько-нибудь значительных ресурсов и легко могли быть реализованы хоть на 68000, хоть на 8088 в IBM PC -- лишь бы памяти было не совсем уж мало (как показывал опыт RSX-11 и OS/360, примерно 64 Кбайт было бы достаточно).
Производительность какой-нибудь IBM 360/30 (аж 30 тыс. простых операций типа целочисленного сложения в секунду) или даже IBM 360/40 была, конечно, категорически недостаточна для серьёзной многозадачной работы (работали, но в пакетном режиме и больше за счёт совмещения вычислений и ввода-вывода: пока одна задача дожидается очередную порцию данных, вторая считает), вот на какой-нибудь 360/65 уже вполне можно было жить. Но 68000 или 8088 производительней не только младших моделей середины 1960-х, но и многих других намного более мощных машин той поры -- однозначно обскачет эти микропроцессоры только 360/91, первая в истории суперскалярная с внеочередным выполнением команд, и, наверное, 360/85; остальные старшие модели мэйнфреймов на целочисленных операциях будут, вероятно, примерно сопоставимы по скорости -- хотя и сильно выигрывать на плавающей запятой, если к микропроцессорам не прикладывать внешний FPU. Большинство же мини-ЭВМ вроде семейства PDP-11, где многозадачность и многопользовательское использование в 1970-х было нормой жизни, такие же или более медленнные. При большом желании можно попробовать провести более точное сравнение с конкретными цифрами.
Что касается памяти, то, пока она была ферритовой, это было проблемой; именно поэтому IBM, создавая 32-разрядную Систему 360, предусмотрела лишь 24-разрядный адрес, занимавший младшие три байта машинного слова: 16 Мбайт памяти в первой половине 1960-х казалось недостижимо гигантским объёмом (упомянутая выше модель 360/30 комплектовалась объёмом от 8 до 64 Кбайт, модель 40 -- до 256 Кбайт, и даже самые мощные редко имели больше мегабайта). Однако появилась полупроводниковая память -- и этот объём был достигнут очень быстро, пусть и за большие в те годы деньги; к середине 1970-х даже у PDP-11, которые мини-ЭВМ, а не мэйнфреймы, нормой было 248 Кбайт, а старшие модели (главным образом, PDP-11/70) нередко комплектовались 2 Мбайтами.
В общем, повторюсь: если разработчики нашли достаточно производительности и памяти для графики -- что действительно требовало много для того времени ресурсов, -- то уж внедрить многозадачность было элементарной и очень дешёвой вещью.
RSX-11M -- бабка Винды -- была многозадачной многопользовательской; многопользовательской была и первая коммерческая система виртуальных машин -- IBM VM/370 (1971 год), а также её полуэкспериментальный предок для модели 360/67. Многопользовательским было диалоговое расширение TSO (time sharing option) для OS/360 -- а это конец 1960-х... В общем, абсолютно ничего нового в плане собственно ОС Apple не принесла в этот мир вообще. Насчёт GUI -- возможно, что-то и было, но к ОС как таковой это относится весьма косвенно.
И вытесняющая, и кооперативная многозадачность существовали в 1960-е годы.
68000 был намного мощней, чем большинство мэйнфреймов 1960-х годов и мини-ЭВМ 1970-х, памяти даже у ранних Маков было тоже не меньше -- однако и на мэйнфреймах, и на мини-ЭВМ успешно использовалась вытесняющая многозадачность. Дополнительная нагрузка от неё крайне незначительна.
В русском переводе книга Брукса называется "Мифический человеко-месяц".
Ну, и SMM, и виртуализация -- это другое™, речь о бесполезности именно колец защиты.
В действительности, польза могла бы быть в комбинации с использованием сегментов для реализации механизма множества адресных пространств и вызова программ, функционально аналогичного мэйнфреймам IBM (там это реализовано по-другому, отдельными механизмами, но это уже второй вопрос). Но для ПК польза от этого не очень-то велика (хотя можно было бы сделать, скажем, графическую подсистему не в ядре самой ОС, а на промежуточном уровне, и позволить через шлюзы вызывать её прямо из прикладных программ, а ей -- при необходимости обращаться прямо к адресным пространствам прикладных программ, не дёргая постоянно ОС, а значит, получив приличный выигрыш в скорости).