Программные прерывания (SWI) - как?

M_K · Post by **M_K** » 09 Feb 2004 19:06

Такой вот вопрос - специалистам по разным BIOS-ам и прочему firmware.

Интересует, как реализуются программные прерывания - сам принцип.
Или ткните носом, где почитать в инете.

Спасибо.

CTAC_P · Post by **CTAC_P** » 09 Feb 2004 19:20

Та же самая подпрограмма, только вид сбоку. Вместо вызова подпрограммы MYPROG напрямую вы записываете ее адрес в таблицу векторов, а потом вызываете по номеру в этой таблице.

M_K · Post by **M_K** » 09 Feb 2004 19:50

Э-э, я, пожалуй, слишком обще/кратко спросил.

У меня есть хардварное прерывание, которое работает всегда (ну, если не маскировано), но на HWI есть вполне очевидное ограничение - нужно "отстреляться" как можно быстрее (и желательно за фиксированное кол-во тактов).

Для того, чтобы выполнить какие-то более комплексные действия (опять-таки, "поперек" основной процедуры), возможно, в более подходящий, но не слишком удаленный по времени момент, - я полагаю, что надо реализовать что-либо подобное механизму программных прерываний. Вот только не знаю, как. В железе какой-то явной поддержки SWI подобной HWI (типа регистров и т.п.) не предусмотрено, или я чего-то не понимаю.

CTAC_P · Post by **CTAC_P** » 09 Feb 2004 19:56

M_K wrote:Э-э, я, пожалуй, слишком обще/кратко спросил.

У меня есть хардварное прерывание, которое работает всегда (ну, если не маскировано), но на HWI есть вполне очевидное ограничение - нужно "отстреляться" как можно быстрее (и желательно за фиксированное кол-во тактов).

Для того, чтобы выполнить какие-то более комплексные действия (опять-таки, "поперек" основной процедуры), возможно, в более подходящий, но не слишком удаленный по времени момент, - я полагаю, что надо реализовать что-либо подобное механизму программных прерываний. Вот только не знаю, как. В железе какой-то явной поддержки SWI подобной HWI (типа регистров и т.п.) не предусмотрено, или я чего-то не понимаю.

Если я правильно понял, Вы хотите отложить обработку прерывания на более поздний срок?
Если знакомы с тредами, то создайте тред-обработчик и повесьте в нем ожидание сигнала. А сигнал посылайте из прерывания.

M_K · Post by **M_K** » 09 Feb 2004 20:20

CTAC_P wrote:Если я правильно понял, Вы хотите отложить обработку прерывания на более поздний срок?

Да, примерно так - например, до выхода основной процедуры из "критической секции".

Если знакомы с тредами, то создайте тред-обработчик и повесьте в нем ожидание сигнала. А сигнал посылайте из прерывания.

Проблема в том, что поддержки тредов по умолчанию нет и надо их как-то реализовать "с нуля", а я не совсем представляю, как это следует делать в real-time системах "по-правильному" - HWI от таймера? Или как-то еще?

CTAC_P · Post by **CTAC_P** » 09 Feb 2004 20:24

Т.е. операционки никакой нет совсем?
Ну тогда заведите флаг и взводите его в прерывании, а в основной программе следите за этим флагом.

M_K · Post by **M_K** » 09 Feb 2004 20:56

CTAC_P wrote:Т.е. операционки никакой нет совсем?

Дык, в том-то и дело - нет даже BIOS-а.

Ну тогда заведите флаг и взводите его в прерывании, а в основной программе следите за этим флагом.

Это, конечно, первое, что пришло мне в голову, но, к сожалению, это не очень удобно. Конечно, если не найдется более изящный способ - придется так и сделать...

CTAC_P · Post by **CTAC_P** » 09 Feb 2004 20:59

M_K wrote:
CTAC_P wrote:Т.е. операционки никакой нет совсем?

Дык, в том-то и дело - нет даже BIOS-а.
Ну тогда заведите флаг и взводите его в прерывании, а в основной программе следите за этим флагом.

Это, конечно, первое, что пришло мне в голову, но, к сожалению, это не очень удобно. Конечно, если не найдется более изящный способ - придется так и сделать...

Написать свою простенькую операционку. Самое простое когда треды сами друг другу передают управление и у всех приоритеты равные.

Tango · Post by **Tango** » 09 Feb 2004 21:04

CTAC_P wrote:Т.е. операционки никакой нет совсем?
Ну тогда заведите флаг и взводите его в прерывании, а в основной программе следите за этим флагом.

Так наверное самое простое будет сделать... если основная программа представляет собой периодический цикл где етот флаг можно проверять (типа, state machine). Иногда такого может не быть, тогда идея с SW interrupt, сгенерированного из HW interrupt обработчика может сработать. Но воплощение тут сильно зависит от платформы. А иногда можно прямо в обработчике HW interrupt выключить то что является критическим, и ограничевает время обработки (типа, enable interrupts, или что еще там держит critical/exclusive section...) Но, (а) ето очень похоже на SW interrupt, (б) потенциально может привести к куче проблем с новыми interrupt'ами, которые могут случится во время обработки ("nested" interrupts).

Короче, одного универсального решения наверное нет, зависит от вашей системы...

Strannik223 · Post by **Strannik223** » 09 Feb 2004 21:10

Отложенная обработка прерывания является распространенной практикой Делаете очередь и обработчик прерывания складывает туда информацию, это пару тактов и занимает
Далее надо определиться какие моменты времени являются подходящими для разгребания очереди
Вообще-то не биосное это дело, получается что то вроде мини операционки. Потоки, объекты синхронизации, очереди задач...

M_K · Post by **M_K** » 10 Feb 2004 11:19

Да, тут проблема еще такого рода, что в основном цикле дергается за хвост библиотечная ф-я, которая в некоторых случаях может исполняться дольше, чем период между прерываниями. Проверить флаг внутри этой ф-ии - нет никакой возможности. А выполнить процедурку надо до прихода следующего аппаратного прерывания. Так что, самым простым способом отделаться не удастся.

А все-таки, как обычно работают SW interrupts во всяких BIOS-ах?

Tango · Post by **Tango** » 10 Feb 2004 12:52

M_K wrote:Да, тут проблема еще такого рода, что в основном цикле дергается за хвост библиотечная ф-я, которая в некоторых случаях может исполняться дольше, чем период между прерываниями. Проверить флаг внутри этой ф-ии - нет никакой возможности. А выполнить процедурку надо до прихода следующего аппаратного прерывания. Так что, самым простым способом отделаться не удастся.

А все-таки, как обычно работают SW interrupts во всяких BIOS-ах?

Как СТАС_Р писал выше, SW interrupts это нечто очень похожее на простой function call (типа, call или jmp). Оснвные отличия: (1) адрес jump'a хранится в определенном (всем заранее известном) месте, (2) часто существует HW поддержка очереди (или счетчик) количества вызовов (но не всегда), так что interrupt handler может правильно обрабатывать multiple events, (3) часто (но опять не всегда) существует HW поддержка для всякого рода защит (например, SWI может выполняться в особой моде процессора, поетому ее нельзя bypass обычным function call. В результате, (в теории) существует только одно место входа в процедуру, где можно реализовыват' access control на OS уровне, итд).

Теперь, по сути вашего вопроса, если "процедурку" из HW interrupt обработчика выполнять не хочется, можно сделать так: (1) оформить "процедурку" как SW interrupt: написать обработчик и прописать его адрес в таблице векторов. Детали зависят от типа CPU, но, как правило, все очень похоже на обработку HW interrupt. Обратите внимание на правильное сохранение регистров и выход (возвращение) из обработчика. (2) Внутри SW interrupt обработчика первым делом надо разрешит'ь HW interrupts (если они запрещены), чтобы система могла обрабатывать ваши HW events. SW interrupts, как правило, будут (и должны быть) запрещены, чтобы новый HW event не сгенерил новый SW interrupt пока вы в его обрабатываете. (Тут также неплохо было проверить, сколько раз SW interrupt был вызван и правильно на это отреагировать). На самом деле, детали (деление на HW/SW interrupts, их приоритеты, маски запрещения, и тд) очень различны для разных CPU, так что детали могут отличаться для вас (Что там за платформа у вас то?

). (3) Из вашего HW interrupt обработчика вы вызываете (генерируете) ваш SW interrupt. Обычно это специальная CPU инструкция (int или swi, функционально типа call или jmp).

Ну вот наверное и все. Ваша система будет быстро обрабатывать HW interrupts немедленно по мере поступления, потом делать более длинные interrupt-triggered действия внутри SW interrupt, а в оставшееся время- крутить "основную" програму.

DMG · Post by **DMG** » 12 Feb 2004 15:31

M_K wrote:Да, тут проблема еще такого рода, что в основном цикле дергается за хвост библиотечная ф-я, которая в некоторых случаях может исполняться дольше, чем период между прерываниями. Проверить флаг внутри этой ф-ии - нет никакой возможности. А выполнить процедурку надо до прихода следующего аппаратного прерывания. Так что, самым простым способом отделаться не удастся.

А все-таки, как обычно работают SW interrupts во всяких BIOS-ах?

Sorry for English: no Russian kbd here.

You may want to learn how RSX-11 (RT-11) kernels were organized: these realtime (RT was "harder", RSX was "softer") kernels had a special hierarchy of priorities allowing for quick response to interrupts and doing their critical parts at non-interruptible level; lower priority was "forked" (delayed) interrupt processing: it might be only interrupted by HW interrupts themselves, but all forked interrupt processing was properly synchronized to use system resources (like dynamic memory - heap, system queues etc). (lower priorities were AST and regular aplication execution). Time constraints were more relaxed for delayed inerrupt processing. You need something like this.

In other words: your system may be in one of the two states: HW interrupt and SW (forked, delayed) interrupt processing. You also need a FIFO queue. Set up your interrupt vector so that upon entering the HWI handler, interrupts are disabled (or maybe enabled for higher HWI priorities). Upon completion of the "quick" non-interruptible part (like fetching data from the device that might be overwritten if not extracted timely eg a non-buffered serial line) see if the queue is empty. If it is then just enable interrupts and continue on (you are in SWI now). If the queue is not empty then create an element of that queue with continuation address and append it to the queue's tail. When you are done with your SWI processing for this HW interrupt inspect the queue. If it is empty (no other HWIs arrived while you were in SWI) then you may return to the application level (if any) or just halt the processor until the next HWI comes. If the queue is not empty then fetch the head element and jump to the continuation address.

Thus you may minimize the time when interrupts are completely disabled (you definitely need this also when manipulating the queue), and properly synchronize all SWI processing.

PS This is a rather simplified scheme (but may be sufficient for you needs); I omitted context save-restore when transitioning from HWI to SWI. I also omitted the I/O completion mechanism. But these are not that hard to figure out. You may want to read more about PDP kernels: dig through old computer publications.

And sources for RSX/RT kernels were available (to understand them, you need to learn the PDP assembly lang Macro-11, but it is much clearer and looks more pleasant than x86 asm).

PPS RSX/RT are "classics" now, but I doubt anybody designed anything significantly better since then.

A. Fig Lee · Post by **A. Fig Lee** » 12 Feb 2004 23:33

M_K wrote:Да, тут проблема еще такого рода, что в основном цикле дергается за хвост библиотечная ф-я, которая в некоторых случаях может исполняться дольше, чем период между прерываниями. Проверить флаг внутри этой ф-ии - нет никакой возможности. А выполнить процедурку надо до прихода следующего аппаратного прерывания. Так что, самым простым способом отделаться не удастся.

А все-таки, как обычно работают SW interrupts во всяких BIOS-ах?

Ето только название - на самом деле ето ничего больше чем обычная таблица для вызова подпрограмм. Единственное, что делает его общего с хардверными прерываниями - таблица переходов леххит в той же самой таблице с хардверными.
Идея бихайнд тхис я думаю - чтоб разные версии конкретно знали какое прерывание(функцию) вызывать и абстрагировались от имплементации и изменений в версиях.

Sergunka · Post by **Sergunka** » 13 Feb 2004 04:49

DMG wrote:PPS RSX/RT are "classics" now, but I doubt anybody designed anything significantly better since then.

Concur

Tango · Post by **Tango** » 13 Feb 2004 05:21

Sergunka wrote:
DMG wrote:PPS RSX/RT are "classics" now, but I doubt anybody designed anything significantly better since then.

Concur

Вы бы ему еще Solaris туда посадить присоветовали! (Шутка

)

А если серьезно, кстати RedHat'овский eCos имеет похожую имплементацию своего кернела.

И еще, мы так и не знаем что за железо у человека... Мы все "таблица да таблица (векторов)", а может там какой ARM с одним единственным SWI....

theukrainian · Post by **theukrainian** » 16 Feb 2004 09:06

M_K - а чем ваше упражнение с software interrupts закончилось, если не секрет?

спасибо,

денис

Tango · Post by **Tango** » 04 Mar 2004 20:53

theukrainian wrote:M_K - а чем ваше упражнение с software interrupts закончилось, если не секрет?

спасибо,

денис

...и вечное молчание было ему ответом.