Я немного запутался между уровнем микропрограммирования и уровнем машинного языка. Например:
- Где находятся оба типа программ во время выполнения?
- Есть ли у 1: 1 сопоставление с инструкциями true-op языка ассемблера?
- Формат любого из них определяется архитектурой процессора?
Ответы:
Микрокод - это еще один уровень абстракции, помимо машинного кода. Фактический процессор выполняет микрокод, а механизм перевода на лету преобразует машинный код в микрокод. Это делается по ряду причин, включая более быстрые, более мелкие процессоры, упрощение создания сложного процессора с меньшим количеством отладок и обратную совместимость. Например, набор команд x86 содержит некоторые инструкции по обработке строк, которые используются редко. Однако для обеспечения обратной совместимости они должны быть доступны в современных процессорах x86. Вместо того, чтобы фиксировать путь выполнения для этих инструкций, они преобразуются в микрокод и выполняются. Это экономит кремний, оставаясь при этом обратно совместимым.
Машинный код находится в кеше (после извлечения из ОЗУ). Микрокод находится в кеше микрокода, в зависимости от конкретной архитектуры машины. Кэш может быть достаточно большим, чтобы вместить достаточное количество микрокода для хранения преобразованного микрокода из максимально возможной инструкции машинного кода, или это может быть больший кэш, в котором хранятся преобразованные результаты многих машинных кодов, так что ему не нужно повторно преобразовывать все машинный код на каждой итерации для маленьких циклов.
В некоторых архитектурах преобразованный микрокод нигде не хранится - модуль выборки / перевода просто выплевывает серию инструкций микрокода на основе текущего исполняемого машинного кода. В этом случае микрокод выполняется из какого-либо ПЗУ, а машинный код, по сути, является индексом в ПЗУ, указывая на последовательность инструкций микрокода, которые необходимо выполнить, чтобы полностью выполнить инструкцию машинного кода.
Машинный код и код сборки, как правило, соответствуют 1: 1 инструкциям по сборке. Это зависит от ассемблера. Ассемблеры высокого уровня могут иметь большой набор макросов, которые позволяют написать одну строку кода сборки, и ассемблер создаст несколько машинных кодов.
Но в целом «чистый» язык ассемблера может быть преобразован непосредственно в машинный код с помощью таблицы набора команд в руководстве процессора.
Я не уверен, что вы подразумеваете под «настоящими инструкциями». Возможно, вы можете объяснить ссылку.
Формат как машинного кода, так и микрокода определяется архитектурой процессора.
источник
По сути, микрокод расширяет ограниченный набор команд ЦП, чтобы содержать инструкции более высокого уровня, которые было бы громоздко реализовать на аппаратном уровне, но относительно легко построить с помощью существующих инструкций. Микрокод позволяет процессору с небольшим набором команд функционировать как процессор с большим набором команд.
Допустим, вы работаете с набором команд MARIE и хотели бы добавить Add x, y, но архитектура допускает только Add x (который просто добавляет то, что в настоящий момент находится в регистре к x), поэтому вы добавляете инструкцию микрокода:
Теперь, когда ваш код машинного языка говорит:
он ищет функцию ADD, которую вы добавили в ROM (ваш микрокод), и выполняет ее. Это здорово, потому что это увеличивает ваш набор инструкций, что позволяет получить более читаемый машинный код, и поскольку ваш микрокод хранится в ПЗУ, это также немного быстрее, чем вызовы LOAD и ADD из RAM.
Раньше я работал в компании, которая фактически писала микрокод для выполнения пользовательских измерений на очень высоких скоростях на своих старых системах. Тем не менее, благодаря достижениям в ПЛИС, они переключились на те, что намного быстрее (поскольку вы фактически реализуете «пользовательские инструкции» в оборудовании, а не в ПЗУ).
источник
Многие процессоры управляются конечным автоматом, чья последовательность перехода зависит от выполняемых инструкций. Микрокодовые «инструкции» часто определяют взаимодействия между различными регистрами и шинами таким образом, который не будет виден программисту.
Например, инструкция микрокода для 8-разрядного ЦП в состоянии # 1 может указывать, что активация вывода для обеих половин программного счетчика должна быть активной (что приводит к выводу программного счетчика на верхнюю и нижнюю внутреннюю адресную шину), должен быть активен сигнал увеличения счетчика программ, должны быть активны сигналы защелки внешнего адреса (чтобы внешняя адресная шина отслеживала внутреннюю), а сигнал чтения ОЗУ должен быть активным, и контроллер должен переключиться в состояние # 2.
В состоянии # 2 внешняя шина данных должна поступать на внутреннюю первичную шину данных, и должен быть загружен регистр команд, который читает с этой шины. Программный счетчик должен по-прежнему выводиться на обе половины адресной шины, и выдается еще одно чтение из ОЗУ. Биты 5-7 регистра команд должны быть загружены в биты 0-2 контроллера состояния, бит 3 регистра состояния должен быть установлен, если не установлены все биты 1-7 регистра команд и другие биты регистра состояния должно быть ясно, чистый результат будет следующим состоянием # 7- # 15.
Обратите внимание, что микрокод на самом деле не определен в терминах инструкций, а скорее в терминах комбинаций управляющих сигналов. Аппаратное обеспечение будет настроено не для того, чтобы разрешать универсальные инструкции в микрокоде, а для загрузки или вывода различных регистров с / на шины, на которых они установлены, или для соединения разных шин друг с другом и использования различных битов или их комбинаций для выберите разные состояния. Многие аспекты проекта будут жестко привязаны (например, коды операций FE и FF могут быть в особом корпусе, а не в микрокоде). Идея с микрокодом - не запускать программы, а заменить логику.
источник