АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Критерии разработки форматов команд

Читайте также:
  1. C) командной
  2. I. 1.1. Пример разработки модели задачи технического контроля
  3. III.4. Критерии оценки преступления. Вина
  4. XV. Сколачивание команды
  5. Адміністративно-командна система (АКС) – спосіб економічної ор-
  6. Аксиологический статус науки в системе культуры. Критерии разграничения научного и вненаучного знания.
  7. Актуальность разработки
  8. Алгебраические критерии устойчивости
  9. Алгебраические критерии устойчивости
  10. Алгоритм разработки урока
  11. Алгоритм роботи командирiв щодо попередження та подолання конфлiктних ситуацiй
  12. Алгоритмизация процесса разработки и принятия управленческого решения

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

 

Эффективность конкретной архитектуры команд зависит от технологии, которая применялась при разработке компьютера. За длительный период времени эта технология значительно изменится, и некоторые характеристики архитектуры команд окажутся (если оглянуться лет на 20 назад) неудачными. Например, если доступ к памяти осуществляется быстро, то подойдет стековая архитектура (как в IJVM), но если доступ к памяти медленный, тогда желательно иметь множество регистров (как в UltraSPARC III). Тем читателям, которые считают, что выбор сделать просто, мы предлагаем взять лист бумаги и записать следующие предположения:

 

+ Какова будет типичная частота тактового генератора через 20 лет?

+ Каково будет типичное время доступа к ОЗУ через 20 лет?

 

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

 

Даже дальновидные разработчики не всегда могут сделать правильный выбор. А если бы и смогли, то проработали бы недолго, поскольку если предлагаемая ими архитектура команд окажется дороже, чем у конкурентов, компания долго не продержится.

 

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

 

Более того, минимизация размера команд может усложнить их декодирование и перекрытие. Следовательно, стремление уменьшить размер команд должно уравновешиваться стремлением сократить время их декодирования и выполнения.

 

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

 

Если пропускная способность кэш-памяти команд составляет t бит/с, а средняя длина команды - г бит, то кэш-память способна передавать самое большее t/r команд в секунду. Отметим, что это - верхний предел скорости, с которой процессор может выполнять команды, хотя в настоящее время предпринимаются попытки преодолеть данный барьер. Ясно, что скорость, с которой могут выполняться команды (то есть быстродействие процессора), может ограничиваться длиной команд. Чем короче команды, тем быстрее работает процессор. Поскольку современные процессоры способны выполнять несколько команд за один цикл, то вызов нескольких команд за цикл обязателен. Этот аспект применения кэш-памяти команд делает размер команд важным критерием, который нужно учитывать при разработке.

 

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

 

Третий критерий связан с числом битов в адресном поле. Рассмотрим проект машины с 8-разрядными символами и основной памятью, которая должна содержать 232 символов. Разработчики вольны были приписать последовательные адреса блокам по 8, 16, 24 или 32 бита.

 

 

Представим, что бы случилось, если бы команда разработчиков разбилась на две воюющие группы, одна из которых утверждает, что основной единицей памяти должен быть 8-разрядный байт, а другая требует, чтобы основной единицей памяти было 32-разрядное слово. Первая группа предложила бы память из 232 байт с номерами 0, 1, 2, 3,4 294 967 295. Вторая группа предложила бы память из 230 слов с номерами 0, 1, 2, 3, 1 073 741 823.

 

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

 

Сторонники 32-разрядной организации скажут, что их проект требует всего лишь 230 отдельных адресов, что дает длину адреса всего 30 бит, тогда как при 8-разрядной организации требуется целых 32 бита для обращения к той же самой памяти. Если адрес короткий, то и команда будет более короткой. Она займет меньше пространства в памяти, и к тому же для ее вызова потребуется меньше времени. В качестве альтернативы они могут сохранить 32-разрядный адрес для обращения к памяти в 16 Гбайт вместо каких-то там 4 Гбайт.

 

Этот пример демонстрирует, что для получения оптимальной дискретности памяти требуются более длинные адреса и, следовательно, более длинные команды. Одна крайность - это организация памяти, при которой адресуется каждый бит (например, Burroughs В1700). Другая крайность - это память, состоящая из очень длинных слов (например, серия CDC Cyber содержала 60-разрядные слова).

 

Современные компьютерные системы пришли к компромиссу, который, в каком-то смысле, объединил в себе худшие качества обоих вариантов. Они требуют, чтобы адреса были у отдельных байтов, но при обращении к памяти всегда считываются одно, два, а иногда даже четыре слова сразу. В результате считывания одного байта из памяти на машине UltraSPARC III единовременно вызываются минимум 16 байт (см. рис. 3.44), а иногда и вся строка кэш-памяти размером 64 байта.


1 | 2 | 3 | 4 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)