Pull to refresh
68
0.6
Иван Савватеев @SIISII

Микроконтроллеры, цифровая электроника, ОС…

Send message

Архитектура -- заимствована. Микроархитектура многих (но не всех) машин -- придумана тут. Реализация -- придумана тут для всех машин.

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

Не было. Появилась через несколько лет, является основой АЛУ в ЕС-1033, о чём надеюсь как-нибудь написать тоже.

Ну, копировать буржуйские машины в полном и абсолютном смысле не копировали; даже когда сдирали микроархитектуру, разработку схемы всё равно делали с нуля сами (хотя б потому, что другой была элементная база). ЕС-1020 и ЕС-1030 прилично отличались от тех IBMовских машин, с которых их потенциально могли бы скопировать (хотя, естественно, общие идеи есть -- но именно идеи); насчёт ЕС-1050 пока сказать не берусь, а в дальнейшем -- не знаю, можно ли будет делать выводы по имеющейся информации. ЕС-1033 -- вообще своя разработка, под неё даже одну свою микросхему в 155-й серии разработали (К155ХЛ1). Вот ЕС-1035 микроархитектурно -- копия модели 145 Системы 370, если не ошибаюсь (потом посмотрю подробнее), хотя чисто схемотехнически -- своя разработка (IBM делала мэйнфреймы сначала на микросборках, а затем микросхемах собственной разработки и производства; мы же скопировали микросхемы TI и Моторолы и машины делали на них -- а соответственно, просто не могли "в лоб" содрать IBMовские).

Ну, по сравнению с оригинальной IBMовской техникой, -- да, формально устаревшее, с отставанием лет на 5 (к концу СССР, правда, отставание стало нарастать), но машины тогда каждый год, как айфоны, не меняли -- служили и по 10 лет, и по 15 что у нас, что у них, так что критического в этом ничего не было. По сравнению с полностью отечественными разработками -- большой шаг вперёд; у нас из архитектурного хаоса 1 и 2 поколений так и не выбрались самостоятельно. Нет, в конечном итоге, пришли бы к тому же -- к необходимости иметь небольшое количество архитектур и разрабатывать совместимые машины (собственно, уже пришли -- по крайней мере, в серии "Минск"; просто сами архитектуры оставались ещё примитивными и малоэффективными, что было общим для техники 1-2 поколения во всех странах), но потратили бы куда больше времени, делая всё (в первую очередь, системное и околосистемное ПО) с нуля. В общем, лично моё мнение -- правильно, что скопировали весьма неплохую архитектуру, это позволило нам совершить быстрый рывок; основные ошибки начались позже -- когда разработку "по мотивам" стали заменять тупым копированием всего подряд, что вкупе с неэффективным расходованием и так не очень больших ресурсов и привело к ещё большему отставанию. Но это уже не техника, а политика и экономика...

Ну почему заменяли... Были на ЕСках и принтеры, и мониторы с клавиатурами. Но в качестве консольного терминала пишмашка часто была удобнее: протокол сохранялся. А что она печатала максимум 10 символов в секунду, то какая нужда-то для консоли печатать быстро? (Ну а принтеры в зависимости от модели -- от 500 до 1200 строк по 128-132 символа в минуту; из-за высокой скорости и низких эксплуатационных расходов их потом к ПК присобачивали).

А что, есть полные исходники MVT?

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

Вот это -- запросто :) И, кстати, не везде микропрограммная. Например, у ЕС-1050 чисто схемное управление что процессором, что каналами.

Если кратко -- делая что-то, надо включать мозги и смотреть, какие правила, рекомендации и т.п. полезны для данного случая, а какие -- вредны, а не следовать им, "потому что так правильно". Скажем, был у меня коллега, который прошивку одного промышленного прибора на микроконтроллере (какой-то из младших STM32) писал примерно как положено по чистому коду: с классами, виртуальными функциями и прочим -- в общем, как уместно было бы, скажем, в игровом движке, где заранее невозможно предсказать, какие расширения "каркаса" потребуются при создании множества продуктов на его основе разными людьми и, вероятно, на протяжении очень длительного времени. Но здесь-то -- не игровой движок, а прошивка промышленной железяки под вполне определённую задачу, которую один раз написал и, скорей всего, больше к ней возвращаться не будешь -- работает и работает, что-то измеряет, какие-то циферки показывает, что-то куда-то передаёт по вполне определённым интерфейсам...

Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.

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

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

Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.

Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.

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

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

Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).

Вычислять квадратный корень может потребоваться и на процессоре, не имеющем не только его аппаратной реализации, но и вообще какой-либо поддержки операций с плавающей запятой -- скажем, на любом микроконтроллере с ядром Cortex-M3 или вообще на Ардуине. И вот там подобная магия может дать многократный прирост (особенно если писать на ассемблере). В общем, если нечто становится не особо актуальным для ПК, может быть вполне себе актуальным для других платформ.

OS/360 -- не первая ОС для мэйнфреймов IBM; DOS/360 и ещё пара систем были разработаны раньше. Вот первой "большой" ОС, и не только для мэйнфреймов IBM, а вообще в истории, она, пожалуй, является. Не является она и "монолитным блоком программного кода", она состоит от огромного числа модулей, загружаемых по мере необходимости. Именно это дало возможность системе объёмом в несколько сотен килобайт работать на машинах с заметно меньшим объёмом памяти -- причём ещё до появления MMU, то есть без виртуальной памяти. У ядра была фиксированная часть, всегда находившаяся в основной памяти, и были модули, которые по мере необходимости загружались в транзитные области. Пользователи системы могли для неё писать свои модули, если возникала такая необходимость.

Ну, 176-я серия -- она КМОП, там с аналоговым режимом попроще будет, насколько знаю. Но вообще, народ остроумные конструкции временами делал, это да.

Information

Rating
2,048-th
Location
Солнечногорск, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Embedded Software Engineer
Lead