Регистры статуса и управления. Исключительные ситуации

Ловушка (trap) — ситуация, при которой надо срочно выполнить код из другого места в памяти, невзирая на состояние процессора, а затем, возможно, продолжить со старого места. Ловушки распознаются аппаратно и в RISC-V бывают двух видов:

1. Исключение (exception) — возникает при выполнении некоторой инструкции в программе и требует дополнительных действий перед тем, как выполнить следующую инструкцию

   • Например, некорректное обращение к памяти, попытка выполнить несуществующую инструкцию, вызов ecall или ebreak и т. п.

2. Прерывание (interrupt) — возникает асинхронно в произвольный момент работы программы по инициативе внешнего устройства и требует дополнительных действий перед тем, как продолжить выполнять текущую инструкцию

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

RISC-V F: исключения FPU — «это другое™», они накапливаются в виде флагов в CSR-регистре fflags, и обрабатывать их надо явно.

В большинстве архитектур для обработки исключений и прерываний используется механизм ловушек (trap):

• Выполнение текущей программы немедленно приостанавливается
• Управление передаётся специальному обработчику
• После завершения работы обработчика выполнение продолжается с прежнего места

Характеристики ловушек

1. Собственные / несобственные. Обработчик выполняется тем же / иным окружением, что и прерванная программа.

   • Пример собственных ловушек: обработка исключений в RARS в плоской модели памяти, где ловушки обрабатываются «тем же самым процессором» в «той же самой памяти».

   • Несобственная ловушка: ecall под управлением операционной системы приводит к переключению в режим ядра, при этом код обработчика выполняется ядром ОС в другом контексте выполнения.

2. Внутренние / внешние. Обработчик внутренней ловушки вызывается в зависимости от состояния процессора, регистров и других свойств контекста выполнения / независимо от свойств контекста.

   • Внешние вызовы и обработчики ошибок (например при обращении к несуществующей памяти) — это внутренние (да!) ловушки.
   • Прерывание при получении данных с внешнего устройства или по таймеру — это внешняя ловушка, потому что состояние таймера или другого внешнего устройства никак не отражается в процессоре.

3. Синхронные / асинхронные. Обработчик вызывается синхронно по запросу со стороны выполняемой программы и с целью получить какой-то результат / по неведомой этой программе причине в неопределённый момент.

   • Пример синхронной ловушки — ecall (любой) и исключение.

   • Пример асинхронной ловушки — обработчик прерывания ввода/вывода.

4. Невидимые / видимые. Переход по ловушке и выполнение обработчика никак не затрагивают контекст выполняемой программы / явно изменяет в нём что-то.

   • В идеале программа не может узнать о том, что сработала невидимая ловушка. Невидимы: программная эмуляция неподдерживаемых инструкций, подгрузка существующих страниц виртуальной памяти, обработка прерываний в других процессах многозадачных систем и т. п. Разумеется, факт сработавшей ловушки можно попробовать угадать по косвенным признакам, например, по «мгновенному» скачку системного времени.

   • Видимы многие внешние вызовы, которые возвращают значения в регистрах a* и/или изменяют содержимое оперативной памяти вызвавшего их контекста.

5. Фатальные / штатные. Ловушка сработала потому, что выполнять программу больше нет возможности / чтобы выполнить некоторое действие.

   • Обработчик фатальной ловушки выполняет какие-то действия «напоследок» и скорее всего не передаст управления обратно в прерванный контекст. Например, попытка процесса обратиться к недоступной памяти фатальна для процесса, ловушка обрабатывается окружением, процесс останавливается, а ОС продолжает работу. Аналогичная ошибка в самом ядре ОС будет обработана ядром: выведется диагностика, после чего вообще вся система будет остановлена.

   • Таким образом, ошибка в запускаемом процессе фатальна для него, но штатна для запустившего его окружения. Пример штатной ловушки — внешний вызов

RARS:

• все ловушки видимые (кроме фатальных)

• несобственные: ecall, ebreak

• собственные: прерывания и некоторые исключения
• много исключений считаются фатальными

Режимы работы CPU или Башня косвенности

Ловушки — довольно общий механизм для «обработки событий в вычислительной системе». Можно, например, в спецификации потребовать, чтобы все ловушки были несобственные и невидимые — тогда описание ловушек не будет входит в архитектуру исполнителя программы, а только в архитектуру окружения (которое может быть каким угодно, например, программой на Java ☺).

Возможные аппаратные требования для реализации собственных ловушек:

• Определение типа и причины ловушки (как минимум должны где-то храниться)

  • Аппаратный разбор причины (например, вектор обработчиков вместо общего)

• Мгновенное переключение контекста (регистров, флагов, аппаратного стека, если таковой имеется, и т. п.),

  • сохранение и восстановление предыдущего контекста
  • (непонятно, сколько должно быть таких «запасных хранилищ» для контекста)

• Запрет и/или дисциплина обработки повторных ловушек (исключительных ситуаций внутри ловушки), возможно, специальный режим работы процессора

  • ⇒ в каких-то случаях проще знапретить обработку, чем заниматься сохраненем / восстановлением контекста
• Поддержка невидимости в рамках одной среды исполнения:
  • Тесно связано с многозадачностью: если есть аппаратная поддержка «задач», объявляем одну такую задачу «ядром», которое будет обрабатывать ловушки
  • ⇒ Т. н. «режим ядра» (kernel mode) VS «режим пользователя» (user mode)
    • теперь обработчики выполняются только ядром, в котором доступны т. н. «привилегированные инструкции»
    • а также обеспечение изоляции / ограничения доступа / разделения времени / …
• Конвейер, суперскалярность, многоядерность и т. п. усложнения архитектуры могут добавить сложности в этот процесс

RISC-V: Несколько спецификаций для разных режимов работы (ссылки ниже могут измениться после ратификации новых расширений/исправлений):

• Unprivileged Spec — user level

  • На сайте five-embeddev

• Privileged Spec — kernel level

  • На сайте five-embeddev

  • отдельно «machine level» — полный доступ, плоская модель памяти,

  • отдельно расширение H (hypervisor)(между Machine и Supervisor) — для управления окружениями, т. е. виртуализации

  • отдельно «supervisor level» — доступ, достаточный для организации виртуальной памяти всех процессов (собственно окружение)

В RARS мы работаем с плоской моделью памяти, наиболее близкий вариант — устаревшая версия User-level ISA 2.2

Блок счётчиков и регистров управления CSR

Подробнее про блок Control and Status Registers

• На five-embeddev

• Volume 2, Privileged Spec v. 20211203

Типичный процессор, если сильно упрощать, состоит из арифметико-логическтого устройства и устройства управления. АЛУ занимается вычислениями, УУ занимается интерпретацией команд, реагирует на изменение состояния процессора, а также само изменяет это состояние. Часть работы УУ не требует контроля со стороны, так как алгоритм задан заранее и не меняется. Но некоторые функции управления хочется сделать модифицируемыми (например, программно обрабатывать различные системные события).

Есть примерно три способа реализовать интерфейс управления процессором:

1. Придумать специальный управляющий сопроцессор (примерно как как FPU, но цель другая), разделить инструкции на обычные и инструкции управления. При этом появляются регистры управляющего сопроцессора, возможно, особенная память, действия внутри этого сопроцессора и т. п.
2. Отказаться от идеи отдельного сопроцессора, и для каждой функции управления ввести отдельную инструкцию в ISA.
3. Спланировать управляющий сопроцессор (или УУ) как устройство с заданной логикой работы, оставив в интерфейсе управления только специальные регистры. Тогда работа с этими регистрами со стороны ЦПУ общего назначения (чтение и запись) и будет приводить к изменению состояния и логики работы.

В RISC-V реализован этот третий подход — в спецификации определён т. н. «блок регистров управления и статуса»

• Всего регистров 4096 (номер CSR-регистра — 12 битов).
• Формат номера:
  • Старшие 2 бита (11:10) — доступ: RW (00, 01, 10) или RO (11)
  • Ещё 2 бита (9:8) — уровень: 00 - user, 01 — supervisor, 10 — hypervisor, 11 — machine
    • Например, обработка ловушек есть на всех уровнях

  • Standard/custom хитрая таблица

• Номера регистров — не «адреса»:
  • регистры нумеруются подряд: 0, 1, 2, 3 и т. п.
  • при этом занимают 32 или 64 разряда в зависимости от разрядности архитектуры

• Атомарные (это важно) R/W инструкции типа I

  • csrrw[i] — обмен значениями между регистром CSR и регистром общего назначения

    • csrrw регистр-приёмник, csr-регистр, регистр-источник

  • а также csrrs[i] / csrrc[i] включение/выключение битов

    • содержимое CSR-регистра заносится в приёмник
    • все равные 1 биты из источника выставляются в 1 в CSR-регистре (csrrs) или в 0 (csrrc)

• Если не хотим читать или писать, используем регистр zero

Инструкции для работы с регистрами управления

Псевдоинструкции (с использованием zero):

Обратите внимание на размер непосредственных значений. Их небольшая величина объясняется форматом команд работы с регистрами контроля и управления/статуса(CSR).

Если быть точным:

• 12-битная immediate-часть инструкции типа I занята номером регистра CSR

• ⇒ Для числа N в инструкции вида csrrwi регистр-приёмник, csr-регистр, N используется поле rs1 (регистр-источник), так что оно может быть только 5-битовое

  • См., например, дизайн регистра fcsr

Пример: во что раскладываются псевдоинструкции управления FPU:

0x00400000  0x00200293  addi x5,x0,2         1   li       t0 2
0x00400004  0x00229373  csrrw x6,2,x5        2   fsrm     t1 t0
0x00400008  0x00300e13  addi x28,x0,3        3   li       t3 3
0x0040000c  0xd00e71d3  fcvt.s.w f3,x28,dyn  4   fcvt.s.w ft3 t3
0x00400010  0x00700393  addi x7,x0,7         5   li       t2 7
0x00400014  0xd003f153  fcvt.s.w f2,x7,dyn   6   fcvt.s.w ft2 t2
0x00400018  0x183170d3  fdiv.s f1,f2,f3,dyn  7   fdiv.s   ft1 ft2 ft3
0x0040001c  0x003022f3  csrrs x5,3,x0        8   frcsr    t0
0x00400020  0x00202373  csrrs x6,2,x0        9   frrm     t1

• Регистры fflags (1) и frm (2) — это всего лишь биты регистра fcsr (3), изменения, сделанные в них, отражаются в fcsr, и наоборот.

• ⇒ запись в эти регистры имеет «непрямой эффект» (впрочем, для непрямого эффекта достаточно и того, что их значение изменяет поведение FPU)

CSR и управление

В RISC-V предусмотрена группа регистров только для чтения — регистров статуса (счётчиков). Поскольку в 11-10 битах номера у них 1, начинаются они с 0xc00, т. е. 3072. Все эти счётчики растут настолько быстро, что не помещаются в 32 разряда, поэтому на 32-разрядной архитектуре в разделе «опциональные (custom) регисты» к ним прибавляются парные для хранения старшего слова.

В RARS реализовано почти что шесть:

И запись, и чтение CSR-регистра могут привести к изменению работы CPU.

• Если состояние CPU однозначно соответствует содержимому CSR-регистра, и меняется, если записать туда определённые данные, это называется «непрямой эффект» (indirect effect), а побочным эффектом не считается

  • (я бы, конечно, назвал такой эффект прямым, но легаси есть легаси)

  • Например, появление некоторой комбинации значений на CSR-регистрах может вызывать ловушку: это однозначная зависимость от содержимого регистров, и, следовательно, непрямой эффект

• Если состояние CPU не может быть распознано на основании только содержимого CSR-регистра, но зависит и от самого факта чтения или записи, это «побочный эффект» (side effect)

Пример из документации:

1. Чтение из регистра зажигает лампочку, запись нечётного числа — гасит. Обе операции имеют побочный эффект (чтение не меняет CSR, но лампочка загорается; если в CSR уже было нечётное число и лампочка горела, запись в CSR того же самого числа её гасит)
2. Запись в регистр чётного числа зажигает лампочку, нечётного — гасит. Обе операции имеют только непрямой эффект, но не побочный

Побочного эффекта по возможности следует избегать:

• В стандартном ISA чтение не должно иметь побочного эффекта

• В стандартном ISA запись может иметь документированный побочный эффект

• В расширении ISA обе операции могут иметь документированный побочный эффект при доступе к описанным в этом расширении нестандартным CSR-регистрам

• При использовании zero в качестве регистра источника или приёмника распознаётся ситуация «не было записи» и «не было чтения» соответственно, и гарантируется отсутствие побочных эффектов, если они у соответствующей операции были

Проблемы синхронизации (особенно при наличии hardware thread).

Обработка исключений в RARS

Исключение — это синхронная ловушка на конкретной инструкции

• Возникает, когда инструкцию нельзя выполнить штатно, и требуются дополнительные действия

• Может быть как собственная (обрабатывается в той же среде), так и несобственная (обрабатывается во внешнем окружении)

• После обработки исключения управление надо передать на инструкцию, следующую сразу после прерванной (во избежание повторного исключения)

  • Нередко (например, обрабатывая ядром некорректные действия пользовательской программы) возвращать управление не адо вовсе, а надо ругаться и всё останавливать

Поддержка ловушек в RARS достаточно далека от стандарта:

• Не соответствует в точности никакой спецификации (прочем, спецификация на плоскую модель памяти для малых устройств только в начале разработки)
• Местами реализована по принципу «как получилось»
• Полностью отсутствует разделение прав доступа

Вы будете смеяться, но это абсолютно обычная ситуация для практически любого «железа» тоже.

Управляющие регистры RARS:

В «большом RISC-V» есть симметричные регистры для других режимов работы процессора (supervisor, hypervisor, machine), а для user — нет. Было т. н. «расширение N», но его перестали развивать. Если процессор совсем простой, скорее всего он работает на уровне Machine, а если он поддерживает несколько уровней, исключения удобнее обрабатывать уровнем выше.

Обработчик исключений

CSR регистр ustatus(0):

• User Previous IE - устанавливается автоматически при входе в ловушку; предотвращает повторный вход.

  • (нажмите «Комментарии» в шапке страницы, чтобы прочитать комментарии от COKPOWEHEU) Там интереснее. Это именно флаг, были ли разрешены прерывания до входа в обработчик. И оттуда же значение будет восстановлено в UIE при выходе. По идее, это должно срабатывать для немаскируемых прерываний. А также чтобы прерывание могло запретить последующие прерывания. То есть чтобы после завершения обработчика UIE оказался сброшен. А еще в этом же регистре (точнее, mstatus) хранится уровень привилегий, с которого мы попали в прерывание. Опять-таки, чтобы можно было вернуться именно с теми правами, с которыми в прерывание попали. А еще именно этот регистр используется чтобы ядро могло понизить привилегии после стартапа. Оно выставляет MPP в user-mode и вместо call main делает mepc=main; mret.

• User Interrupt enable - глобальное разрешение ловушек (0 - отключить, 1 — включить).
• когда происходит вход в ловушку:
  • бит 0 сбрасывается в 0
  • бит 4 устанавливается в 1
• когда происходит выход из ловушки, восстанавливаются предыдущее значение

В регистре CSR ucause (0x42, 42, Карл) отображается номер ловушки и её тип (прерывание или исключение):

Номера исключений (cause) RARS:

0. INSTRUCTION_ADDR_MISALIGNED
1. INSTRUCTION_ACCESS_FAULT
2. ILLEGAL_INSTRUCTION

3. BREAKPOINT (<!> в RARS ebreak обрабатывается окружением)

4. LOAD_ADDRESS_MISALIGNED
5. LOAD_ACCESS_FAULT
6. STORE_ADDRESS_MISALIGNED
7. STORE_ACCESS_FAULT
8. ENVIRONMENT_CALL (в «больших» архитектурах это значение соответствует уровню, на котором произошёл вызов: 8-Umode, 9-Smode, 10-Hmode, 11-Mmode)

Чтобы создать работающий обработчик исключений, следует:

• Записать в utvec адрес обработчика

  • Адрес кода всегда кратен 4, два младших бита имеют особое значение, но в RARS не используются

• Установить биты, соответствующие обрабатываемым исключениям в uie

• Установить в 1 бит разрешения прерывания (младший) в ustatus, чтобы включить обработчик

Дисциплина оформления обработчика:

• Можно рассчитывать на постоянное значение регистра uscratch и использовать его на своё усмотрение

• Перед выходом из обработчика необходимо восстановить значения всех регистров (включая t* и f*) для соблюдения «локальной невидимости». Исключение, а тем более — прерывание — может возникнуть когда угодно, а после возвращения ничего не должно меняться.

  • Для этого сразу после входа в ловушку необходимо где-то сохранить часть контекста, которую она испортит, а перед выходом — восстановить. Вот тут-то и понадобится uscratch.

• Вернуть управление программе с помощью инструкции uret.

  • В случае ловушки-прерывания это должен быть адрес прерванной инструкции

  • В случае ловушки-исключения это должен быть адрес инструкции, непосредственно следующей за прерванной, т. е. uepc+4

  • (на больших архитектурах есть также mret и sret для возврата на соответствующий уровень выполнения, а вот hret — нет; интересно, почему)

Дополнительная дисциплина для RARS:

• Разрешается задействовать пользовательский стек
  • Вот для чего нам строгая дисциплина «никакие данные не лежат за пределами стека»
• Разрешается использовать фиксированную область в качестве стека ловушек при условии, что её не попортит основная программа и её хватит для одного обработчика. Это возможно, т. к. повторный вход в ловушку запрещён.

В «больших» системах

• на каждом уровне выполнения свои регистры и своё адресное пространство, так что проблем со стеком нет

• при работе в плоской модели памяти предусматривается отдельный стек ядра (пользовательский стек может быть испорчен)

Пример тривиального обработчика, не соблюдающего конвенцию по сохранению контекста (пройти под отладчиком RARS):

   1 .text
   2         la      t0      handler
   3         csrrw   zero    5       t0      # Сохранение адреса обработчика ловушек в utvec (5)
   4         csrrsi  zero    0       1       # Разрешить обработку ловушек (бит 0 в регистре uststus (0)
   5         lw      t0      (zero)          # Попытка чтения по адресу 0
   6         li      a7      10
   7         ecall
   8 
   9 handler:
  10         csrrw   t0      65      zero    # В регистре uepc (65) — адрес инструкции, где произошло прерывание
  11         addi    t0      t0      4       # Добавим к этому адресу 4
  12         csrrw   zero    65      t0      # Запишем обратно в uepc
  13         uret                            # Продолжим работу программы

Пример обработчика исключений, чуть более близкого к жизни (как всегда, спасибо @COKPOWEHEU за идею):

• В нём соблюдается стандартная конвенция
• Эта конвенция дополняется следующим требованием:

  • CSR-регистр uscratch при входе в обработчик и при выходе из него должен содержать адрес стека ядра (проще всего этого достичь, единожды прописав туда нужный адрес)

• Это обработчик только исключений; ловушка и для прерываний, и для исключений одновременно должна быть сложнее: возврат из прерывания происходит не на следующую, а на ту же самую инструкцию.

• Помимо обработчика используется т. н. «код запуска» (bootstrap code) — фрагмент кода, которые выполняется перед запуском пользовательской программы; в нём-то и происходит инициализация uscratch и (особым образом) разрешение прерываний

   1 .macro  csrprint        %message %csrreg %end
   2 .data
   3 msg:    .asciz  %message
   4 .text
   5         la      a0 msg
   6         li      a7 4
   7         ecall
   8         li      a0 ' '
   9         li      a7 11
  10         ecall
  11         csrr    a0 %csrreg
  12         li      a7 34
  13         ecall
  14         li      a0 %end
  15         li      a7 11
  16         ecall
  17 .end_macro
  18 
  19 .text
  20 .globl main                     # Это код старта системы
  21 main:
  22         li      t0 0
  23         csrw    t0 uscratch     # Вершина ядерного стека 0 - 4 == 0xfffffffc
  24         la      t0 handler
  25         csrw    t0 utvec                # обработчик прерывания
  26   
  27         li      t0 0x10
  28         csrw    t0 ustatus      # UPIE=1, а PIE=0, т. е. прерывания «были разрешены», но пока запрещены
  29         la      t0 user_main
  30         csrw    t0 uepc         # начало программы пользователя
  31         uret                    # восстанавливаем разрешение прерываний и переходим к программе
  32   
  33 user_main:                      # Это пользовательский код
  34         csrprint        "CSR cycle" cycle '\n'  
  35         lw      t0 0(zero)      # Исключение по доступу к NULL
  36         csrprint        "CSR cycle" cycle '\n'  
  37         li a7, 10
  38         ecall
  39   
  40 handler:
  41         csrrw   sp uscratch, sp # стек ядра меняем местами со стеком пользователя
  42         addi    sp sp -8
  43         sw      a0 4(sp)
  44         sw      a7 0(sp)        # сохраняем регистры на стеке
  45 
  46         csrprint        "Exception" ucause ' '  
  47         csrprint        "at" uepc ' '
  48         csrprint        "value" utval '\n'
  49  
  50         csrr    a0 uepc
  51         addi    a0 a0 4
  52         csrw    a0 uepc         # исключение не фатальное
  53         lw      a7 0(sp)
  54         lw      a0 4(sp)        # Восстанавливаем регистры
  55         addi    sp sp 8         # Восстанавливаем стек ядра
  56         csrrw   sp uscratch sp  # Восстанавливаем пользовательский стек и сохраняем стек ядра
  57         uret

Несколько пояснений:

• Стек ядра в плоской модели памяти RARS проще всего разместить «с самого верха» — с адреса 0xfffffffc. Поскольку sp по конвенции указывает на (уже занятую) вершину стека, её смело можно приравнять к 0.

• Смысл стартового кода ещё и в том, чтобы сменить уровень выполнения
  • Если уровней больше одного при включении процессор обычно начинает работу на уровне Machine
  • Задача уровня Machine — загрузить ядро операционной системы и передать ему управление, например, на уровне Supervisor (уровень Hypervisor в RISC-V пока не стандартизирован)

  • Следовательно, наиболее логичное поведение — это настроить все CSR-регистры типа s* (у Machine есть на это права), указать предыдущий уровень выполнения (поле MPP регистра mstatus), как если бы мы оттуда попали в обработчик, и выполнить инструкцию mret

  • Этот mret переключит уровень выполнения на Supervisor (а там все регистры уже готовы!) и перейдёт по нужному адресу

• В RARS уровень выполнения единственный — User — и полей в ustatus намного меньше, чем в mstatus

Связь с внешним окружением

Функции окружения (ecall) входят в ту или иную конвенцию. Нередко возникает необходимость обменяться с окружением произвольными данными, специфичными для данного экземпляра окружения, локальных договорённостей и т. п. Для этого можно воспользоваться инструкцией ebreak, которая в обычном случае приводит к полной передаче управления окружению (это инструкция, которую отладчик вписывает в код, чтобы исполнение остановилось и можно было продолжать отладку).

К сожалению, эта инструкция не параметризуема. Специальная конвенция описывает, как оформить её с помощью псевдоинструкций NOP особого вида, чтобы намекнуть окружению: мы хотим не выпасть в отладчик, а запрашиваем специальное обслуживание. Такая технология называется «semihosting»

   1 slli x0, x0, 0x1f       # 0x01f01013    Entry NOP
   2 ebreak                  # 0x00100073    Break to debugger
   3 srai x0, x0, 7          # 0x40705013    NOP encoding the semihosting call number 7

Ещё одно отличие semihosting от ecall — окружению, к которому мы обращаемся, нет нужды уметь «перехватывать» различные инструкции (например, ecall). Использование ebreak гарантированно передаст управление отладчику, а тот в состоянии разобраться, что перед ним не просто ebreak, а «semihosting call number 7».

В RARS ebreak в любом контексте приводит к выходу в отладчик.

(Если успеем: HINT Instructions)

Вектор прерываний

Быстрый аппаратный вызов обработчика ловушки можно сделать с помощью т. н. «вектора прерываний» (в RARS не поддерживается).

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

Вариант с таблицей:

В RISC-V вполне может отсутствовать, потому что для эффективной реализации требуется одно из двух:

• Двойная косвенная адресация

• Непонятно где находящийся (аппаратный?) фрагмент кода, который будет считывать значения из ячейки, допустим, 0x80000108 и передавать управление на 0x800015b0

• Однако в небольших микроконтроллерах с плоской моделью памяти иногда делают так (хотя это и сложнее, чем схема, описанная ниже)

Поэтому в RISC-V вектор прерываний — это особый вид секции .text (кода!):

   1 .text.mtvec_table
   2         b  riscv_mtvec_exception
   3         b  riscv_mtvec_ssi
   4         b  riscv_mtvec_msi
   5         b  riscv_mtvec_sti
   6         b  riscv_mtvec_mti
   7         # и т. д.
   8 

• В примере показано начало таблицы прерывания для режима Machine Level

• Традиционно все исключения — это прерывание № 0 (векторизовать исключения обычно смысла нет)

• Места в памяти при этом занято столько же, сколько и в таблице адресов
• Код позиционно-независим (при условии, что обработчики загружены в одном адресном пространстве с вектором прерываний)

В RISC-V обработка ловушек вектором включается с помощью младшего бита CSR-регистра uvec (как часть адреса младший бит не имеет смысла, т. к. адрес инструкции обработчика кратен 4 даже в упакованном ISA).

Д/З

Домашнее задание будет на обработку исключений. К сожалению, в RARS самое интересное исключение — ввод ерунды вместо числа — пока (?) несобственное. Так что будем упражняться с несуществующими системными вызовами и обращением к несуществующей памяти. Имеет смысл заранее написать комплект макросов и библиотеки-обработчика исключений для домашних заданий

• Соблюдать конвенцию неприкосновенности регистров

• Аккуратно отлавливать случаи других исключений, в т. ч. попытки вызова других несуществующих ecall — в этом случае RARS должен сам это исключение обрабатывать. Я сделал так:

  1. Сбросил в ustatus сохранённый бит UPIE (не UIE) в 0

  2. Вышел из ловушки, не увеличивая uepc

  3. ⇒ выполнилась та же инструкция, но на этот раз в ustatus UIE оказался 0 (он туда приехал из только что занулённого UPIE), вместо ловушки сработал RARS

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

TODO

1. EJudge: UnCSR 'Несуществующий регистр'

   Написать обработчик исключения INSTRUCTION_ACCESS_FAULT, когда оно возникает в RARS при попытке обратиться к несуществующему CSR-регистру. Соответствующая инструкция при этом игнорируется и выполнение кода продолжается. Все остальные исключения, в том числе другие случаи INSTRUCTION_ACCESS_FAULT, должны считаться фатальными и приводить к останову программы с диагностикой «Exception №», где № — это десятичный номер исключения. К обработчику будет приписана такая проверяющая программа (TODO) и соответствующий проверочный код. Метка обработчика должна называться handler:.

   • Проверочный код для примера ниже:

     • TODO

   Input:

   10

   Output:

   10
   Exception 5

2. EJudge: SafeInt 'Ввод целого'

   Написать новый ecall 71 — «безопасный ввод целого». Этот ecall должен вводить строку, пропускать в ней лидирующие пробелы, а затем преобразовывать находящееся в ней число в десятичной записи в целое. Вызов должен возвращать количество обработанных цифр в a1, а само число — в a0. Если в начале строки строке не содержится целого числа, оба регистра нулевые. Задачу можно решить так: обработать исключение, проверить ucause на равенство ENVIRONMENT_CALL и содержимого a7 на равенство 71. Если возникло какое-то другое исключение или a7 не равен 71, немедленно завершать работу с диагностикой «Exception №», где № — номер исключения. К решению будет приписана такая проверяющая программа: (TODO)

   Input:

   123e4
    -3456
   no

   Output:

   123 3
   -3456 4
   0 0

3. EJudge: PseudoVM 'Псевдопамять'

   Создать обработчик исключений, имитирующий «виртуальную память» для любого «запрещённого» адреса — такого, чтение или запись машинного слова по которому приводило бы к LOAD_ACCESS_FAULT или STORE_ACCESS_FAULT. Исключение — адрес 0x00000000, он не поддерживается. Предлагается использовать таблицу вида «виртуальный» адрес:значение. Размер таблицы — 16 таких пар (т. е. 128 байтов). Можно использовать адрес 0 для обозначения пустой ячейки.

   • «Виртуальная память» работает только на операциях lw и sw с регистром t0 в качестве приёмника или источника соответственно (другие варианты не проверяются). Других исключений в тестах не будет.

   • Чтение по любому адресу работает так:
     • Если адрес уже есть в таблице, возвращается хранящееся там значение

     • Если адреса нет в таблице, возвращается 0

   • Запись по любому адресу работает так:
     • Если адрес уже есть в таблице, меняется его значение

     • Если адреса нет в таблице, но в ней есть свободная ячейка, сохраняется новая пара «виртуальный» адрес:значение

     • Если адреса нет в таблице, и таблица переполнена, не происходит ничего

   Это делается обработкой соответствующих двух исключений. Соблюдать конвенцию неприкосновенности регистров. К обработчику будет приписана следующая программа: PseudoVM.asm. Ввод и вывод полученной программы:

   Input:

   21
   123
   22
   1234
   20
   1001
   100500
   1000
   100
   -70001
   -70001
   -70000
   -70004
   0

   Output:

   1234
   100500
   0
   0
   -70001