Введение в архитектуру компьютеров

Архитектура как интерфейс между уровнями физической системы


Применительно к ВС термин "архитектура" может быть определен как распределение функций, выполняемых системой, по различным уровням и установление интерфейса между этими уровнями. На рис.1.4 представлен набор уровней абстракции как специфического свойства архитектуры ВС. Остановимся лишь на ключевых уровнях.

Рис. 1.4. Многоуровневая организация архитектуры

вычислительной системы

Архитектура первого уровня определяет, какие функции по обработке данных решаются системой, а какие передаются внешнему миру: пользователю, оператору ЭВМ, администратору баз данных и т. д. Система взаимодействует с внешним миром через два набора интерфейсов: языки (язык программирования, язык оператора терминала, язык управления заданиями, язык общения с базой данных, язык оператора ЭВМ) и системные программы (программы редактирования, связи, оптимизации, восстановления и обновления информации, интерпретации, управления и т. д., т. е. программы, созданные разработчиком системы). Оба интерфейса должны быть созданы при разработке архитектуры системы.



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

Уровень 5 является одним из центральных уровней архитектуры и проводит разграничение между системным программным и аппаратным (т. е. схемным и микропрограммным) обеспечением. Он позволяет представить физическую структуру системы независимо от способа реализации.

Остальные уровни отражают интерфейсы и распределяют функции между отдельными частями физической системы.

Таким образом, можно сказать, что архитектура компьютера – это абстрактное представление физической системы с точки зрения программиста.

Процесс разработки архитектуры ЭВМ включает все этапы разработки типовых проектов:


· анализ требований, предъявляемых к системе;

· составление спецификаций;

· изучение известных решений;

· разработку функциональной схемы;

· разработку структурной схемы;

· отладку проекта;

· оценку проекта.

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

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

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

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

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



И наконец – оценка проекта. Простая оценка быстродействия (которое иногда понимается как производительность) мало что определяет. Здесь необходимо учитывать время, затраченное на разработку программы. Используя известные статистические данные о том, что преобладающее количество разработанных программ выполняется только один раз, простота программирования при оценке архитектуры может оказаться важнее скорости выполнения команд.

Однако скорость выполнения операций – важный параметр. Быстродействие, естественно, зависит как от технологической элементной базы, влияющей на скорость обработки данных, так и от архитектуры машины, которая определяет объем выполняемых работ. Часто архитектуры сравниваются по критерию эффективности обработки информации. Для этого, как правило, анализируют следующие параметры:

S – размер программы, определяемый длиной команд, размером косвенных адресов, объемом рабочих областей для временного размещения

данных;

Np – количество битов, передаваемых между процессором и памятью машины (пересылка между регистрами) за время выполнения программы, характеризующее интерфейс, т. е. "полосу пропускания" между процессором и памятью, что в значительной степени определяет предел эффективности выполнения программ. Ясно, что параметр должен учитывать и локальность ссылок, т. е. близость расположения в памяти используемых данных;

NR – количество битов, передаваемых между внутренними регистрами процессора за время выполнения программы. Здесь учитываются те пересылки, которые не охватывает параметр Np. Значение NR в значительной части определяется набором функций, воплощенных в АЛУ и в схемной реализации процессора.

Иногда архитектуры сравнивают лишь по параметрам S и Np, исключая параметр NR, игнорируя тем самым внутренней организацией процессора.


Содержание раздела