Нужна помощь с прерываниями

Нельзя. Они все равно генерятся, но не "доходят" до программы.

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

c80f120 -- "генерятся" -- битик в регистре устанавливается, но не доходят -- замаскированы. Все таймеры, начиная с Timer2 и выше.

Демагогия.

OP>> И что там в UNIX с прерываниями такого особого? >> Что там с прерываниями не знаю, а с сигналами -- бардак... AVM> Hет там никакого бардака - ты просто не разобрался.

Hет, просто ты пытаешься вставить свои две копейки там, где вставить по существу уже нечего. Проблемы широко известны уже много лет и описаны во многих источниках. Сигналы в Unix опасны и ненадёжны как русская рулетка. Для особо одарённых: речь про Unix, а не POSIX.

Ересь полнейшая. Сигнал совершенно асинхронное, относительно прерываемой программы, событие. Об этом в любом букваре пишется.

Да, я на тебя твит уже настроил и здесь.

Добрый день.

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

Добрый день.

Маскирование аппаратного прерывания дает 0 команд исполнения обработчика, т.е. 0 тактов на обработку. Маскирование программного прерывания - минимум команд, необходимый для определения того, что это прерывание замаскировано. А этот минимум включает в себя по крайней мере сохранение и восстановление программного счетчика, регистра флагов и минимум пару команд проверки состояния бита. Разница между программным и аппаратным прерываниями и их маскированием - налицо. Так понятно?

Истина. 8-)

Добрый день.

Это ты неподумавши ляпнул - ересь как раз ты несешь.

Однако всегда известно место программы, которое может послать сигнал.

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

Всегда так делай, когда сказать в защиту своего мнения нечего. 8-)

Hello, Andrew! Andrew V. Miheev wrote to Oleg Saharuk on 22 nov 2004 05:15:

DO>>> Прерывание - это вызов процедуры по аппаратно генерируемому DO>>> сигналу. DO>>> Юникс тут не причем.

AVM> А при чем тут сигналы юникса? Они совершенно другой механизм имеют AVM> и логический и программный.

В первом приближении на прерывания весьма похоже. Переписать таблицу векторов на свой обработчик, и по появлению сигнала его вызвать. А вообще - тема скатилась к демагогии. Я завязываю, оставаясь при своем мнении, чего и всем желаю:-)

With best regards, Oleg Saharuk.

Добрый день.

Это какую же оптику надо иметь, чтобы такое увидеть? 8-)

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

Мы про юникс? Если да, то там это делается передачей ядру адреса обработчика

- никакой таблицы векторов нет. За прием сигналов отвечает ядро системы и посылка некоторых сигналов процессу всегда обрабатывается ядром, т.е. никогда не перехватывается обработчиком процесса.

Это всегда пожалуйста.