Какие два основных фактора следует учитывать при разработке архитектуры набора команд?
Я знаю, что такое ISA. Но какие факторы следует учитывать? Я уже просматривал Википедию, но это мало помогает.
Я обнаружил, что это проблемы с дизайном ISA.
Но это два фактора, которые меня немного смущают! Пожалуйста, помогите кому-нибудь! Подготовка к экзаменам по компьютерной организации и архитектуре
вы можете прочитать всю статью здесь Важность дизайна набора инструкций
В этой главе мы исследуем один из наиболее интересных и важных аспектов проектирования ЦП: структуру набора команд ЦП. Архитектура набора команд (или ISA) - одна из наиболее важных проблем проектирования, которую разработчик ЦП должен решить с самого начала. Такие функции, как кэширование, конвейерная обработка, суперскалярная реализация и т. Д., Могут быть привиты к проекту ЦП спустя долгое время после того, как исходный дизайн устареет. Однако очень сложно изменить инструкции, выполняемые ЦП, когда ЦП находится в рабочем состоянии, и люди пишут программное обеспечение, которое использует эти инструкции. Следовательно, нужно тщательно выбирать инструкции для ЦП.
У вас может возникнуть соблазн применить подход «кухонной раковины» к разработке набора инструкций1 и включить в свой набор инструкций столько инструкций, сколько вы можете придумать. Этот подход не работает по нескольким причинам, которые мы обсудим в следующих параграфах. Дизайн набора команд - это воплощение компромиссного управления. Хорошая конструкция ЦП - это процесс выбора того, что выбросить, а не что оставить. Достаточно легко сказать: «Давайте включим все». Сложнее всего решить, что не учитывать, если вы понимаете, что не можете положить все на карту.
Противная реальность №1: кремниевое имущество. Первая проблема с «размещением всего на кристалле» заключается в том, что для каждой функции требуется определенное количество транзисторов на кремниевом кристалле ЦП. Разработчики ЦП работают с «кремниевым бюджетом» и получают для работы конечное число транзисторов. Это означает, что транзисторов недостаточно для поддержки «размещения всех функций» на ЦП. Например, оригинальный процессор 8086 имел транзисторный бюджет менее 30 000 транзисторов. Бюджет процессора Pentium III составлял более восьми миллионов транзисторов. Эти два бюджета отражают различия в полупроводниковой технологии в 1978 и 1998 гг.
Противная реальность №2: Стоимость. Хотя сегодня можно использовать миллионы транзисторов в ЦП, чем больше транзисторов вы используете, тем дороже ЦП. Например, процессоры Pentium IV стоили сотни долларов (около 2002 г.). ЦП всего с 30 000 транзисторов (тоже примерно в 2002 г.) будет стоить всего несколько долларов. Для недорогих систем может быть более важным избавиться от некоторых функций и использовать меньше транзисторов, что снизит стоимость ЦП.
Противная реальность №3: расширяемость. Одна из проблем подхода «кухонная раковина» заключается в том, что очень трудно предвидеть все функции, которые потребуются людям. Например, были добавлены усовершенствованные инструкции Intel MMX и SIMD, чтобы сделать мультимедийное программирование более практичным на процессоре Pentium. Еще в 1978 году мало кто мог предположить, что эти инструкции понадобятся.
Противная реальность №4: поддержка устаревших версий. Это почти полная противоположность расширяемости. Часто бывает так, что инструкция, которую разработчик ЦП считает важной, оказывается менее полезной, чем ожидалось. Например, инструкция LOOP на процессоре 80x86 практически не используется в современных высокопроизводительных программах. Инструкция 80x86 ENTER - еще один хороший пример. При проектировании ЦП с использованием подхода «кухонной раковины» часто обнаруживается, что программы почти никогда не используют некоторые из доступных инструкций. К сожалению, вы не можете легко удалить инструкции в более поздних версиях процессора, потому что это нарушит работу некоторых существующих программ, которые используют эти инструкции. Как правило, после добавления инструкции вы должны постоянно поддерживать ее в наборе инструкций. Если только очень мало программ используют инструкции (и вы готовы позволить им сломаться) или вы не можете автоматически имитировать инструкции в программном обеспечении, удаление инструкций является очень сложной задачей.
Противная реальность №4: сложность. Популярность нового процессора легко измерить по тому, сколько программного обеспечения для этого процессора пишут люди. Большинство проектов ЦП быстро умирают, потому что никто не пишет программное обеспечение специально для этого ЦП. Следовательно, разработчик ЦП должен учитывать программистов сборки и разработчиков компиляторов, которые будут использовать микросхему после внедрения. В то время как подход «кухонной раковины» может показаться привлекательным для таких программистов, правда в том, что никто не хочет изучать слишком сложную систему. Если ваш ЦП делает все под солнцем, это может понравиться тем, кто уже знаком с ЦП. Однако пожалей беднягу, которая не знает чип и вынуждена выучить все сразу.
У всех этих проблем с подходом «кухонная раковина» есть общее решение: для начала спроектируйте простой набор инструкций и оставьте место для дальнейшего расширения. Это одна из основных причин, по которой формат 80x86 оказался таким популярным и долговечным. Intel начала с относительно простого процессора и выяснила, как с годами расширить набор инструкций для включения новых функций.
