Так-то оно так, только вирус встраивается в ДНК как раз затем, чтобы живая клетка синтезировала ему и оболочку, и всё прочее, что необходимо. А при каких условиях активируются такие фрагменты, не до конца понятно даже для "современников", не говоря уже про допотопные организмы.
Насчёт (не)опасности - с одной стороны, за время развития приматов с ними, по идее, уже должны были контактировать самые разнообразные вирусы, и живём же... С другой - оспа и герпес появились относительно недавно, так что червячок сомнения остаётся.
Если бы получилось восстановить ДНК из клетки настоящего динозавра, был бы шанс восстановить оттуда и ретровирус, который в неё встроился. У курозавра, конечно, тоже возможно, но это значит, что такой ретровирус уже "гуляет" где-то в природе и может добраться до нас и без курозавра.
Логику пишет дизайнер, для него разница принципиальная: попробовал, поправил, щёлкнул пальцами, и логика должна поменяться. И никаких этих ваших часовых компиляций.
И одновременно создали операционную систему, программы ввода/вывода, компиляторы кобола и других языков. И все это не имея привычных нам всем отладчиков программ. А ОС ведь была многозадачной !!!
Вот уж нет: и сама OS/360 провалила срок выпуска где-то на год, и многозадачный режим в ней заработал далеко не сразу. А разработки велись на DOS/360, да и пользователям поначалу пришлось её ставить, за неимением другой системы.
Для себя я не могу объяснить появление системы IBM/360.
Ларчик открывается просто: System/360 была далеко не первым успешным продуктом IBM; операционные системы также развивались вместе с техникой, а главное: в компании уже сложились команды, имевшие опыт разработки того и другого. Их грандиозный труд позволил подняться на новый качественный уровень, обидно, когда их наработки вычеркивают или принципиально не замечают.
Небольшое дополнение: в архитектуре предусмотрена возможность атомарно прочитать показания интервального таймера и установить новое значение. Для этого слова по адресам 4C и 54 оставлены неиспользуемыми процессором; считывание и установка выполняются одной командой
Собственно, это уже делается. И продажу просрочки не пропускает, да.
Правда, насчёт "ничего сложного" можно поспорить: там сертифицированные программно-аппаратные комплексы по всей цепочке от производства до продажи, с ежемесячной платой и прочим.
Одна SCM зачастую знает только следующего поставщика или потребителя, но ей ничего не известно о том, каких потребителей снабжает этот потребитель, или каких поставщиков использует этот поставщик.
Сдаётся мне, это не только и не столько техническое решение: прятать реальных поставщиков выгодно. Возьмём, к примеру, скандал с кониной под видом говядины -- там расследование цепочки поставок выявило много интересного, но до реальных поставщиков, насколько я помню, так и не добрались.
Появление кода цифры в знаковом полубайте или кода знака в цифровом вызывает программное прерывание по особому случаю данных.
Немного дополню: такие данные могут получиться вследствие недопустимого перекрытия операндов команд десятичной арифметики. Вкратце, допустимые варианты определяются как если бы процессор обрабатывал десятичные числа справа налево по одному байту и сразу записывал результат. В большинстве случаев требуется, чтобы при перекрытии совпадали самые правые байты.
Именно что энергетически. А чтобы сжечь водород, полученный где-то, его нужно ещё доставить до машины, т.е. построить и обслуживать сеть водородных заправочных станций. Что, в свою очередь, невыгодно экономически.
Одни из самых сложных процедур в оптимизирующем кодогенераторе -- это поиск в программе паттернов, которые бы отображались напрямую на комбинации команд и режимов адресации в прикладном режиме. И я не сказал бы, что красивая система команд однозначно упрощает этот процесс. Приведу пример из PDP-11.
Имеется автодекрементная адресация, которая по архитектуре применима ко многим командам. Однако, чтобы задействовать этот режим адресации для генерации команд помимо MOV, требуется научить кодогенератор отыскивать очень специфичные (и редко встречающиеся) комбинации в исходном коде. Теперь, гипотетически, создадим другую, не такую красивую систему команд, в которой автодекрементую адресацию оставим только как особый случай команды MOV. Кодогенерация при этом, очевидно, упрощается: нет лишних комбинаций команд -- не нужно выявлять для них паттерны -- нет лишних проблем.
(Нетрудно заметить, что выше я просто-напросто пересказал кусок из идеологии RISC. Ну да, набор команд у них не назовешь однозначно красивым.)
Уродливость системы команд -- понятие, которое зависит от вкуса, привычек, опыта работы с ними. Если сравнивать, к примеру, с MIPS или ARM (ранними), так ЕС вполне достойно смотрится.
Только зачем нужны красивые системы команд, когда на ассемблере не пишут практически ничего? Даже операционные системы. Уже при написании IBM MVS широко использовался язык PL/S, а это середина 1970-х.
16 Мбайт памяти — это огромная величина для середины 1960-х годов, машины с таким объёмом ОП стали сколько-нибудь массово появляться «у них» лишь во второй половине 1970-х
Забавный факт: программа начальной загрузки (IPL) ранних версий OS/360 зацикливается при максимальном размере ОП 16 Мб. Происходит это потому, что определение размера ОП реализовано так: выполняется чтение через каждые 2 Кб и перехват прерывания, возникающего при выходе за доступный размер ОП. Соответственно, на 16 Мб такого прерывания не возникает.
Более поздняя версия IPL выполняет этот цикл более корректно, с проверкой верхней границы.
Насколько я помню публикации про эту технологию, основной упор делался на то, что не потребуется создавать сеть для хранения и распределения водорода (с чем до сих пор проблема): у машины в баках чистая вода.
В таком виде, как сейчас, -- показуха, безусловно, но если начать использовать отходы производства (упомянутую алюминиевую стружку) и вторсырьё, то, может, и получится кое-какая выгода. Затраты при этом будут не на производство алюминия, а на сбор сырья и на этот самый нанопорошок.
Так-то оно так, только вирус встраивается в ДНК как раз затем, чтобы живая клетка синтезировала ему и оболочку, и всё прочее, что необходимо. А при каких условиях активируются такие фрагменты, не до конца понятно даже для "современников", не говоря уже про допотопные организмы.
Насчёт (не)опасности - с одной стороны, за время развития приматов с ними, по идее, уже должны были контактировать самые разнообразные вирусы, и живём же... С другой - оспа и герпес появились относительно недавно, так что червячок сомнения остаётся.
Если бы получилось восстановить ДНК из клетки настоящего динозавра, был бы шанс восстановить оттуда и ретровирус, который в неё встроился. У курозавра, конечно, тоже возможно, но это значит, что такой ретровирус уже "гуляет" где-то в природе и может добраться до нас и без курозавра.
Логику пишет дизайнер, для него разница принципиальная: попробовал, поправил, щёлкнул пальцами, и логика должна поменяться. И никаких этих ваших часовых компиляций.
Почему нет? На вокзале, в зале ожидания, думаю, такие находились.
Вот уж нет: и сама OS/360 провалила срок выпуска где-то на год, и многозадачный режим в ней заработал далеко не сразу. А разработки велись на DOS/360, да и пользователям поначалу пришлось её ставить, за неимением другой системы.
Ларчик открывается просто: System/360 была далеко не первым успешным продуктом IBM; операционные системы также развивались вместе с техникой, а главное: в компании уже сложились команды, имевшие опыт разработки того и другого. Их грандиозный труд позволил подняться на новый качественный уровень, обидно, когда их наработки вычеркивают или принципиально не замечают.
Небольшое дополнение: в архитектуре предусмотрена возможность атомарно прочитать показания интервального таймера и установить новое значение. Для этого слова по адресам 4C и 54 оставлены неиспользуемыми процессором; считывание и установка выполняются одной командой
Собственно, это уже делается. И продажу просрочки не пропускает, да.
Правда, насчёт "ничего сложного" можно поспорить: там сертифицированные программно-аппаратные комплексы по всей цепочке от производства до продажи, с ежемесячной платой и прочим.
Вот отсюда
Сдаётся мне, это не только и не столько техническое решение: прятать реальных поставщиков выгодно. Возьмём, к примеру, скандал с кониной под видом говядины -- там расследование цепочки поставок выявило много интересного, но до реальных поставщиков, насколько я помню, так и не добрались.
Мне говорили, что ЕС-1036, ЕС-1046 и ЕС-1066 соответствуют серии IBM 303X. То есть, ЕС-1066 - это копия IBM Model 3033.
Немного дополню: такие данные могут получиться вследствие недопустимого перекрытия операндов команд десятичной арифметики. Вкратце, допустимые варианты определяются как если бы процессор обрабатывал десятичные числа справа налево по одному байту и сразу записывал результат. В большинстве случаев требуется, чтобы при перекрытии совпадали самые правые байты.
Именно что энергетически. А чтобы сжечь водород, полученный где-то, его нужно ещё доставить до машины, т.е. построить и обслуживать сеть водородных заправочных станций. Что, в свою очередь, невыгодно экономически.
Одни из самых сложных процедур в оптимизирующем кодогенераторе -- это поиск в программе паттернов, которые бы отображались напрямую на комбинации команд и режимов адресации в прикладном режиме. И я не сказал бы, что красивая система команд однозначно упрощает этот процесс. Приведу пример из PDP-11.
Имеется автодекрементная адресация, которая по архитектуре применима ко многим командам. Однако, чтобы задействовать этот режим адресации для генерации команд помимо MOV, требуется научить кодогенератор отыскивать очень специфичные (и редко встречающиеся) комбинации в исходном коде. Теперь, гипотетически, создадим другую, не такую красивую систему команд, в которой автодекрементую адресацию оставим только как особый случай команды MOV. Кодогенерация при этом, очевидно, упрощается: нет лишних комбинаций команд -- не нужно выявлять для них паттерны -- нет лишних проблем.
(Нетрудно заметить, что выше я просто-напросто пересказал кусок из идеологии RISC. Ну да, набор команд у них не назовешь однозначно красивым.)
Уродливость системы команд -- понятие, которое зависит от вкуса, привычек, опыта работы с ними. Если сравнивать, к примеру, с MIPS или ARM (ранними), так ЕС вполне достойно смотрится.
Только зачем нужны красивые системы команд, когда на ассемблере не пишут практически ничего? Даже операционные системы. Уже при написании IBM MVS широко использовался язык PL/S, а это середина 1970-х.
Я встречал упоминание о ещё двух вариантах:
Срабатывание схем аппаратного контроля может сразу перевести ЦП в останов, а не вызывать соответствующее прерывание.
Некорректное PSW программных прерываний на некоторых моделях также может перевести ЦП в останов.
Забавный факт: программа начальной загрузки (IPL) ранних версий OS/360 зацикливается при максимальном размере ОП 16 Мб. Происходит это потому, что определение размера ОП реализовано так: выполняется чтение через каждые 2 Кб и перехват прерывания, возникающего при выходе за доступный размер ОП. Соответственно, на 16 Мб такого прерывания не возникает.
Более поздняя версия IPL выполняет этот цикл более корректно, с проверкой верхней границы.
Насколько я помню публикации про эту технологию, основной упор делался на то, что не потребуется создавать сеть для хранения и распределения водорода (с чем до сих пор проблема): у машины в баках чистая вода.
В таком виде, как сейчас, -- показуха, безусловно, но если начать использовать отходы производства (упомянутую алюминиевую стружку) и вторсырьё, то, может, и получится кое-какая выгода. Затраты при этом будут не на производство алюминия, а на сбор сырья и на этот самый нанопорошок.
В очередной раз сошлюсь на мой любимый сайт со сканами старых документов, вот небольшая подборка:
PL/1 для System/360
PL/1 для System/370
Добавлю сюда кое-какую документацию по микропрограммированию от IBM
Model 25 microprogramm listing
Model 30 microprogramming language
Introduction to microprogramming