Рис. 5.1. Уровень архитектуры набора команд — это промежуточное звено между компиляторами и аппаратным обеспечением
В идеале при создании новой машины разработчики архитектуры команд должны консультироваться с разработчиками и компиляторов, и аппаратуры, чтобы выяснить, какими особенностями должен обладать подведомственный им уровень. Если разработчики компилятора потребуют какого-то свойства, которое инженеры не смогут реализовать, то такая идея не пройдет. Точно так же, если разработчики аппаратного обеспечения захотят ввести в компьютер какой-либо новый элемент, но программисты не смогут написать поддерживающую его программу, такой проект никогда не воплотится. Реализуемый в конечном итоге уровень архитектуры набора команд, оптимизированный для нужных языков программирования, всегда является плодом долгих обсуждений и моделирования.
Но все это в теории. А теперь перейдем к суровой реальности. Когда появляется новая машина, первый вопрос, который задают все потенциальные покупатели: «Совместима ли машина с предыдущими версиями?» Второй вопрос: «Можно ли запустить на ней прежнюю операционную систему?» И третий вопрос: «Будут ли работать на этой машине прежние приложения и не потребуется ли заменять их новыми версиями?» Если ответ на любой из этих вопросов оказывается отрицательным, разработчики должны объяснить, почему. Покупатели вряд ли захотят выбросить свои любимые программы, чтобы начать все заново.
Этот факт заставляет производителей компьютеров поддерживать один и тот же уровень команд в разных моделях или, по крайней мере, делать его обратно совместимым. Под обратной совместимостью мы понимаем способность новой машины выполнять старые программы без изменений. В то же время новая машина может поддерживать новые команды и иметь другие особенности, используемые новым программным обеспечением. Разработчики должны делать уровень команд совместимым с предыдущими моделями, но они вправе как угодно менять аппаратное обеспечение, поскольку едва ли кого-нибудь из покупателей волнует, что собой в реальности представляют «внутренности» компьютера и что именно делает то или иное устройство. Разработчики могут переходить от микропрограмм к непосредственному использованию устройств, добавлять конвейеры, реализовывать суперскалярные схемы и т. п., но при условии, что они сохранят обратную совместимость с уровнем команд предыдущих моделей. Основная цель — убедиться, что старые программы работают на новой машине. То есть на первый план выходит задача не просто создания хороших машин, а создания хороших машин при условии их обратной совместимости.
Все сказанное вовсе не принижает значимость уровня архитектуры набора команд. Качественный уровень архитектуры набора команд чрезвычайно важен, особенно в отношении вычислительных возможностей и стоимости. Производительность эквивалентных машин с разными уровнями архитектуры набора команд может различаться на 25 %. Мы просто хотим сказать, что рынок в определенной степени затрудняет переход от старой архитектуры команд к новой. Тем не менее иногда появляются новые уровни команд универсального назначения, а на специализированных рынках (например, на рынке встроенных систем или на рынке мультимедийных процессоров) они возникают гораздо чаще. Следовательно, важно понимать принципы работы этого уровня.