Реклама:

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

Уровень архитектуры набора команд имеет особое значение: он является связующим звеном между программным и аппаратным обеспечением. Конечно, можно было бы сделать так, чтобы аппаратное обеспечение непосредственно выполняло программы, написанные на С, С++, Java или других языках высокого уровня, но это не очень хорошая идея. Преимущество компиляции перед интерпретацией было бы тогда потеряно. Кроме того, из чисто практических соображений компьютеры должны уметь выполнять программы, написанные на разных языках, а не только на одном.

В сущности, все разработчики считают, что нужно транслировать программы, написанные на различных языках высокого уровня, в некую общую для всех промежуточную форму - уровень архитектуры набора команд - и, соответственно, строить аппаратное обеспечение, которое сможет непосредственно выполнять программы этого уровня. Уровень архитектуры набора команд связывает компиляторы и аппаратное обеспечение. Это язык, который понятен и компиляторам, и устройствам. На рис. 5.1 показана взаимосвязь компиляторов, уровня архитектуры набора команд и аппаратного обеспечения.

Глава 5. Уровень архитектуры набора команд

Рис. 5.1. Уровень архитектуры набора команд - это промежуточное звено между компиляторами и аппаратным обеспечением

В идеале при создании новой машины разработчики архитектуры команд должны консультироваться с разработчиками и компиляторов, и аппаратуры, чтобы выяснить, какими особенностями должен обладать подведомственный им уровень. Если разработчики компилятора потребуют какого-то свойства, которое инженеры не смогут реализовать, то такая идея не пройдет. Точно так же, если разработчики аппаратного обеспечения захотят ввести в компьютер какой-либо новый элемент, но программисты не смогут написать поддерживающую его программу, такой проект никогда не воплотится. Реализуемый в конечном итоге уровень архитектуры набора команд, оптимизированный для нужных языков программирования, всегда является плодом долгих обсуждений и моделирования.

Но все это в теории. А теперь перейдем к суровой реальности. Когда появляется новая машина, первый вопрос, который задают все потенциальные покупатели: "Совместима ли машина с предыдущими версиями?" Второй вопрос: "Можно ли запустить на ней прежнюю операционную систему?" И третий вопрос: "Будут ли работать на этой машине прежние приложения и не потребуется ли заменять их новыми версиями?" Если ответ на любой из этих вопросов оказывается отрицательным, разработчики должны объяснить, почему. Покупатели вряд ли захотят выбросить свои любимые программы, чтобы начать все заново.

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

Все сказанное вовсе не принижает значимость уровня архитектуры набора команд. Качественный уровень архитектуры набора команд чрезвычайно важен, особенно в отношении вычислительных возможностей и стоимости. Производительность эквивалентных машин с разными уровнями архитектуры набора команд может различаться на 25 %. Мы просто хотим сказать, что рынок в определенной степени затрудняет переход от старой архитектуры команд к новой. Тем не менее иногда появляются новые уровни команд универсального назначения, а на специализированных рынках (например, на рынке встроенных систем или на рынке мультимедийных процессоров) они возникают гораздо чаще. Следовательно, важно понимать принципы работы этого уровня.

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

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

Вопросы и задания4 || Оглавление || Общий обзор уровня архитектуры набора команд5