Вообще, если учить современный C++, то программы должны компилироваться любым современным компилятором. Есть, конечно, специфические вещи, завязанные на платформу, но это явно не для учебных целей.
Более того, модули, кроме как в современной VS, могут вполне себе не работать или работать плохо. Пробовал относительно недавно с ARMCLANG -- наткнулся на кучу типа ошибок, которых быть не должно (аналогичный код в VS компилировался без проблем). Сопрограммы работают, но IDE (Keil) подглючивает, особенно на отладке. Ну и т.д. и т.п. И, опять-таки, даже обучая современному, надо показывать и древности, объясняя, чем они хуже и почему с ними всё-таки, с приличной вероятностью, придётся встречаться на практике.
Ну, современный C++ начинается с C++11, и почти всё, внесённое в язык тогда, вполне себе актуально (хотя нередко и расширено). Так что как отправную точку вполне можно рассматривать именно его, а не C++17 -- конечно, с учётом обучения с нуля, а не расширения знаний тех, кто давно уже язык использует. В частности, при первоначальном обучении не обойтись без указателей, а значит, без nullptr вместо NULL -- а это как раз C++11. А вот говоря о типах, включённых в сам язык, нужно говорить и о char8_t -- а это C++20.
Ну а код будет разительно отличаться только при использовании новых крупных вещей, добавленных в C++20, -- скажем, модулей и сопрограмм. Если такое не используется (а при начальном обучении это практически неизбежно), особой разницы не будет.
Хотя исключить такую гипотезу нельзя, на 0/1/8/9 заканчивается целый склад команд -- скажем, LR и CR (18 и 19). Старшие четыре бита КОП эта проверка не смотрит, так что выделить конкретно SSK и ISK из всего формата RR она не может. Кроме того, в конечном итоге переход происходит по всему коду операции, и проверка на режим супервизора, надо полагать, выполняется в микропрограммах конкретных команд...
Производимая на территории СССР, на советском оборудовании и на советских материалах. Хотя, конечно, он (процессор) сам является отечественной элементной базой, а не производился на ней -- видимо, автор именно об этом хотел сказать.
Некоторые занимаются археологическими раскопками -- им древние окаменелости интересны, хотя вокруг действительно полно современных интересных вещей. Ну а кому древности не интересны, тот волен выбрать себе занятие (и чтение) по душе, оставив окаменелости другим.
"Знать наизусть на экзамене" -- это, конечно, глупость; если бы преподавал я, то требовал бы понимания принципов, а не запоминания всего этого (и, более того, не запрещал бы пользоваться справочниками: если студент что-то по мелочи забыл, ему поможет, ну а если реально не знает, препод всё равно поймёт это).
Ну а принципы... Если усвоил, как работает и как программировать КР580ВВ51, то сможешь разобраться с любым другим UARTтом; если понял, как ШИМить с помощью КР580ВИ53 -- сделаешь это и на любом другом таймере, ну и т.д. и т.п. Так что полезные знания можно было и на старье получить. Кроме того, Пентиумы в освоении именно этих вещей помогли бы мало: у ПК и у промышленных (микро)контроллеров разное назначение и разные функциональные возможности, и "переписать программы для современных процессоров" зачастую было невозможно: не подходили они для этих целей. Сейчас, конечно, программированию подобных вещей лучше учиться на каких-нибудь там STM32 или других популярных микроконтроллерах, но в 1990-х обучение на 8080 и его периферии -- вполне разумное решение.
Там все проверки, по большому счёту, выполняются микропрограммно, поэтому-то и странно. Никаких общих черт у этих особых случаев, кажется, нет, поэтому я и в недоумении...
"Многопоточность" в смысле multithreading одного процесса тут никаким боком, она появилась заметно позже.
Вот тут Вы ошибаетесь: многопоточность именно в таком смысле была в OS/360 MFT с подзадачами и в OS/360 MVT, т. е. уже в конце 1960-х. Подзадачи в терминологии OS/360 -- это как раз потоки одного процесса, если использовать терминологию Винды (ну а задачей именовался головной поток).
Что такие резисторы были, я, конечно, знаю -- сам их в своё время использовал. Но я не уверен, что в микросборке использовали именно привычные резисторы, а не что-то специально изготовленное с габаритами поменьше. Самих этих микросборок я в глаза не видел и тем более не разламывал, поэтому просто процитировал написанное в книжке.
Можно ещё отметить, что критерий опубликовали в 1974, но IBM и без него всё сделала правильно с первого же раза (VM/370 -- 1971 год; железо, соответственно, проектировалось ещё раньше). А Интел и опубликованное, и уже широко используемое не помогло. Вероятно, чукча не читатель...
Реально граница между микрокодом (микропрограммой) и схемным управлением не очень чёткая. Конечно, когда микропрограмма загружается в ОЗУ, как это было, скажем, на ЕС-1035 и ЕС-1045, сказать можно чётко: микропрограмма. Если она намертво зашита в ПЗУ, такое сказать уже сложней: не поменяешь же, не забравшись внутрь проца. А если на ПЛМ (вроде, так было сделано в нашей серии К1801)? Это, по большому счёту, уже не отличается от схемного управления, где управляющие сигналы вырабатывались логикой -- но за счёт более "стройной" структуры блока управления, не "размазанного" по 100500 триггерам, управляющим друг другом с помощью столько же "размазанной" логики, выглядит ближе к микропрограмме...
Ну, речь-то о том, что ИБМ всё сразу сделала принципиально правильно на уровне архитектуры, чем и дала возможность создания СВМ без какой-либо специальной аппаратной поддержки.
Кстати говоря, думаю, что тогда -- в 1970-х -- такая поддержка и не очень-то требовалась. Без неё будут временами сильно тормозить гостевые ОС с виртуальной памятью, но не стоит забывать, что множество пользователей мэйнфреймов IBM тогда ещё сидело либо на OS/360 MVT/MFT, либо вообще на DOS/360, и виртуализация позволяла им перенести на один мощный мэйнфрейм работу, которая раньше выполнялась на нескольких ранних слабых моделях. Ну а поскольку эти системы не имели своей виртуальной памяти, дополнительных накладных расходов их перенос в СВМ не создавал.
Вполне себе эффективно и красиво, и не только для человека. Компилятору тоже намного проще иметь дело с одинаковыми регистрами, а не с целой кучей, ни один из которых ни разу "общего назначения", как в 8086. Ну а что недостатки есть... Везде они есть, и среди 16-разрядных PDP-11 если и не лучшая, то одна из лучших -- а 8086 худшая вообще из всех, кажется.
Кстати говоря, не со всеми Вашими утверждениями в том посте я согласен. Например, что MOV меняет флаги, мне как раз нравилось, и я нередко этим пользовался. Хотя, конечно, 32-разрядный ARM в этом плане больше свободы даёт: там половина команд может изменять флаги, а может не изменять в зависимости от одного битика в коде команды.
Вот насчёт ADC/SBC спорить глупо -- но им банально не хватало разрядности команды, как не хватило и на полноценную адресацию для XOR.
А вот тамошний MMU вполне себе эффективен и очень прост в железе -- тоже немаловажная деталь. Не удивлюсь, если деление адресного пространства на 8 страниц по 8 Кбайт пошло из технических соображений: уже были быстрые статические ОЗУ организацией 16*4 бита, а соответственно, в четырёх микросхемах можно было реализовать 16 16-разрядных регистров -- по 8 для режимов пользователя и ядра (режим супервизора впендюрили уже позже и непонятно зачем). Делать "полноценную" систему с таблицами переадресации в памяти, как, например, в Системе 370 -- по-моему, для 16-разрядной машины это уже архитектурное излишество, и выбранное решение было вполне эффективным, пусть и не совсем безупречным.
Ну а 8086 как замена iAPX432... Лишний раз доказывает, что руководство Интел -- идиоты. Во-первых, нельзя складывать все яйца в одну корзину. Во-вторых, нельзя делать "процессор для Ады", когда сама Ада ещё только разрабатывается, и стандарта на неё нет. А в-третьих, не надо обладать послезнанием, чтобы понимать: основными "кормильцами" на рынке являются достаточно простые микропроцессоры, пользующие массовым спросом (тот же 8080, при всех его уродствах, оказался очень популярен). То, что в короткий срок смогли что-то слепить, делает часть инженерам, непосредственно разрабатывавшим схемы, но отнюдь не архитекторам этого уродства и, тем более, не руководству компании.
Наоборот, это очень компактное представление. Код общий для всех типов дисков, все необходимые параметры (далеко не только адреса) -- как раз в блоках управления.
Вообще, если учить современный C++, то программы должны компилироваться любым современным компилятором. Есть, конечно, специфические вещи, завязанные на платформу, но это явно не для учебных целей.
Более того, модули, кроме как в современной VS, могут вполне себе не работать или работать плохо. Пробовал относительно недавно с ARMCLANG -- наткнулся на кучу типа ошибок, которых быть не должно (аналогичный код в VS компилировался без проблем). Сопрограммы работают, но IDE (Keil) подглючивает, особенно на отладке. Ну и т.д. и т.п. И, опять-таки, даже обучая современному, надо показывать и древности, объясняя, чем они хуже и почему с ними всё-таки, с приличной вероятностью, придётся встречаться на практике.
Ну, современный C++ начинается с C++11, и почти всё, внесённое в язык тогда, вполне себе актуально (хотя нередко и расширено). Так что как отправную точку вполне можно рассматривать именно его, а не C++17 -- конечно, с учётом обучения с нуля, а не расширения знаний тех, кто давно уже язык использует. В частности, при первоначальном обучении не обойтись без указателей, а значит, без nullptr вместо NULL -- а это как раз C++11. А вот говоря о типах, включённых в сам язык, нужно говорить и о char8_t -- а это C++20.
Ну а код будет разительно отличаться только при использовании новых крупных вещей, добавленных в C++20, -- скажем, модулей и сопрограмм. Если такое не используется (а при начальном обучении это практически неизбежно), особой разницы не будет.
Хотя исключить такую гипотезу нельзя, на 0/1/8/9 заканчивается целый склад команд -- скажем, LR и CR (18 и 19). Старшие четыре бита КОП эта проверка не смотрит, так что выделить конкретно SSK и ISK из всего формата RR она не может. Кроме того, в конечном итоге переход происходит по всему коду операции, и проверка на режим супервизора, надо полагать, выполняется в микропрограммах конкретных команд...
Производимая на территории СССР, на советском оборудовании и на советских материалах. Хотя, конечно, он (процессор) сам является отечественной элементной базой, а не производился на ней -- видимо, автор именно об этом хотел сказать.
Некоторые занимаются археологическими раскопками -- им древние окаменелости интересны, хотя вокруг действительно полно современных интересных вещей. Ну а кому древности не интересны, тот волен выбрать себе занятие (и чтение) по душе, оставив окаменелости другим.
"Знать наизусть на экзамене" -- это, конечно, глупость; если бы преподавал я, то требовал бы понимания принципов, а не запоминания всего этого (и, более того, не запрещал бы пользоваться справочниками: если студент что-то по мелочи забыл, ему поможет, ну а если реально не знает, препод всё равно поймёт это).
Ну а принципы... Если усвоил, как работает и как программировать КР580ВВ51, то сможешь разобраться с любым другим UARTтом; если понял, как ШИМить с помощью КР580ВИ53 -- сделаешь это и на любом другом таймере, ну и т.д. и т.п. Так что полезные знания можно было и на старье получить. Кроме того, Пентиумы в освоении именно этих вещей помогли бы мало: у ПК и у промышленных (микро)контроллеров разное назначение и разные функциональные возможности, и "переписать программы для современных процессоров" зачастую было невозможно: не подходили они для этих целей. Сейчас, конечно, программированию подобных вещей лучше учиться на каких-нибудь там STM32 или других популярных микроконтроллерах, но в 1990-х обучение на 8080 и его периферии -- вполне разумное решение.
Похоже на то; пошёл добавлю в текст.
ADD. Полума -- хорошо, а полтора -- лучше :)
Не переполнения как такового, а неверного размера операндов. У настоящего переполнения своя индикация.
Там все проверки, по большому счёту, выполняются микропрограммно, поэтому-то и странно. Никаких общих черт у этих особых случаев, кажется, нет, поэтому я и в недоумении...
Интересно, многие ли из читателей заметят без подсказок, в чём заключается крайнее расточительство при реализации БУР?.. :)
Вот тут Вы ошибаетесь: многопоточность именно в таком смысле была в OS/360 MFT с подзадачами и в OS/360 MVT, т. е. уже в конце 1960-х. Подзадачи в терминологии OS/360 -- это как раз потоки одного процесса, если использовать терминологию Винды (ну а задачей именовался головной поток).
Что такие резисторы были, я, конечно, знаю -- сам их в своё время использовал. Но я не уверен, что в микросборке использовали именно привычные резисторы, а не что-то специально изготовленное с габаритами поменьше. Самих этих микросборок я в глаза не видел и тем более не разламывал, поэтому просто процитировал написанное в книжке.
Можно ещё отметить, что критерий опубликовали в 1974, но IBM и без него всё сделала правильно с первого же раза (VM/370 -- 1971 год; железо, соответственно, проектировалось ещё раньше). А Интел и опубликованное, и уже широко используемое не помогло. Вероятно, чукча не читатель...
Никаких проблем с виртуализацией эти команды не создают.
Реально граница между микрокодом (микропрограммой) и схемным управлением не очень чёткая. Конечно, когда микропрограмма загружается в ОЗУ, как это было, скажем, на ЕС-1035 и ЕС-1045, сказать можно чётко: микропрограмма. Если она намертво зашита в ПЗУ, такое сказать уже сложней: не поменяешь же, не забравшись внутрь проца. А если на ПЛМ (вроде, так было сделано в нашей серии К1801)? Это, по большому счёту, уже не отличается от схемного управления, где управляющие сигналы вырабатывались логикой -- но за счёт более "стройной" структуры блока управления, не "размазанного" по 100500 триггерам, управляющим друг другом с помощью столько же "размазанной" логики, выглядит ближе к микропрограмме...
А уж сколько народу рубится во всякие КонтрСтрайки...
Ну, речь-то о том, что ИБМ всё сразу сделала принципиально правильно на уровне архитектуры, чем и дала возможность создания СВМ без какой-либо специальной аппаратной поддержки.
Кстати говоря, думаю, что тогда -- в 1970-х -- такая поддержка и не очень-то требовалась. Без неё будут временами сильно тормозить гостевые ОС с виртуальной памятью, но не стоит забывать, что множество пользователей мэйнфреймов IBM тогда ещё сидело либо на OS/360 MVT/MFT, либо вообще на DOS/360, и виртуализация позволяла им перенести на один мощный мэйнфрейм работу, которая раньше выполнялась на нескольких ранних слабых моделях. Ну а поскольку эти системы не имели своей виртуальной памяти, дополнительных накладных расходов их перенос в СВМ не создавал.
Вполне себе эффективно и красиво, и не только для человека. Компилятору тоже намного проще иметь дело с одинаковыми регистрами, а не с целой кучей, ни один из которых ни разу "общего назначения", как в 8086. Ну а что недостатки есть... Везде они есть, и среди 16-разрядных PDP-11 если и не лучшая, то одна из лучших -- а 8086 худшая вообще из всех, кажется.
Кстати говоря, не со всеми Вашими утверждениями в том посте я согласен. Например, что MOV меняет флаги, мне как раз нравилось, и я нередко этим пользовался. Хотя, конечно, 32-разрядный ARM в этом плане больше свободы даёт: там половина команд может изменять флаги, а может не изменять в зависимости от одного битика в коде команды.
Вот насчёт ADC/SBC спорить глупо -- но им банально не хватало разрядности команды, как не хватило и на полноценную адресацию для XOR.
А вот тамошний MMU вполне себе эффективен и очень прост в железе -- тоже немаловажная деталь. Не удивлюсь, если деление адресного пространства на 8 страниц по 8 Кбайт пошло из технических соображений: уже были быстрые статические ОЗУ организацией 16*4 бита, а соответственно, в четырёх микросхемах можно было реализовать 16 16-разрядных регистров -- по 8 для режимов пользователя и ядра (режим супервизора впендюрили уже позже и непонятно зачем). Делать "полноценную" систему с таблицами переадресации в памяти, как, например, в Системе 370 -- по-моему, для 16-разрядной машины это уже архитектурное излишество, и выбранное решение было вполне эффективным, пусть и не совсем безупречным.
Ну а 8086 как замена iAPX432... Лишний раз доказывает, что руководство Интел -- идиоты. Во-первых, нельзя складывать все яйца в одну корзину. Во-вторых, нельзя делать "процессор для Ады", когда сама Ада ещё только разрабатывается, и стандарта на неё нет. А в-третьих, не надо обладать послезнанием, чтобы понимать: основными "кормильцами" на рынке являются достаточно простые микропроцессоры, пользующие массовым спросом (тот же 8080, при всех его уродствах, оказался очень популярен). То, что в короткий срок смогли что-то слепить, делает часть инженерам, непосредственно разрабатывавшим схемы, но отнюдь не архитекторам этого уродства и, тем более, не руководству компании.
Наоборот, это очень компактное представление. Код общий для всех типов дисков, все необходимые параметры (далеко не только адреса) -- как раз в блоках управления.