В первой части были описаны многие разные процессоры до середины 90-х. Для мейнфреймов IBM там места не нашлось, так как эти системы долгое время не использовали процессоры-чипы. Однако, мейнфреймы IBM тесно связаны с другими компьютерными системами, долгое время являясь лучшими образцами компьютерной техники, на которую так или иначе ориентировались практически все. Кстати, формат хабр-блога, как и Википедии, позволяет редактирование, что позволило значительно переработать содержимое первой части с учетом поступивших замечаний и прочей дополнительной информации.
В этой части главное внимание уделяется сравнению машинного языка мейнфреймов с другими системами, которые были популярны в период с 70-х по 90-е. Это прежде всего x86, 68k, VAX и ARM. Системы 390 и, в особенности, Z рассматриваются очень фрагментарно – основное внимание уделяется именно системе 370.
Первые системы 360 стали поставляться заказчикам с 1965 года, а более совершенные системы 370 с 1970. IBM поддерживает программную совместимость с этими системами до настоящего времени! Удивительно, но до систем 390, поставляемых, как можно догадаться с 1990 года, мейнфреймы работали с 24-битными адресами, т. е. могли адресовать не более 16 мегабайт памяти, столько же, сколько, например, 68000, выпущенный в 1979, или 65816 или 32016, выпущенные в 1982. VAX изначально поддерживал 32-битную адресацию. Популярные процессоры 68020 или 80386, появившись в середине 80-х, также поддерживали 32-битные адреса. Реально 16 МБ памяти для лучших систем второй половины 80-х – это было уже мало. Однако, IBM c 1983 производила совместимые с 370 вычислительные машины, которые могли как расширение использовать 31 разряд для адреса, что снимало проблему объема памяти для лучших компьютеров. Необычно и уникально, что в этих расширениях и системах 390 использовали 31-битный адрес, а не полный 32-битный. В 2000 IBM объявила о первой системе Z, где используются 64-битные адресация и данные. Системы Z стали c 2008 использовать чипы-процессоры. Архитектуру Z c 2007 пытаются соединить в одном чипе с архитектурой POWER, но пока безуспешно. Соединить CISC и RISC в одном чипе пока получилось только у Intel – Pentium Pro в 1995 стал первым чипом такого рода.
IBM System/370-145 c ленточными накопителем 2401 и принтером вместо дисплея, 1971. Может удивить отсутствие дисплея в этой очень дорогой системе при том, что телевизоры массово производятся уже более 20 лет
Кстати, некоторые авторитеты считают, что первым серийным персональным компьютером был IBM 5100, производимый с 1975, который через аппаратный эмулятор мог исполнять инструкции системы 360. Его улучшенные варианты производились до середины 80-х. Хотя скорее всё-таки первым был Wang 2200. По ценам (примерно $10000) эти первые персоналки были явно не для домашнего использования.
IBM 5100, вариант с поддержкой языка APL
С появлением архитектуры IBM PC, которая, как оказалось, на десятилетия определила основное направление развития для вычислительной техники, IBM попыталась в 1983 соединить почти все лучшие тогда компьютерные технологии в одном изделии PC XT/370: свои системы 370, IBM PC XT, Motorola 68000 и Intel 8087. Этот XT/370 можно было использовать как интеллектуальный терминал для работы с мейнфреймом, как обычный IBM XT или для прямого запуска мейнфреймовского софта. Интересно, что в XT/370 была реализована поддержка использования виртуальной памяти, что требовало наличия двух 68000. В 1984, с появлением PC AT был выпущен улучшенный вариант «персонального мейнфрейма» AT/370, который в режиме мейнфрейма был примерно в два раза быстрее XT/370. На этом история таких систем не закончилась, с 90-х производились подобные изделия, соответствующие системам 390. Насколько мне известно, для систем Z такого уже не делали.
IBM для своих мейнфреймов использует довольно необычную для сегодняшнего дня бизнес-модель, при которой компьютеры не продаются, а сдаются в аренду. Одно из преимуществ такой модели в том, что она гарантирует постоянный апгрейд аппаратуры, устаревающая техника автоматически заменяется на обновленную соответствующего класса. У этой модели есть и недостатки. Например, особенно ощутимый недостаток для тех, кто занимается историей компьютерных технологий, – это то, что отслужившие свое компьютеры практически всегда утилизируются и поэтому их практически невозможно встретить ни в каком музее.
Удивительно было обнаружить живую систему IBM 4361 в LCM! Но есть основания предположить, что это возможно не настоящее железо. Доступ посетителей музея к этому компьютеру почему-то закрыт. Не понятно также, какая именно модель там якобы представлена, и это при том, что другие компьютеры в музее идентифицируются весьма точно. Среди систем 4361 известны три модели 3, 4 и 5, причем модель 3 появилась позже моделей 4 и 5. Но система в музее самоидентифицируется как модель 1. Возможно, что это прототип. Однако, сотрудники музея на прямой вопрос о помощи с идентификацией не ответили и это при том, что на другие и часто довольно сложные вопросы они отвечают довольно оперативно. Некоторые особенности таймингов исполнения кодов дают основания, хотя и не абсолютно твердые, предполагать, что скорее всего к сети подключен эмулятор. Летом в музее, в связи с ковид, явно перешли на эмулятор… Есть ещё шанс добраться до железных мейнфреймов через сеть HNET, но у меня пока не получилось.
Но что бы там ни было, каждый может подключиться и попробовать поработать примерно так же, как работали высокооплачиваемые специалисты с середины 70-х. Цены были такие, что сегодня трудно поверить. Например, час машинного времени стоил в середине 80-х более 20 долларов и надо было ещё доплачивать за место на дисках! Правда речь идет именно о времени работы мейнфрейма, а не терминала, через который шла работа. Поэтому, например, при редактировании текста из часа фактической работы редко набиралось и 5 минут времени на оплату. Цены на сами мейнфреймы также были фантастические. Например, сотрудники Intel вспоминают, что в начале 80-х им предоставляли для работы только один мейнфрейм. Его производительность была 10 MIPS, а цена примерно 20 миллионов тогдашних долларов, которые были раза в три тяжелее сегодняшних! Интересно, что Intel предпочитала такие компьютеры, а не более дешевые системы VAX. Сейчас даже Raspberry Pi размером с таблетку и ценой в несколько долларов может запросто выдать более 1000 MIPS. Кстати, на Raspberry Pi или практически любом современном компьютере можно запустить эмулятор IBM/370, который будет работать значительно быстрее, чем любая система IBM из 80-х или даже 90-х. Однако, эмулятор надо настраивать и не все полезные программы для IBM/370 доступны свободно, поэтому бесплатный доступ к хорошо настроенной системе – это часто лучший способ поработать с мейнфреймом. Удивительно, но такие программы для доступа, эмуляторы терминалов 3270, доступны даже на мобильниках! Между прочим, мне удалось наладить свою систему VM/CMS на эмуляторе Hercules и разобраться с переносом файлов, но это потребовало не менее недели времени.
Эмулятор Hercules может эмулировать и более поздние системы IBM/390 и IBM/Z, но из-за проблем с лицензией на программное обеспечением это сделать намного сложнее. В качестве иллюстрации таких проблем приведу известный случай, когда IBM настояла на удалении раздела Эмуляция из уже опубликованной книги! В современных электронных вариантах этой книги этого раздела нет, его можно найти только в типографском издании или отдельным файлом на сайтах, посвященных свободному ПО. Дело в том, что эмуляция на обычных персоналках с начала 2000-х могла быть заметно быстрее, чем исполнение на гораздо более дорогих мейнфреймах. IBM поэтому пришлось изменить лицензии на своё программное обеспечение так, что его можно легально использовать только на аппаратуре, купленной у IBM. Конечно, речь не идет, что эмуляторы быстрее лучших мейнфреймов, они только демонстрируют заметно лучшее отношение быстродействия к стоимости.
Один из способов поработать с системами Z или 390 – это установить Linux в эмуляторе этих систем. Для 390 и Z доступны, как минимум, дистрибутивы Ubuntu и Debian. Тут стоит заметить, что быстрое развитие Linux во многом связано со значительной поддержкой от IBM. В частности, IBM в 2001 вложила миллиард долларов в развитие Linux.
Рассмотрим теперь особенности машинного языка систем, совместимых с 360. Базовый ассемблер таких систем называют BAL – Basic Assembly Language. Удивительно, но если верить слухам об IBM, то ассемблер там до сих пор один из основных рабочих языков программирования.
Ассемблер рассматриваемых мейнфреймов имеет ряд архаических особенностей, которые в других известных архитектурах, появившихся позже, уже отсутствовали. Речь, например, идет о том, что мнемоники BAL определяют тип аргументов. Рассмотрим в качестве примера команды ассемблера x86
Ассемблер BAL позволяет работать с тремя основными типами данных: двоичными, десятичными и вещественными числами. Системы 390 для работы с вещественными числами используют ещё один специальный тип. Некоторые системы Z могут ещё использовать и совершенно уникальные данные типа десятичные вещественные числа. Инструкции для работы с каждым типом образуют особый и довольно изолированный класс инструкций. Как правило, за очень редкими исключениями все системы, совместимые с 360, поддерживают инструкции десятичной и вещественной арифметики. Как известно, для архитектур x86 или 68k поддержка работы с вещественными числами появилась не сразу и долгое время была необязательной опцией, а работа с десятичными числами не была чем-то совершенно отдельным от двоичной арифметики – это было скорее расширение.
Для работы с вещественными и двоичными числами используют разные наборы регистров, а для работы с десятичными числами регистры не используются вообще. Система 370 предоставляет 16 32-разрядных регистров общего назначения для целых двоичных чисел, причем счетчик команд – это часть слова состояния процессора. Отдельного стека нет, его можно организовать, используя любой регистр, – так впоследствие реализовали работу со стеком и в ARM. Вызов подпрограмм также сделан как и в ARM, через регистр связи. Практически всегда все регистры взаимозаменяемые, исключения очень редки. Если сравнивать систему двоичных регистров BAL с конкурентной архитектурой VAX, то можно заметить, что у VAX на один регистр меньше. Это верно и для ARM.
Структура операндов в инструкциях покажется довольно знакомой тем, кто знает ассемблер x86. Для двоичных чисел операнды имеют структуру «регистр-регистр» или «регистр-память», причем для последнего случая из памяти можно загружать как 32-битные, так и 16-битные, расширяемые знаково, величины. Например, аналогом x86-инструкции
Редкая особенность BAL в наличии отдельных команд для сложения и вычитания для знаковых и беззнаковых чисел, причем беззнаковые операции в BAL называются логическими. Такая странность вызвана отсутствием в архитектуре 360 привычных для большинства других архитектур флагов. Вместо них используется только два бита, которые устанавливаются по-разному разными инструкциями! Разница между знаковыми и беззнаковыми операциями только в том, что они по-разному устанавливают упомянутые два бита признаков. Для знаковых операций по ним можно узнать, был ли результат равен нулю, был ли он положительный или отрицательный, произошло ли переполнение, а для беззнаковых – был ли результат равен нулю и случился ли перенос или заем. Команды условных переходов позволяют учитывать все 16 подмножеств случаев, которые возможны при использовании 2 бит. По причине такой необычной сегодня работы с признаками операций, инструкции условных переходов получаются трудными для быстрого понимания. Хотя в расширения BAL обычно добавляют довольно удобные для восприятия макросы для условных переходов, где не нужно заниматься разбором каждого из 4-х бит. Тут для справедливости можно заметить, что отдельные команды для знакового и беззнакового сложения и вычитания есть, например, в архитектуре MIPS, где вообще нет флагов!
Другая редкая особенность – в отдельных командах для знакового и беззнакового сравнения. Подобные встречал не только у MIPS, но и на MicroBlaze. В последнем, кстати, перенос – это единственный поддерживаемый флаг признаков операций.
В системах, совместимых с IBM 360, нет арифметических операций с флагом переноса, поэтому если нам нужно работать с двоичными числами, например, в 128-разрядов, то мы должны для организации их сложения или вычитания проверять признак переноса после выполнения первых 32-битных операций и делать при необходимости переход. Это, конечно, очень громоздко по сравнению с x86, ARM, 68k или даже 6502, но на гораздо более позднем MIPS – это ещё более громоздко. Нормальную работу с переносом сделали только в системе Z.
В BAL нет циклических сдвигов, зато нециклические, как и в x86, могут быть как одинарными, так и двойными. Однако, BAL имеет отдельные инструкции сдвигов для беззнаковых и знаковых чисел, только последние из них устанавливают флаги признаков. Очевидно, что результаты сдвигов влево для обоих случаев различаются только флагами. Вращения добавили только в системы 390.
Среди команд загрузки регистров в BAL есть скорее всего уникальные. Можно загружать модуль целого числа, отрицание этого модуля или число с измененным знаком – нечто отдаленно похожее мне встречалось только в архитектуре ARM. Тут стоит отметить, что вся архитектура 360 тяготеет к знаковой арифметике, а беззнаковая арифметика в этой архитектуре скорее вторична. В BAL изначально не было беззнаковых деления и умножения, их добавили только в систему 390. При загрузке регистра флаги, также как и в x86, не меняются, но есть специальная команда загрузки, которая ставит флаги – это опять напоминает ARM, где установкой флагов можно управлять.
Все знаковые арифметические операций, включая сдвиги, могут генерировать исключение при переполнении. Генерировать ли исключение или нет определяется специальным флагом маски в регистре состояния. Интересно, что двоичные деление и умножение в BAL вообще не влияют на флаги – тут можно вспомнить x86, где деление лишь портит флаги.
Поразрядные логические операции в BAL представлены обычным набором операций И, ИЛИ, исключающее ИЛИ, т. е. отдельной операции отрицания нет. Логические операции могут иметь не только структуру «регистр-регистр» или «регистр-память», но и «память-константа» или «память-память» – последний способ адресации похож на тот, что используется для десятичных чисел. Адресация типа «память-константа» возможна только для работы с байтами. Очевидно, для логических операции, в отличие от арифметических, использование 16-битных чисел невозможно. Для адресации типа «память-память» можно работать с данными длиной до 256 байт! Получается, что мы имеем три типа данных для работы с логическими операциями: байты, 32-битные слова, последовательности байт – и специальные инструкции для каждого такого типа, что скорее как-то неуниверсально.
К логическим операциям в BAL примыкают операции для пересылки байт. Помимо обычной пересылки до 256 байт одной командой, есть ещё уникальная инструкция пересылки тетрад байтов. Можно пересылать только старшие или младшие половинки байт и при этом другие половинки при копировании сохраняют своё значение! Такие странные операции нужны для поддержки особенностей BAL при работе с символьной и десятичной информацией. Есть ещё появившиеся для систем 370 команды пересылки и сравнения для до более 16 миллионов байт за один раз, которые могут прерываться. Удивительно, но также небыстрые команды по работе с блоками длиной до 256 байт прерываться не могут, что может создать неприятную своей длительностью задержку реакции на запрос на прерывание. Команды для пересылки можно использовать и для заполнения памяти заданным байтом. Помимо пересылки из памяти в память, можно ещё и устанавливать заданным значением отдельные байты. Очевидно, что команды для пересылки байт, если не рассматривать новые инструкции для 390 и Z, для x86 реализованы более продвинуто.
В регистр можно загружать не только значение по заданному адресу, но и сам адрес, как в командах LEA для x86 или 68k. Эта возможность позволяет также напрямую загружать в регистр нужную константу, хотя её максимальное значение не может быть большим 4095. Она же позволяет делать инкремент регистра на величину не более 4095. А вот декремент регистра можно делать только на 1. Как инкремент, так и декремент – это команды работы с адресом, поэтому они не меняют флаги. В регистр можно загружать и отдельные байты и даже группы байт из слова в памяти, например, только первый и третий байты – такое для всех других известных мне 32-битных архитектур возможно только через серию из 4-х команд. Аналогичным образом BAL позволяет выгружать в память только части регистра.
Ряд BAL инструкций очень специализирован – в других архитектурах такие реализуются серией более простых команд. Например, инструкция TR позволяет провести перекодировку строки символов – одним аргументом задаётся строка для перекодировки, а другим адрес перекодировочной таблицы. Особый вариант этой инструкции, TRT, можно использовать для сканирования заданной строки и пропуска пустых символов – это функциональность стандартного вызова strpos языка C. Инструкции ED и EDMK абсолютно уникальны – они имеют функциональность примитивного варианта sprintf! Однако почти все операции со строками имеют ограничение на максимальную длину строки, не более 255 байт, что значительно снижает их мощность.
В BAL из-за отсутствия команд вращения или команд типа SWAP довольно трудно работать с 16-битными беззнаковыми величинами. С систем 390 ситуация с этой проблемой стала лучше. Некоторые инструкции BAL объявлены устаревшими, например, инструкция для полубайтовых сдвигов MVO была вытеснена более удобной SRP. Для блочных пересылок и сравнений лучше использовать новые инструкции, хотя из-за того, что они используют другой способ адресации, это может быть в некоторых редких случаях неоптимальным.
Уже приводились примеры четырех основных режимов адресации BAL. Есть еще пятый для трехадресных команд. Такие режимы, как характерные для VAX, 68k, PDP-11 или даже 6809 режимы с авто-инкрементом или декрементом в BAL отсутствуют. Также нет режимов с двойным косвенным обращением к памяти, которые есть для VAX, 68020 или PDP-11. И, конечно, BAL, в отличие от ассемблеров VAX или PDP-11, совершенно неортогонален. Ближе всего BAL к ассемблерам x86 и ARM — самым успешным современным архитектурам. Порядок операндов в BAL справа-налево так же, как и в ассемблере Intel для x86 или в ассемблере ARM и, соответственно, не так как у VAX, PDP-11 или 68k. Хотя порядок байт в данных в BAL от старшему к младшему (MSB), что отличается от x86, ARM или VAX, но соответствует принятому для 68к или MIPS.
Операции с десятичными числами реализуются в BAL только через адресацию типа «память-память». Десятичные числа могут задаваться участками памяти длиной до 16 байт, что позволяет использовать числа, имеющие до 31 десятичного разряда. Это соответствует точности двоичного числа со 107 разрядами. Таким образом, только самые современные системы программирования, использующие целые двоичные числа, могут работать с большими величинами, чем системы 360 почти 60 лет назад! Конечно, можно через двоичную арифметику реализовывать сколь угодно большие числа, но популярных языков программирования, поддерживающих числа, большие, чем у древней системы 360, почему-то до недавнего времени не было. Да и сейчас поддержка 128-разрядных целых для x86 – это обычно только неофициальные расширения, как например, для GCC.
Десятичные числа на BAL представляются уникально, они должны хранить знак – такого нет для VAX, x86, 68k,… Причем знак хранится в последнем байте представления числа! Для десятичных чисел в BAL есть непосредственная поддержка для всех основных операций: сложения, вычитания, умножения и даже деления – такого также нет ни в одной другой известной мне архитектуре. Кроме того в BAL есть ещё инструкции для копирования, сравнения и сдвигов десятичных чисел. Упоминавшаяся инструкция MVO и SRP предназначены именно для таких сдвигов. Операции могут выполняться только над упакованными десятичными числами, но для их распечатки их надо распаковать, причем и для представления распакованных цифр в BAL также необходим знак, который в этом случае не занимет места, так как помещается в старшую тетраду, что требует особой работы с этой тетрадой перед печатью. Странно, что операции для паковки и распаковки могут работать только с не более чем 16 байтами распакованного десятичного числа, что позволяет использовать с ними только не более, чем 15-разрядные числа. Эта неприятная проблема может быть решена использованием для распаковки инструкций ED или EDMK, а вот упаковку большого неупакованного числа придётся делать через не самую простую последовательность инструкций. В системы 390 добавили новые инструкции, решающме эту проблему. Любопытно, что инструкции для упаковки и распаковки работают с любыми двоичными данными, а не только с десятичными.
В BAL есть специальные уникальные инструкции, позволяющие за раз конвертировать двоичное число в упакованное десятичное и наоборот. Для десятичного числа в этих инструкциях всегда выделяется 8 байт, т. е. 15 цифр и знак. Однако, 32-битного регистра хватает только для представления знакового числа, соответствующего 9-значному десятичному числу, поэтому не всякое десятичное число в правильном формате BAL можно преобразовать в двоичное одной командой. Для систем Z есть расширенные инструкции для подобных преобразований.
Команды переходов в BAL отличаются тем, что они, как правило, парные – адрес перехода можно задать как явно, так и содержимым регистра – в многих других архитектурах переходы по содержимому регистра есть только для безусловных переходов. Кстати, безусловных переходов в BAL нет, они реализуются заданием всегда истинного условия, что аналогично архитектуре ARM. Условные переходы в BAL, как уже отмечалось, имеют уникальный синтаксис. Рассмотрим, например, инструкцию
Как уже отмечалось, вызов подпрограмм в BAL реализован без использования стека, через простое сохранение адреса возврата в регистре. Однако, инструкции BAL для таких вызовов, одна из которых также называется BAL, сохраняют не только адрес возврата, но и часть регистра статуса, в частности, флаги условий, длину текущей инструкции и даже маску для опциональных исключительных ситуаций, например, для целочисленного или десятичного переполнения, – об этом уже упоминалось выше. Такое необычное расширенное сохранение информации связано с тем, что счётчик команд в архитектуре мейнфреймов – это старшая часть машинного слова статуса и инструкции вызова подпрограмм механически сохраняют его старшую часть. Специальных команд для возврата из подпрограмм нет, нужно использовать обычный переход по адресу в регистре. В системах 390 в связи с переходом на 31-разрядную архитектуру появились новые команды для вызова и даже возврата из подпрограмм. Новые инструкции позволяют гибко использовать в одной программе коды, исполняющиеся в разных режимах.
Для быстрого вызова однокомандных подпрограмм в BAL есть уникальная инструкция EX, которая выполняет инструкцию по заданному адресу и переходит к следующей команде. Инструкция EX может модифицировать вызываемую инструкцию, что позволяет использовать в вызываемой инструкции любой нужный регистр или задавать параметры при массовой пересылке байт. Подобная инструкция, но более простая есть ещё в системе команд TMS9900.
Изначально в BAL не было относительных, перемещаемых переходов, таких как есть в Z80 или x86. Их добавили только в системы 390.
Несколько необычны ещё команды SPM, TM, TS, STCK и STPT. Первая из них позволяет одной командой установить все флаги операций и маску опциональных исключений. Команда TM позволяет проверить группу бит и определить три случая: все нули, все единицы, смесь из нулей и единиц. Такую проверку одной командой в других архитектурах не сделать. Однако, TM работает только с отдельными байтами в памяти. TS используется при работе с несколькими процессорами – похожая команда есть для 68k. Инструкция STCK считывает значение внешнего (!) таймера, а инструкция STPT значение внутреннего таймера, встроенного в процессорную схему. Странно, но команда STPT привилегированная, а STCK нет.
Стоит ещё упомянуть инструкции CS и CDS, которые предназначены для поддержки мультипроцессорной работы. Они реализованы для систем 370, т. е. доступны с начала 70-х. В x86 аналог CS, инструкция CMPXCHG, была реализована не ранее 1987, а аналог CDS, инструкция CMPXCHG8B, – только в 1994!
С систем 370 вводится команда самоидентификации системы STIDP, она привилегированная и не слишком информативная. Для x86 подобная команда сделана существенно мощнее. Тут можно ещё заметить, что IBM 4361 в LCM позволяет исполнить STIDP любому пользователю. Это очевидно эмуляция, срабатывающая по исключению.
Четыре адресных режима BAL задают два операнда для инструкции, пятый режим задает трехадресные команды. Однако, игнорирование части информации позволяет иметь одноадресные команды, а использование неявной информации – четырехадресные. При использовании в адресации регистр 0 имеет особую роль: он там просто игнорируется – это позволяет не учитывать базу и индекс при расчете адреса. Все инструкции BAL занимают строго 2, 4 или 6 байт. Это похоже на 68000 или PDP-11, но не на x86, VAX или ARM.
В систему 390 добавили ещё несколько режимов адресации, доведя их число до 18. Число инструкций также возросло весьма значительно, среди новых инструкций есть даже поддерживающие работу с Unicode – такого до сих пор нет для x86! Среди новых инструкций систем 390 есть и другие уникальные. В систему Z добавили ещё несколько режимов адресации, а общее число команд для современных Z весьма велико и наверное даже больше числа команд для современных x86-64!
В системах 360, 370 и 390 смещения при обращении к данным в памяти, как и в ARM, 12-разрядное, т. е. не более 4095, что не очень удобно – в больших кодах может возникнуть нехватка регистров для базы. В x86 такое смещение 16-разрядное, что, конечно, гораздо удобнее. Но в систему Z добавили поддержку адресации с 20-разрядным смещением, что, конечно, ещё лучше. Хотя, стоит отметить, что в x86-64 или даже в 68020 смещение может быть 32 битным. Как уже отмечалось, в системах до 390, как и в ARM, не было возможности использовать большие константы при работе с регистрами. Архитектура x86 здесь гораздо гибче. Поэтому при использовании ассемблера с системой 360 или 370 часто приходилось использовать литералы, псевдоконстанты, что несколько медленнее.
По быстродействию системы, совместимые с IBM/360, всегда имели неплохие показатели. Мои эксперименты с 4361-1, в частности, в проекте вычисления числа ? по алгоритму-затвору, показали очень хорошие тайминги. Инструкции 4361-1 работают практически без задержек, как ARM или другие современные процессоры. Однако, из-за несколько неуклюжей системы команд, полученной в наследство из 60-х, в частности, из-за отсутствия деления на 16-разрядный делитель, результат по эффективности электроники процессора оказался на уровне 80186. Это примерно на 80% хуже результата, показанного лучшим тогда компьютером из семейства VAX, модели 785. Однако, мейнфрейм в LCM явно далеко не самый лучший среди мейнфреймов IBM доступных тогда. Здесь ещё уместно заметить, что мейнфреймы использовали каналы, специализированные процессоры, которые делали ввод-вывод очень быстрым, гораздо более быстрым, чем у большинства современных им компьютеров.
Мне студентом случилось поработать с отечественным клоном IBM/370, ЕС-1045, в 1987 через пакетный режим, а в 1989 через диалоговый. Для пакетного режима приходилось готовить перфокарты. В то время уже использовал домашний компьютер и поэтому использование архаичных перфокарт оставило не лучшее впечатление. А вот диалоговый режим был неплох, только часто ломался, при большом числе пользователей. Поэтому некоторые студенты приезжали работать к 4 утра! С тех пор больше с мейнфреймами дела иметь не получалось, только недавно решил через эмуляцию поразбираться с этой веховой для истории компьютеров технологией.
Клонирование IBM 360 было весьма популярно. Клоны делали в Англии, Германии, Японии и другими компаниями в США. В СССР это клонирование приобрело очень драматический оттенок. Ради этого клонирования произошла свёртка почти всех отечественных разработок в области ИТ, некоторые из которых были весьма перспективны. В частности была закрыта тема компьютеров Урал, о которых потом с теплотой отзывался известный компьютерщик Чарльз Симони. Закрыт был также проект БЭСМ-10, хотя машины предшествующего класса БЭСМ-6 были сравнимы с IBM 360 по быстродействию. Также ради этого клонирования сорвали почти заключенный контракт с ICL, возможно с этим контрактом британская индустрия ИТ приобрела бы новую динамику и не пришла бы в упадок. Только суперкомпьютеры Эльбрус, возможно из-за их связи с оборонной промышленностью, уцелели после «вторжения клонов», которое Дейкстра назвал величайшей победой США в холодной войне.
Как вспоминают люди, работавшие с мейнфреймами в СССР, отечественный клоны отличались чрезвычайно низкой надежностью и требовали к себе постоянного внимания со стороны обслуживающего персонала. В то время как оригинальные американские мейнфреймы IBM были одними из самых надежных компьютеров своего времени. В советские клоны закладывали иногда более десятка килограмм драгоценных металлов, золота, платины, палладия и серебра, но это не помогло исправить ситуацию с надежностью. Из-за такого большого количества высоколиквидных ценностей трудно представить, что работающий отечественный клон мог где-нибудь сохраниться.
Интересно, что главный разработчик IBM 360 ушел из IBM и основал фирму Amdahl, которая более двух десятков лет специализировалась на производстве систем, совместимых с мейнфреймами IBM и при этом несколько их превосходящих по быстродействию и надежности при более низких ценах. В итоге из-за больших перемен на рынке мейнфреймов, Amdahl, как и ICL, стали частью японской корпорации Fujitsu.
Как уже писал, мне удалось настроить рабочую конфигурацию для VM/CMS 6. Однако, обнаружилось, что редактора XEDIT в свободном доступе нет, а простой EDIT слишком своеобразен и неудобен, поэтому редактировать тексты приходится в хосте. Также обнаружилось недоступность штатной программы для переноса файлов с эмулятора терминала на мейнфрейм и обратно, что потребовало использования виртуальных перфокарт для такого переноса. Другая неприятная неожиданность обнаружилась в связи с отладкой. Команда DEBUG не поддерживает пошагового исполнения! В то время как такая возможность была даже для отладчика DDT для процессора 8080. Также удивительно, хотя и менее критично, что DEBUG не умеет делать дизассемблирование, которое часто встраивалось даже в простейшие мониторы процессоров 70-х. Под CMS на низком уровне не поддерживается перенос длинных строк и управляющий символ конца строки! Поэтому при печати из программ на ассемблере нужно форматировать строки вручную, чтобы они не пропадали за правым краем экрана, а также заботиться о заполнении финишными пробелами последней строки. Также необычно отсутствие автоматического вертикального скроллинга.
Тем, кто захочет поработать с мейнфреймами впервые, стоит иметь в виду, что мейнфреймы – это огромная экосистема, где многие привычные понятия могут иметь другую трактовку. Например, простого понятия файл там нет. Одним из ключевых атрибутов файла является размер записи, ничего подобного для файлов Linux или Microsoft Windows нет. Сами файлы различаются по методам доступа к ним и об этом писались и возможно пишутся нетонкие книги. Также необычно, что в CMS имя диска пишется в конце полного имени файла, а разделяются имя, расширение и диск пробелами, причем само имя диска называется почему-то режимом файла. Хотелось бы ещё поразбираться с многозадачной MVS, насколько знаю в СССР до неё так и не дошли.
Вообще несколько неожиданно, что некоторые известные операционные системы, которые использовались на весьма дорогих компьютерах, не поддерживали работу с каталогами файлов, что равняло их с самыми первыми и примитивными ОС для микрокомпьютеров, например, CP/M или Commodore DOS. Не случайно поэтому CMS иногда называли CP/M для мейнфреймов. Удивительно, но насколько мне известно, поддержку для каталогов в CMS так и не ввели, хотя последний выпуск системы датируется 2018. Почему-то работа с каталогами для дорогих компьютеров до 80-х поддерживалась часто плохо. Например, такой поддержки не было в DEC RT-11 и даже одна из лучших ОС для PDP-11, RSX-11, поддерживала только двухуровневые каталоги. В самой популярной IBM ОС до 2000-х была MVS (1974) и даже тут каталоги были сделаны только частично, как и в Apple MFS (1984). Хотя в Unix (1973), MS-DOS (с 1983) или даже 8-битной Apple ProDOS (1983) с этим всё было в порядке с самого начала. Самая продвинутая работа с файлами предлагалась в VAX/VMS (1977), где помимо каталогов есть даже встроенная поддержка версионирования файлов.
Интересно, что язык сценариев для CMS, MVS и некоторых других IBM ОС, REXX, в сокращенном варианте стал языком командных файлов для Commodore Amiga.
Программы для мейнфреймов, как правило, двухцветные. Терминалы, поддерживающие цвет, использовались сравнительно редко и поэтому цветных программ мало. Также мало программ с динамической графикой, частое обновление экрана приводит к заметному неприятному мерцанию.
Динамическая демка, запущена на эмуляторе IBM 4381 в LCM, терминал 3270-3
В заключении не могу удержаться, чтобы не выразить восхищение технологиями IBM. Они всегда отличались неповторимым своеобразием и высоким уровнем. Особенно хочу отметить очень хорошее качество документации, которая и даже по современным системам есть в открытом доступе. IBM демонстрирует колоссальный динамизм развития технологий и это при том, что это одна из крупнейших компаний в мире. По числу наемных работников она почти равна Microsoft, Google и Intel взятым вместе!
Тема мейнфреймов огромна. Конечно, смог написать только небольшую часть того, что она может вместить. Буду очень признателен за уточнения и дополнительную информацию.
Этот материал доступен и на английском.
В этой части главное внимание уделяется сравнению машинного языка мейнфреймов с другими системами, которые были популярны в период с 70-х по 90-е. Это прежде всего x86, 68k, VAX и ARM. Системы 390 и, в особенности, Z рассматриваются очень фрагментарно – основное внимание уделяется именно системе 370.
Первые системы 360 стали поставляться заказчикам с 1965 года, а более совершенные системы 370 с 1970. IBM поддерживает программную совместимость с этими системами до настоящего времени! Удивительно, но до систем 390, поставляемых, как можно догадаться с 1990 года, мейнфреймы работали с 24-битными адресами, т. е. могли адресовать не более 16 мегабайт памяти, столько же, сколько, например, 68000, выпущенный в 1979, или 65816 или 32016, выпущенные в 1982. VAX изначально поддерживал 32-битную адресацию. Популярные процессоры 68020 или 80386, появившись в середине 80-х, также поддерживали 32-битные адреса. Реально 16 МБ памяти для лучших систем второй половины 80-х – это было уже мало. Однако, IBM c 1983 производила совместимые с 370 вычислительные машины, которые могли как расширение использовать 31 разряд для адреса, что снимало проблему объема памяти для лучших компьютеров. Необычно и уникально, что в этих расширениях и системах 390 использовали 31-битный адрес, а не полный 32-битный. В 2000 IBM объявила о первой системе Z, где используются 64-битные адресация и данные. Системы Z стали c 2008 использовать чипы-процессоры. Архитектуру Z c 2007 пытаются соединить в одном чипе с архитектурой POWER, но пока безуспешно. Соединить CISC и RISC в одном чипе пока получилось только у Intel – Pentium Pro в 1995 стал первым чипом такого рода.
IBM System/370-145 c ленточными накопителем 2401 и принтером вместо дисплея, 1971. Может удивить отсутствие дисплея в этой очень дорогой системе при том, что телевизоры массово производятся уже более 20 лет
Кстати, некоторые авторитеты считают, что первым серийным персональным компьютером был IBM 5100, производимый с 1975, который через аппаратный эмулятор мог исполнять инструкции системы 360. Его улучшенные варианты производились до середины 80-х. Хотя скорее всё-таки первым был Wang 2200. По ценам (примерно $10000) эти первые персоналки были явно не для домашнего использования.
IBM 5100, вариант с поддержкой языка APL
С появлением архитектуры IBM PC, которая, как оказалось, на десятилетия определила основное направление развития для вычислительной техники, IBM попыталась в 1983 соединить почти все лучшие тогда компьютерные технологии в одном изделии PC XT/370: свои системы 370, IBM PC XT, Motorola 68000 и Intel 8087. Этот XT/370 можно было использовать как интеллектуальный терминал для работы с мейнфреймом, как обычный IBM XT или для прямого запуска мейнфреймовского софта. Интересно, что в XT/370 была реализована поддержка использования виртуальной памяти, что требовало наличия двух 68000. В 1984, с появлением PC AT был выпущен улучшенный вариант «персонального мейнфрейма» AT/370, который в режиме мейнфрейма был примерно в два раза быстрее XT/370. На этом история таких систем не закончилась, с 90-х производились подобные изделия, соответствующие системам 390. Насколько мне известно, для систем Z такого уже не делали.
IBM для своих мейнфреймов использует довольно необычную для сегодняшнего дня бизнес-модель, при которой компьютеры не продаются, а сдаются в аренду. Одно из преимуществ такой модели в том, что она гарантирует постоянный апгрейд аппаратуры, устаревающая техника автоматически заменяется на обновленную соответствующего класса. У этой модели есть и недостатки. Например, особенно ощутимый недостаток для тех, кто занимается историей компьютерных технологий, – это то, что отслужившие свое компьютеры практически всегда утилизируются и поэтому их практически невозможно встретить ни в каком музее.
Удивительно было обнаружить живую систему IBM 4361 в LCM! Но есть основания предположить, что это возможно не настоящее железо. Доступ посетителей музея к этому компьютеру почему-то закрыт. Не понятно также, какая именно модель там якобы представлена, и это при том, что другие компьютеры в музее идентифицируются весьма точно. Среди систем 4361 известны три модели 3, 4 и 5, причем модель 3 появилась позже моделей 4 и 5. Но система в музее самоидентифицируется как модель 1. Возможно, что это прототип. Однако, сотрудники музея на прямой вопрос о помощи с идентификацией не ответили и это при том, что на другие и часто довольно сложные вопросы они отвечают довольно оперативно. Некоторые особенности таймингов исполнения кодов дают основания, хотя и не абсолютно твердые, предполагать, что скорее всего к сети подключен эмулятор. Летом в музее, в связи с ковид, явно перешли на эмулятор… Есть ещё шанс добраться до железных мейнфреймов через сеть HNET, но у меня пока не получилось.
Но что бы там ни было, каждый может подключиться и попробовать поработать примерно так же, как работали высокооплачиваемые специалисты с середины 70-х. Цены были такие, что сегодня трудно поверить. Например, час машинного времени стоил в середине 80-х более 20 долларов и надо было ещё доплачивать за место на дисках! Правда речь идет именно о времени работы мейнфрейма, а не терминала, через который шла работа. Поэтому, например, при редактировании текста из часа фактической работы редко набиралось и 5 минут времени на оплату. Цены на сами мейнфреймы также были фантастические. Например, сотрудники Intel вспоминают, что в начале 80-х им предоставляли для работы только один мейнфрейм. Его производительность была 10 MIPS, а цена примерно 20 миллионов тогдашних долларов, которые были раза в три тяжелее сегодняшних! Интересно, что Intel предпочитала такие компьютеры, а не более дешевые системы VAX. Сейчас даже Raspberry Pi размером с таблетку и ценой в несколько долларов может запросто выдать более 1000 MIPS. Кстати, на Raspberry Pi или практически любом современном компьютере можно запустить эмулятор IBM/370, который будет работать значительно быстрее, чем любая система IBM из 80-х или даже 90-х. Однако, эмулятор надо настраивать и не все полезные программы для IBM/370 доступны свободно, поэтому бесплатный доступ к хорошо настроенной системе – это часто лучший способ поработать с мейнфреймом. Удивительно, но такие программы для доступа, эмуляторы терминалов 3270, доступны даже на мобильниках! Между прочим, мне удалось наладить свою систему VM/CMS на эмуляторе Hercules и разобраться с переносом файлов, но это потребовало не менее недели времени.
Эмулятор Hercules может эмулировать и более поздние системы IBM/390 и IBM/Z, но из-за проблем с лицензией на программное обеспечением это сделать намного сложнее. В качестве иллюстрации таких проблем приведу известный случай, когда IBM настояла на удалении раздела Эмуляция из уже опубликованной книги! В современных электронных вариантах этой книги этого раздела нет, его можно найти только в типографском издании или отдельным файлом на сайтах, посвященных свободному ПО. Дело в том, что эмуляция на обычных персоналках с начала 2000-х могла быть заметно быстрее, чем исполнение на гораздо более дорогих мейнфреймах. IBM поэтому пришлось изменить лицензии на своё программное обеспечение так, что его можно легально использовать только на аппаратуре, купленной у IBM. Конечно, речь не идет, что эмуляторы быстрее лучших мейнфреймов, они только демонстрируют заметно лучшее отношение быстродействия к стоимости.
Один из способов поработать с системами Z или 390 – это установить Linux в эмуляторе этих систем. Для 390 и Z доступны, как минимум, дистрибутивы Ubuntu и Debian. Тут стоит заметить, что быстрое развитие Linux во многом связано со значительной поддержкой от IBM. В частности, IBM в 2001 вложила миллиард долларов в развитие Linux.
Рассмотрим теперь особенности машинного языка систем, совместимых с 360. Базовый ассемблер таких систем называют BAL – Basic Assembly Language. Удивительно, но если верить слухам об IBM, то ассемблер там до сих пор один из основных рабочих языков программирования.
Ассемблер рассматриваемых мейнфреймов имеет ряд архаических особенностей, которые в других известных архитектурах, появившихся позже, уже отсутствовали. Речь, например, идет о том, что мнемоники BAL определяют тип аргументов. Рассмотрим в качестве примера команды ассемблера x86
MOV EAX,EBX и MOV EAX,address – в обоих случаях используется мнемоника MOV. Для BAL для подобных случаев используются разные мнемоники LR и L в командах соответственно LR 0,1 и L 0,address. Однако подобные разные мнемоники позволяют использовать числа для именования регистров, хотя обычно макросы R0, R1,… вместо чисел 0, 1,… – это первое, что определяется в макропакетах для удобства программирования. Другой архаизм – это использование переходов по метке в конструкциях условной компиляции, хотя по моему скромному мнению – это иногда удобнее блочных структур. Но самый известный архаизм – это использование кодировки EBCDIC для работы с символьной информацией. В этой странной даже для вчерашнего дня кодировке буквы английского алфавита кодируются не подряд, например, буква I имеет код 201, а следующая за ней J – 209! Эта кодировка происходит из технологий работы с перфокартами, возникшими ещё в докомпьютерную эпоху. Система 360 на аппаратном уровне поддерживает и кодировку ASCII, но в её древнем и давно забытом варианте, где символ для цифры 0 имеет код 80, а не 48 как сейчас. Насколько мне известно, ASCII с мейнфреймами IBM лучше было даже и не пытаться использовать. Поддержку ASCII убрали уже системах 370, но ввели на новом уровне в системах 390. Некоторые мнемоники BAL поражают своей сверхкраткостью и даже немнемоничностью, например, N значит AND, O – OR, X – XOR, A – ADD, S – SUBTRACT, M – MULTIPLY,…Ассемблер BAL позволяет работать с тремя основными типами данных: двоичными, десятичными и вещественными числами. Системы 390 для работы с вещественными числами используют ещё один специальный тип. Некоторые системы Z могут ещё использовать и совершенно уникальные данные типа десятичные вещественные числа. Инструкции для работы с каждым типом образуют особый и довольно изолированный класс инструкций. Как правило, за очень редкими исключениями все системы, совместимые с 360, поддерживают инструкции десятичной и вещественной арифметики. Как известно, для архитектур x86 или 68k поддержка работы с вещественными числами появилась не сразу и долгое время была необязательной опцией, а работа с десятичными числами не была чем-то совершенно отдельным от двоичной арифметики – это было скорее расширение.
Для работы с вещественными и двоичными числами используют разные наборы регистров, а для работы с десятичными числами регистры не используются вообще. Система 370 предоставляет 16 32-разрядных регистров общего назначения для целых двоичных чисел, причем счетчик команд – это часть слова состояния процессора. Отдельного стека нет, его можно организовать, используя любой регистр, – так впоследствие реализовали работу со стеком и в ARM. Вызов подпрограмм также сделан как и в ARM, через регистр связи. Практически всегда все регистры взаимозаменяемые, исключения очень редки. Если сравнивать систему двоичных регистров BAL с конкурентной архитектурой VAX, то можно заметить, что у VAX на один регистр меньше. Это верно и для ARM.
Структура операндов в инструкциях покажется довольно знакомой тем, кто знает ассемблер x86. Для двоичных чисел операнды имеют структуру «регистр-регистр» или «регистр-память», причем для последнего случая из памяти можно загружать как 32-битные, так и 16-битные, расширяемые знаково, величины. Например, аналогом x86-инструкции
ADD EAX,EBX будет AR 0,1, ADD EAX,address – A 0,address, ADD EAX,address[EBX] – A 0,address(1), ADD EAX,address[EBX][EDX] – A 0,address(1,3). Однако системы 360 и даже их поздние развитие не умеют работать с масштабированием, например, ADD EAX,address[8*EBX] на BAL одной командой не запишешь. С другой стороны, x86 не умеет работать с 16-битными знаковыми расширениями, например, команда BAL AH 0,address, которая означает взять 16-битное знаковое число из памяти и добавить его к содержимому регистра 0, на x86 потребует двух команд для своей реализации.Редкая особенность BAL в наличии отдельных команд для сложения и вычитания для знаковых и беззнаковых чисел, причем беззнаковые операции в BAL называются логическими. Такая странность вызвана отсутствием в архитектуре 360 привычных для большинства других архитектур флагов. Вместо них используется только два бита, которые устанавливаются по-разному разными инструкциями! Разница между знаковыми и беззнаковыми операциями только в том, что они по-разному устанавливают упомянутые два бита признаков. Для знаковых операций по ним можно узнать, был ли результат равен нулю, был ли он положительный или отрицательный, произошло ли переполнение, а для беззнаковых – был ли результат равен нулю и случился ли перенос или заем. Команды условных переходов позволяют учитывать все 16 подмножеств случаев, которые возможны при использовании 2 бит. По причине такой необычной сегодня работы с признаками операций, инструкции условных переходов получаются трудными для быстрого понимания. Хотя в расширения BAL обычно добавляют довольно удобные для восприятия макросы для условных переходов, где не нужно заниматься разбором каждого из 4-х бит. Тут для справедливости можно заметить, что отдельные команды для знакового и беззнакового сложения и вычитания есть, например, в архитектуре MIPS, где вообще нет флагов!
Другая редкая особенность – в отдельных командах для знакового и беззнакового сравнения. Подобные встречал не только у MIPS, но и на MicroBlaze. В последнем, кстати, перенос – это единственный поддерживаемый флаг признаков операций.
В системах, совместимых с IBM 360, нет арифметических операций с флагом переноса, поэтому если нам нужно работать с двоичными числами, например, в 128-разрядов, то мы должны для организации их сложения или вычитания проверять признак переноса после выполнения первых 32-битных операций и делать при необходимости переход. Это, конечно, очень громоздко по сравнению с x86, ARM, 68k или даже 6502, но на гораздо более позднем MIPS – это ещё более громоздко. Нормальную работу с переносом сделали только в системе Z.
В BAL нет циклических сдвигов, зато нециклические, как и в x86, могут быть как одинарными, так и двойными. Однако, BAL имеет отдельные инструкции сдвигов для беззнаковых и знаковых чисел, только последние из них устанавливают флаги признаков. Очевидно, что результаты сдвигов влево для обоих случаев различаются только флагами. Вращения добавили только в системы 390.
Среди команд загрузки регистров в BAL есть скорее всего уникальные. Можно загружать модуль целого числа, отрицание этого модуля или число с измененным знаком – нечто отдаленно похожее мне встречалось только в архитектуре ARM. Тут стоит отметить, что вся архитектура 360 тяготеет к знаковой арифметике, а беззнаковая арифметика в этой архитектуре скорее вторична. В BAL изначально не было беззнаковых деления и умножения, их добавили только в систему 390. При загрузке регистра флаги, также как и в x86, не меняются, но есть специальная команда загрузки, которая ставит флаги – это опять напоминает ARM, где установкой флагов можно управлять.
Все знаковые арифметические операций, включая сдвиги, могут генерировать исключение при переполнении. Генерировать ли исключение или нет определяется специальным флагом маски в регистре состояния. Интересно, что двоичные деление и умножение в BAL вообще не влияют на флаги – тут можно вспомнить x86, где деление лишь портит флаги.
Поразрядные логические операции в BAL представлены обычным набором операций И, ИЛИ, исключающее ИЛИ, т. е. отдельной операции отрицания нет. Логические операции могут иметь не только структуру «регистр-регистр» или «регистр-память», но и «память-константа» или «память-память» – последний способ адресации похож на тот, что используется для десятичных чисел. Адресация типа «память-константа» возможна только для работы с байтами. Очевидно, для логических операции, в отличие от арифметических, использование 16-битных чисел невозможно. Для адресации типа «память-память» можно работать с данными длиной до 256 байт! Получается, что мы имеем три типа данных для работы с логическими операциями: байты, 32-битные слова, последовательности байт – и специальные инструкции для каждого такого типа, что скорее как-то неуниверсально.
К логическим операциям в BAL примыкают операции для пересылки байт. Помимо обычной пересылки до 256 байт одной командой, есть ещё уникальная инструкция пересылки тетрад байтов. Можно пересылать только старшие или младшие половинки байт и при этом другие половинки при копировании сохраняют своё значение! Такие странные операции нужны для поддержки особенностей BAL при работе с символьной и десятичной информацией. Есть ещё появившиеся для систем 370 команды пересылки и сравнения для до более 16 миллионов байт за один раз, которые могут прерываться. Удивительно, но также небыстрые команды по работе с блоками длиной до 256 байт прерываться не могут, что может создать неприятную своей длительностью задержку реакции на запрос на прерывание. Команды для пересылки можно использовать и для заполнения памяти заданным байтом. Помимо пересылки из памяти в память, можно ещё и устанавливать заданным значением отдельные байты. Очевидно, что команды для пересылки байт, если не рассматривать новые инструкции для 390 и Z, для x86 реализованы более продвинуто.
В регистр можно загружать не только значение по заданному адресу, но и сам адрес, как в командах LEA для x86 или 68k. Эта возможность позволяет также напрямую загружать в регистр нужную константу, хотя её максимальное значение не может быть большим 4095. Она же позволяет делать инкремент регистра на величину не более 4095. А вот декремент регистра можно делать только на 1. Как инкремент, так и декремент – это команды работы с адресом, поэтому они не меняют флаги. В регистр можно загружать и отдельные байты и даже группы байт из слова в памяти, например, только первый и третий байты – такое для всех других известных мне 32-битных архитектур возможно только через серию из 4-х команд. Аналогичным образом BAL позволяет выгружать в память только части регистра.
Ряд BAL инструкций очень специализирован – в других архитектурах такие реализуются серией более простых команд. Например, инструкция TR позволяет провести перекодировку строки символов – одним аргументом задаётся строка для перекодировки, а другим адрес перекодировочной таблицы. Особый вариант этой инструкции, TRT, можно использовать для сканирования заданной строки и пропуска пустых символов – это функциональность стандартного вызова strpos языка C. Инструкции ED и EDMK абсолютно уникальны – они имеют функциональность примитивного варианта sprintf! Однако почти все операции со строками имеют ограничение на максимальную длину строки, не более 255 байт, что значительно снижает их мощность.
В BAL из-за отсутствия команд вращения или команд типа SWAP довольно трудно работать с 16-битными беззнаковыми величинами. С систем 390 ситуация с этой проблемой стала лучше. Некоторые инструкции BAL объявлены устаревшими, например, инструкция для полубайтовых сдвигов MVO была вытеснена более удобной SRP. Для блочных пересылок и сравнений лучше использовать новые инструкции, хотя из-за того, что они используют другой способ адресации, это может быть в некоторых редких случаях неоптимальным.
Уже приводились примеры четырех основных режимов адресации BAL. Есть еще пятый для трехадресных команд. Такие режимы, как характерные для VAX, 68k, PDP-11 или даже 6809 режимы с авто-инкрементом или декрементом в BAL отсутствуют. Также нет режимов с двойным косвенным обращением к памяти, которые есть для VAX, 68020 или PDP-11. И, конечно, BAL, в отличие от ассемблеров VAX или PDP-11, совершенно неортогонален. Ближе всего BAL к ассемблерам x86 и ARM — самым успешным современным архитектурам. Порядок операндов в BAL справа-налево так же, как и в ассемблере Intel для x86 или в ассемблере ARM и, соответственно, не так как у VAX, PDP-11 или 68k. Хотя порядок байт в данных в BAL от старшему к младшему (MSB), что отличается от x86, ARM или VAX, но соответствует принятому для 68к или MIPS.
Операции с десятичными числами реализуются в BAL только через адресацию типа «память-память». Десятичные числа могут задаваться участками памяти длиной до 16 байт, что позволяет использовать числа, имеющие до 31 десятичного разряда. Это соответствует точности двоичного числа со 107 разрядами. Таким образом, только самые современные системы программирования, использующие целые двоичные числа, могут работать с большими величинами, чем системы 360 почти 60 лет назад! Конечно, можно через двоичную арифметику реализовывать сколь угодно большие числа, но популярных языков программирования, поддерживающих числа, большие, чем у древней системы 360, почему-то до недавнего времени не было. Да и сейчас поддержка 128-разрядных целых для x86 – это обычно только неофициальные расширения, как например, для GCC.
Десятичные числа на BAL представляются уникально, они должны хранить знак – такого нет для VAX, x86, 68k,… Причем знак хранится в последнем байте представления числа! Для десятичных чисел в BAL есть непосредственная поддержка для всех основных операций: сложения, вычитания, умножения и даже деления – такого также нет ни в одной другой известной мне архитектуре. Кроме того в BAL есть ещё инструкции для копирования, сравнения и сдвигов десятичных чисел. Упоминавшаяся инструкция MVO и SRP предназначены именно для таких сдвигов. Операции могут выполняться только над упакованными десятичными числами, но для их распечатки их надо распаковать, причем и для представления распакованных цифр в BAL также необходим знак, который в этом случае не занимет места, так как помещается в старшую тетраду, что требует особой работы с этой тетрадой перед печатью. Странно, что операции для паковки и распаковки могут работать только с не более чем 16 байтами распакованного десятичного числа, что позволяет использовать с ними только не более, чем 15-разрядные числа. Эта неприятная проблема может быть решена использованием для распаковки инструкций ED или EDMK, а вот упаковку большого неупакованного числа придётся делать через не самую простую последовательность инструкций. В системы 390 добавили новые инструкции, решающме эту проблему. Любопытно, что инструкции для упаковки и распаковки работают с любыми двоичными данными, а не только с десятичными.
В BAL есть специальные уникальные инструкции, позволяющие за раз конвертировать двоичное число в упакованное десятичное и наоборот. Для десятичного числа в этих инструкциях всегда выделяется 8 байт, т. е. 15 цифр и знак. Однако, 32-битного регистра хватает только для представления знакового числа, соответствующего 9-значному десятичному числу, поэтому не всякое десятичное число в правильном формате BAL можно преобразовать в двоичное одной командой. Для систем Z есть расширенные инструкции для подобных преобразований.
Команды переходов в BAL отличаются тем, что они, как правило, парные – адрес перехода можно задать как явно, так и содержимым регистра – в многих других архитектурах переходы по содержимому регистра есть только для безусловных переходов. Кстати, безусловных переходов в BAL нет, они реализуются заданием всегда истинного условия, что аналогично архитектуре ARM. Условные переходы в BAL, как уже отмечалось, имеют уникальный синтаксис. Рассмотрим, например, инструкцию
BT 9,address, которая означает сделать переход, если условия 0 и 3 выполнились, но условия после разных команд означают разные вещи. Например, после знакового сложения эти условия означают «результат равен 0 или произошло переполнение», а после беззнакового – «результат 0 и переноса не было или результат не 0 и перенос был». Несмотря на громоздкость и некоторую избыточность нельзя не признать, что такая система работы с условиями для переходов наверное самая гибкая из всех известных. Девятка в команде из примера используется в двоичном представлении 1001, т. е. задаёт номера бит – сама система кодировать все комбинации условий 4 битами используется и в ARM. Помимо переходов по условию в BAL есть ещё переходы по счетчику с декрементом, примерно такие же как в ассеблерах Z80, x86, 68k, PDP-11,… Но BAL ещё имеет две совершенно уникальные инструкции для переходов, которые в зависимости от номера одного из регистров-операндов могут быть трех- или четырехадресными! В этих уникальных командах два регистра скаладываются и полученная сумма сравнивается с содержимым другого регистра и по результатам этого сравнения определяется делать переход или нет. Считается, что такие необычные инструкции удобны для работы с таблицами переходов.Как уже отмечалось, вызов подпрограмм в BAL реализован без использования стека, через простое сохранение адреса возврата в регистре. Однако, инструкции BAL для таких вызовов, одна из которых также называется BAL, сохраняют не только адрес возврата, но и часть регистра статуса, в частности, флаги условий, длину текущей инструкции и даже маску для опциональных исключительных ситуаций, например, для целочисленного или десятичного переполнения, – об этом уже упоминалось выше. Такое необычное расширенное сохранение информации связано с тем, что счётчик команд в архитектуре мейнфреймов – это старшая часть машинного слова статуса и инструкции вызова подпрограмм механически сохраняют его старшую часть. Специальных команд для возврата из подпрограмм нет, нужно использовать обычный переход по адресу в регистре. В системах 390 в связи с переходом на 31-разрядную архитектуру появились новые команды для вызова и даже возврата из подпрограмм. Новые инструкции позволяют гибко использовать в одной программе коды, исполняющиеся в разных режимах.
Для быстрого вызова однокомандных подпрограмм в BAL есть уникальная инструкция EX, которая выполняет инструкцию по заданному адресу и переходит к следующей команде. Инструкция EX может модифицировать вызываемую инструкцию, что позволяет использовать в вызываемой инструкции любой нужный регистр или задавать параметры при массовой пересылке байт. Подобная инструкция, но более простая есть ещё в системе команд TMS9900.
Изначально в BAL не было относительных, перемещаемых переходов, таких как есть в Z80 или x86. Их добавили только в системы 390.
Несколько необычны ещё команды SPM, TM, TS, STCK и STPT. Первая из них позволяет одной командой установить все флаги операций и маску опциональных исключений. Команда TM позволяет проверить группу бит и определить три случая: все нули, все единицы, смесь из нулей и единиц. Такую проверку одной командой в других архитектурах не сделать. Однако, TM работает только с отдельными байтами в памяти. TS используется при работе с несколькими процессорами – похожая команда есть для 68k. Инструкция STCK считывает значение внешнего (!) таймера, а инструкция STPT значение внутреннего таймера, встроенного в процессорную схему. Странно, но команда STPT привилегированная, а STCK нет.
Стоит ещё упомянуть инструкции CS и CDS, которые предназначены для поддержки мультипроцессорной работы. Они реализованы для систем 370, т. е. доступны с начала 70-х. В x86 аналог CS, инструкция CMPXCHG, была реализована не ранее 1987, а аналог CDS, инструкция CMPXCHG8B, – только в 1994!
С систем 370 вводится команда самоидентификации системы STIDP, она привилегированная и не слишком информативная. Для x86 подобная команда сделана существенно мощнее. Тут можно ещё заметить, что IBM 4361 в LCM позволяет исполнить STIDP любому пользователю. Это очевидно эмуляция, срабатывающая по исключению.
Четыре адресных режима BAL задают два операнда для инструкции, пятый режим задает трехадресные команды. Однако, игнорирование части информации позволяет иметь одноадресные команды, а использование неявной информации – четырехадресные. При использовании в адресации регистр 0 имеет особую роль: он там просто игнорируется – это позволяет не учитывать базу и индекс при расчете адреса. Все инструкции BAL занимают строго 2, 4 или 6 байт. Это похоже на 68000 или PDP-11, но не на x86, VAX или ARM.
В систему 390 добавили ещё несколько режимов адресации, доведя их число до 18. Число инструкций также возросло весьма значительно, среди новых инструкций есть даже поддерживающие работу с Unicode – такого до сих пор нет для x86! Среди новых инструкций систем 390 есть и другие уникальные. В систему Z добавили ещё несколько режимов адресации, а общее число команд для современных Z весьма велико и наверное даже больше числа команд для современных x86-64!
В системах 360, 370 и 390 смещения при обращении к данным в памяти, как и в ARM, 12-разрядное, т. е. не более 4095, что не очень удобно – в больших кодах может возникнуть нехватка регистров для базы. В x86 такое смещение 16-разрядное, что, конечно, гораздо удобнее. Но в систему Z добавили поддержку адресации с 20-разрядным смещением, что, конечно, ещё лучше. Хотя, стоит отметить, что в x86-64 или даже в 68020 смещение может быть 32 битным. Как уже отмечалось, в системах до 390, как и в ARM, не было возможности использовать большие константы при работе с регистрами. Архитектура x86 здесь гораздо гибче. Поэтому при использовании ассемблера с системой 360 или 370 часто приходилось использовать литералы, псевдоконстанты, что несколько медленнее.
По быстродействию системы, совместимые с IBM/360, всегда имели неплохие показатели. Мои эксперименты с 4361-1, в частности, в проекте вычисления числа ? по алгоритму-затвору, показали очень хорошие тайминги. Инструкции 4361-1 работают практически без задержек, как ARM или другие современные процессоры. Однако, из-за несколько неуклюжей системы команд, полученной в наследство из 60-х, в частности, из-за отсутствия деления на 16-разрядный делитель, результат по эффективности электроники процессора оказался на уровне 80186. Это примерно на 80% хуже результата, показанного лучшим тогда компьютером из семейства VAX, модели 785. Однако, мейнфрейм в LCM явно далеко не самый лучший среди мейнфреймов IBM доступных тогда. Здесь ещё уместно заметить, что мейнфреймы использовали каналы, специализированные процессоры, которые делали ввод-вывод очень быстрым, гораздо более быстрым, чем у большинства современных им компьютеров.
Мне студентом случилось поработать с отечественным клоном IBM/370, ЕС-1045, в 1987 через пакетный режим, а в 1989 через диалоговый. Для пакетного режима приходилось готовить перфокарты. В то время уже использовал домашний компьютер и поэтому использование архаичных перфокарт оставило не лучшее впечатление. А вот диалоговый режим был неплох, только часто ломался, при большом числе пользователей. Поэтому некоторые студенты приезжали работать к 4 утра! С тех пор больше с мейнфреймами дела иметь не получалось, только недавно решил через эмуляцию поразбираться с этой веховой для истории компьютеров технологией.
Клонирование IBM 360 было весьма популярно. Клоны делали в Англии, Германии, Японии и другими компаниями в США. В СССР это клонирование приобрело очень драматический оттенок. Ради этого клонирования произошла свёртка почти всех отечественных разработок в области ИТ, некоторые из которых были весьма перспективны. В частности была закрыта тема компьютеров Урал, о которых потом с теплотой отзывался известный компьютерщик Чарльз Симони. Закрыт был также проект БЭСМ-10, хотя машины предшествующего класса БЭСМ-6 были сравнимы с IBM 360 по быстродействию. Также ради этого клонирования сорвали почти заключенный контракт с ICL, возможно с этим контрактом британская индустрия ИТ приобрела бы новую динамику и не пришла бы в упадок. Только суперкомпьютеры Эльбрус, возможно из-за их связи с оборонной промышленностью, уцелели после «вторжения клонов», которое Дейкстра назвал величайшей победой США в холодной войне.
Как вспоминают люди, работавшие с мейнфреймами в СССР, отечественный клоны отличались чрезвычайно низкой надежностью и требовали к себе постоянного внимания со стороны обслуживающего персонала. В то время как оригинальные американские мейнфреймы IBM были одними из самых надежных компьютеров своего времени. В советские клоны закладывали иногда более десятка килограмм драгоценных металлов, золота, платины, палладия и серебра, но это не помогло исправить ситуацию с надежностью. Из-за такого большого количества высоколиквидных ценностей трудно представить, что работающий отечественный клон мог где-нибудь сохраниться.
Интересно, что главный разработчик IBM 360 ушел из IBM и основал фирму Amdahl, которая более двух десятков лет специализировалась на производстве систем, совместимых с мейнфреймами IBM и при этом несколько их превосходящих по быстродействию и надежности при более низких ценах. В итоге из-за больших перемен на рынке мейнфреймов, Amdahl, как и ICL, стали частью японской корпорации Fujitsu.
Как уже писал, мне удалось настроить рабочую конфигурацию для VM/CMS 6. Однако, обнаружилось, что редактора XEDIT в свободном доступе нет, а простой EDIT слишком своеобразен и неудобен, поэтому редактировать тексты приходится в хосте. Также обнаружилось недоступность штатной программы для переноса файлов с эмулятора терминала на мейнфрейм и обратно, что потребовало использования виртуальных перфокарт для такого переноса. Другая неприятная неожиданность обнаружилась в связи с отладкой. Команда DEBUG не поддерживает пошагового исполнения! В то время как такая возможность была даже для отладчика DDT для процессора 8080. Также удивительно, хотя и менее критично, что DEBUG не умеет делать дизассемблирование, которое часто встраивалось даже в простейшие мониторы процессоров 70-х. Под CMS на низком уровне не поддерживается перенос длинных строк и управляющий символ конца строки! Поэтому при печати из программ на ассемблере нужно форматировать строки вручную, чтобы они не пропадали за правым краем экрана, а также заботиться о заполнении финишными пробелами последней строки. Также необычно отсутствие автоматического вертикального скроллинга.
Тем, кто захочет поработать с мейнфреймами впервые, стоит иметь в виду, что мейнфреймы – это огромная экосистема, где многие привычные понятия могут иметь другую трактовку. Например, простого понятия файл там нет. Одним из ключевых атрибутов файла является размер записи, ничего подобного для файлов Linux или Microsoft Windows нет. Сами файлы различаются по методам доступа к ним и об этом писались и возможно пишутся нетонкие книги. Также необычно, что в CMS имя диска пишется в конце полного имени файла, а разделяются имя, расширение и диск пробелами, причем само имя диска называется почему-то режимом файла. Хотелось бы ещё поразбираться с многозадачной MVS, насколько знаю в СССР до неё так и не дошли.
Вообще несколько неожиданно, что некоторые известные операционные системы, которые использовались на весьма дорогих компьютерах, не поддерживали работу с каталогами файлов, что равняло их с самыми первыми и примитивными ОС для микрокомпьютеров, например, CP/M или Commodore DOS. Не случайно поэтому CMS иногда называли CP/M для мейнфреймов. Удивительно, но насколько мне известно, поддержку для каталогов в CMS так и не ввели, хотя последний выпуск системы датируется 2018. Почему-то работа с каталогами для дорогих компьютеров до 80-х поддерживалась часто плохо. Например, такой поддержки не было в DEC RT-11 и даже одна из лучших ОС для PDP-11, RSX-11, поддерживала только двухуровневые каталоги. В самой популярной IBM ОС до 2000-х была MVS (1974) и даже тут каталоги были сделаны только частично, как и в Apple MFS (1984). Хотя в Unix (1973), MS-DOS (с 1983) или даже 8-битной Apple ProDOS (1983) с этим всё было в порядке с самого начала. Самая продвинутая работа с файлами предлагалась в VAX/VMS (1977), где помимо каталогов есть даже встроенная поддержка версионирования файлов.
Интересно, что язык сценариев для CMS, MVS и некоторых других IBM ОС, REXX, в сокращенном варианте стал языком командных файлов для Commodore Amiga.
Программы для мейнфреймов, как правило, двухцветные. Терминалы, поддерживающие цвет, использовались сравнительно редко и поэтому цветных программ мало. Также мало программ с динамической графикой, частое обновление экрана приводит к заметному неприятному мерцанию.
Динамическая демка, запущена на эмуляторе IBM 4381 в LCM, терминал 3270-3В заключении не могу удержаться, чтобы не выразить восхищение технологиями IBM. Они всегда отличались неповторимым своеобразием и высоким уровнем. Особенно хочу отметить очень хорошее качество документации, которая и даже по современным системам есть в открытом доступе. IBM демонстрирует колоссальный динамизм развития технологий и это при том, что это одна из крупнейших компаний в мире. По числу наемных работников она почти равна Microsoft, Google и Intel взятым вместе!
Тема мейнфреймов огромна. Конечно, смог написать только небольшую часть того, что она может вместить. Буду очень признателен за уточнения и дополнительную информацию.
Этот материал доступен и на английском.
Allister2
Хочу только напомнить, что клонировали не только IBM — поэтому нужно сказать, что не «ради этого», а вообще ради клонирования, ибо не понятно, кто бы писал софт на весь наш зоопарк.
Что касается уровня софта, то на той же БЭСМ-6 понятие «файл» в операционных системах появилось только в 80е годы.
Сейчас всплыло достаточно много софта для БЭСМ — можно посмотреть на него и сравнить уровень с IBM. Чтобы больше не писать про то, что какой-то там Урал всех бы «порвал», а непонятно откуда взявшиеся программисты все бы написали.
litwr2 Автор
3десь довольно ярко описан драматизм перехода на глобальное клонирование. Трудно, конечно, просчитать, что было бы, если бы дела пошли по другому сценарию. Но могу предположить, что честное сотрудничество с ICL могло бы оказаться предпочтительнее. Уралы также вполне могли получится, мотоциклы вроде получились. :) БЭСМ-6 эксплуатировали до конца СССР, паскаль там вроде был… С клонированием пришло какое-то скорее скорее упадническое программирование, копи-пасты и подгонка под кодировки. Для Apple II сделали много софта из ничего, включая революционный VisiCalc. Oracle начинался со скромненькой PDP-11, а не дорогих мейнфреймов или ваксов…
Allister2
А толку то? Никто платить ICL валютой за каждый выпущенный компьютер не собирался, речь шла исключительно о том, что выбрали ГДР, где склонировали IBM 360 вместо Англии.
В обоих вариантах подразумевалось сворачивание всех советских несовместимых компьютеров и воровство софт.
Мотоциклы десятилетиями производили без всяких изменений, а кто писал бы софт для Уралов? В одной IBM программистов было больше, чем во всем СССР.
Без изменений с 1966 года! А с софтом там было достаточно грустно — тот же компилятор Паскаля — переделка с версии для CDC.
Именно поэтому клонировали и Apple II :)
Поэтому склонировали и PDP-11 и Писюк — чтобы запускать Oracle и остальной софт :)
Вы же сами сейчас не сидите за компьютером с ни с чем не совместимой архитектурой. А других предлагаете заставить — советские люди ведь тоже не идиоты были ;)
litwr2 Автор
Англичане могли бы помочь производство наладить, где бы и без тон драгметаллов все бы нормально работало. В самом массовом реактивном самолете МиГ-15 стояли лицензионные английские моторы и никто англичанам за каждый мотор не платил. Тут можно и итальянцев вспомнить с Жигулями.
В мире постоянно возникали новые архитектуры (PDP-11, CP/M, VAX, ...) и софт там как-то нормально писался, без прямого копи-паста с мейнфреймов.
Неплохой был значит комп, что с ним работали нормально, имея множество клонов рядом. Сам помню, студенты с кафедры СП говорили, что старенькая БЭСМ почти любой другой компьютер может обогнать на расчетах.
Историю всего лишь обсуждаем, а политика была в 60-е, заставили юзать ИБМ, получилось не очень.
Allister2
Это означает — целиком построить нам электронную промышленность??
Заставить армянский завод соблюдать качество? ;)))
Ну и клепали бы их, как Жигули — без особых изменений. Как БЭСМ-6.
Толку то?
В мире было программистов сильно больше, чем в СССР. У нас же каждый завод писал себе свой софт для бухгалтерии, людей не хватало ни на что.
Ну и стимула не было — программисты ведь не за участие в дележке прибыли работали, а за фиксированную зарплату.
Причем в СССР были свои операционные системы (ни с чем не совместимые), много ли Вы таких помните? И почему, как Вы думаете, они не получили популярности? :)
litwr2 Автор
У меня Линус, а его можно даже на особо умный тостер поставить, совместимый только с другим тостером. :)
Почему же всю — несколько образцовых заводов, чтобы было на что народу равняться, а так равнялись на Ереван. :) МиГ-15 был одним из лучших самолетов своего времени, хотя там тоже не обошлось без армянского фактора. :)
Жигули модернизировали и даже экспорт в Европу и ещё куда-то наладили. БЭСМ-6 не дали модернизировать…
Не так уж всё и плохо было. Обыграла Каиса же американцев в 1970. И программисты вместо того чтобы тупить копи-паст с мейнфреймов, могли бы делать свои разработки. Потом были ещё венгры, поляки, румыны,… Англичане в сарае АРМ сделали и софт к нему неплохой и сравните масштабы возможностей Acorn и всей централизованной экономики СССР. А в дележе были всегда очень немногие, большинство программистов в мире были обычные наёмные работники.
Придавили их мейнфреймами и глобальным политическим решением «копипастить!» :) Для своих систем нужно было свое железо.
Allister2
Поставить его можно только если портировать, а потом поддерживать архитектуру в новых версиях ядра.
Не удивительно, что linux уже лишился поддержки многих архитектур.
Советские разработчики просто взяли AT&T Unix и запустили его на западных же архитектурах, а на БЭСМ-6 ее уже портировать не смогли :)
Причем даже сишный компилятор для БЭСМ делали не с нуля, а переделывали буржуйский Portable C Compiler (при этом им занимался один (!) человек).
СССР вовсю закупал западное оборудование для производства электроники, просто на выходе получался низкий уровень выхода годных и постоянное устаревание. Нельзя 10 лет штамповать одно и тоже, электроника — это не Жигули.
Это военка же.
Кстати у военных с компьютерами тоже было очень специфично — писали практически всегда на ассемблере, куча несовместимых архитектур, софта по которые — кот наплакал.
Жигули поставляли по принципу «ножницы» — дешево за границу, дорого дома.
Т.е. за счет советского народа. Чем советский народ так провинился, чтобы еще и экспорт ЭВМ оплачивать? :)
А на смену БЭСМ-6 пришел Эльбрус, но он был уже сильно так себе и стоил как чугунный мост (и производство и обслуживание).
C софтом там тоже было грустновато.
А Вы знаете, что стало с Каиссой? Бросили ее нафиг, потому что не было ресурсов поддерживать.
А соперничала она со студенческими (!) проектами Duchess и Chess.
Студенты в свободное время развлекались, а нам важно было показать, какие мы крутые ;)
Вы знаете, кстати, как делали FORTRAN для БЭСМ-6? Взяли версию для CDC и творчески портировали :) Т.е. пытались копи-пастить и раньше, но ведь не только с мейнфреймов копировали, но и с микрокомпьютеров.
Как сейчас — взяли Linux и назвали его российской OS :)
А они еще сильнее хотели западный софт, там клоны были вовсю.
Им даже запрещали свое творить, пытались в советские проекты втянуть, но они так же драли PDP-11 (сами, без помощи СССР) и т.д.
А восточные немцы нам проект ЕС и впарили, кстати :)
Ни в каком не в сарае, а в компании Acorn, ее основатели к тому времени были миллионерами. Производством занималась VLSI, а используемые ей технологии были сильно круче, чем все, что было в СССР.
Причем софт то был сразу — компьютеры на ARM были совместимы с BBC Micro — стандартным школьным компьютером от Acorn.
Но те, кто писал революционный софт и создавал свои компании — разбогатели. Это великий стимул!
Даже на Эльбрус портировали ДЕМОС, чтобы гонять западный софт для UNIX.
Не работает Ваша теория на практике ;)
litwr2 Автор
Могу предположить, что Юникс не пошел из-за маленького размера адресуемой памяти. Но такие размеры для системы 60-х были вполне нормальны, для запуска Юникс требовалась модернизация, БЭСМ-10, но этого не случилось.
ICL предлагала сотрудничество и готовый продукт, под который было не мало софта. С ними могли бы налаживать и модернизацию. Конечно, это всё фантастика, но не невозможная. Британцам катастрофически не хватало рынков, американцы теснили их отовсюду.
Дешево — это было за валюту, а на честный рублевый эквивалент скорее нет. Эльбрус — это не смена БЭСМ-6, а очень дорогая разработка для военных. У гражданских не хватило бы денег даже на поддержание температурного режима. :)
В том то и дело, что все ресурсы ушли в мейнфреймы. Может там и были студенты, но лучшего тогда у американцев не было.
Все понемножку копипастят. В том-то и дело, что была бы БЭСМ-10, Уралы или ICL туда бы накопипастили, но это было бы развитие, а не то что получилось. Кстати, Каисса была именно на ICL.
Наверное заведующие соответствующим отделом в ЦК имел соответствующие установки. :)
Вот материал — ищем там слово сарай (a barn). :) VLSI имела тогда довольно посредственные технологии, сильно уступающие Motorola, Intel или DEC. Хотя это было и покруче среднего по СССР. О том и речь, что можно было покупать зарубежные технологии и специалистов как делали в 30-е.
Это скорее единичные легенды. Программисты горели, а деньги делали маркетологи.
А почему бы и не портировать? И чем плох этот софт? На современных МСЦТ тоже Линукс (правда уж очень несвежий). Какая теория? Похоже, что Вы, извините, что-то нафантазировали, чего нет.
Allister2
Был Эльбрус-1К2, с режимом совместимости с БЭСМ-6.
Ничем особенным не выделялась, на мировом фоне — морально устаревший компьютер.
Так в ГДР уже сделали клон IBM/360!
Пржиалковский. По IBM-360 имеем систему из 6 тыс. микрокоманд, 90% схем ТЭЗов, 70% растрассировано, 7000 единиц конструкторской документации. При переориентировке на ICL придется переработать весь этот задел, это задержит работы на 1-1,5 года. Понадобится много валюты (для закупки ЭВМ фирмы ICL). Вариант сотрудничества с ГДР, успешно ведущей работу по IBM-360, предпочтительнее. Если усилить коллектив математиков, то ДОС можно разработать к 1971 г. Пора прекратить колебания.
О чем я и говорю — в соцлагере уже был проект по IBM/360, его можно было запустить, не тратя валюту.
Что Вы предлагаете — не понятно. Ну купили бы клонов IBM у ICL, потратили бы 5 лет на «советизацию», ничего бы не поменялось.
Точно так же все советские разработки похоронили бы.
А там Тэтчер зарубила бы проект, ибо отношения с Англией сильно испортились.
БЭСМ тоже была у военных (с некоторой модернизацией), а Эльбрусы стояли у гражданских — в Курчатнике, например.
Просто БЭСМ — это считалка, не бизнес машина (коей была серия IBM/360).
Когда шахматные программы стали индустрией (появились покупатели) — то и софт появился. А когда это была игрушка для студентов — то особо и не нужно никому было.
Еще один пример того, что индустрия всегда побеждает кучку энтузиастов.
Что именно копипастили на Уралы? Под них софта было — кот наплакал.
ICL — это воровство софта под IBM/360, причем, хочу заметить, ICL ведь не выпускали электроннын компоненты, из которых собирали их компьютеры. Чтобы собрать ICL на советской базе — нужно «советизировать» производство, а это годы (как и с IBM/360 вышло).
Под словом «сарай» подразумевается вот это здание:
community.arm.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-21-42/1184.Fig_5F00_ARM_5F00_Headquarters.jpg
Собственно его арендовали, т.к. в Кэмбридже офисы стоило дорого, а этот дом удалось снять дешево. Acorn просто выделели разработчиков CPU в отдельное юр.лицо, причем это случилось уже через 5 лет после запуска первого ARM, который разработали в офисе Acorn.
У них были прекрасные инструменты для разработки, которые использовали в Acorn. Ничего подобного в СССР не было вообще.
Вы помните, какой был голод в СССР в 30е, потому что зерно ушло на продажу? Советский народ должен был еще и поумирать массово, чтобы менеджеры ICL бонусы годовые получили?
Это тысячи человек! А в СССР что грозило программисту? Премия в 100 рублей?
Т.е. украсть? Украсть всегда дешевле, чем разрабатывать самому.
А это прямой путь к загибанию всяких советских архитектур.
Ну и кому он нужен? Он никому не нужен. И Вам даже не нужен.
Эльбрус — это продукт, который никто не хочет покупать, его можно только заставить брать насильно.
Вы утверждали, что советские программисты обязательно написали бы кучу своего софта, если бы у них была собственная аппаратная платформа.
А по факту они даже на свои платформы портировали западный софт, чтобы самим писать поменьше, а софт запускать западный.
litwr2 Автор
Вы писали, что иностранцы строили в СССР заводы для производства электроники. Это где? В Зеленограде неофициальные американцы поработали и там действительно был один из лучших центров разработки электроники СССР. А если бы поработали официально и большим числом, то зеленоградов могло бы быть побольше. И не так уж это было бы и дорого оплатить бонусы нескольким сотням «викингов». Сколько денег в Африку вбухали и прочие странные проекты…
Мейнфреймы — это был самый дорогой проект и поэтому средств на него ушло немерено. Переносить программы с одной архитектуры на другую вещь вполне реальная. При таком переносе и своё бы делать научились. Советизация английских технологий в МиГ-15 прошла более чем успешно, а итальянских в Тольяти относительно успешно. И это было гораздо быстрее, чем если бы воровали по винтику как было с мейнфреймами.
Сотрудничество с ICL давало бы развитию компьютерной электроники совершенно другую динамику. Речь бы шла и о соревновании в том числе, а с мейнфреймами СССР получался в позиции запрограммированного отставания — не зря же Дейкстра свои слова произнес. Специалисты не могли даже консультацию в IBM получить, всё приходилось делать тормознуто и некрасиво.
По Каиссе, как Вы сами отметили, финансирование прекратили — отсюда и результат. И лучшие шахматные программы всегда были скорее научно-исследовательскими проектами, чем просто коммерческими.
Что касается поляков и прочих товарищей, то они советскую электронику в 80-е брали очень хорошо: телевизоры, микроволновки, игровые телеприставки. Известному венгру и Уралы понравились.
Столько было этих Эльбрусов и какова была их цена? Несколько десятков, когда компы уже штамповали деcятками тысяч. Такую моденизацию можно было бы понять в 70-е, в первой половине. И тем не менее эти усовершенствованные БЭСМ-6 были очень неплохи по быстродействию. Если бы потратились не на мейнфреймы, а на БЭСМ-6, то возможно таких компьютеров было бы в сотни раз больше и они были бы намного дешевле. А софт бы появился, накопипастили, сами написали, заказали у румын,…
Вам не кажется смешным, что этот товарищ сравнивает возможности ведущей мировой компании в развитии новой технологии с возможностями через разведку ворующих технологии восточных немцев? И опять приходится Вам повторить, что речь была не о покупке отдельных компьютеров (что и так практиковалось), а о широком сотрудничестве в развитие невоенных технологий.
Конечно, вся эта тема была очень связана с политикой. Повернись дело иначе, имели бы какую-то другую реальность. Американская бизнес-модель — это работает, но именно от американцев и слышал о том, что людей в компьютерных корпорациях иногда заработывали до смерти, давая им немеренные зарплаты и хорошую нагрузку. А кто-то стал миллионером и одновременно пожизненным пациентом у психологов и психиатров.
Не знаю про такое, хотя может какой попроще и стоял. Однако курчатник — это скорее особый случай.
Мало что известно сейчас про Уралы, но если англичане успешно переносили софт на другую архитектуру, что мешало делать подобные вещи и для Уралов?
Это были уже совсем другие времена и другие люди.
Не согласен. Все-таки считается, что иметь удочку для ловли рыбы, предпочтительнее однократной рыбодобычи. Решающее слово тут всегда за политикой, решили «советским мейнфреймам быть», а свои наработки слить. Это просто факт, как-то так получилось.
Используется РЖД, в системе ГАС Выборы и много ещё где. Конечно, трудно выдержать конкуренцию. Тем не менее не могу, не восхищаться, что параметры МЦСТ близки к параметрам лучших современных процессоров.
Повторю, это нормально. Вы сами в этом контексте про ICL упомянули. И в том же ICL копи-паст не мешал делать оригинальные разработки. Уверен, если бы были компьютеры был бы и софт. Не может не поражать, сколько софта сделали для, например, БК. Там и свои оригинальные операционные системы и редакторы и много чего другого. И это при том, что даже дисководы для этого ПК стали внедряться массово только с 90-х. А что касается статьи, то там только известные мне факты — никаких выводов и теорий там нет, там больше про ассемблер. :) Достаточно 12 бит для смещения или нет? Некоторые считают, что достаточно, а некоторым мало.
Allister2
Это, например, завод «Искра», на котором была смонтирована проданная General Instruments фабрика в ~1977 году.
Особенно такое не афишировали.
Еше раз, АвтоВАЗ заработал через 4 года после подписания контракта.
Учитывая, что мы воровали документацию прямо из IBM, то особых то проблем не было. Так что 5 лет — это нормальная задержка, даже если все официально.
Зато весь софт был бесплатный. А ICL пришлось бы платить за него, как и за саппорт.
Какие еще телевизионный приставки? В 80е в Польше и прочих странах был огромный рынок домашних компьютеров, например считается, что наш Спектрум — был создан уже на основе польских работ по его реверс-инжинирингу.
За 20 лет было произведено всего несколько сотен БЭСМ-6, никакого особо преимущества ни в архитектуре, ни в чем-либо еще в 70е годы у нее не было.
Румыны в начале 80х уже были в заднице — из-за огромных кредитов, которые они взяли на Западе, пришлось уйти в нищету — горячую воду включали на несколько часов 1 день в неделю, электричество было лимитировано — разрешалось одновременно включать только 1 маломощную электрическую лампочку.
И эти люди должны были показать чудеса программирования??
Там дети голодные, натурально, побирались на улицах. Пообщайтесь с теми, кто прожил 80е.
Ну и примеры по софта — возьмем, к примеру, базы данных. На ЕС сразу появился ADABAS. А наши аналоги 10 лет писали, пока не довели до какого-то более-менее внятного состояния.
И так во всем.
Восточные немцы на Роботроне были самыми крутыми копировщикам в соцлагере. Они даже 80286 смогли скопировать, а вот СССР уже не смог.
Они нам готовы были помогать, в обмен на нашу нефть и газ.
Остается только удивляться, почему в СССР так не долго жили по сравнению с США, раз в США до смерти зарабатывали…
Ну и если есть такие заболевшие миллиардеры — примеры приведете?
Да не только в Курсатнике, а Сарове был — атомные реакторы на нем считали, еще где-то…
Да достаточно известно — и воспоминаний куча. В Англии программистов было тупо больше. В 1969 году в СССР было 1500 программистов. Вот от этой цифры и пляшите (это официальные данные).
Этот факт хорошо понимал академик А. А. Дородницын, возглавлявший комиссию АН СССР и ГКНТ по вычислительной технике.
В январе 1969 г. он выступил с докладом на коллегии ГКНТ «О состоянии математического обеспечения ЭВМ и мерах по его коренному улучшению», в котором объективно отражено состояние с МО в СССР и предложены меры по его существенному развитию. Докладчик оценил отставание от США в области математического обеспечения минимум в девять лет. Он назвал число программистов в СССР – 1500, 660 из них трудились в 18 союзных и республиканских ВЦ, институтах – разработчиках ЭВМ, институтах АН СССР и университетах, т.е. в основных организациях, занятых программированием и созданием средств его автоматизации. Численность программистов только в двух организациях – Институте кибернетики АН УССР и СКБ Минского завода им. Г. К. Орджоникидзе – составляла более 100 человек, а в остальных 16 организациях не превышала 40 человек в каждом. В то же время численность программистов в США оценивалась в 50 000 человек.
1500 против 50 тысяч. Даже не смешно.
Что слить то? В СССР на тот момент не выпускались жесткие диски, вообще с любыми накопителями проблемы. Вот Вы про БЭСМ-6 пишите — а ведь она вообще не была предназначена для работы с текстовой информацией, процессор непосредственно управлял переферией. Архитектурно это был устаревший компьютер, не случайно Эльбрусы начали делать заново, по сути (поэтому делали очень долго, с задержками по вводу в эксплуатацию в несколько лет).
Не используется, они так и не купили.
Вы тоже не купили и не купите никогда.
Все линейки ICL в итоге загнулись, а ведь у них был доступ ко всей западной индустрии микроэлектроники.
И СССР был под КОКОМ, и 32 битные компьютеры нам было запрещено поставлять. В любой момент любое сотрудничество с ICL могло было быть свернуто.
БК, если что, это архитектура PDP-11, максимальное удешевленный представитель семейства, которое в СССР было крайне популярно как раз за счет доступа к западному софту.
А написали для под него кучу всякого весьма убогого софта, причем немалую часть — уже в годы заката СССР.
Т.е. я никогда не мечтал иметь дома БК, а вот Yamaha MSX — мечтал, т.к. там было всё что хочешь и красиво.
litwr2 Автор
Теперь понятно, почему в СССР в 80-е делали неплохие калькуляторы! А если бы ICL пару заводов построили, то возможно и компьютеры были бы гораздо лучше.
Нефтью и газом, а взамен имели мы нормальные компы, а не ерудну, которая почти не работала и стоила немерeно. А софт он бы и сам стал образовываться. Нашим программисты ездили бы по обмену опытом и много было альтернатив вместо «за всё платить».
Были в Польше Спектрумы, Атари и прочие 8-битки, но рынок был ненасыщен. Там даже закон был, запрещающий вывоз любых компьютеров. Поэтому, повторю, советское железо шло очень хорошо, можно было состояние сделать на телевизорах, но таможня была серьёзная преграда. Рассказывали, как полякам приходилось иногда бить телевизоры на границе в 80-е — рискованный был бизнес. В Венгрии было похоже, но с техникой там было в целом получше.
Наверное БЭСМ был неудачный пример, им в штатах соответствовали CDC. Может таких и не нужно было слишком много. Как считалка БЭСМ-6 была очень даже достойной машинкой на конец 60-х. Румыния непростая страна, не случайно сам Марвин Минский пусть и в фантастическом произведении изобретение ИИ поместил туда.
Ну-ну, трабанты — самы немцы над ними смеялись. И что толку от их роботронов? Все было дорого и тормознуто, хотя и в приятном качественном немецком исполнении.
А вот если бы этот академик проверил ещё число компьютеров в США, то с удивлением бы обнаружил, что число программистов и число компьютеров связаны. И если бы в СССР сделали больше компьютеров, то больше стало бы и программистов, но академики, вхожие в политику, иногда забывают даже таблицу умножения. Последний раз повторю Вам, как только появлялась новая архитектура, так сразу там и появлялся софт. Под примитивный CP/M сделали и базы данных и кучу компиляторов и прочее всякое. Аналогично и для весьма примитивного аппаратно Apple II. А сколько софта сделали для казалось бы изолированных архитектур типа Амиги? И сейчас постоянно появляются «умные тостеры», новые планшеты и прочее — набирают больше программистов и копи-пастом, переделками и новыми разработками всё это двигают.
Под БК отдельными энтузиастами сделаны очень даже интересные ОС и это для дешевенького компьютера, которого продали наверное не более 50000 экземпляров. И редакторы там были нормальные, и ассемблеры-дизассемблеры и много чего ещё. Кстати фирменные компиляторы, как кросс-платформенные средства, с БК стали пробовать использовать только с развитием интернета, где уже после 2005. Поэтому мне очевидно, что для массового компьютера с хорошей поддержкой, проблемы с софтом быть не должно. Китайцы столько всего делают и у них не Андроид и не iOS. Хотя там у них целые юридические конторы спкциализируются на защите копи-пастеров. :)
И не понимаю, что вы так не по доброму к МСЦТ относитесь. Все же какой-то вклад в общемировую копилку технологий и это при таких серьёзных конкурентах.
Allister2
Ну во-первых калькуляторы у нас были очень так себе. Всякие программируемые Б3-21 и Б3-34, на которых прошла моя юность — это медленно и неудобно.
Во вторых, ICL должна была эти заводы модернизировать каждый год. А в 80е уже начались перебои с валютой.
Да никуда они бы не ездили! На Запад ездили особо приближенные, кто бы пустил советских граждан за рубеж просто так? Насмотревшись (а я помню шок, когда впервые попал в капстрану) — наши программисты вторую поездку совмещали бы с последней выездной :) И так куча народу утекла, как железных занавес упал. Почти весь коллетив, который разрабатывал ДЕМОС — уехал.
Это был достаточно короткий период, вызванный перекосом в валютном курсе злотого к рублю. Все очень быстро прикрыли, потому что получалось, что советский народ спонсирует покупку поляками телевизоров.
Как с жигулями — чтобы француз купил себе ниву за копейки, русский должен был копить на нее 10 лет.
В Польше с «массовой» компьютеризацией было сильно лучше, чем в СССР и компьютеры оттуда везли, я лично знаю владельцев Правецов.
Румыния еще в конце 60х начала закупать лицензии на производство западных компьютеров, купили у французов, к примеру, лицензию на Iris, вообще не совместимые с IBM.
Чего бы им писать нам что-то под ICL?
У них был свой экспорт даже, в Китай, с которым у нас все было плохо.
Было у них с CDC совместное предприятие, от сотрудничества по ЕС ЭВМ они отказались совсем (!). Потому что у них не было ничего IBM/360 совместимого и уже были хорошие отношения с CDC.
Вот в PDP-11 они были заинтересованы, но это все были такие, весь восточный блок сходил по PDP с ума :)
IBM совместимые персоналки, включая 80286.
Качественные плоттеры, принтеры.
На фоне западных немцев — убого, конечно.
По компьютерам разница на порядок была (в США их тупо больше >10 раз в год производили). Не могла наша промышленность их больше выдавать.
Собственно к 80м годам ситуация не особо улучшилась.
Не правда. Была куча архитектур, которые померли как раз без софта.
Вам напомнить, как страдали советские владельцы всяких несовместимых друг с другом РК-86 клонов?
Напомню только, что там стоял процессор, совместимый с сотнями тысяч других компьютеров в СССР. Всего изготовили, думаю тысяч 150-160, лень искать точные цифры.
Там на урезанном варианте RT-11 можно было пускать софт с компьютеров побольше. Еще раз — БК была частью огромного семейства, самых, наверное, распространенных компьютеров в СССР и мире.
Это не советская платформа, это PDP-11. Софт для БК можно было на ДВК разрабатывать.
Android у них вовсю, если что.
Какой вклад? Они даже в ядро Линукс не шлют патчи.
litwr2 Автор
Надо наверное заканчивать эту болтовню, поскольку если привязывать прошлое к настоящему, как это у Вас хорошо получается, то, конечно, надо поправить Дейкстру и сказать, что это была победа СССР, «воровством» американцев взяли и победили! :)
Странно, конечно, что было мало примеров сотрудничества СССР с другими странами. Примеры Жигулей и ещё несколько других выглядят как что-то исключительное. И в этой связи, история с мейнфреймами, когда пошли по пути отказа от нормальной работы, оказывается вполне себе в русле истории тех лет. Тут надо политологам статьи писать, а не компьютерным специалистам.
Поправлю только некоторые мелочи. Советская электроника шла в Польше очень хорошо и могу ручаться в этом за 1984-89 годы. И советские везли и поляки — всем было выгодно.
А молодцы румыны, поняли, что дело с мейнфреймами на советской почве тухлое. :)
Да, вот с PDP-11 и надо было начинать, хотя как и написал в статье, подозреваю, что они почти зарезали PDP-11 к 1980 не без влияния его успешного копирования в СССР.
Ну и пример у вас, Радио-РК! А много софта было на KIM-1, SYM-1,…? Это же радиолюбительские компьютеры. А возьмите хотя бы английские Драконы, которых сделали всего десятки тысяч — и вполне нормальный там софт. Может это даже закон такой, что если компьютеров введено в эксплуатацию в числе, большем 50000, то софт начинает образовываться сам. :) Типа дополнения к закону Мура.
У БК был процессор как у дешевеньких PDP-11, но софт там никакого отношения к DEC не имел. RT-11 перенесли только для БК11, которую только барыги с рук ворованными тушками продавали. И почти все бэкашники про RT-11 почти ничего не знали и не знают, только в этом году один энтузиаст взялся написать там демку. Там больше копировали софт со спектрума и писишек. Ассемблер PDP-11 хорош тем, что на него хорошо другие ассемблеры ложатся. Только тормозной был БК, хотя и побыстрее Корвета или даже дорогого Коммодора 128 под CP/M.
У МСЦТ интересная архитектура, они её вроде до сих пор держат почти в секрете.
Allister2
VAX'ы у нас тоже копировали, более того, PDP-11 доставались организациям попороще, а наш VAX клон — организациям покруче. А особые небожители получали оригинальные ваксы!
Ну и какой софт из тех времен сохранился в развитии до наших дней? :)
На CP/M на ямахах работала и Dbase и Turbo Pascal и LISP с Прологом и компилятор с Си был и черти что (потому как была CP/M с тысячами программ).
А на БК все было какое-то простое и примитивное.
RT-11 мне там показывали и демонстрировали, как работали какие-то компиляторы с нормальных ДВК. Давно это было, но это было демонстрацией «вменяемости» машинки — видимо это была уже 11М, не помню.
Правда совершенно все умерло вместе с ней.
Это Вы десятилетия перепутали :) 70е с восьмидесятыми.
На клонах РК, кстати, вовсю использовался тыренный бейсик от Microsoft.
Я даже про такие не знал — посмотрел, с софтом все было весело. Первый был частично совместим с TRS-80 (по бейсику вообще целиком).
Посмотрел операционки — софт появился, потому что там был стандартный процессор от Мотороллы.
Скажите, Вы процессор от одного из лидеров рынка называется какой-то «особенной» платформой? :)
А вот Уралы — они были совсем, целиком и полностью несовместимы.
Это как Эльбрус — не было других компьютеров с такой же системой команд.
Т.е. в Драконе должна была быть не моторолла, под которую были операционки и нужно было просто доработать поддержку ROM/BIOS…
Собственно возьмите любой пример умершей компьютерной платформы, для которой не появилось достаточно софта — например Sinclair QL и убедитесь, что Ваша гипотеза о «саморождении» софта — просто не работает.
PS. Кстати, БК был тормознее компьютеров на z80. Особенно если на них стоял графический сопроцессор.
litwr2 Автор
На БК весь софт и сохранился. Операционки используют все только наши. Все свое оригинальное, доморощенное, можно даже сказать «колхозное», но работает отлично. Другое дело, что компьютер такого класса можно было нормально эксплуатировить не далее конца 90-х. RT-11, повторю, на БК0011 никогда нормально не работала. К сожалению, других оригинальных компьютеров для масс не сделали. Можно, конечно, ещё упомянуть игровой Вектор, где некоторые игры сделаны вполне на мировом уровне. Для Корвета мой знакомый сделал компилятор Турбо-паскаля 4! Фирменный был только для Z80 и для 8-биток только до версии 3. И игры на Корвете некоторые не хуже, чем фирменные, хотя часто и скопированы с них. Но Корвет в массы не пошел, не дали.
История с мейнфреймами как-то повторилась на Корветах. Опять «академики» помешали развитию очень интересного проекта. Стали трубить «устарело!» и требовать УКНЦ. Но на доведения УКНЦ до ума требовалось ресурсов почти как и на мейнфреймы и в итоге сгинул этот УКНЦ практически без следа, не попав ни в одну школу, институт или на производство. Но люди вокруг этой аферы неплохо заработали, до сих пор ещё что-то пилят. :) А Корвет был ничуть не хуже Apple II или BBC Micro, которые успешно в школах самых развитых стран простояли до конца 90-х. Между прочим, если верить википедии, то УКНЦ это самая массовая модель архитектуры PDP-11 в мире. :)
Кимы, симы и альтаиры примерно соответствуют классу Радио-РК. На РК и CP/M шел. И тут, конечно, естественный для СССР лаг в 10 лет.
Для QL море программ — даже удивительно, компьютер почти сразу зарезали, но его выпустить успели в немалых количествах, это и объясняет размер софта.
Получается, что работает теория.
Что БК была тормознее большинства систем на Z80 во многом связано с отечественной памятью, производство которой наладили только к 90-м, а до этого она даже на 1 МГц не всегда работала стабильно. На БК память сильный тормоз, но дорогой Коммодор-128 на z80 БК уверенно обгоняет, процентов на 20%. Кстати эти коммодоры ещё и обновили в 1987 и всего наштамповали и продали более 5 миллионов.
А с ваксами анекдоты одни. У нас в отделе стоял один причем настоящий, не клон, лет более 5, чинили его чинили, а потом на свалку. Никто так и не поработал. Прямо как Черненко с водкой. :)
Allister2
Так почему оттуда ничего не портировали на PC? Ведь вообще весь софт сгинул.
Ответ: а потому что на PC уже была куча другого софта, гораздо лучше.
Ну и странно читать про конец 90х — там же даже клавиатуры нормальной не было, как его «экcплуатировать»? Это игрушка, не более.
Еще раз — это продукт линейки PDP-11, он не оригинален в том смысле, что это часть скопированной западной архитектуры.
И чрезвычайно убог по сравнению с тем, что в тот момент делали на Западе.
Вы издеваетесь? :) Судя по гуглу — этот Express Pascal был написан в 1991 году! В 1991 году уже вышел Turbo Pascal для windows. В 1990 году уже был Turbo Pascal 6.0 по DOS, по сравнению с которым этот express pascal смотрится как динозавр из прошлой эпохи. Не удивительно, что никакого продукта из него не получилось.
Ну вот смотрим. Что сделали люди — взяли обычную CP/M, русифицировали, назвали Микродос.
Т.е. типичное советское поведение — запуск западного софта на ворованном железе с руссификацией. Чем это отличается от ЕС?
Скопированные игры — ну сами же подтверждаете мои слова. Если можно скоммуниздить — то будут коммуниздить.
В США поставки Макинтошей в школы начались с конца 80х (как раз одновременно с Корветом).
К моменту, когда Корвет начал проивзодиться — в США уже в 98% школах были компьютеры, которые использовались в учебном процессе. Да, на это ушло 10 лет, ну так а в СССР к этому времени бог, чтобы процентов 10 школ хоть как-то были компьютерезированы.
Это отсталость, многолетняя…
Вот мы и вернулись к тому, что в СССР ничего вовремя запустить не могли. И были вынуждены копировать уже готовое.
en.wikipedia.org/wiki/List_of_Sinclair_QL_software
Вы шутите? :) Это море? :)
Да вся электроника в СССР была такой, ненадежной.
А БК не дорогой? Он стоил 600 рублей. Это 4 зарплаты инженера.
Сравнивать полноценную CP/M машину, с цветной графикой 640x200, с многоканальным звуком, 128 кб памяти с БК, который стоил по факту дороже:
Коммодор — 300 баксов, БК — 600 рублей?
Ничего себе сравненьице получается.
Вообщем мы уже ушли в рассказы, какие были хорошие советские компьютеры, но их никто не ценил :)))))
PS. Я сильно сомневаюсь, что у вас в советские годы стоял оригинальный VAX, таких контор в СССР было совсем несколько. И уж точно это не было во времена Черненко.
litwr2 Автор
А зачем с БК портировать на ИБМ ПК? Ну и логика у Вас! Наоборот портировали. Речь у нас о том, что могли люди с минимумом ресурсов создавать сами софт. Привел вам пример, создавали. Для БК, Корвета, может ещё Вектора.
Конечно, Express Pascal не мог конкурировать с Borland на ИБМ ПК, но на 8-битках под CP/M вполне мог бы быть продаваем за рубежом ещё пару лет. К сожалению, автор его не допилил, не платили. :( Разработка уникальная, Вам бы гордиться, а вы сливаете. :(
БК в школах это намного лучше, чем ничего. Немало современных хороших компьютерщиков именно с БК в школах и начинали знакомиться с компьютерами. И тексты набирать и расчеты делать не слишком масштабные на БК вполне можно и принтер использовать. В Европе Amstrad PCW до конца 90-х очень даже активно использовали. А в многих школах, повторю, стояли Apple II и BBC Micro, думаю и во Франции ещё какие-нибудь Томсоны стояли.
Макинтоши в отдельные школы ставили. США страна сложная и разнообразная. Но мне вот американец рассказывал, что ещё в году 1987 школьников в классы с апплами почти никогда не пускали, типа поломают. На Западном побережье с этим было лучше. И не понял Вашей логики. В СССР медленно шла компьютеризация школ, Корветы могли её ускорить — что не так?
БК если сравнить с западными домашними ПК середины 80-х не так уж и плох. Все же честные 16-бит. Портило сильно отставание по дисководам, но и тут не все просто. В США и Европе для 8-биток все дисководы были очень дороги до середины 80-х. И имели смешные емкости. Для Apple II 140 КБ, для Коммодоров — 170 КБ, для Амстрадов — 180 КБ. А для БК сразу массово пошли с 800 КБ.
Корвет — это не ворованное железо, а вполне оригинальная разработка. Процессор, конечно, стащили, но он уже стал как Шекспир в переводе, скорее советским. В США 8080 в компьютерах практически не использовали. Тут СССР отличился, реально создал что-то оригинальное. Конечно, хуже чем на Z80 или на 8085, но не в разы, на десятки процентов только. Поставили туда вполне нормальный CP/M, добавили несколько оригинальных утилит — всё достойно. Люди могли честно в глаза своим коллегам из США смотреть. Получаем, что по имеющимся примерам, можно было создавать свое, незначительно худшее по совокупности свойств.
А куда было деваться если было принято политическое решение, которое всё затормозило? Мейнфреймы сожрали все ресурсы и пользы от них было мало — чем они помогли в развитие Радио-РК?
Про QL посмотрите, там только баз данных несколько десятков, выбор электронных таблиц (а их так и не сделали для PDP-11), куча трансляторов. И каталог этот далеко не полный, хорошо если только процентов 30% софта покрывает.
Для коммодора нужно ёще покупать дисковод и для использования 80 знаков на экране монитор. Причем дисковод стоил почти как сам компьютер при 170 КБ емкости. 300 долларов в 1985 это все же побольше 600 руб. Цены очень сложно сравнивать из-за большой разницы экономик. Могу только сказать, что Коммодор-128 считался, например, в Англии в 1986 дорогим домашним компьютером. Детям его редко покупали.
Стоял Вакс, в отделе Машинного фонда русского языка, наблюдал его там в 1992-95. Какая-то там деталька постоянно пропадала. :) Этот фонд сам А. Ершов учредил. Втянули его в аферу с УКНЦ… :(
Allister2
Ну так если софт хороший, то нужно портировать? Или он не был хорошим? Вот на IBM PC портировали кучу софта с CP/M, например.
Этого софта было крайне мало и он был весьма незамысловатый. Кроме того, его никто не покупал. Т.е. отсутствовал рынок ПО.
В 1991 году продавать компилятор Pascal для CP/M? Во-первых, это противоречит Вашей идее, что нужно было делать только советские компьютеры (на которых не было бы CP/M), а во вторых — это нужно было делать лет на 6 раньше.
Потому и не платили, т.к. не нужен был продукт уже никому.
Это несоизмеримо лучший компьютер, чем БК. Он его делает по всем параметрам, начиная с комплектации и заканчивая ценой + наличие софта.
В СССР так и не смогли решить, какие же компьютеры ставить в школы. И ставили вообще любые доступные. Они между собой были не совместимы, в результате чего учебный софт писался каждый раз заново.
Корвет ничем не спасал ситуацию, он делал ее еще более запутанной.
А толку то от 16 бит? Адресовать памяти он не мог больше 64к, унылая графика, никакой периферии в продаже.
С какими? Apple II в школы еще с 70х годов шли, там уже не одно поколение прошло через эти компьютеры.
Когда на БК появились первые дисководы — во всем мире с дисководами было уже очень хорошо. А Вы сравниваете 70е годы с концом 80м…
Вовсю использовали! Вам привести примеры? Просто их использовали в 70е годы, когда в СССР ничего не было вообще для дома.
Собственно реально купить компьютер можно было только с 1986 года, и то с трудом. В магазинах ничего не лежало.
Ну и какова была судьба этого оригинального? Смогло оно победить против западных клонов?
Как это мало пользы? Это же не БК, там стояли жесткие диски на мегабайты, куча терминалов, базы данных, нормальные рассчеты и т.д.
Представьте, что наступил какой-нибудь 1980 год, какой компьютер нужно поставить на завод?
Это все какое-то убожество. На ЕС была ADABAS, Вы представляете, насколько это отличается по возможностям от убогих поделок? Даже ничего уровня DBase для QL не появилось.
Были такие для PDP, причем еще и мультиюзеровские. Почему не было то?
Действительно, ведь для БК в 1986 году купить дисковод было невозможно :) Вообще никакой. И 80 символов в строке не было там никогда.
А многим советским детям в 1986 году купили БК-0010 ценой в 4 папиных зарплаты? :)
Это уже не советское время.
litwr2 Автор
Софт для БК как раз и покупали — это и было большой движущей силой для разработчиков.
Фантазируете, где это такое прочитали, что «нужно было делать только советские компьютеры (на которых не было бы CP/M)»?
С Экспресс-Паскалем очень все хорошо бы шло в образовании, и даже в вузах. Корвет хорошо тиражировался и до середины 90-х вполне адекватно смотрелся, а в школах, пусть и не лучших, мог бы быть актуальным и до конца 90-х. Повторю с Экспресс-Паскалем. Этот паскаль можно и на другие маломощные машины было перенести, а не устраивать ерунду с УКНЦ — типа там сразу фирменного софта будет много — всё в точности как с мейнфреймами.
У Амстрада ПСВ была только актуальная программа Locoscript — с ней народ за рубежом в большинстве случаев только и работал. Был ещё CP/M, наверное лучший, но это было второстепенно, для модели PCW16 CP/M вообще стандартно нет, запускается только через трюки. Конечно, PCW хороший комп в своем классе, но с проблемами. Покупать надо было в комплекте со странным принтером, вместо которого или в довесок обычно приходилось покупать другой. Дисковод встроенный у PCW 256 и 512 на только 180К и нестандартного размера. Цветов нет вообще. Если использовать в школах, то надо разбираться с комплектацией, и никаких особых преимуществ в этом случае перед БК нет.
Золотые слова! Вал можно было гнать, а БК и Корветы подходили для этого лучше всего. Агаты получились какие-то дорогие почему-то, но и их можно было делать побольше. Проризводство ДВК можно было делать более дешевым и массовым. И что же Корвет запутывал?
У БК графика не супер, но сверхпопулярного Спектрума существенно хуже, а у Корвета так вообще почти EGA.
Американец рассказывал именно про обычные школьные Apple II где-то на Восточном побережье. И не раз подобные истории слышал — в Америке обычные школы финансируют не слишком богато, и раньше гораздо хуже, чем сейчас.
На коммодорах и апплах люди так и до сих пор ничего кроме этих дисководов на 170 и 140 КБ не имеют или их эмуляторов. А в 90-е эмуляторов не было приходилось покупать «железных монстров» задорого и со смешными техническими характеристиками. Сам видел коммодоры 64 в Берлине 1993-4 — их там раскрасили весело, но железки-то уже были почти «допотопные».
8080 в компьютерах? Типа Altair 8800, где не было даже клавиатуры? Ни одного известного бренда или массового компьютера с 8080 не было, его использовали массово только в контроллерах. Пытались на первый TRS-80 уговорить поставить, но преимущества от z80 перевесили аргументы Intel.
БЭСМ-6 или Эльбрус может никого и не победили, но показали что техника сравнимого с лучшими образцами из США могла быть.
БК вроде как контроллер для станков изначально и делали. :) А какой вы предлагаете выбор?
Это очень голословно. У разработчиков ПО ерунду на продажу предлагать было не принято, как и сейчас. ЕС от QL сильно отличала очень мощная поддержка быстрого ввода-вывода — отсюда возникает естественная разница для возможностей СУБД для этих системами. QL разрабатывался для мелкого бизнеса в первую очередь. И количества софта, которое сделали всего за год не может не поражать.
Вы знаете электронные таблицы для PDP-11? Знаю людей, которые с PDP-11 очень многое связывает, они таких не знают.
У БК и Корвета 64 символа в строке — совсем неплохо. У Спектрума — 32, например. У большинство зарубежных 8-биток — 40.
А Вакс стоял наверное еще с 90-го или даже раньше.
Allister2
Я не помню ничего такого в конце 80х — точнее можно было купить кассеты, но авторы точно ничего не получали.
Вы сами считали IBM/360 злом и что нужно было свои разработки поддержать. А свои разработки были несовместимы ни с чем. CP/M работала, потом что содрали Intel 8080, а не стали делать что-то свое.
the basic PCW model was priced at ?399 plus value added tax,[8] which included a printer, word processor program, the CP/M operating system and associated utilities, and a BASIC interpreter.[7] Software vendors quickly made a wide range of additional applications available, including accounting, spreadsheet and database programs, so that the system was able to support most of the requirements of a home or small business
Т.е. на машинке был изначально софт (включая CP/M — а это автоматически дает тысячи различных программ).
Нормальная такая печатная машина для бедных (всего 400 фунтов), причем за год до начала продаж БК (у которого нет нормальной клавиатуры и никаких дисководов).
Ну Вы вправду считаете, что БК с клавиатурой, на которой невозможно толком печатать — это хорошо?
А про Корвет советская электронная промышленность имела собственное мнение, судя по всему.
Ну Apple II вышла в 70е, к тому времени, как появились БК — ее уже и не выпускали.
Это нужно сравнивать с IIc — там были 800 кб 3.5 диски.
У коомодора с 1987 года — Commodore 1581, тоже 800 килобайт. Что-то Вы путаете.
Все первые популярные компьютеры на нем были — к Altair и IMSAI клавиатура подключалась. Потом уже Zilog подсуетились, конечно. Но CP/M написали не под Zilog.
Только Altair и IMSAI продали тысяч 60-70, видимо, а были еще и другие… TRS-80 же выпустили тогда, когда тысяч 30-40 Альтаиров было продано.
Эльбрус не был сравним с лучшими образцами, вот БЭСМ в 60е была более-менее достойна, но на этом все и закончилось, ибо БЭСМ паяли тетушки вручную, а дальше прогресс уже ушел далеко вперед, за ним СССР не поспевал.
Контроллер, но не более. Зарплату на нем считать… ээ… Вряд ли :)
ЕС-1052, например? :) С кучкой терминалов, конечно. Памяти побольше, мегабайт 8, дисков на несколько десятков мегабайт.
Еще как было принято :) Мало, что ли, ужасного софта в 80х годах было?
Да их много разных, например — PortaCalc.
www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/11s047.html
А вот тут даже образы дисков еще какой-то системы валяются:
avitech.com.au/?page_id=2570 (там целый офисный пакет).
MSX-2, которые везли в СССР — были с 80 символами в строке (это требование стандарта).
Подавляющее большинство машин с CP/M было с поддержкой 80 символов в строке, уже начиная с 70х.
litwr2 Автор
Там целая кооперативная индустрия сложилась, стухла только к концу 90-х.
Опять фантазируете, ничего нигде такого не писал. Это вы скорее так думаете. Содрать можно на любую архитектуру. Кстати, если говорить о мейнфреймах, то в Штатах были не только IBM/360 — там были целые семь гномов и даже Белоснежка. :) И везде был актуальный софт, при том что эти гномы были совершенно несовместимые.
Я Вам и написал Локоскрипт и СР/М. Бейсик (очень кстати хороший, возможно самый быстрый на 8-битках) для СР/М. Кстати, на Амстраде просто так любую программу СР/М не запустишь, там они немного кое-что изменили в системных вызовах, что требовало небольшик, но переделок. Как там и написали, работайте с вашим вендором, несите ему деньги. Принтер, повторю, там был чумной. Что-то типа 20 знаков в минуту и убрать его нельзя, через него шла загрузка. Приходилось покупать второй, если реально надо было печатать. Кто ж, сомневается, что в целом Амстрад посерьезнее, но без звука и цвета. Кстати, знаю человека, который реально предпочел БК Амстраду 6128, хотя сам его не понимаю в этом вопросе. БК и PCW слишком разные классы машин, сравнивать можно именно БК и CPC. А к CPC, например, принтер было проблемно подключить, там почему-то интерфейс урезали до 7-бит — прощай умалауты. Софт игровой на процентов 90 со Спектрума довольно низкокачественный из-за быстрого копи-паст переноса. В целом CPC по очкам у БК выиграет, но не накаутом. А если сравнивать с БК0011 и дисководом, то уже не уверен, но это уже 1990 или даже 91. Хотя в начале 90-х CPC за рубежом ещё понемногу шли.
Не промышленность, а какие-то страсти вокруг нее, которые вместо реального проекта, сделали позорище. Были проблемы с клавиатурой, особенно на первых БК, но к ней быстро привыкали. На Амиге вот тоже был баг, не все тройные нажатия правильно отрабатывались. Вопрос, сделать внемяемые машинки или ничего не делать и жаловаться.
Вы отчасти правы, но эти поздние дисководы получили почему-то очень небольшое распространение. Дистрибутивы почти все шли на старых дискетах. Поэтому требовалось уже покупать два дисковода. Потом С1581 был довольно медленный — это вообще беда всех коммодоров. Основной дисковод 1541 имел скорость 300 байт в секунду, программа 30 КБ грузилась 100 секунд. С1581 при работе с64 или 128 в режиме С64 имел такую же скорость. Были способы разгона до внемяемой скорости, но они требовали аппаратных переделок. Кроме того, на таких довольно больших дискетах уже неудобно без каталогов. И тут вопреки всем Вашим теориям, неожиданно обнаруживаем, что популярные операционки для БК каталоги поддерживают, они даже поддерживают жесткие диски.
согласно oldcomputers.net/altair-8800.html — альтаиров всего несколько тысяч, а IMSAI — 20000 и на последнем использоволи 8085 в поздних вариантах. Это все же были очень специфические компьютеры и даже не совсем компьютеры в сегодняшнем понимании. Их нельзя назвать популярными компьютерами, обычный юзер их использовать не мог. Радио-РК на их фоне выглядит очень даже неплохо, почти как мейнфрейм рядом с БК. :) Настоящие массовые компьютеры начались с троицы TRS-80, Apple II, Commodore PET. Да, а CP/M так и осталась в кодах 8080, кодов для z80 не написали. Запускали и запускают энтузиасты на Альтаирах CP/M, но ценой полного преобразоввания — это демо-сцена, а не нормальная работа. В США было может несколько десятко мелко-тиражных компов. И софт был пропорционален тиражу, что вам и доказываю.
Это почему же? Я с Бабаяном разговаривал. Американцы в 80-е очень были им впечатлены. Потом почти всю команду сманили делать свой Эльбрус, Itanium. Был ещё проект, навеянный Эльбрусом, Transmeta, которому похоже просто не дали стать успешным. Тетушек заменить станками и всего дел. :)
Для небольших предприятий, почему бы нет. Человек до 500 потянет, хотя это уже средний размер.
Почему бы и нет. Только это система 360, такие уже в Штатах шли в металлoлом. И главное, с надежностью беда, в обслуживании дорого,… Предположу, что что-то типа клона PDP-11/70 или какой-нибудь ICL пошло бы лучше, особенно если бы делали по лицензии.
Если получалась ерунда, то это из-за нереальных сроков, которые иногда ставили. С QL очень торопились, Синклер хотел «квантового скачка», обогнал сам себя. :) Софт был поэтому сыроват, но это же при следующих релисах правится, а с QL следующего релиса по большинству программ не получилось. И были там БД класса DBASE.
Уверяю Вас PortaCalc — это единственная, с ней никто не работал. Какой-то энтузиаст на DECOS выложил, похоже перенесено с прoграммируемого калькулятора. Про неё давно знаю, это скорее анекдот, а не таблицы. PD soft.
А почему Вы решили, что Saturn — это пакет с таблицами, там только битые диски? Ни в каких нормальных каталогов софта таблиц для PDP-11 нет. Могу предположить, что что-то теоретически можно перенести на 4.3BSD, но там сегментация гораздо круче той, что на IBM PC и этот перенос c других Юниксов был бы очень непростым делом.
Allister2
Кооперативная индустрия 80х заключалась в продаже софта за безнал. За нал любая перепродажа в 80е (Вы точно про 80е говорите?!) не работала. Не было никаких «авторских» отчислений.
И часть этих гномов умерла как раз из-за отсутствия софта. Вот, к примеру, Вы сможете назвать 4-5 линеек мейнфреймов в начале 70х?
Вы вообще о чем?! Какой бейсик? Точно для CP/M?
Какой-то несвязный текст, уже простите — я не понимаю Ваших логических цепочек :(
Нет, не было там 20 знаков в минуту, вранье. И причем тут БК? Под него никакого принтера не было совсем.
В 1991 году всерьез говорить про PDP-11 уже было нельзя. Это была шутка такая, глупая.
Не была проблема, а клавиатура была убогая абсолютно. Вы сами то какой клавиатурой пользуетесь сейчас? :)
Вы что несете то? Назовите год, когда первый жесткий диск был подключен к БК.
Это сильно в 90е годы, до этого этот жесткий диск раз в 10 больше стоил, чем сама БК.
Кстати, назовите, какой дисковод в 1986 году можно было купить в магазине и подключить к БК.
Жду, с нетерпением.
During the Altair’s brief life, 60,000 units were sold.
www.sancoale.net/the-altair-8800-story-and-its-strategy-lessons
По вашей ссылке нет вообще ничего про общую цифру по продажам.
Радио-РК вообще не продавали! При том, что это было 10 лет спустя. 86 год!
Как можно с Вами дискутировать, если Вы ерунду пишите, полную!!!
Вам напомнить, сколько инсталляций в 70е было у MS BASIC?!
Чем впечатлены? Тем, что он выбил миллиарды на компьютер, которые был на уровне 10 лектнего отставания?
Кто не дал? Это были тормозные компьютеры, полный отстой.
Писать данные по зарплате — на кассеты? А если кассеты зажевало, то все, расстрелять всех?
Если нужно вводить данные по производству в общую базу, то как это делать на 1 компьютере?
На ЕС — стоял отдельнй терминал в соответствующем отделе.
Какие еще терминалы на бК?!
В 1980 году? Вы зачем врете?
ICL — это те же самые IBM/360, т.е. Вы врете мне, по циклу.
PDP-11/70 — это импортный компьютер, Вы мне говорили, что нельзя импортные компьютеры клонировать. Врали опять?!
Кстати, PDP-11/70 — это по сравнию с моим примером — убожество. Для начала скажите, сколько памяти она могу адресовать?!
НАЗВАНИЕ!
Я два названия привел.
Могу еще, если перестанете врать постоянно.
Какого еще калькулятора?! Модель назовете ил опять врете?
PD soft — это что? Это коммерческий продект, если что.
Меня в гугле не забанили.
Есть, я Вам привел примеры как раз из каталогов.
Вы постоянно врете, постоянно!
Не удивительно, что советская комьютерная индустрия сдохла — Вот такие люди как Вы там и рулили. А выхлопе — БК.
При том, что Вы сами не сидите за ЮК, не пользуете его софт и ненавидите Эльбрус (иначе бы купили компьютер на нем).
Вы и есть то самое подтверждение, почему в СССР все было плохо с компьютерами.
litwr2 Автор
Ещё добавлю, что на trs-80, вопреки вашим теориям, CP/M нормально не шел, как и на Спектруме. Предпочитали, что-то новенькое смастерить по-быстрому.
Allister2
Опять врете.
Ну сколько можно то? Есть ведь эмуляторы и trs и zx.
Давайте так — я под ними запускаю софт для CP/M, а Вы мне платите в евро, если я смогу.
И я Вам плачу в евро, если не смогу.
Можно начать с Wordstar.
Согласны? Шаг 100 евро.
litwr2 Автор
Как у вас всё эмоционально…
Вы очень далеки от мира БК, а это реально очень интересный пример. Авторы популярных программ их тиражировали через кооперативы. С некоторыми из этих людей и сейчас реально связаться. К сожалению, некоторые программы так и не вышли с обновлением, из-за общего краха БК бизнеса. Люди надеялись на переход на системы на базе К1801ВМ3, но этого не произошло, пошел вал IBM PC.
У гномов серьёзные проблемы начались в 80-е, когда всё стало быстро меняться в ИТ. 70-е им и белоснежке тяжело пришлось из-за массового внедрения мини-компьютеров. Очень глупо было копировать технику, которая уже была очевидным динозавром на фоне мини. Ваше рассуждение про софт — абсурд какой-то. Проблема была в дороговизне мейнфреймов и появившихся альтернативах. Посмотрите, например, в разделе про 68k моей статьи по ссылке в начале на картинку жонглера для Амиги — она была просчитана на британском компьютере Atlas, тоже не с чем не совместимом. Кстати, некоторые гномы и, конечно, Белоснежка и сегодня крупные компании.
Повторю для PCW весь софт — это CP/M (с хорошим бейсиком, про который Вы что-то не поняли), Locoscript и очень немного игр. Про принтер описался, скорее 20 знаков в секунду — это было реально медленно, сам с таким работал. На PCW912 принтер стандартный повеселее с ромашкой — печать очень красивая и не так тормознуто, но на ромашке всего символов 90, точно не помню.
К БК подключался любой Centronics.
PDP-11 официально поддерживали до конца 90-х, их вроде ещё до сих пор где-то эксплуатируют — www.theregister.com/2013/06/19/nuke_plants_to_keep_pdp11_until_2050
Технически лучшие PDP-11 в 1991 не так уж и плохо смотрелись.
Эконом-клавиатуры были и на зарубежных ПК, посмотрите на Спектрум, Коммодор 116 и много ещё где. На БК с 1987 клавиатура достаточно адекватная.
Написал Вам, что для БК было сделано ПО поддержки жестких дисков. Конечно, это про 90-е и не ранние. Но софт сделали. В 1986 и БК скорее всего было продано не более нескольких сотен, а дисководах никто тогда и не мечтал. Что же Вы такую ерунду написали?!
Получается, что по Альтаирам данные противоричивые, на указанной Вам странице приводится информация только, что несколько более 2000.
За рубежом также публиковали радиолюбительские компьютерные схемы. И почему нельзя сравнить Альтаир и Радио-РК? Сами писали о слабости электронной промышленности СССР, к тому же заваленную авантюрными прожектами. Люди хоть через журнал могли что-то сделать, А, например, Орион-128 для своего класса просто мировой шедевр. Это почти как Амстрад дома спаять. И сравните, что мог владелец Альтаира и Ориона.
А я не знаю сколько было инсталяций у Microsoft Basic в 70е. Знаю только, что шел он очень хорошо и в 80-е также зашёл успешно. Но не понял, как это мешает зависимости объема софта от тиража компьютера?
Эльбрус и 10 лет отставания — такого не знаю, было бы интересно про такое почитать. То что я знаю, это скорее наоборот. Даже после почти полного разгрома в 90-е, когда почти все специалисты уехали в Штаты, удалось восстановиться в рамках МЦСТ. Данные про Transmeta противоречивые, там есть признаки нечестной конкуренции.
Для расчета зарплаты имел ввиду БК0011 с дисководом. Был свидетелем внедрения на предприятие такой зарплатной системы на базе Amstrad PCW, а где-то возможно внедряли на CPC. Про терминалы на БК ничего не писал — это Вы опять фантазируете. Я писал про отдельное рабочее место в бухгалтерии.
Обычный срок эксплуатации мейнфреймов был примерно лет 5-10. В 1977 уже на металлолом пошли первые модели систем 370. Гугл поламался? :)
ICL — это не IBM — это совершенно разные архитектуры.
Ничего такого и близко не писал, похоже Вы спорите Сами с Собой. PDP-11/70 очень надежный комп — они до сих пор живые в сети доступны, работают 24 часа почти без перерывов на техобслуживание. Там многозадачные многопользовательские системы RSX-11 или 4.3BSD. Но, сравнить, с древним давно сгинувшим монстром ЕС-1052, конечно, трудно. Их и выпущено было всего несколько десятков. А памяти на PDP-11/70 можно поставить до 4 мегабайт, подозреваю, что на ЕС-1052 столько реально никогда не ставили. Кроме того, по цене одной такой EC может возможно было бы купить несколько PDP-11/70, а если делать их по лицензии, то и несколько десятков. Хотя это всё предположения, которые практически невозможно проверить.
Я с QL не работал, встречал иногда людей, знакомых лучше меня с темой. Что Вы так на QL нападаете, это что-то типа Atari ST или AMiga и софт примерно такого же класса. Гугл сообщает, что QL Archive считалась не хуже DBase тех времен.
Про PortaCalc повторю, никто про неё ничего не знал, среди некоторых знатоков PDP-11, с которыми общался. PortaCalc есть только для DECOS и каких-то калькуляторов, отсюда и связь. Хотя есть ненулевая вероятность, что это совершенно разные программы. Действительно, не раз удивлялся сколько много программ можно обнаружить для системы выпущенной в совсем небольшом количестве. Действительно, были какие-то таблицы для сторонней операционной системы TSX-Plus, сделанные фирмой Saturn и названия которых так и не нашёл. Однако отсутствие брендированных электронных таблиц должно говорить само за себя. Тут какой-то пусть и не PD, но маргинальный софт. Если бы он был хорош, то авторы отличились бы с ним и на других системах.
Не понял. Не надо было делать БК? Опять Вы что-то выдумываете. Мне представляется, что решение по мейнфреймам, которое было принято в СССР, многими, включая Дейкстру, воспринималось, как ошибочное. Потому, что политика вмешалась в сложные процессы и получился слон в посудной лавке. Часть отличных специалистов, настроенных на развитие существуещих проектов, оказались практически не у дел. Это как-бы сами себе конечность ампутировали. А другая часть получила избыточное финансирование и изначально порочную схему работы.
Нельзя на обычном Спектруме запустить CP/M или на TRS-80 моделе 1, с которых всё начиналось. Про TRS-80 знаю меньше, но на Спектруме людям приходилось использовать режим прерываний 2 из-за того, что в начале памяти жестко стоит ПЗУ. Если кто-то там и запустил CP/M — это невероятное шаманство с какими-то аппаратными переделками. Извините, но вы пишите полную ерунду. Никогда к Спектруму или моделе 1 CP/M не предлагалась. Может Вы ещё скажите, что CP/M это была одна из штатных ОС для этих ПК?! Софт там был уникальный, с нуля. Они даже бейсик Билла Гейтса не взяли. Хотя на TRS-80 все же его потом тоже стали использовать.
Allister2
Да зачем он мне нужен то, этот мир? ДВК — это еще куда ни шло, но БК…
Да причем тут мейнфреймы? В СССР мини-компьютеры штамповали массово, СМ и прочее. Их было сильно поболее, чем ЕС, но это были разные области применения.
На ЕС стояли диски на десятки мегабайт, это было лучшее, что могла предложить промышленность, был софт, а Вы мне пишите про компьютер, на котором можно было разве что несложные программки запускать.
Чтобы считать — вообще ничего не нужно, ассемблера хватит. Ну а фортран сделать — это вполне решаемо.
Не путайте считалеки и бизнес-компьютеры.
CP/M — это тысячи разных программ. Вы сами понимаете, о чем пишите то?
Поддерживали, что никто их уже не продавал и, разумеется, никто не хотел купить, кроме как на замену.
Ужасно они смотрелись. Нафига покупать PDP-11 в 1991 году? Кто бы это делал??
Даже на спектруме клавиатура лучше. Хотя никто не считал спектрум ничем, кроме как супер-дешевым компьютером для дома.
Софт под 8 битные компьютеры (под CP/M) для поддержки жестких дисков был еще в 70е! Причем сразу в поставке вместе с жестким диском — C8000, 1979 год. Вопрос, почему советские разработки такие хорошие, если надо столько лет ждать, пока они догонят США?
Это за первый год.
www.adwaterandstir.com/altair-history
Тут цифра 40,000 до 1978 года.
Потому что это разные эпохи.
Возьмите телефон 10 летней давности и сравните с существующим.
1500py470.livejournal.com/403284.html
Да почитайте, в чем проблема. Эльбрус-1 медленнее Cray-1 в 10 раз. Догнать удалось только на Эльбрус-2, а это как раз…
А если бы дисковод сломался? Все, сидит завод без зарплаты?
Это я не шучу, если что :) Вы просто не застали советские порядки, поэтому для Вас это непостижимо.
Или больше.
ICL — это несколько архитектур, в том числе и IBM совместимые.
Вы не сравнивайте PDP-11/70 и советские клоны.
Они были совсем не чета DEC'овским оригиналам.
Предложение заменить глючные ЕС на глючные PDP, это, конечно, интересно, особенно учитывая, что ими занимались разные министерства.
Про базу данных:
Archive did however also suffer from two other problems, in that if you exited the program (or the QL crashed) without you closing the database, then you had to use a third party tool to recover the database.
Спасибо, забирайте это дерьмо себе, дальше даже не читал, хотя там, видимо, все на такое уровне :(
Ну вот я знаю, сейчас ковыряю ее сорцы.
Прикольный фортран под PDP-11.
А Ваши знакомые — лохи колхозные, какие-то, ничего не знают :(
Лежит же в открытом доступе!
Можно скачать и запустить! Ну не тупите!
avitech.com.au/?page_id=2570
Что еще то сделать, чтобы Вы закрыли этот вопрос для себя?
Если бы он был хорош, то авторы отличились бы с ним и на других системах.
Отличились!
Operating System: AMIGA DOS, IAS, MS/DOS, MicroVMS, RSX-11M,
RSX-11M-PLUS, VAX/VMS
Source Language: FORTRAN 77, MACRO-11, MACRO-32
Keywords: Business Applications, Data Base Management, Mathematical,
PortaCalc, Spreadsheet
Если я дам Вам исходники — обещаете написать про нее статью на Хабре?
Кстати, у меня и порт под UNIX есть. Какой офигенный софт то!
Надо было делать один (!) компьютер для школ и один для дома.
Надо было понимать, что ты страна не первого, а второго мира и ресурсов на кучу архитектур просто нет.
Ну и это не должен был быть БК, потому что софт надо быть драть с Z80 based компьютеров.
Раз уж испокон веку драли, то CP/M с нормальным видеоадаптером и звуковым процессором надо было осилить. Не тратить силы на десятки разных компьютеров, но сделать один. Пусть на 3-4 года с отставанием, пусть здоровый, пусть мониторы убогие — но сделать что-то одно.
А почему на 1 то? На 3+ прекрасно работает CP/M.
У Вас то БК-0010 решает бухгалтерские задачи, то выясняется, что это 11М с дисководом.
Только 11M — это 1989 год, тогда уже IBM PC совместимы компьютеры в АСУченных предприятиях появились. А это 640 кб RAM, жесткий диск…
Какой еще БК то? :)