Я начну с вашего примера с Windows RT, Windows RT — это порт Windows на архитектуру ARM. Это не «выделенная операционная система». Есть (вероятно) много ОС, которые работают только на одной архитектуре, но это скорее функция, которую нельзя портировать по какой-то причине.
Что на самом деле означает «порт»?
У Windows есть ядро (здесь мы будем называть его NT, не имеет значения), и в этом ядре NT есть множество концепций, которые необходимо реализовать. Этими концепциями являются такие вещи, как таймеры, виртуализация памяти, исключения и т. д.
Эти концепции реализуются по-разному в разных архитектурах, поэтому порт ядра и драйверов (здесь я буду игнорировать остальную часть ОС, часто это только перекомпиляция) будет зависеть от использования доступных кусочков кремния для реализации необходимых концепций. . Эта реализация называется «портом».
Давайте рассмотрим прерывания (исключения AKA) на ARM с FIQ и IRQ. В общем случае прерывание может происходить асинхронно, то есть в любое время. Процессор обычно чем-то занят, когда активируется IRQ, поэтому этот контекст (назовем его UserContext1) должен быть сохранен, прежде чем ЦП сможет использовать какие-либо ресурсы, используемые UserContext1. Обычно это означает сохранение регистров в стеке перед их использованием. На ARM, когда происходит IRQ, процессор переключается в режим IRQ. Регистры r13 и r14 имеют свою копию для режима IRQ, остальные нужно будет сохранить, если они будут использоваться - так и происходит. Эти сохранения в памяти занимают некоторое время. IRQ обрабатывается, UserContext1 извлекается из стека, после чего происходит выход из режима IRQ.
Таким образом, задержка в этом случае может быть временем от утверждения IRQ до момента начала выполнения вектора IRQ. Это будет некоторое установленное количество тактовых циклов, основанное на том, что делал ЦП, когда произошло IRQ. Задержка до того, как может произойти обработка IRQ, — это время от утверждения IRQ до момента, когда ЦП закончил сохранение контекста. Задержка перед выполнением кода пользовательского режима зависит от слишком большого количества вещей в ОС/ядре, чтобы объяснять их здесь, но минимум сводится к времени от утверждения IRQ до возврата после восстановления UserContext1 + время для переключения контекста ОС.
FIQ - Если вы упорный программист, вам может понадобиться всего 7 регистров, чтобы полностью справиться с обслуживанием прерываний. Я упомянул, что режим IRQ имеет собственную копию из 2 регистров, а режим FIQ имеет собственную копию из 7 регистров. Да, это 28 байтов контекста, которые не нужно выталкивать в стек (на самом деле один из них — это регистр ссылок, так что у вас действительно 6). Это может устранить необходимость сохранять UserContext1, а затем восстанавливать UserContext1. Таким образом, задержка может быть уменьшена до времени, необходимого для сохранения/восстановления.
Ничто из этого не имеет большого отношения к ОС. ОС может использовать или не использовать эти функции. ОС может дать гарантии относительно того, сколько времени потребуется для выполнения концепции обработчика прерываний ОС, а может и нет. Это одна из основных концепций RTOS, контракт о том, как долго будет запускаться обработчик. ОС предназначена для какой-то цели (и эта цель может быть «общей») — эта целевая цель дизайна будет иметь гораздо большее влияние на задержку, чем количество целей, на которые была перенесена ОС.
Идите и почитайте о чем-то вроде freertos, чем купите какое-нибудь оборудование и попробуйте. Аннотируйте код, чтобы определить задержки, на которые вы действительно хотите обратить внимание. ИТ, вероятно, будет лучшим способом обойти это.
(*Многопроцессорные системы делают то же самое, но с некоторыми функциями синхронизации и барьера, а также с небольшим количеством сложности)
person
SilverCode
schedule
21.10.2014
