Comments 11
Короче я программист никакой, и решил разобраться с преоываниями, ибо с детства слышал за них, видел эти IRQи в BIOS, но шо за чем было не понятно.
И вот решил я по мере прочтения сего опуса, обратиться за разъяснениями к Гроку:
Скрытый текст
Я: Прерывания в х86
Грок:
Прерывания в x86 — механизмы обработки событий, временно приостанавливающие выполнение программы. Делятся на:
Аппаратные (внешние): от устройств (IRQ), управляются контроллером прерываний (PIC/APIC).
Программные: вызываются инструкцией INT n (например, системные вызовы).
Исключения: ошибки процессора (деление на 0, страничные сбои).
Механизм работы:
Процессор получает сигнал прерывания.
Сохраняет состояние (регистры, флаги).
Переходит к обработчику из таблицы векторов прерываний (IDT).
Выполняет обработчик, затем восстанавливает состояние (IRET).
IDT (Interrupt Descriptor Table):
Хранит адреса обработчиков.
Настраивается ОС (регистр IDTR).
Примеры:
IRQ0: системный таймер.
INT 0x80: системный вызов в Linux.
Режимы:
Реальный: 16-бит, векторы в первых 1 КБ памяти.
Защищённый: 32/64-бит, использует IDT.
Я: Так эти IRQ (pic/apic) — это контроллер внутри процессора?
Грок:
Нет, IRQ (PIC/APIC) — это не контроллер внутри процессора.
PIC (Programmable Interrupt Controller, например, 8259) — отдельная микросхема или часть чипсета, управляющая аппаратными прерываниями от устройств, перенаправляя их процессору.
APIC (Advanced Programmable Interrupt Controller) — более современный контроллер, интегрированный в чипсет или процессор (в новых системах), поддерживает многопроцессорность и сложные схемы маршрутизации IRQ.
Процессор только получает сигналы от PIC/APIC через линии прерываний и обрабатывает их согласно IDT.
Я: Окей. А когда процессору нужно сделать программные прерывание ?
Грок:
Программные прерывания (вызываемые инструкцией INT n) нужны процессору, когда:
Системные вызовы: Программа запрашивает услуги ОС (например, INT 0x80 в Linux для доступа к ядру).
Отладка: Вызов INT 3 для точек останова.
Эмуляция: Обработка устаревших или специфичных инструкций (например, INT 0x2F в DOS).
Управление задачами: Переключение контекста или вызов подпрограмм в определённых ОС.
Они инициируются программно, а не внешними устройствами, для передачи управления ОС или обработчику в IDT.
Я: Да, но почему в Risc-v этим занимается процессор?
Грок:
В RISC-V процессор напрямую обрабатывает прерывания, так как архитектура не использует отдельный контроллер прерываний (PIC/APIC), как в x86.
Почему:
Простота архитектуры: RISC-V минимизирует внешние компоненты, перенося управление прерываниями в процессор (встроенный механизм CLINT/PLIC).
CLINT (Core-Local Interruptor): Обрабатывает локальные прерывания (таймеры, софт-прерывания) для каждого ядра.
PLIC (Platform-Level Interrupt Controller): Управляет внешними прерываниями, но интегрирован ближе к процессору и настраивается через его регистры.
Гибкость: Процессор через CSR (Control and Status Registers) напрямую управляет приоритетами, маскировкой и векторизацией прерываний.
В отличие от x86, где PIC/APIC — отдельные модули, RISC-V встраивает логику обработки в ядро, упрощая систему и снижая зависимость от внешних чипов.
Я: Но теперь в х86 через apic поишли к этому же?
Грок:
Да, в современных x86-системах с APIC (особенно Local APIC, интегрированным в процессор) архитектура приближается к модели RISC-V, где управление прерываниями частично встроено в процессор.
Как это работает:
Local APIC (в каждом ядре x86) обрабатывает локальные прерывания (таймеры, термические события, межпроцессорные прерывания — IPI).
I/O APIC (в чипсете) управляет внешними прерываниями от устройств, но передаёт их в Local APIC.
Процессор настраивает и приоритизирует прерывания через регистры APIC, что схоже с CSR в RISC-V.
Сходство с RISC-V:
Встроенная логика в процессоре (Local APIC vs CLINT/PLIC).
Гибкая маршрутизация и векторизация прерываний.
Отличия:
x86 сохраняет разделение на Local APIC и I/O APIC, тогда как RISC-V чаще использует единый PLIC.
x86 сложнее из-за обратной совместимости с PIC (8259).
Таким образом, x86 с APIC движется к интеграции управления прерываниями в процессор, но сохраняет более сложную структуру по сравнению с RISC-V.
Я: А почему так сложилось исторически с х86?
Грок:
Историческая сложность управления прерываниями в x86 обусловлена:
Эволюция архитектуры:
x86 начался с 8086 (1978), где использовался простой PIC 8259 для управления IRQ. Это был внешний чип, так как процессоры того времени были ограничены по функционалу.
Обратная совместимость заставляла сохранять поддержку старых механизмов (реальный режим, PIC) при добавлении новых (APIC в 1990-х).
Рост сложности систем:
С появлением многопроцессорных систем и сложных периферийных устройств PIC стал недостаточным (ограничение на 15 IRQ, отсутствие поддержки SMP).
Введён APIC (Local и I/O) для поддержки многопроцессорности, приоритизации и большего числа прерываний, но он дополнял, а не заменял PIC.
Экосистема IBM PC:
x86 развивался в тесной связи с IBM PC, где стандарты (как ISA, PCI) диктовали использование внешних контроллеров.
Это привело к разделению функций между процессором и чипсетом (включая I/O APIC).
Контраст с RISC-V:
RISC-V создавался позже, с нуля, для простоты и модульности, избегая исторического багажа.
x86 же обрастал новыми слоями (реальный режим → защищённый → 64-бит), сохраняя старые механизмы для совместимости.
Итог: x86 усложнял систему прерываний из-за необходимости поддержки старых стандартов и постепенной адаптации к новым требованиям, в отличие от более чистой и интегрированной модели RISC-V.
Я: Окей. А теперь опиши мне саму суть прерываний.
Грок:
Прерывания — механизм, позволяющий процессору реагировать на события, временно останавливая текущую программу.
Суть:
Событие: Внешнее (устройство, IRQ) или внутреннее (ошибка, программный вызов).
Реакция: Процессор сохраняет состояние (регистры, флаги), переходит к обработчику из таблицы векторов (IDT в x86), выполняет его, затем восстанавливает состояние.
Цель: Быстрая обработка событий (ввод/вывод, ошибки, системные вызовы) без постоянного опроса устройств.
Ключ: Перенос управления на нужный код (обработчик) с минимальной задержкой, обеспечивая многозадачность и реактивность системы.
Я: В каких случаях требуется прерывать ход выполнения программы и как он это понимает?
Грок:
Когда требуется прерывание:
Аппаратные события: Устройства (клавиатура, таймер, диск) сигнализируют через IRQ (например, ввод данных, завершение операции).
Исключения: Ошибки процессора (деление на 0, доступ к недопустимой памяти).
Программные вызовы: Программа инициирует INT n для системных функций (например, доступ к ОС).
Многозадачность: Переключение задач или таймер для распределения процессорного времени.
Как процессор понимает:
Сигнал: Аппаратное прерывание (IRQ) через контроллер (PIC/APIC) или программное (INT n) активирует линию прерывания.
Таблица векторов: Процессор смотрит в IDT (x86) или аналог (например, CSR в RISC-V), где хранятся адреса обработчиков.
Контекст: Сохраняет текущие регистры и флаги, переходит к обработчику.
Флаги: Проверяет регистр флагов (например, IF в x86) — если прерывания разрешены, реагирует.
Процессор реагирует автоматически, если событие имеет приоритет и прерывания не замаскированы.
Я: Зачем вообще они нужны в логике?
Грок:
Прерывания нужны в логике процессора для:
Реактивности: Быстрая реакция на внешние (устройства) или внутренние (ошибки, вызовы) события без опроса.
Многозадачности: Переключение между задачами, управление временем (таймеры).
Эффективности: Освобождение процессора от постоянной проверки устройств, позволяя выполнять программу до нужного события.
Обработки ошибок: Коррекция или завершение при сбоях (деление на 0, защита памяти).
Системные вызовы: Доступ программ к функциям ОС (файлы, сеть).
Логика: Прерывания позволяют процессору гибко управлять событиями, сохраняя производительность и порядок выполнения.
Я: Ну а почему вообще от них не избавиться?
Грок:
Избавиться от прерываний нельзя, потому что:
Реактивность: Без прерываний процессор должен постоянно опрашивать устройства (поллинг), тратя ресурсы и замедляя выполнение.
Многозадачность: Прерывания (таймеры) необходимы для переключения задач в ОС.
Обработка событий: Аппаратные (ввод/вывод) и программные (системные вызовы) события требуют немедленной реакции, что без прерываний невозможно.
Ошибки: Исключения (например, деление на 0) требуют немедленного вмешательства для стабильности.
Эффективность: Прерывания минимизируют ожидание, позволяя процессору работать, пока событие не произойдёт.
Итог: Без прерываний система теряет гибкость, производительность и способность реагировать на события в реальном времени.
Я: Реактивность: зачем ему постоянно опрашивать кого-то.
Давай на примере с загруженной игрой, где есть нажатия одной кнопки
Грок:
Реактивность и почему нужен опрос без прерываний:
В контексте игры с нажатием кнопки (например, пробел для прыжка):
Без прерываний (поллинг):
Процессор постоянно проверяет состояние кнопки (например, порт ввода-вывода) в цикле.
Пример: Игра каждые несколько миллисекунд читает регистр клавиатуры, чтобы узнать, нажат ли пробел.
Проблема:
Процессор тратит время на проверку, даже если кнопка не нажата.
Задержки в обработке других задач (графика, физика игры), так как цикл опроса занимает ресурсы.
Если опрос редкий, нажатие может быть пропущено или обработано с задержкой.
С прерываниями:
Клавиатура отправляет сигнал IRQ при нажатии пробела через контроллер (PIC/APIC).
Процессор мгновенно прерывает игру, сохраняет состояние, вызывает обработчик (например, “персонаж прыгает”), затем возвращается.
Преимущество:
Процессор не тратит время на опрос — работает над игрой (рендеринг, логика).
Реакция на нажатие моментальная, без задержек.
Эффективное использование ресурсов.
Итог: Прерывания избавляют от необходимости постоянного опроса клавиатуры, позволяя игре быть отзывчивой и одновременно выполнять другие задачи (графику, звук), не теряя производительность.
Я: Вот тут я и не понимаю. Чего ему постоянно опрашивать клаву, а не просто ждать сигнала, что кнопка нажата?
Грок:
Без прерываний процессор не может “просто ждать” сигнала от клавиатуры, потому что:
Нет механизма уведомления: Без прерываний процессор не знает, когда кнопка нажата, пока сам не проверит (опрос порта ввода-вывода).
Поллинг как единственный способ: В отсутствие прерываний процессору приходится в цикле читать состояние клавиатуры (например, регистр порта), чтобы заметить нажатие. Это и есть опрос — активная проверка, тратящая ресурсы.
Почему нельзя “ждать”:
Процессор не имеет встроенного пассивного режима ожидания конкретного сигнала без прерываний.
Без IRQ (сигнал от клавиатуры через контроллер) процессор не получает уведомлений о событиях.
Пример с игрой:
С прерываниями: Клавиатура посылает IRQ при нажатии кнопки, процессор мгновенно реагирует, вызывая обработчик (прыжок персонажа).
Без прерываний: Игра должна постоянно проверять порт клавиатуры (например, 1000 раз в секунду), чтобы поймать нажатие. Это нагружает процессор и замедляет другие задачи (графику, физику).
Итог: Прерывания позволяют процессору “ждать” сигнала пассивно, реагируя только при событии, вместо активного опроса, который тратит ресурсы и снижает отзывчивость.
Я: Так почему вы назвацте прерываниями, то что является уведомлением/сигналом по сути?
Грок:
Прерывания называют так, потому что они прерывают текущий ход выполнения программы:
Суть: Сигнал (аппаратный или программный) заставляет процессор остановить текущую задачу, сохранить состояние и перейти к обработчику.
Почему “прерывание”: Это не просто уведомление, а активное вмешательство в работу процессора, вынуждающее его временно бросить текущую программу.
Механизм: Сигнал (IRQ, исключение, INT n) инициирует переключение контекста, что буквально “разрывает” выполнение кода.
Термин “прерывание” отражает процесс принудительной паузы и переключения, а не просто получение сигнала.
Я: А понял. Прерывание рутин на поступающий вызов i/o
Грок: Точно! Прерывания — это когда процессор ставит текущую задачу (рутину) на паузу, чтобы обработать входящий сигнал ввода-вывода (I/O), вроде нажатия клавиши, и затем возвращается обратно.
Я: Офигеть, как запутано мы пришли к простому определению.
Грок: Хех, да, путь был тернистый, но суть проста: прерывания — это пауза программы для обработки срочного I/O-сигнала с возвратом назад.
От туда же я понял, что такое контекст в терминологии процессора и еще там что-то про регистры и прочее. Мило. И главное, что относительно быстро можно получить исчерпывающую информацию, не имея под руками толкового специалиста готового помочь в принципе или за так…
Погнали дальше читать статью))))
Сначала пойми, что не "от туда", а "оттуда". А про прерывания спроси у дедушки, он их весело юзал как только персональные компьютеры свалились нам на голову в конце 80х годов прошлого века.
Только не спутай "прерывания" с прерыванием беременности, ибо аборт и abort - таки две большие разницы.
Жду, когда уже наконец лопнет пузырь ИИ, чтобы перестать мило засорять ум доверчивых людей и интернет устаревшей и отчасти откровенно выдуманной информацией.
Исчерпывающую же информацию можно быстро и за так получить из замечательной инструкции к процессору. У RISC-V, кстати, документация достаточно лаконичная, можно хоть всю прочитать за несколько дней.
Я понимаю о чем вы и это нормально
Речь о том что генеративные претрансляторы могут генерировать очень правдоподобно выглядящие технические тексты. При этом эти тексты представляют из себя всего лишь набор "слов" собранный с помощью алгоритма на основе статистики и системы вероятностей. Именно поэтому когда вы скармливаете ему свои дополнительные вопросы или комментарии он слишком легко с вами соглашается и начинает сам себе противоречить. Тут наверное можно порекомендовать поизучать историю развития экспертных систем.
Как будто до ии этого не было
Изначально стоит обратить внимание на то что эта статья представляет из себя перевод другой статьи написанной на иностранном языке. Хоть Хабрахабр с самого начала и славился как источник гайдов для офисного планктона порой тут мелькают переводы серьёзных статей а также авторские статьи состоявшихся специалистов. Частенько тема бывает лучше раскрыта в комментариях к статье. А у нейросетей лучше выпытывать список литературы по интересующей теме с последующим изучением этой самой литературы.
Благодарю за консалт. Я тут с 2011 года, понимаю о чем Вы. По сабжу, к сожалению не все лишь здесь адекватно помогают, постоянно хейтят в карму, выбреживуют снобизном и прочие радости жизни..
Заминусили и, бог с ними нами вами. Я просто поделился радостью, похвастался по сути, что вопросы которые у меня возникали лет тридцать, я смог раскрыть даже в беглом неуклюжем общение с ботом.
По сути я инфантильно поделился с хабром своей маленькой радостью. Но хабр суровый. Да и бог с нами.
Спасибо за статью.
Пишем с нуля ядро операционной системы