?

Log in

No account? Create an account
Правда о CDC, БЭСМ и IBM/360 - заговор или недосмотр? - На волнах сознания Будды... [entries|archive|friends|userinfo]
Горная жаба

Widgetize!

[ website | Тупизм.ру ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Правда о CDC, БЭСМ и IBM/360 - заговор или недосмотр? [июл. 5, 2012|09:43 pm]
Горная жаба

Компьютерная археология. Часть 1

(следующая часть - здесь)

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

Итак, мы рассмотрим два вопроса:

  • Являлась ли БЭСМ-6 уникальной передовой машиной, или же это была копия знаменитой CDC-1604?
  • Оправдан ли был переход со своих наработок (БЭСМ, УРАЛ, Минск) к копированию серии IBM/360/370?

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

консоль CDC-1604машинный зал БЭСМ-6

Начнем с первого вопроса.

Те, кто увлекался историей вопроса могли заметить, что отзывы о ранних советских компьютерах очень противоречивы. Одни вспоминают огромные гудящие шкафы, заминающиеся перфокарты, и производительность позволяющую вздремнуть между двумя прогонами программы. Другие наоборот - не жалеют превосходных эпитетов типа: "БЭСМ-6, непризнанный историей лидер компьютерной индустрии, имела рекордное быстродействие и обладала совершенно оригинальной архитектурой".

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

Мы последовательно рассмотрим различные архитектурные аспекты БЭСМ-6 и CDC-1604 чтобы подкованный читатель смог сам составить представление об этих машинах. Вот список сравниваемых параметров:

  1. Элементная база
  2. Разрядность регистров и памяти
  3. Формат представления чисел
  4. Формат команд
  5. Арифметические команды
  6. Сдвиги
  7. Логические команды и битовые операции
  8. Команды работы с памятью
  9. Индексация
  10. Переходы
  11. Ввод/вывод

Для удобства, сведем их в таблицу:

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

Параметр\МашинаCDC-1604БЭСМ-6
Начало серийного выпуска19601968
Элементная базаТранзисторыТранзисторы
Тип адресацииОдноадреснаяОдноадресная
Разрядность слова48 бит48 бит
Длинна команды24 бита24 бита
Разрядность сумматора48 бит48 бит
Разрядность адреса15 бит15 бит
Регистров общего назначения1 (+1)1 (+1)
Индексных регистров615
Обьем ОЗУ (оригинальный)32 768 слов32 768 слов
Представление чисел
 4       4          3         2         1 
 7 65432109876 543210987654321098765432109876543210 
+-+-----------+------------------------------------+
|s| exponent  | mantissa                           |
+-+-----------+------------------------------------+
1 бит - знак, 11 бит - порядок, 36 бит - мантисса
 4       4          3         2         1 
 7654321 0 9876543210987654321098765432109876543210 
+-------+-+----------------------------------------+
| exp.  |s| mantissa                               |
+-------+-+----------------------------------------+
7 бит - порядок, 1 бит - знак, 40 бит - мантисса
Формат команд 24-х битные команды упакованы в 48-битные слова по две.
 2  2           1 
 321098 765 432109876543210 
+------+---+---------------+
|opcode|idc|addr./operand  | 
+------+---+---------------+
6 бит - код операции, 3 бита - индекс или условие перехода, 15 бит - адрес или операнд
24-х битные команды упакованы в 48-битные слова по две. Имеется два формата:
 2  2             1 
 3210 9 8 765432 109876543210 
+----+-+-+------+------------+
|indx|0|S|opcode| address    | 
+----+-+-+------+------------+
4 бита - индексный регистр, 6 бит - код операции, 12 бит - адрес или операнд.
 2  2             1 
 3210 9 8765 432109876543210 
+----+-+----+---------------+
|indx|1|op. |  address      | 
+----+-+----+---------------+
4 бита - индексный регистр, 4 бита - код операции, 15 бит - адрес или операнд.
Арифметические команды

Имелись как целочисленная, так и вещественная арифметика.

Целочисленная арифметика: Increase Accumulator, Add, Subtract, Multiply integer, Divide integer, Multiply Fractional, Divide Fractional, Replace Add, Replace Subtract, Replace Add One, Replace Subtract One.

Вещественная арифметика: Floating Add, Floating Subtract, Floating Multiply, Floating Divide

Имелась только вещественная арифметика

Целочисленная арифметика: отсутствует

Вещественная арифметика:CЛOЖEHИE, BЫЧИTAHИE, ДEЛEHИE, УMHOЖEHИE, СЛОЖЕНИЕ KOHTPOЛЬHOE, BЫЧИTAHИE OБPATHOE, BЫЧИTAHИE AБC.BEЛИЧИH, ИЗMEHEHИE ЗHAKA, CЛOЖ.ПOPЯДKA C ПOPЯДKOM, BЫЧ.ПOPЯДKA ИЗ ПOPЯДKA, CЛOЖEHИE C ПOPЯДKOM, BЫЧИTAHИE ИЗ ПOPЯДKA

Команды сдвига Accumulator Right Shift, Q-register Right Shift, AQ Right Shift, Accumulator Left Shift, Q-register Left Shift, AQ Left Shift, Scale A, Scale AQ, Storage Shift CДBИГ ПPABЫЙ, CДBИГ ПPABЫЙ ПO ПOPЯДKУ
Логические команды и битовые операции Selective Set, Selective Clear, Selective Complement, Selective Substitute, Load Logical, Store Logical, Add Logical, Subtract Logical ЛOГИЧECKOE "И", CЛOЖEHИE ПO MOДУЛЮ 2, ЛOГИЧECKOE "ИЛИ", CБOPKA, PAЗБOPKA, BЫЧИCЛEHИE ЧИCЛA EДИHИЦ, BЫЧИCЛEHИE HOMEPA CTAPШEЙ EДИHИЦЫ
Команды работы с памятью Enter A, Enter Q, Load A, Load A complement, Load Q, Load Q complement, Store A, Store Q, Substitute Address (upper), Substitute Address, Equality Search, Threshold Search, Masked Equality, Masked Threshold ЗAПИCЬ, ЗAПИCЬ И ЧTEHИE ИЗ MAГАЗИНА, CЧИTЫBAHИE MAГAЗИHHOE, BЫДAЧA PEЖИMA, BЫДAЧA MЛAДШИX PAЗPЯДOB
Индексация Enter Index, Increase Index, Load Index, Store Index, Index Skip, Index Jump УCTAHOBKA ИP, УCTAHОВКА ИP И ЧTEHИЕ ИЗ MAГАЗИНА, BЫДAЧA ИP, BЫДAЧA ИP MAГAЗИHHAЯ, УCTAHOBKA ИP ПO ИP, CЛOЖEHИE ИP, УCTAHOBKA ИP AДPECOM, CЛOЖEHИE ИP C AДPECOM
Переходы A Jump, Q Jump, Selective Jump, Selective Stop ПEPEXOД ПO HУЛЮ, ПEPEXOД ПO EДИHИЦE, ПEPEXOД БEЗУCЛOBHЫЙ, ПEPEXOД C BOЗBPATOM, ПEPEXOД ПO "ИHДEKC = 0", ПEPEXOД ПO "ИHДEKC<> 0", ЦИKЛ
Ввод-вывод Input Transfer, Output Transfer, External Function УПРАВЛЕНИЕ ВВОДОМ-ВЫВОДОМ

Возможно, если вы знакомы с современными архитектурами (на уровне ассемблера), приведенный набор команд вас несколько удивил. Оно и понятно. Дело в том, что в 60-х годах система команд только формировалась (не было даже единого представления о длине байта=символа) и эпоха "регистровых" машин только начиналась. CDC-1604 и БЭСМ-6 были машинами с сумматором. Т.е. в них был один выделенный регистр (на самом деле 2 - аналог AL и AH в терминологии Intel 8086) в котором и производились все операции. Чем-то это похоже на стековую архитектуру JVM. Отголоски такого подхода сохранились и Intel-овском ассемблере. Регистр AX - и есть не что иное, как 16-ти битный (всего лишь) аккумулятор.

Понятно, что при такой архитектуре приходится постоянно загружать и выгружать значения из памяти/в память. Для этого уже тогда применялись различные схемы адресации, и (а куда деваться) существовали т.н. индексные регистры (их далекие потомки - регистры SI, DI в Intel). Однако, разрядность индексных регистров не совпадала с размером слова (!) и размером регистра аккумулятора, ибо обьем памяти в те годы был невелик, а вычисления приходилось вести в общем-то те же. В CDC-1604 и БЭСМ-6 мы имеем 15-ти битные индексные регистры и 48-битный аккумулятор.

Другая забавная особенность, касающаяся правда только БЭСМ-6 - это отсутствие целочисленной арифметики. В наше время подход радикально изменился. Процессор может не иметь поддержки float point, но обязан иметь целочисленную арифметику. В те времена это не было очевидно. Машины (особенно в Союзе) использовались в основном для научных расчетов, где вычисления с плавающей точкой преобладали. Соответственно "обрезать" fixed point не выглядело чем-то странным. Плюс, можно было манипулировать с индексными регистрами.

Можете себе представить, как нелегко приходилось ассемблерным программистам прошлого!

Еще одной интересной возможностью БЭСМ-6 был набор специализированных битовых инструкций среди которых вычисление номера старшей единицы и подсчет числа единиц - population count на современном языке. Это "canonical NSA instruction" - инструкция, быстрая реализация которой очень нужная АНБ для целей криптографии. Поскольку основными заказчиками БЭСМ-ов были "ящики" то не удивительно, что такие инструкции были нужны и ей. Кроме них имелись еще "сборка" и "разборка" - это выборка определенных битов по маске. Было бы интересно понять, для каких целей они применялись.

Далее стоит рассмотреть загадочные "экстракоды". По сути, это не что иное как далекий предок современных INT. Изначально планировалось, что "экстракоды" будут наполняться функциональностью по мере эксплуатации машины. Т.е. поняв, что появилась нужда в инструкциях для вычисления синуса или квадратного корня, мы быстро реализуем их на программном (или даже аппаратном) уровне, присвоив определенному экстракоду нужную функциональность. Со временем идея несколько трансформировалась, и дополнительные команды с "загружаемой" логикой стали использоваться в основном для нужд поддержки OS.

Переходя к "системным" аспектам архитектуры БЭСМ-6 и собственно вопросу о ее "корнях", нам нужно включить в рассмотрение не только CDC-1604, но и две других машины. Собственно, у архитектуры БЭСМ-6 было, как и у марксизма три источника и три составных части. Один уже был назван, а два других - это CDC-6600 легендарного Сеймура Крэя и Ferranti Atlas не менее легендарного (но гораздо менее известного в России) англичанина Тома Килбурна.

консоль CDC-6600машинный зал Ferranti Atlas

Что же было взято от архитектуры Atlas кроме уже упомянутых "экстракодов"? Прежде всего - страничная организация памяти. Часто пишут, что в БЭСМ-6 была и поддержка виртуальной памяти (а в Atlas она была!), но на самом деле это не верно. С современной точки зрения "поддержка виртуальной памяти" дает нам возможность адресовать больший обьем памяти, чем реально установлен на машине (к примеру - процесс может получить 4 Гб памяти, при том, что реально установлен всего гигабайт).

На БЭСМ-6 (поздних модификаций) сложилась парадоксальная ситуация, обратная вышеописанной. Физической памяти на машине было доступно больше, чем ее можно было адресовать! Сиречь, имея 128 килослов памяти, мы должны были по-прежнему работать с ней через 15-ти битные регистры=адреса. Для поддержки этой возможности, имелись 32 т.н. "регистра приписки". Перед обращением к реальной памяти, исполнительный адрес разбивался на две части 5+10 бит. Старшая часть трактовалась как номер регистра приписки, из которого брались 7 разрядов номера физической страницы, и вместе с 10 младшими разрядами адреса они составляли 17-ти битный физический адрес. Таким образом, механизм виртуальной памяти как бы был "вывернут наизнанку".

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

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

Иными словами - в БЭСМ-6 речь не шла о распараллеливании схожих операций. Если ALU умножало два числа, то ничего другого оно делать уже не могло. Надо правда заметить, что Сеймур Крей в CDC-6600 как раз попытался заняться распараллеливанием. Каждый процессор имел 10 независимых функциональных блоков (для умножения, сложения, сдвига, etc) и если все складывалось удачно, мог выполнять эти операции одновременно! При том, что общая идея "конвейеризации" была реализована и в БЭСМ-6, функциональности параллельной обработки аналогичной CDC-6600 в лебедевской машине не было.

Итак, обсудив наиболее важные архитектурные аспекты мы снова возвращаемся к поставленному вопросу - было ли творение Лебедева оригинальным, или являлось копией детища Сеймура Крэя? Говоря о "копировании" архитектуры, надо отметить, что существует целый спектр возможных значений этого слова. От "нагло содрана" и "точно скопирована" до "взята за основу" и "творчески переработана". Какая из градаций больше подходит в данном случае - судить читателю.

На мой взгляд, правильно говорить именно о творческой переработке базовой архитектуры CDC c добавлением множества идей из других источников. Об этом свидетельствует разный формат представления чисел, разная кодировка команд и самый их набор, разный подход к управлению памятью, etc. Быть может переработка вышла не на 100% удачной (ибо отсутствие целочисленной арифметики никак не назовешь архитектурной находкой), но надежной, и, в принципе, подходящей для тех задач (в первую очередь военных и научных) которые были на нее возложены. В любом случае важно понимать, что "абсолютно новых" решений в инженерии практически не бывает. Мы просто стоим "на плечах" гигантов, порой не замечая этого.

Во второй части нашего обзора мы рассмотрим еще более сложную и неоднозначную тему - переход от собственных разработок к "точному копированию" системы IBM/360.

Ссылки на документацию и другие источники информации, равно как и благодарности будут помещены во второй части.

P.S. Ссылки на эту запись приветствуются (редкий случай).

P.P.S. И, конечно, не расслабляйтесь - вас ждет вторая серия!

Update:

Поскольку оказывается, что есть еще как минимум два (а то и три) заблуждения по поводу БЭСМ-6, я решил написать небольшое обновление по теме.
Первое заблуждение касается наличия в БЭСМ-6 кэш-памяти. Об этом пишет чуть не каждый второй. На самом деле, назвать то, что имелось в машине "кэш-памятью" можно только с очень большой натяжкой. Примерно такой, как изобретение Рентгена Иваном Грозным. Да, принцип похож, но до полноценной реализации еще пахать и пахать. Что было на самом деле? Четыре т.н. буферных регистра числа (БРЧ) куда считывались слова из памяти, чтобы потом к ним могло быстрее обратиться арифметическое устройство (АУ). Аналогично, имелось 8 (забавная асимметрия) буферных регистров записи (БРЗ) куда число помещалось перед отписыванием в память. Адрес, куда должен быть записан операнд, сохранялся в т.н. БАЗ (буферном регистре адреса записи). Если в дальнейшем оказывалось, что исполнительный адрес совпадает с одним из адресов в БАЗ/БАС-ах, операнд брался из БРЗ/БРЧ а не из памяти. Вот и вся наука. Чтобы не утомлять вас дальше русскими TLA, отсылаю всех желающих к документации по АЛУ (http://www.mailcom.com/besm6/ALU.pdf). Полноценная же реализация кэш-памяти впервые появилась в машине IBM/360-85 в 1969 году.

Второе заблуждение говорит о БЭСМ-6, как якобы предвестнице RISC-архитектуры. На этой почве тоже строится много спекуляций. Но и тут, истина довольно далеко. Безусловно, в БЭСМ-6 не слишком много команд. Можно сказать даже - мало. И, разве что по этому параметру она сближается с RISC. Другое дело, что команды эти - совсем не похожи на традиционные RISC-овские. Они имеют совершенно различную сложность и времена выполнения. Ключевыми особенностями RISC можно считать:

  1. Небольшой набор простых команд
  2. Минимизация команд работы с памятью, за счет большого числа регистров общего назначения
  3. Небольшая длительность выполнения каждой команды (1-2 такта) CPU

Ни одна из этих особенностей не присуща системе команд БЭСМ-6. Она включает как очень простые команды (запись, сложение) так и довольно сложные (деление, сборка). Время выполнения команд различается в десятки раз! Например, чтение требует 3-х тактом, сложение - 11-ти, деление - 50 (в среднем). О максимальных временах выполнения говорить не приходится. Чтобы не быть голословным, и дать читателю более полную информацию, приведу страницу руководства с таймингом команд:

Последнее заблуждение частично вытекает из двух первых, и, кроме того, и сильно подогревает самомнение ура-патриотов. Состоит оно в том, что БЭСМ-6 была быстрой, и не просто быстрой, а прямо таки супер-быстрой машиной для своего времени. Спору нет, на европейском уровне характеристики БЭСМ-6 смотрятся неплохо. Но и только. Даже не беря творения Сэймура Крэя (по сути - тоже числодробилки) обычные майнфрэймы IBM были не хуже на научных расчетах, и существенно лучше на финансовых. Удивляться тут нечему. Еще раз напомню читателю, что БЭСМ-6 не имела полноценных команд целочисленной арифметики, и, значит любые арифметические команды выполнялись на вещественном сумматоре. Это приводило к тому, что даже в самом лучшем случае сложение занимало 5 тактов (в среднем - 11) а умножение - 15 тактов (в среднем - 18.5, в худшем - 162(!)). Что уж говорить о каком-нибудь сложением десятичных чисел. В результате, программы не только выполнялись медленнее, чем могли бы, но и занимали больше места. Об этом упоминает и В.В. Пржиялковский в своем обзоре - "Проведенные в ИПМ АН СССР исследования показали, что программы, составленные для IBM-360, требуют в 1,5-3 раза меньшего объема памяти, чем программы БЭСМ-6, “Весна”, М-20". Если же говорить о производительности в цифрах - по "популярному" тогда тесту Whetstone, БЭСМ-6 набирала примерно 0.3-0.4 миллиона операций с одинарной точностью в секунду, что было на уровне средних моделей IBM. И никаких чудес, увы...

СсылкаОтветить

Comments:
[User Picture]From: livejournal
2012-10-18 06:24 am

Правда о CDC, БЭСМ и IBM/360 - заговор, недосмотр, или?

User and2u referenced to your post from Правда о CDC, БЭСМ и IBM/360 - заговор, недосмотр, или? saying: [...] 1. Являлась ли БЭСМ-6 уникальной передовой машиной, или же это была копия знаменитой CDC-1604? [...]
(Ответить) (Thread)
From: (Anonymous)
2017-09-26 09:16 am

Re: Правда о CDC, БЭСМ и IBM/360 - заговор, недосмотр, или?

ТовариСЧи!!!

Кто сказал, что на БЭСМ-6 не было целочисленной арифметики??? :) Какой козел запустил эту фенечку?
А как же тогда работали тесты, которые я писал??? В которых я использовал сложение 48-разрядных чисел... А ведь работали... Например, тесты дисков/дисководов Или тесты ОЗУ (при переходе с МОЗУ на микросхемное ОЗУ - отладка операции "Чтение с МЛ с наложением") Все тесты - с 48-разрядной целочисленной арифметикой.

Да, была такая хохмочка на языках высокого уровня - фортран, Алгол, когда ДЛЯ ПРОСТОТЫ в качестве integer использовали ненормализованную мантиссу real. Но это - ОТ ЛЕНИ ПРОГРАММИСТОВ при преобразовании типов. (Трудно перевести 48-разр. integer в real-мантиссу. И нужно ОЧЕНЬ ВНИМАТЕЛЬНО следить за режимом АЛУ. Команда условного перехода на БЭСМ-6 по-разному работала с real и integer. Это было НА САМОМ ДЕЛЕ неудобно!) А не потому что не было целочисленной арифметики.

--
Шумилов Павел (инженер-эксплуатационщик и программист-системщик на БЭСМ-6)
(Ответить) (Parent) (Thread)
[User Picture]From: a_jelly
2017-09-26 12:05 pm

Re: Правда о CDC, БЭСМ и IBM/360 - заговор, недосмотр, или?

Павел, трудно сказать, что именно за тесты вы писали. Но в статье перечислены все команды БЭСМ-6. Как вы можете видеть, команды есть только для вещественной арифметики.
В традиционном процессоре коды операция для сложения целых и вещественных - различны. Как и регистры.
(Ответить) (Parent) (Thread)
[User Picture]From: gineer
2012-10-19 10:47 am
Ну если так брать,
то получается что отставание на 10 лет (условно) было заложено еще тогда,
а значится -- никто ничего не про...л. :)
(Ответить) (Thread)
[User Picture]From: netch80
2013-09-20 07:45 am
> Таким образом, механизм виртуальной памяти как бы был "вывернут наизнанку".

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

Реализация БЭСМ-6 принципиально не отличалась в этом моменте, например, от PDP-11, где при 16-битном виртуальном адресе можно было адресовать физическую память в пределах 18 бит (для средних моделей) или 22 бит (для старших), или x86 в случае механизмов PAE и PSE36, которые были введены для систем с более 4GB ОЗУ при сохранении 32-битной адресации. Да, это сложнее и неудобнее, требует постоянной возни с переключением страниц, и сокращает применимость вкусностей, которые были придуманы позже, типа memory-mapped files. Зато такая VM позволяла одновременную работу нескольких задач, и даже их своппинг.

Принципиальное смещение фокуса внимания при рассмотрении механизмов VM на превышение виртуальной памяти над физической - "приобретение" уже достаточно поздних времён.

В остальном, очень интересная статья, спасибо.


Edited at 2013-09-20 08:23 (UTC)
(Ответить) (Thread)
[User Picture]From: a_jelly
2013-09-20 10:01 am
Тут я не могу согласиться ни по первому ни по второму пункту.

Я готов согласиться, что в БЭСМ-6 был реализован некий аналог PAE. В общем-то это и есть буквально PAE. Но назвать это виртуальной памятью язык не поворачивается. Этак можно договориться, что адресация x86 (сегмент:смещение) - это типа тоже виртуальная память! А что, адрес-то 16 битный, а памяти может быть аж целый мегабайт! Это скорее из области инженерных извращений.

Что касается поздних времен - это тоже неверно. И Atlas (в 1963 году) и уж тем паче IBM S/360 Model 67 понимали виртуальную память "по современному". Т.е. именно как возможность иметь большую виртуальную память на малой физической.
(Ответить) (Parent) (Thread)
[User Picture]From: netch80
2013-09-20 10:39 am
> Но назвать это виртуальной памятью язык не поворачивается.

У меня в общем тоже не поворачивается, поскольку, с моей точки зрения, виртуальная память возникает тогда, когда какая-либо страница может физически отсутствовать, или быть недопустимой для данной операции (обычно - только для записи), и тогда её присутствие эмулируется для прикладной программы так, что последняя ничего не замечает, кроме торможения. Вот в этом основная суть. А трансляция адреса - необходимый компонент для удобства обеспечения этой базовой функциональности, но не единственно возможный в привычном нам виде. Например, на HP 300 была фактически обратная общепринятой трансляция (у МакКузика можно почитать, как это влияло на дизайн 4.4BSD).

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

> Этак можно договориться, что адресация x86 (сегмент:смещение) - это типа тоже виртуальная память!

Для 086/186 - безусловно нет, но уже для защищённого режима 286 - скорее да, чем нет. Сегмент, заданный селектором, может отсутствовать полностью или быть урезанным, и размещённым в любом месте памяти. Неудобство работы с парой селектор+смещение было существенным и привело к прекращению изобретения велосипедов и переходу в 386 к более традиционной схеме, но формально условия соблюдены:)

> Что касается поздних времен - это тоже неверно.
> и уж тем паче IBM S/360 Model 67

Моё рассмотрение ограничивается известными мне отзывами из "широких народных масс" пользователей, программистов и админов СССР, где наиболее известной системой, реализующей виртуальную память, были звери типа СМ-1420, позже - старшие ДВК. Даже ряд-3 местного разлива ЕС уже был чем-то сверхэкзотическим, и его ОС - аналогично, как бы они ни были продвинуты; а про Model 67 можно было и не упоминать вообще:) Следующий абзац прошу рассматривать сугубо с учётом этого ограничения.

Возможность иметь для одной конкретной задачи виртуальное пространство больше реального ОЗУ не рассматривалась всерьёз как что-то полезное - потому, что любая реальная задача в этих условиях выливалась в дикий пейджинг с просадкой производительности на порядки. Зато ценились 1) гарантированная непрерывность адресного пространства задачи, дающая возможность создавать массивы любой разумной длины; 2) возможность вытеснения задачи без аварийного останова и продолжения счёта после освобождения ресурсов (вытеснение было тогда свопингом целого процесса; пейджинг по страницам вошёл в широкое распространение заметно позже, хотя технически был возможен с самого начала). Широкое использование виртуального пространства под отображение файлов, совмещение страниц, copy-on-write и т.д. - начались вместе с Mach, а это уже середина 80-х. До того, массово используемые механизмы были значительно более примитивны.
(Ответить) (Parent) (Thread)
[User Picture]From: a_jelly
2013-09-20 05:35 pm
Я согласен, что виртуальная память неотделима от обработки страничного промаха. Иначе это уже что-то другое. Правда, и без транляции адресов тоже никогда не обходится.

Что до широких масс, то тут есть несколько аспектов.
Во-первых, в НИИ, и даже учебных институтах все же имелись EC. А в крупных и/или столичных, и EC и СМ вместе. Правда, EC-овские программисты всегда воспринимали и машину и ОС на CM-ке скорее как игрушку.

Если взять традиционного Fortran-пользовтеля, то конечно он не подозревал о наличии виртуальной памяти, страничного обмена и прочей ботвы. Но уже программист на ассемблере мог о ней знать. Не говоря уж о системных программистах. А их все же было немало. Если учесть, что одних ЕС-ок успели наклепать больше 15 тыс. Хотя, System/370 конечно видели не все. Тем не менее - понимание в народе было. Особенно учтя, что наиболее популярной ОС среди системщиков EC была VM/SP.

К тому же, если смотреть в том аспекте, о котором идет речь, то собственно даже не важно, знал ли кто-то о тех или иных архитектурных возможностях. Важно что они были в железе, и OS их активно использовала.

Потому, что даже и сейчас - спроси бухгалтера, нажна ли 1C виртуальная память? Что он ответит...
Да и программисты многие тоже.
(Ответить) (Parent) (Thread)
[User Picture]From: b0p0h0k
2017-08-08 06:33 am
виртуальная память возникает тогда, когда какая-либо страница может физически отсутствовать, или быть недопустимой для данной операции (обычно - только для записи), и тогда её присутствие эмулируется для прикладной программы так, что последняя ничего не замечает, кроме торможения.


Вы совершенно точно описали ровно то, что и происходило в ОС БЭСМ-6. Обращение к отсутствующей странице за операндом или командой вызывало внутреннее прерывание по защите адреса. В ответ на это ОС подкачивала требуемую страницу с внешнего устройства (барабана или диска). Естественно, это событие приводило к rescheduling и передаче процессора другому процессу. Всё как у взрослых.
(Ответить) (Parent) (Thread)
From: (Anonymous)
2018-09-21 10:45 pm

Автор, похоже плохо понимает, что такое виртуальная па

Надо же такую ахинею написать!! Страничный механизм трансляции без подкачки отсутствующих страниц -- это вообще где, как и зачем? Ленивый разработчик не сделал прерывания по несуществующей (в ОЗУ)странице или ленивый программист ОС не сделал адекватную обработку? И при чем здесь соотношение разрядности виртуального и физического адреса? И не забываем про то, что ОС БЭСМ-6 многозадачная. При многопользовательской работе реально не хватало именно физической памяти и подкачка вовсю работала!
(Ответить) (Parent) (Thread)
[User Picture]From: a_jelly
2018-09-22 07:16 am
По-моему у вас а голове cache (можете открыть наружу порт 3128). Но, возможно, если почитать хотя бы wiki, то наступит некоторая упорядоченность и ясность.

Edited at 2018-09-22 07:16 (UTC)
(Ответить) (Parent) (Thread)
[User Picture]From: spamsink
2016-10-20 02:35 am
Ой, не спрашивайте, как я сюда попал, но пару слов скажу:

Кроме них имелись еще "сборка" и "разборка" - это выборка определенных битов по маске. Было бы интересно понять, для каких целей они применялись.

В основном для ввода-вывода. Транспонирование битовой матрицы 80х12 для работы с перфокартами этими командами делается довольно тривиально. Еще, например, преобразование слова в текстовое восьмеричное представление делалась разборкой на группы из трех бит в каждый байт. В кодировке ГОСТ это сразу получались коды цифр. И, соответственно, сборкой текстовое представление восьмеричных чисел преобразовывалось в собственно число.

Ну и, разумеется, всегда можно было использовать эти команды для перепутывания бит как элемента криптографического S-box.

(Ответить) (Thread)
[User Picture]From: a_jelly
2016-10-20 08:22 am
Спасибо за уточнения!
(Ответить) (Parent) (Thread)