Насколько я помню, до Win7 были какие-то заморочки, народе того что когда файлы видны, то аудио треки нет. Кстати, качество записи в тех файлах было хуже, чем на треках.
Судя по давним публикациям об этом диске, он содержал две части: плеер с файлами для воспроизведения на компе и обычный CD для прослушивания где-нибудь ещё. Если маркером поставить точку в нужном месте, диск можно было слушать на компе без всякого плеера.
IBM в своих мейнфреймах серии z исторически использовала нестандартные иерархии памяти с бо́льшим числом уровней, чем принято в x86-мире
К слову, IBM давно экспериментирует с нестандартными иерархиями памяти. Любопытный пример - IBM 2361 (конец 1960-х, архитектура System/360). Это блок расширения ОП, который адресуется так же, как и "основная" ОП, но медленнее неё (8 мкс вместо 750 нс на Model 65).
А вот после полного очищения (clear()), вектор освободил буфер, и аллокатор зафиксировал 0 байт занятых.
Что-то тут не так: по описанию Vec::clear
Clears the vector, removing all values.
Note that this method has no effect on the allocated capacity of the vector.
Поэтому после вызова v.clear() должны были остаться те же 800 байт. Предполагаю, что это компилятор вставил drop(v) сразу после вызова v.clear() и перед println.
Насколько мне известно, в исходниках шла не вся система, а только те части, которые изменялись при генерации, в основном ядро, и в ОС ЕС так же. Но был бы рад и этому: не сохранилось, да.
Тут начинается зыбкая почва, ведь Machine Check не просто так существуют, а в целях облегчения процесса поиска неисправностей, поэтому весьма желательно бы иметь соответствующий MCH. Опять же, не знаю как конкретно на 1055, а на Ряд-2 должны были появиться прерывания из-за ухудшения характеристик, т.е. какое-то оборудование работает со сбоями, пока исправляемыми. Но да, попробовать запустить можно.
Объясняю: от OS/360 хотя бы исходники есть и можно, в теории, пропатчить систему, чтобы нормально обрабатывались машинные сбои и прочие зависимые вещи. Работать же под VM без адекватного MCH - ну так себе, до первого сбоя.
Нужны ещё эмуляторы магнитных лент, чтобы перетащить софт. А ещё либо дописать машиннозависимую часть для DOS или OS/360, либо раздобыть где-нибудь копию самой ДОС/ОС ЕС. Иначе, сдается мне, кроме автономных утилит и тестов (если они в наличии) на ней не получится ничего запустить.
А можно объяснить научно. Что наука покажет, то покажет. Нет?
Мне, к примеру, интересно, как озоновая гипотеза научно объясняет факт, что при подъёме в горы на 5-6 км интенсивность УФУ возрастает в десятки раз, причем в самом жёстком диапазоне, от которого озоновый слой вроде как должен защищать.
Например, в том, что изменения в озоновом слое над Антарктидой можно объяснить естественными циклическими процессами, которые до того просто-напросто не исследовали. Без привлечения какого-либо антропогенного воздействия.
Чем-то похожая история развивалась в СССР в 1970-80 годах, в прессе была куча статей про то что "Каспий мелеет", "Спасём Каспий".
Обе команды - изначально NOP (регистр 0 в цели перехода),
Не совсем так. В качестве NOP изначально рекомендовали использовать "BCR 0,R2" либо "BC 0, address". Операции "BCR R1,0" просто не выполняли переход, но это не означает что они не делали чего-то ещё.
Возможно, какой-то другой документ утверждаёт её обязательность.
Да, и это гуглится:
z/OS V2R3
Minimum server levels and machine facilities that are required for z/OS
45
Distinct-operands, fast-BCR-serialization, and other facilities.
Т.е. эта опция заложена в целевую платформу компилятора.
Две колонки - норма в научных публикациях. Я как-то не думаю, что PoO это научная публикация ;\
Ну в данном случае мы имеем дело в нормами публикации в корпорации, созданной в начале XX века. Я уже не говорю о том, что IBM сама по себе изрядная "консерва".
Читать такое с экрана неудобно, и это ещё один фактор к утяжелению с непривычки.
К слову, с экрана телефона двухколнонный набор читать удобнее. Но вообще-то, "внешняя" документация печаталась, так что это определенно типографские требования.
И почему `bcr 14, 0`, если в доке её действие определено только "When the fast-BCR-serialization facility is installed"? Считается, что эта опция гарантированно есть?
BCR 15,0
15 - это битовая маска, которая означает переход по любому коду условия. Это не опция, эта особенность была ещё в System/360, просто нормально описана уже в 370, когда кеши и конвейер стали более распространенными.
Тут слишком много всякого смешалось. Защита от записи в чужие области была и в 4.1, но в поздних 6.1 убрали дырку в системном вызове FREEDBUF, которая позволяла получить нулевой ключ защиты любой программе. (И, соответственно, давала возможность обходить защиту от записи).
Хм... Надо будет как-нить на Херкулесе попробовать.
Я совершенно серьёзно, для меня в своё время был культурным шоком факт, что ОС ЕС не запрещает залезать в чужие области памяти. По всей вероятности, дело в том, что аппаратные средства защиты от чтения появились позже самих ключей защиты памяти, и ко времени выхода OS/360 были не на всех машинах.
Но вообще без понятия, как точно они это реализовали
Это документировано. SVS использует два ключа защиты памяти: 0 для системных областей и 1 для всех пользовательских. Поэтому защитить от доступа к чужим разделам можно только через таблицы переадресации, которым всё равно, чтение это или запись.
Уточнение: для разделов V=R используются другие ключи защиты, тут как раз полное моделирование MVT для тех программ, которые почему-то отказываются жить с виртуальной памятью.
Увы, именно в ней. Несмотря на то, что аппаратные средства защиты от чтения ОП имелись, ни OS/360, ни OS/VS, ни ОС ЕС ими не пользовались. Причина в том, что для уточнения деталей программам приходится читать те или иные поля из системных блоков: CVT, TCB и др. Это была официальная политика, и выпускалась документация где и что можно найти. Вот в SVS залезть в адресное пространство другого задания не получится, но это Ряд-2 и динамическая переадресация.
В СССР это была ОС ЕС 6. А потом уже появилась MVS - фактически, новая система но под тем же именем, скопировать которую в СССР ниасилили.
Не то чтобы не осилили скопировать саму систему... От сотрудников НИЦ ЭВТ я слышал такую версию: MVS намного более требовательна к железу, намного сильнее трясет его по сравнению с VM, и соответственно выявляет больше аппаратных сбоев. Надёжность нашей техники справедливо сочли недостаточной и сделали ставку на СВМ.
К слову сказать, на рубеже 80/90-х IBM также продвигали VM.
В описании IBM ничего такого не сказано, и возникает вопрос на подумать.
Потому и не сказано, что там банальный сдвиг безо всяких округлений:
the fraction with the smaller characteristic is rightshifted; its characteristic is increased by one for each hexadecimal digit of shift
Что получится - 0x912_4 (где 4 это guard digit) или 0x912_5? Куда округлится за счёт этого F, вылетевшего за пределы даже guard digit?
Первый вариант. Цифра F вылетела и пропала, и в промежуточном представлении останется четвёрка. Примеры приводятся в конце описания. Можно ещё заглянуть в описание System/370, там подробнее разжёвано.
И, далее, guard digit для чего именно используется?
Такое впечатление, что она нужна только для того, чтобы при вычитании, когда нормализованный порядок падает и значение надо сдвигать влево, она входила в сохраняемую часть.
Верно, так и есть. Вместо округления пытаемся сохранить на одну значащую цифру побольше.
В том и дело, что для современной (подразумеваем IEEE754) сохранение данных для правильного округления, и дальше само округление, является критичным для корректности операций.
Окей, буду знать теперь, что между ними есть ещё одно существенное различие.
сравнил версии 0 и 7 (декабрь 67; 68го у меня нет под рукой)
На самом деле есть. ;) На bitsavers в названии файла почему-то прописана версия 7 и дата Dec67, хотя если взглянуть на вторую страницу, там:
Насколько я помню, до Win7 были какие-то заморочки, народе того что когда файлы видны, то аудио треки нет. Кстати, качество записи в тех файлах было хуже, чем на треках.
Судя по давним публикациям об этом диске, он содержал две части: плеер с файлами для воспроизведения на компе и обычный CD для прослушивания где-нибудь ещё. Если маркером поставить точку в нужном месте, диск можно было слушать на компе без всякого плеера.
К слову, IBM давно экспериментирует с нестандартными иерархиями памяти. Любопытный пример - IBM 2361 (конец 1960-х, архитектура System/360). Это блок расширения ОП, который адресуется так же, как и "основная" ОП, но медленнее неё (8 мкс вместо 750 нс на Model 65).
Что-то тут не так: по описанию Vec::clear
Поэтому после вызова v.clear() должны были остаться те же 800 байт. Предполагаю, что это компилятор вставил drop(v) сразу после вызова v.clear() и перед println.
Я про СВМ и ОС ЕС, а за ссылку спасибо!
Насколько мне известно, в исходниках шла не вся система, а только те части, которые изменялись при генерации, в основном ядро, и в ОС ЕС так же. Но был бы рад и этому: не сохранилось, да.
Тут начинается зыбкая почва, ведь Machine Check не просто так существуют, а в целях облегчения процесса поиска неисправностей, поэтому весьма желательно бы иметь соответствующий MCH. Опять же, не знаю как конкретно на 1055, а на Ряд-2 должны были появиться прерывания из-за ухудшения характеристик, т.е. какое-то оборудование работает со сбоями, пока исправляемыми. Но да, попробовать запустить можно.
Объясняю: от OS/360 хотя бы исходники есть и можно, в теории, пропатчить систему, чтобы нормально обрабатывались машинные сбои и прочие зависимые вещи. Работать же под VM без адекватного MCH - ну так себе, до первого сбоя.
Нужны ещё эмуляторы магнитных лент, чтобы перетащить софт. А ещё либо дописать машиннозависимую часть для DOS или OS/360, либо раздобыть где-нибудь копию самой ДОС/ОС ЕС. Иначе, сдается мне, кроме автономных утилит и тестов (если они в наличии) на ней не получится ничего запустить.
Забавно: я спрашивал про научное объяснение, а мне в ответ -- про веру.
А выяснил я, как нынче модно поступать с неудобными фактами.
Мне, к примеру, интересно, как озоновая гипотеза научно объясняет факт, что при подъёме в горы на 5-6 км интенсивность УФУ возрастает в десятки раз, причем в самом жёстком диапазоне, от которого озоновый слой вроде как должен защищать.
Например, в том, что изменения в озоновом слое над Антарктидой можно объяснить естественными циклическими процессами, которые до того просто-напросто не исследовали. Без привлечения какого-либо антропогенного воздействия.
Чем-то похожая история развивалась в СССР в 1970-80 годах, в прессе была куча статей про то что "Каспий мелеет", "Спасём Каспий".
Не совсем так. В качестве NOP изначально рекомендовали использовать "BCR 0,R2" либо "BC 0, address". Операции "BCR R1,0" просто не выполняли переход, но это не означает что они не делали чего-то ещё.
Да, и это гуглится:
Т.е. эта опция заложена в целевую платформу компилятора.
Ну в данном случае мы имеем дело в нормами публикации в корпорации, созданной в начале XX века. Я уже не говорю о том, что IBM сама по себе изрядная "консерва".
К слову, с экрана телефона двухколнонный набор читать удобнее. Но вообще-то, "внешняя" документация печаталась, так что это определенно типографские требования.
BCR 15,0
15 - это битовая маска, которая означает переход по любому коду условия. Это не опция, эта особенность была ещё в System/360, просто нормально описана уже в 370, когда кеши и конвейер стали более распространенными.
Тут слишком много всякого смешалось. Защита от записи в чужие области была и в 4.1, но в поздних 6.1 убрали дырку в системном вызове FREEDBUF, которая позволяла получить нулевой ключ защиты любой программе. (И, соответственно, давала возможность обходить защиту от записи).
P.S. Я писал раньше как "работала" эта дырка.
Я совершенно серьёзно, для меня в своё время был культурным шоком факт, что ОС ЕС не запрещает залезать в чужие области памяти. По всей вероятности, дело в том, что аппаратные средства защиты от чтения появились позже самих ключей защиты памяти, и ко времени выхода OS/360 были не на всех машинах.
Это документировано. SVS использует два ключа защиты памяти: 0 для системных областей и 1 для всех пользовательских. Поэтому защитить от доступа к чужим разделам можно только через таблицы переадресации, которым всё равно, чтение это или запись.
Уточнение: для разделов V=R используются другие ключи защиты, тут как раз полное моделирование MVT для тех программ, которые почему-то отказываются жить с виртуальной памятью.
Увы, именно в ней. Несмотря на то, что аппаратные средства защиты от чтения ОП имелись, ни OS/360, ни OS/VS, ни ОС ЕС ими не пользовались. Причина в том, что для уточнения деталей программам приходится читать те или иные поля из системных блоков: CVT, TCB и др. Это была официальная политика, и выпускалась документация где и что можно найти. Вот в SVS залезть в адресное пространство другого задания не получится, но это Ряд-2 и динамическая переадресация.
Не то чтобы не осилили скопировать саму систему... От сотрудников НИЦ ЭВТ я слышал такую версию: MVS намного более требовательна к железу, намного сильнее трясет его по сравнению с VM, и соответственно выявляет больше аппаратных сбоев. Надёжность нашей техники справедливо сочли недостаточной и сделали ставку на СВМ.
К слову сказать, на рубеже 80/90-х IBM также продвигали VM.
В книге "Принципы работы системы IBM/370" этот термин перевели как "временная отмена совмещений". Получилось длиннее, но, на мой взгляд, точнее.
Потому и не сказано, что там банальный сдвиг безо всяких округлений:
Первый вариант. Цифра F вылетела и пропала, и в промежуточном представлении останется четвёрка. Примеры приводятся в конце описания. Можно ещё заглянуть в описание System/370, там подробнее разжёвано.
Верно, так и есть. Вместо округления пытаемся сохранить на одну значащую цифру побольше.
Окей, буду знать теперь, что между ними есть ещё одно существенное различие.
На самом деле есть. ;) На bitsavers в названии файла почему-то прописана версия 7 и дата Dec67, хотя если взглянуть на вторую страницу, там: