Горячий возврат из подпрограммы

Некоторые инструкции или их сочетание мы называем горячими инструкциями. Почему горячие? Это такие инструкции,  которые не делают полезную работу и могут являться результатом программной ошибки. В предыдущей статье я рассказывал о  работе конвейера и упомянул что пример должен зациклиться, но не объяснил почему. Понять, почему пример должен зациклиться, а так же отладить инструкцию RETURN нам поможет следующий пример.

Засечка NOTCH перед инструкцией перехода послужит для сохранения адреса инструкции, следующей за инструкцией перехода, в регистр общего назначения R15. Т.е. в момент выполнения инструкции RETURN, в регистре R15 будет адрес возврата, указывающий на саму инструкцию возврата. В результате получается бесконечный цикл, состоящий из одной инструкции RETURN, возвращающейся на саму себя. Поскольку инструкция RETURN системы команд Эверест не использует стек. То программа зациклится выполняя инструкцию по адресу 0xff000004.

При моделировании это выглядит следующим образом:

На диаграмме видно что программа зациклилась начиная с седьмого такта — до останова или выключения питания она будет выполнять инструкцию RETURN. Вот такие ситуации мы и называем «горячими инструкциями».

Немного изменим тестовую программу, вставив другую «горячую инструкцию» — NOP перед инструкцией возврата.

И для теста сразу запустим его в симуляторе:

На этой диаграмме видна работа инструкции RETURN, которая возвращает выполнение на предшествующую ей инструкцию NOP.

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

Моделирование этого кода:

У этой диаграммы есть общее свойство с первой диаграммой — в процессе работы не изменяется счётчик команд и ядро циклично каждый такт выполняет одну и ту же инструкцию. Есть ли в этом смысл? Очевидно что такие ситуации являются ошибочными и ведут к бессмысленному потреблению энергии. В случае с инструкцией NOP мы не можем детектировать зацикливание, но если счётчик команд не меняется по сигналу подтверждения из устройства выборки инструкций, то это явное зацикливание в бесконечном цикле. Такую ситуацию довольно легко отловить с точки зрения схемотехники. Соответственно, следуя хакерским традициям, когда с помощью небольших изменений недостатки и проблемы превращаются в преимущества, мы решили использовать свойство некоторых инструкций не изменять счётчик команд как расширение системы команд. Таким образом решаются сразу две проблемы — исключаются ошибочные формы инструкций и появляется третий путь расширения системы команд.

Что дальше? Сейчас перед нашей командой стоит задача покрыть тестами и отладить все инструкции из системы команд «Эверест» версии 1 редакции 2. Следите за нашими новостями.