Блог → Микропроцессор будущего: а может быть MISC? Часть 2

Итак, в первой части своей заметки о технологии микропроцессора будущего, я остановился на особенностях RISC и CISC архитектур, показав их достоинства и недостатки. Как вы могли сами убедиться, ни одна из них не идеальна, и вряд ли способна стать чем-то универсальным, применимым во всех областях. Что же следует из этого вывода? В-сущности, лишь одну вещь, что нужно не останавливаться, и продолжать искать дальше. Если вы не читали начало статьи, сделайте это сейчас, а для тех же, кто помнит на чём мы остановились - движемся дальше, и встречаем MISC!

Логическая структура MISC

Собственно микропроцессор должен состоять как минимум из двух частей (микросхем). Первая, основная, часть (host) – это RISC-процессор, но несколько расширенный так, что при подключении второй части, которая является практически исключительно ПЗУ микропрограммного управления, этот процессор превращается в CISC. Таким образом, выполнение 4-5 десятков команд, присущих обычно RISC-процессорам, возлагается на логику host-процессора, а любые команды, не принадлежащие к их числу, преобразуются в адрес соответствующей микропрограммы. В отсутствие ПЗУ MISC-процессор работает, как чистый RISC. Все команды исполняются им за один такт. При наличии же ПЗУ, он эквивалентен процессору со сложным набором команд, хотя 40…50 простых команд, характерных для RISC, по-прежнему выполняются не более чем за один такт.

Каковы же преймущества у такого подхода? Один из основных недостатков RISC-процессора заключается в том, что любой компилятор с языка высокого уровня вынужден фактически генерировать микрокод. Библиотеки стандартных функций (некоторые из них CISC-процессоры выполняют одной, хотя и сложной командой) для RISC-процессоров занимают много места в памяти. В предлагаемой архитектуре библиотеки функций располагаются в микропрограммном ПЗУ. Для команд микропрограммы не требуется время на выборку из системной памяти и дешифрацию, так как фактически - это уже дешифрованная последовательность RISC-команд, видимая программистом как единая CISC-команда.

Зафиксировав протокол взаимодействия host-процессора со своим ПЗУ или логическим устройством, а также со всеми сопроцессорами, можно получить реализацию процессора с открытой архитектурой, а это значит:
1. С развитием технологии появляется возможность практически неограниченно расширять набор команд/программ (движение к концепции CISC) при сохранении полной преемственности в отношении старого ПО, а также совершенствовать и оптимизировать уже созданные команды заменой только микросхемы ПЗУ.
2. В дальнейшем ПЗУ может быть заменено на логическое устройство (движение в сторону концепции RISC), которое, получая входной адрес от host-процессора, будет выполнять соответствующую стандартную функцию за меньшее по сравнению с микропрограммой число тактов, сильно увеличивая быстродействие при сохранении совместимости. В свою очередь, команды, не реализованные в таком логическом устройстве, могут быть отданы на исполнение следующему ПЗУ.
3. Для простых приложений, в которых необходимо быстрое выполнение небольшого набора простых логических команд, можно использовать только host-процессор.
4. С точки зрения технологии: выполнить ПЗУ микропрограмм на отдельном кристалле значительно проще, чем вместе со схемой процессора. В будущем, вероятно, можно сделать это ПЗУ перепрограммируемым; высвобождающееся от ПЗУ место на кристалле host-процессора (а в таком процессоре, как Intel 80386, ПЗУ занимает значительную часть площади кристалла) можно использовать для реализации более развитого регистрового файла, т.е. расширения набора регистров общего назначения, что характерно для RISC-процессоров. Некоторые из этих регистров могут использоваться для хранения промежуточных CISC-операций (такое использование регистров должно быть оговорено в описании архитектуры, так как из-за побочных эффектов могут возникнуть проблемы их совместимости).

Система команд

Формат команды MISC-процессора должен обеспечивать возможность реализации всех существующих режимов адресации и формирования новых. Сложность режимов адресации, как и самих команд, будет возрастать по мере увеличения длины команды. Рассмотрим пример построения системы команд MISC.

Для наиболее эффективной реализации, как самой системы команд, так и правил её расширения представляется наиболее целесообразной система команд, организованная в виде дерева. Корень дерева состоит из базисной системы команд (RISC-команды host-процессора), а также префиксов для вхождения в более сложные команды. На уровне базисной системы команд все команды однобайтовые. В случае набора из 63 команд возможны четыре режима адресации. При этом 64-я команда в различных режимах адресации резервируется как четыре префикса для входа в более сложные команды. Процесс исполнения такого префикса host-процессором заключается в дешифрации следующего за ним байта как адреса микропрограммы ПЗУ, а набор двухбайтовых команд (кодов операций) может состоять, например, из 127 команд в восьми режимах адресации, 128-ая команда резервируется под восемь префиксов трехбайтовых команд. Набор трехбайтовых команд будет состоять из 127 команд в 16 режимах адресации или из 255 команд в восьми режимах и т.д.

Для каждого из наборов команд (двух-, трехбайтовые и т.д.) необходима своя микросхема ПЗУ микропрограмм или логического устройства. Все они соединяются друг с другом цепочкой, так же как host-процессор с первым ПЗУ (см. рисунок А и Б), т.е. всякое логическое устройство (ЛУ), стоящее перед очередным ПЗУ, является для него host-процессором.

На рисунке ниже вы можете увидеть примеры простой (А) и расширенных (Б,В) конфигураций. ЛУ содержит реализации двухбайтовых команд, реализации трехбайтовых команд находятся в ПЗУ (Б) и системном ОЗУ (В).



Кроме того, один из наборов команд может быть сформирован в системной памяти компьютера с помощью специальных компиляторов или ассемблера. В этом случае вместо одного из ПЗУ или логического устройства устанавливается кэш-память микропрограмм (см. рисунок В), имеющая на входе шину данных, разрядностью соответствующую ширине шины данных вычислительной системы, в которой работает процессор (например 32 бит), а на выходе - слову микропрограммного управления (48…64 бит). Это необходимо, в основном, для процесса написания, отладки и оптимизации микропрограмм с целью последующей реализации в аппаратуре. Широкое использование данного режима ограничено высокой загрузкой шины. В такой конфигурации MISC-процессор становится похожим на WISC (Writable Instruction Set). В этом случае возможна более тонкая оптимизация программы, позволяющая достичь разумного компромисса между объемом памяти, занимаемым командами в виде слов микропрограммного управления (против обычной компактной формы), и скоростью исполнения программы.

Стек

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

Управление памятью

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

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