Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
Потому что скорость расчёта в "десятичном текстовом" виде будет многократно меньше, чем при естественном для машины двоичном числовом, а схемы для всего этого будут существенно сложней.
Скорей всего, причина в том, что автор использует инструменты, которые сами заточены на реальный режим. Винда с помощью режима V86 может эмулировать ДОС, но поддержка V86 выпилена из 64-разрядного режима процессора; соответственно, если работа идёт под 64-разрядной Виндой, гонять ДОСовские программы прямо из-под Винды невозможно (только ставить ДОС на виртуальную машину или там какой ДОСБох использовать).
Особого смысла в их хранении отдельно нет. Проще хранить всю сумму не в рублях, а в копейках (или там в десятых/сотых копейки -- зависит от конкретных требований).
Ещё от архитектуры процессора зависит. Мэйнфреймы IBM от самого своего рождения (Система 360, 1964 год) имеют поддержку двоично-десятичных чисел (до 31 десятичной цифры плюс знак), и на них "экономическая" информация естественным образом считается в десятичной системе. Вот на ПК (IA-32, AMD64 -- неважно) или, скажем, на ARM любой разновидности такие вещи приходится считать, используя целочисленную арифметику; плавающая запятая -- лишь для задач, где ошибки округления приемлемы (скажем, научные расчёты: там не обязательно, чтоб последняя циферка сходилась, достаточно лишь обеспечить необходимую точность).
Так бурно развивали КМОПы как раз потому, что ещё в конце 80-х стало понятно, что от ЭСЛ никаким жидким гелием не отведёшь столько тепла, сколько выделяется, если на кристалле будут не тысячи, а сотни тысяч транзисторов. Ну а индивидуально биполярный транзистор как был, так и остаётся сильно быстрей полевого, если они выполнены на плюс-минус одном технологическом уровне -- просто это осталось только в аналоговых схемах, где транзисторов... ну, десятки (не тысяч, а просто десятки).
А ещё в документации написано, что сразу после сброса по включении питания нельзя обращаться ко встроенной памяти. Это означает, что самое первое, что надо сделать, -- провести минимальную настройку питания, чтоб можно было обращаться к памяти, причём это можно делать только на ассемблере, прямо в обработчике сброса: компилятор же всегда обращается к стеку, а это -- память.
9-я дорожка пишется одновременно с остальными восемью и содержит контрольный разряд для для каждого записанного байта. А ещё пишется контрольная сумма в конце каждого блока, и всё это вместе даёт возможность исправлять при чтении некоторые ошибки. Так что нету там свободного места -- не говоря о том, что читать на большой скорости движения ленты и получать надёжный результат невозможно. Не просто так ленты при чтении/записи двигаются медленно, и лишь перемотка идёт быстро.
А были ещё круглые дырочки -- но это для 45-колоночных перфокарт, которые использовались на табуляторах, но не на ЭВМ (хотя устройства ввода перфокарт некоторых моделей умели читать и стандартные 80-колоночные, и 45-колоночные).
Во-первых, чтобы распознавать "единички", как и любую другую информацию, лента должна двигаться достаточно медленно, что исключает её быструю перемотку, -- а светоотражающие полоски ловятся датчиками на любой скорости, поэтому-то перемотка ленты и осуществляется в несколько раз быстрей, чем простое передвижение, как при записи/считывании.
Во-вторых, содержимое ленты постоянно перезаписывается, и подобные "программные" маркеры легко могут быть стёрты -- особенно если появляются сбойные блоки, и приходится выполнять стирание промежутка.
Ну а в-третьих, как Вы собираетесь отличать подобные "пограничные" блоки от обычной информации на ленте?
Ну, курсы могут быть для "переезда" с ДОС ЕС (DOS/360) на ОС ЕС или СВМ ЕС (OS/360, VM/370). Хотя, как по мне, больше потусоваться и "обменяться опытом": если ты уже более-менее освоил программирование, то для перехода откуда угодно куда угодно достаточно документации.
Даже не в разы, а в сотни, а нередко -- и тысячи раз слабее. Скажем, упомянутая в статье ЕС-1020 (самая медленная из "настоящих" ЕСок) выполняла 30 тыс. 32-разрядных сложений или вычитаний в секунду. Каждый проц современного ПК (а их много -- скажем, у меня 12-ядерный Ryzen-что-то-там, а соответственно, я имею 12 процов) способен выполнить, если звёзды сойдутся (а нередко они сходятся), порядка 10 млрд. подобных операций в секунду. Но сейчас эти миллиарды уходят, главным образом, на всякого рода свистоперделки, реализованные с помощью целой кучи библиотек, фреймворков и прочих пыхтонов. (Конечно, сейчас реально есть программы, сделанные более-менее эффективно и действительно нуждающиеся в огромных вычислительных мощностях, -- но, наверное, 95% современного ПО с точки зрения эффективности находится ниже всякого плинтуса.)
Не вымерли они. IBM продолжает производить мэйнфреймы z/Architecture -- наследники Системы 360, 370 и т.д., архитектура которых была реализована, в том числе, и в ЕСках. Это в России своя электроника почти полностью умерла -- но это уже второй вопрос.
Вообще, до появления дисплеев ввод обычно с перфокарт, а вывод обычно на АЦПУ; Консул -- это консольный терминал машины, и программисты с ним дела особо не имели. Хотя на мелких машинках он бывал и в качестве обычного терминала (у них, есно, то же самое, только на 10 лет раньше; скажем, первые PDP-11 комплектовались телетайпом в качестве терминала -- тот же Консул, вид сбоку).
А вот что колхозного в наклейке светоотражающих маркеров на магнитную ленту, убей не пойму :)
На фотке -- абсолютно точно не ЕС-1020. Возможно, это чехословацкая ЕС-1021 (именно эта фотка появляется в качестве иллюстрации к одной статье на чешском), но они в СССР не поставлялись.
Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
Тогда даже шутка была: какой бы поисковый запрос ни ввели, ему будет удовлетворять, по меньшей мере, один порносайт.
Наивный чукотский юноша... (с)
Потому что скорость расчёта в "десятичном текстовом" виде будет многократно меньше, чем при естественном для машины двоичном числовом, а схемы для всего этого будут существенно сложней.
Всего-то 18,5 десятичных цифр... Маловато будет! :) (на мэйнфреймах -- до 31)
Скорей всего, причина в том, что автор использует инструменты, которые сами заточены на реальный режим. Винда с помощью режима V86 может эмулировать ДОС, но поддержка V86 выпилена из 64-разрядного режима процессора; соответственно, если работа идёт под 64-разрядной Виндой, гонять ДОСовские программы прямо из-под Винды невозможно (только ставить ДОС на виртуальную машину или там какой ДОСБох использовать).
Особого смысла в их хранении отдельно нет. Проще хранить всю сумму не в рублях, а в копейках (или там в десятых/сотых копейки -- зависит от конкретных требований).
Ещё от архитектуры процессора зависит. Мэйнфреймы IBM от самого своего рождения (Система 360, 1964 год) имеют поддержку двоично-десятичных чисел (до 31 десятичной цифры плюс знак), и на них "экономическая" информация естественным образом считается в десятичной системе. Вот на ПК (IA-32, AMD64 -- неважно) или, скажем, на ARM любой разновидности такие вещи приходится считать, используя целочисленную арифметику; плавающая запятая -- лишь для задач, где ошибки округления приемлемы (скажем, научные расчёты: там не обязательно, чтоб последняя циферка сходилась, достаточно лишь обеспечить необходимую точность).
Гы :) Я даже не пытался думать насчёт этой частоты -- думал, она чисто для видео :)
Так бурно развивали КМОПы как раз потому, что ещё в конце 80-х стало понятно, что от ЭСЛ никаким жидким гелием не отведёшь столько тепла, сколько выделяется, если на кристалле будут не тысячи, а сотни тысяч транзисторов. Ну а индивидуально биполярный транзистор как был, так и остаётся сильно быстрей полевого, если они выполнены на плюс-минус одном технологическом уровне -- просто это осталось только в аналоговых схемах, где транзисторов... ну, десятки (не тысяч, а просто десятки).
А ещё в документации написано, что сразу после сброса по включении питания нельзя обращаться ко встроенной памяти. Это означает, что самое первое, что надо сделать, -- провести минимальную настройку питания, чтоб можно было обращаться к памяти, причём это можно делать только на ассемблере, прямо в обработчике сброса: компилятор же всегда обращается к стеку, а это -- память.
9-я дорожка пишется одновременно с остальными восемью и содержит контрольный разряд для для каждого записанного байта. А ещё пишется контрольная сумма в конце каждого блока, и всё это вместе даёт возможность исправлять при чтении некоторые ошибки. Так что нету там свободного места -- не говоря о том, что читать на большой скорости движения ленты и получать надёжный результат невозможно. Не просто так ленты при чтении/записи двигаются медленно, и лишь перемотка идёт быстро.
А были ещё круглые дырочки -- но это для 45-колоночных перфокарт, которые использовались на табуляторах, но не на ЭВМ (хотя устройства ввода перфокарт некоторых моделей умели читать и стандартные 80-колоночные, и 45-колоночные).
Во-первых, чтобы распознавать "единички", как и любую другую информацию, лента должна двигаться достаточно медленно, что исключает её быструю перемотку, -- а светоотражающие полоски ловятся датчиками на любой скорости, поэтому-то перемотка ленты и осуществляется в несколько раз быстрей, чем простое передвижение, как при записи/считывании.
Во-вторых, содержимое ленты постоянно перезаписывается, и подобные "программные" маркеры легко могут быть стёрты -- особенно если появляются сбойные блоки, и приходится выполнять стирание промежутка.
Ну а в-третьих, как Вы собираетесь отличать подобные "пограничные" блоки от обычной информации на ленте?
Ну, курсы могут быть для "переезда" с ДОС ЕС (DOS/360) на ОС ЕС или СВМ ЕС (OS/360, VM/370). Хотя, как по мне, больше потусоваться и "обменяться опытом": если ты уже более-менее освоил программирование, то для перехода откуда угодно куда угодно достаточно документации.
Даже не в разы, а в сотни, а нередко -- и тысячи раз слабее. Скажем, упомянутая в статье ЕС-1020 (самая медленная из "настоящих" ЕСок) выполняла 30 тыс. 32-разрядных сложений или вычитаний в секунду. Каждый проц современного ПК (а их много -- скажем, у меня 12-ядерный Ryzen-что-то-там, а соответственно, я имею 12 процов) способен выполнить, если звёзды сойдутся (а нередко они сходятся), порядка 10 млрд. подобных операций в секунду. Но сейчас эти миллиарды уходят, главным образом, на всякого рода свистоперделки, реализованные с помощью целой кучи библиотек, фреймворков и прочих пыхтонов. (Конечно, сейчас реально есть программы, сделанные более-менее эффективно и действительно нуждающиеся в огромных вычислительных мощностях, -- но, наверное, 95% современного ПО с точки зрения эффективности находится ниже всякого плинтуса.)
Не вымерли они. IBM продолжает производить мэйнфреймы z/Architecture -- наследники Системы 360, 370 и т.д., архитектура которых была реализована, в том числе, и в ЕСках. Это в России своя электроника почти полностью умерла -- но это уже второй вопрос.
Вообще, до появления дисплеев ввод обычно с перфокарт, а вывод обычно на АЦПУ; Консул -- это консольный терминал машины, и программисты с ним дела особо не имели. Хотя на мелких машинках он бывал и в качестве обычного терминала (у них, есно, то же самое, только на 10 лет раньше; скажем, первые PDP-11 комплектовались телетайпом в качестве терминала -- тот же Консул, вид сбоку).
А вот что колхозного в наклейке светоотражающих маркеров на магнитную ленту, убей не пойму :)
Подозреваю, отлаживали вычислительную часть алгоритмов...
На фотке -- абсолютно точно не ЕС-1020. Возможно, это чехословацкая ЕС-1021 (именно эта фотка появляется в качестве иллюстрации к одной статье на чешском), но они в СССР не поставлялись.