И насчёт "выключения" прерывания. Во-первых, их не выключают, а запрещают (да, придираюсь к терминам -- но от слишком вольного их использования возникают проблемы). А во-вторых, в любых ARMах М-профиля, в т.ч. в STM32, при входе в обработчик прерывания автоматом запрещаются прерывания с тем же и более низким (численно -- более высоким) приоритетом, а соответственно, до завершения данного обработчика прерывания они уже не могут быть обслужены. Это одна из причин, почему в обработчиках прерываний надо выполнять минимально необходимую работу, всё остальное перекладывая на код, выполняющийся "снаружи" (например, посредством механизма отложенной обработки, который использует Винда, а до неё использовала её "мамаша" -- VAX/VMS, а до этого -- её "бабка" -- RSX-11M, а наверняка и много какие другие системы).
volatile говорит про "неустойчивость" переменной, но не про тип памяти -- о нём компилятор вообще ничего не знает. Как правильно заметили, внутренняя память микроконтроллеров технически вся статическая, динамическая (SDRAM, например) может быть подключена только снаружи. Но этот самый volatile применим с тем же успехом и к оперативной памяти "сверхстатического" типа -- к ферритовой, которая сохраняет содержимое даже при выключении питания. Он -- просто указание компилятору, что при каждом обращении программы к переменной надо обращаться к переменной в памяти, а не полагаться на ранее прочитанное значение, лежащее в одном из регистров проца.
Вообще-то, блокирующий и неблокирующий ввод-вывод -- это извраты из Униха, а не из реальной жизни. Реальный ввод-вывод либо синхронный -- когда каждый байтик должен передать процессор, причём непрерывно опрашивая устройство, а соответственно, не имея возможности отвлечься на что-то другое, -- либо асинхронный, когда устройство либо само передаёт данные посредством DMA, либо дёргает-таки процессор, но через прерывания, а не удерживает его внимание непрерывно. Соответственно, при асинхронном вводе-выводе процессор работает в целом параллельно и независимо от работы устройства ввода-вывода.
Пы.Сы. Претензии -- к заголовку, ибо термины "блокирующий" и "неблокирующий" -- из Унихов-Линухов, но означают, скажем так, немного не то, что синхронный и асинхронный.
WinNT изначально была чисто 32-разрядной и разрабатывалась вообще отдельно, и её ноги растут из VAX/VMS, а у этой оси -- из RSX-11M (во всех трёх системах главным разработчиком был Дэвид Катлер; когда мне впервые драйвер под НТ 4 пришлось писать, я сильно удивлялся, как много там знакомого -- про Катлера я тогда ещё не знал, а вот с упомянутыми DECовскими системами был знаком; по сути, начинал как специалист с RSX-11M под советским названием ОС-РВ). OS/2 к ней отношение имеет весьма косвенное.
Во-первых, если под мэйнфреймами разуметь IBMовскую Систему 370 и позднейшие, то, хотя термин "сегмент" там использовался и используется, он означает совершенно не то, что в x86: всё плоское виртуальное адресное пространство делится на сегменты (либо 1 Мбайт, либо 64 Кбайта), а сегменты -- на страницы (либо 2, либо 4 Кбайта; почти всегда использовались сегменты в 64 Кбайта и страницы в 4 Кбайта, остальные комбинации могли не поддерживаться). Таблицы сегментов -- это просто верхний уровень таблиц переадресации (нижний -- таблицы страниц). У современных машин сверху добавили ещё до трёх уровней таблиц регионов, чтоб эффективно управлять 64-разрядным адресным пространством.
А во-вторых, MMU -- правда, в виде внешней микросхемы -- был предусмотрен, как минимум, в Z8000, а это -- ровесник 8086.
А это уже вопрос тонкой оптимизации под конкретную микроархитектуру, а не совместимости. Скорость работы, кстати, тоже далеко не везде важна -- хотя, конечно, есть задачи, где её всегда мало. Ну а если не очищать кэши и т.п. при переключении контекста, то всегда будет риск подобных уязвимостей независимо от архитектуры. Так что, в данном случае приходится выбирать между либо максимальной производительностью, либо потенциальным наличием уязвимостей.
Посмотрели, когда архитектуры появились, ну и написали. Как будто эти 40-47 лет для них не было приличных и популярных программ, и только-только сейчас стали появляться.
Почему ж? Эти проблемы не оказывают влияния на правильность выполнения программы, а соответственно, на переносимость между разными реализациями этой архитектуры. Если уязвимость закрыть (например, принудительно очищать кэши при прерываниях), программы как работали, так и будут работать. Таким образом, и реализация, допускающая эксплуатацию этой уязвимости, и реализация, её не имеющая, будут полностью совместимы между собой и удовлетворять требованиям, изложенным в описании архитектуры.
Ну, архитектура ARM предусматривать возможность цеплять сопроцессоры -- собсно, "юридически" FPU является именно сопроцессором. И, вроде как, никаких ограничений на сопроцессоры пользователя там не предусмотрено.
Если на архитектуру есть полноценная документация, описывающая кодирование и поведение всех команд, систему прерываний и т.д. и т.п., то никакой "пропасти" нет: что там написано на Верилоге, программистам совершенно без разницы. Если некоторая реализация не соответствует документации -- это бракованная реализация, и её надо исправлять, а не объявлять баги фичами, вот и всё.
А через дискеты вирусы, значит, заметно для пользователя проникали ? Вирусы на дискетах распространялись со скоростью свиста. Но дело даже не в этом, а в том, что само их существование было обусловлено ущербностью операционной системы MS-DOS.
Во-первых, через дискеты требовались определённые действия пользователя, "само по себе" ничего не распространялось (и при простом помещении в дисковод тоже). Во-вторых, очень часто распространялись вполне себе заметно -- скажем, увеличивались длины системных файлов (хотя это замечал, конечно, далеко не каждый пользователь). А в-третьих, МС ДОС изначально не предполагала какой-либо защиты и изначально была ориентирована на машины, не имеющие технических возможностей для организации защиты -- в отличие от Униха, который в принципе не жил на машинах без разделения режимов пользователя и ядра и без наличия MMU.
Может быть я увидел в Вас потенциал и пообщавшись со мной Вы завтра прямо с утра начнете сносить винду и переходить на OS/2 FreeBSD
Нет уж, спасибо, лучше Вы к нам. А если серьёзно, то, если и слезу с десятки на что-то не виндузовое, то на отечественную ось Линух: по причине её относительной массовости и т.д. и т.п. (хотя любые Унихи я, честно говоря, в гробу видал -- но мелкософт старается принудить меня перейти-таки на них).
Очень даже может. К сожалению подавляющее большинство людей легко управляемы и слабохарактерны.
Вот только управляемость и слабохарактерность -- вина/беда людей, а отнюдь не злобный оскал капитализма (или лично Билла Гейтса -- хотя он деятель тот ещё, конечно). Так что неправильно людские пороки валить на систему. Будет Линух столь же массовым -- будут те же самые проблемы с безопасностью (в конце концов, основная масса проникновения зловредов -- результат прямых действий пользователя, а не пороков системы как таковых; если мне на почту приходит письмо "вам начислено 100500 рублей от озона, идите и получите" -- и я иду и получаю, то кто ж мне виноват, что я получу не 100500 рублей, а 100500 проблем?)
Только вот с недавних пор в школах с младших классов начали рассказывать про безопаcность в интернете, в том числе и про компьютерные вирусы. К чему бы это ? Не уж то общество дожило и осознало, что беспечность и полный пофигизм привели нас к таким проблемам.
Скорей, говорить стали из-за всяких там групп смерти и прочей чернухи. И вряд ли это сильно поможет (и уж точно не поможет в плане борьбы со зловредами: криворуких и/или ленивых сисадминов кругом полно, хотя они-то, в силу своей профессии, осведомлены об угрозах).
Червь Морриса использовал баг в конфиге sendmail-а (достаточно было отключить режим отладки), его пофиксили моментально без перекомпиляции. Еще он использовал дефолтные и пустые пароли, тем самым показав беспечность пользователей и админов. А что нужно чтобы зафиксить баг в винде ? Ждать у моря погоды (ну то есть очередного KB) ?
А вот мне помнится, что он использовал переполнение буфера в какой-то из прикладных программ... Ну и пароли, да -- но пароли относятся уже к человеческому фактору, а не к достоинствам/недостаткам системы или к качеству её реализации (а вот переполнение буфера при качественной реализации невозможно).
И я тоже работаю без антивирусов, и никогда их не использовал. За 30+ лет на персоналках -- два случая заражения, оба таки да -- через дыры в Винде, и оба очень давно, во времена 2000-й. Так что она, конечно, вполне себе дырявая, но напоминаю про Морриса: Уних тоже дырявая.
Это уже технические детали. Если угодно, можно было бы сказать "зловред" без конкретизации, какой именно. Тут главное -- факт того, что Уних оказался ничуть не лучше защищённым, чем МС ДОС, в котором в принципе никакой защиты не предусматривалось.
Первые вирусы были написаны под MS-DOS и расползались отнюдь не по сетям, а по дискетам
Во-первых, первый вирус был написан для OS/360. Во-вторых, не находите, что распространение через дискеты -- более сложный способ, чем незаметно для пользователя по сети? А в-третьих, речь, вообще-то, была о том, что Уних -- отнюдь не гарантия некоей надёжности, стабильности и прочая.
Microsoft делает из своих пользователей полных олигофренов.
Ну, возможно, я уже стал олигофреном, только тогда зачем со мной дискутировать?
А если серьёзно, не может никакая корпорация сделать из умного человека дебила или наоборот. Вот человек сам себя отупить вполне может -- но это уж от него самого зависит.
Сначала продает им заведомо ущербный продукт, навешивая лапшу на уши и пуская пыль в глаза разными сивстелками-пределками и многократными переделками интерфейса
А что, Линух менее ущербный продукт? В ней даже асинхронного ввода-вывода не было, пока недавно IO_URING (если не ошибаюсь) не прикрутили; реализовать POSIX в полном объёме им религия не позволяет, вероятно. И там, кстати, тоже реклама из всех щелей, только не от корпорации, а от "сообщества" религиозных фанатиков. А интерфейсов целая куча -- но ни одного нормального, как по мне (хотя, возможно, это дело привычки и вкуса).
Подавляющее большинство пользователей винды свято верят в то, что установив антивирус и регулярно отчисляя за него они покупают себе безопасность
А причём здесь микрософт как таковая? Подавляющее большинство пользователей Винды близко не ИТ-профессионалы и даже не любители, а обычные домохозяйки, грубо говоря -- в отличие от Линуха и, тем более, от ОС/2, и требовать от широких народных масс тонкого понимания, что и как обстоит на самом деле... такое себе.
Разве это нормальное положение вещей ?
Это обычное положение вещей. Бессмысленно требовать от массового потребителя чего-либо быть профессионалом во всех тех областях, которые он потребляет.
Дык 60 FPS далеко не каждой программе нужно. Если обновления информации в окне нет, зачем дёргать? В непрерывном обновлении нуждаются почти все игры и все видеоплееры -- но, как правило, если такая программа активна, другие программы если и крутятся, то где-то в фоне, (почти) ничего на экран не выводя.
Реально же частота вызова ядра определяется не только скоростью формирования кадров, но и тем, какой объём памяти доступен или целесообразен для заполнения, прежде чем работу надо скармливать железу. Впрочем, это уже технические детали; в любом случае, при грамотном проектировании (с учётом уже накопленного за 30 лет опыта) можно весьма сильно уменьшить количество переключений контекста.
Пы.Сы. А в z/Architecture можно реализовывать клиент-серверное взаимодействие вообще без вмешательства ядра, не считая этапа инициализации клиента и сервера. В IA-32 это, в теории, тоже можно было сделать, пользуясь сегментами и шлюзами вызова, но на практике этим, считай, не пользовались, а сейчас и не сделаешь: в AMD64/Intel 64 сегменты выпилили, они для совместимости лишь в 16/32-разрядных режимах поддерживаются. Вот так дурная реализация испортила неплохую, в общем-то, идею.
И насчёт "выключения" прерывания. Во-первых, их не выключают, а запрещают (да, придираюсь к терминам -- но от слишком вольного их использования возникают проблемы). А во-вторых, в любых ARMах М-профиля, в т.ч. в STM32, при входе в обработчик прерывания автоматом запрещаются прерывания с тем же и более низким (численно -- более высоким) приоритетом, а соответственно, до завершения данного обработчика прерывания они уже не могут быть обслужены. Это одна из причин, почему в обработчиках прерываний надо выполнять минимально необходимую работу, всё остальное перекладывая на код, выполняющийся "снаружи" (например, посредством механизма отложенной обработки, который использует Винда, а до неё использовала её "мамаша" -- VAX/VMS, а до этого -- её "бабка" -- RSX-11M, а наверняка и много какие другие системы).
volatile говорит про "неустойчивость" переменной, но не про тип памяти -- о нём компилятор вообще ничего не знает. Как правильно заметили, внутренняя память микроконтроллеров технически вся статическая, динамическая (SDRAM, например) может быть подключена только снаружи. Но этот самый volatile применим с тем же успехом и к оперативной памяти "сверхстатического" типа -- к ферритовой, которая сохраняет содержимое даже при выключении питания. Он -- просто указание компилятору, что при каждом обращении программы к переменной надо обращаться к переменной в памяти, а не полагаться на ранее прочитанное значение, лежащее в одном из регистров проца.
Вообще-то, блокирующий и неблокирующий ввод-вывод -- это извраты из Униха, а не из реальной жизни. Реальный ввод-вывод либо синхронный -- когда каждый байтик должен передать процессор, причём непрерывно опрашивая устройство, а соответственно, не имея возможности отвлечься на что-то другое, -- либо асинхронный, когда устройство либо само передаёт данные посредством DMA, либо дёргает-таки процессор, но через прерывания, а не удерживает его внимание непрерывно. Соответственно, при асинхронном вводе-выводе процессор работает в целом параллельно и независимо от работы устройства ввода-вывода.
Пы.Сы. Претензии -- к заголовку, ибо термины "блокирующий" и "неблокирующий" -- из Унихов-Линухов, но означают, скажем так, немного не то, что синхронный и асинхронный.
WinNT изначально была чисто 32-разрядной и разрабатывалась вообще отдельно, и её ноги растут из VAX/VMS, а у этой оси -- из RSX-11M (во всех трёх системах главным разработчиком был Дэвид Катлер; когда мне впервые драйвер под НТ 4 пришлось писать, я сильно удивлялся, как много там знакомого -- про Катлера я тогда ещё не знал, а вот с упомянутыми DECовскими системами был знаком; по сути, начинал как специалист с RSX-11M под советским названием ОС-РВ). OS/2 к ней отношение имеет весьма косвенное.
Ну, не "сверх" (БСОДы временами бывали), но весьма устойчивой, да.
Во-первых, если под мэйнфреймами разуметь IBMовскую Систему 370 и позднейшие, то, хотя термин "сегмент" там использовался и используется, он означает совершенно не то, что в x86: всё плоское виртуальное адресное пространство делится на сегменты (либо 1 Мбайт, либо 64 Кбайта), а сегменты -- на страницы (либо 2, либо 4 Кбайта; почти всегда использовались сегменты в 64 Кбайта и страницы в 4 Кбайта, остальные комбинации могли не поддерживаться). Таблицы сегментов -- это просто верхний уровень таблиц переадресации (нижний -- таблицы страниц). У современных машин сверху добавили ещё до трёх уровней таблиц регионов, чтоб эффективно управлять 64-разрядным адресным пространством.
А во-вторых, MMU -- правда, в виде внешней микросхемы -- был предусмотрен, как минимум, в Z8000, а это -- ровесник 8086.
Кстати говоря, в русской литературе -- n-МОП и p-МОП, NMOS/PMOS -- буржуинское...
Самое ценное здесь -- ссылки на забугорные статьи.
А это уже вопрос тонкой оптимизации под конкретную микроархитектуру, а не совместимости. Скорость работы, кстати, тоже далеко не везде важна -- хотя, конечно, есть задачи, где её всегда мало. Ну а если не очищать кэши и т.п. при переключении контекста, то всегда будет риск подобных уязвимостей независимо от архитектуры. Так что, в данном случае приходится выбирать между либо максимальной производительностью, либо потенциальным наличием уязвимостей.
Посмотрели, когда архитектуры появились, ну и написали. Как будто эти 40-47 лет для них не было приличных и популярных программ, и только-только сейчас стали появляться.
Почему ж? Эти проблемы не оказывают влияния на правильность выполнения программы, а соответственно, на переносимость между разными реализациями этой архитектуры. Если уязвимость закрыть (например, принудительно очищать кэши при прерываниях), программы как работали, так и будут работать. Таким образом, и реализация, допускающая эксплуатацию этой уязвимости, и реализация, её не имеющая, будут полностью совместимы между собой и удовлетворять требованиям, изложенным в описании архитектуры.
Ну, архитектура ARM предусматривать возможность цеплять сопроцессоры -- собсно, "юридически" FPU является именно сопроцессором. И, вроде как, никаких ограничений на сопроцессоры пользователя там не предусмотрено.
Если на архитектуру есть полноценная документация, описывающая кодирование и поведение всех команд, систему прерываний и т.д. и т.п., то никакой "пропасти" нет: что там написано на Верилоге, программистам совершенно без разницы. Если некоторая реализация не соответствует документации -- это бракованная реализация, и её надо исправлять, а не объявлять баги фичами, вот и всё.
А зачем, если у меня к тырнетам подключены несколько компов и НАС с торентами?
Во-первых, через дискеты требовались определённые действия пользователя, "само по себе" ничего не распространялось (и при простом помещении в дисковод тоже). Во-вторых, очень часто распространялись вполне себе заметно -- скажем, увеличивались длины системных файлов (хотя это замечал, конечно, далеко не каждый пользователь). А в-третьих, МС ДОС изначально не предполагала какой-либо защиты и изначально была ориентирована на машины, не имеющие технических возможностей для организации защиты -- в отличие от Униха, который в принципе не жил на машинах без разделения режимов пользователя и ядра и без наличия MMU.
Нет уж, спасибо, лучше Вы к нам. А если серьёзно, то, если и слезу с десятки на что-то не виндузовое, то на
отечественную осьЛинух: по причине её относительной массовости и т.д. и т.п. (хотя любые Унихи я, честно говоря, в гробу видал -- но мелкософт старается принудить меня перейти-таки на них).Вот только управляемость и слабохарактерность -- вина/беда людей, а отнюдь не злобный оскал капитализма (или лично Билла Гейтса -- хотя он деятель тот ещё, конечно). Так что неправильно людские пороки валить на систему. Будет Линух столь же массовым -- будут те же самые проблемы с безопасностью (в конце концов, основная масса проникновения зловредов -- результат прямых действий пользователя, а не пороков системы как таковых; если мне на почту приходит письмо "вам начислено 100500 рублей от озона, идите и получите" -- и я иду и получаю, то кто ж мне виноват, что я получу не 100500 рублей, а 100500 проблем?)
Скорей, говорить стали из-за всяких там групп смерти и прочей чернухи. И вряд ли это сильно поможет (и уж точно не поможет в плане борьбы со зловредами: криворуких и/или ленивых сисадминов кругом полно, хотя они-то, в силу своей профессии, осведомлены об угрозах).
А вот мне помнится, что он использовал переполнение буфера в какой-то из прикладных программ... Ну и пароли, да -- но пароли относятся уже к человеческому фактору, а не к достоинствам/недостаткам системы или к качеству её реализации (а вот переполнение буфера при качественной реализации невозможно).
И я тоже работаю без антивирусов, и никогда их не использовал. За 30+ лет на персоналках -- два случая заражения, оба таки да -- через дыры в Винде, и оба очень давно, во времена 2000-й. Так что она, конечно, вполне себе дырявая, но напоминаю про Морриса: Уних тоже дырявая.
Это уже технические детали. Если угодно, можно было бы сказать "зловред" без конкретизации, какой именно. Тут главное -- факт того, что Уних оказался ничуть не лучше защищённым, чем МС ДОС, в котором в принципе никакой защиты не предусматривалось.
Во-первых, первый вирус был написан для OS/360. Во-вторых, не находите, что распространение через дискеты -- более сложный способ, чем незаметно для пользователя по сети? А в-третьих, речь, вообще-то, была о том, что Уних -- отнюдь не гарантия некоей надёжности, стабильности и прочая.
Ну, возможно, я уже стал олигофреном, только тогда зачем со мной дискутировать?
А если серьёзно, не может никакая корпорация сделать из умного человека дебила или наоборот. Вот человек сам себя отупить вполне может -- но это уж от него самого зависит.
А что, Линух менее ущербный продукт? В ней даже асинхронного ввода-вывода не было, пока недавно IO_URING (если не ошибаюсь) не прикрутили; реализовать POSIX в полном объёме им религия не позволяет, вероятно. И там, кстати, тоже реклама из всех щелей, только не от корпорации, а от "сообщества" религиозных фанатиков. А интерфейсов целая куча -- но ни одного нормального, как по мне (хотя, возможно, это дело привычки и вкуса).
А причём здесь микрософт как таковая? Подавляющее большинство пользователей Винды близко не ИТ-профессионалы и даже не любители, а обычные домохозяйки, грубо говоря -- в отличие от Линуха и, тем более, от ОС/2, и требовать от широких народных масс тонкого понимания, что и как обстоит на самом деле... такое себе.
Это обычное положение вещей. Бессмысленно требовать от массового потребителя чего-либо быть профессионалом во всех тех областях, которые он потребляет.
Дык 60 FPS далеко не каждой программе нужно. Если обновления информации в окне нет, зачем дёргать? В непрерывном обновлении нуждаются почти все игры и все видеоплееры -- но, как правило, если такая программа активна, другие программы если и крутятся, то где-то в фоне, (почти) ничего на экран не выводя.
Реально же частота вызова ядра определяется не только скоростью формирования кадров, но и тем, какой объём памяти доступен или целесообразен для заполнения, прежде чем работу надо скармливать железу. Впрочем, это уже технические детали; в любом случае, при грамотном проектировании (с учётом уже накопленного за 30 лет опыта) можно весьма сильно уменьшить количество переключений контекста.
Пы.Сы. А в z/Architecture можно реализовывать клиент-серверное взаимодействие вообще без вмешательства ядра, не считая этапа инициализации клиента и сервера. В IA-32 это, в теории, тоже можно было сделать, пользуясь сегментами и шлюзами вызова, но на практике этим, считай, не пользовались, а сейчас и не сделаешь: в AMD64/Intel 64 сегменты выпилили, они для совместимости лишь в 16/32-разрядных режимах поддерживаются. Вот так дурная реализация испортила неплохую, в общем-то, идею.
Вот с этим полностью согласен.