WikiDer > Архитектура компьютера на языке высокого уровня - Википедия

High-level language computer architecture - Wikipedia

А архитектура компьютера на языке высокого уровня (HLLCA) это компьютерная архитектура предназначен для целевой аудитории язык высокого уровня, а не архитектура, продиктованная аппаратными соображениями. Соответственно, это также называется языковой компьютерный дизайн, придуман в МакКиман (1967) и в основном использовались в 1960-х и 1970-х годах. HLLCA были популярны в 1960-х и 1970-х годах, но в значительной степени исчезли в 1980-х. Это последовало за драматическим провалом Intel 432 (1981) и появление оптимизация компиляторов и вычисление с сокращенным набором команд (RISC) и RISC-подобные архитектуры CISC, а также более поздняя разработка своевременная компиляция для ГЛУ. Подробный обзор и критику можно найти в Дитзель и Паттерсон (1980).

HLLCA датируются практически началом HLLs, в Большие системы Берроуза (1961), которые были разработаны для АЛГОЛ 60 (1960), одна из первых HLL. Самыми известными HLLCA являются Лисп-машины 1970-х и 1980-х годов (для Лисп, 1959). В настоящее время наиболее популярными HLLCA являются: Процессоры Java, за Ява (1995), и они имеют определенный успех и используются для определенных приложений. Недавней архитектурой в этом духе является архитектура гетерогенных систем (2012 г.), которая Промежуточный уровень HSA (HSAIL) обеспечивает поддержку набора команд для функций HLL, таких как исключения и виртуальные функции; это использует JIT для обеспечения производительности.

Определение

Под этим заголовком имеется большое количество разнообразных систем. Наиболее ярким примером является язык с прямым исполнением, в котором архитектура набора команд компьютера соответствует инструкциям HLL, а исходный код является непосредственно исполняемым с минимальной обработкой. В крайних случаях требуется только компиляция токенизация исходный код и подача токенов прямо в процессор; это находится в стек-ориентированные языки программирования работает на штабелеукладчик. Для более традиционных языков операторы HLL сгруппированы в команду + аргументы, а инфиксный порядок преобразуется в префиксный или постфиксный порядок. DEL, как правило, носят лишь гипотетический характер, хотя их пропагандировали в 1970-х годах.[1]

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

В более широком смысле HLLCA может быть просто компьютерной архитектурой общего назначения с некоторыми функциями, специально предназначенными для поддержки данного HLL или нескольких HLL. Это было обнаружено в машинах Lisp с 1970-х годов, которые дополнили процессоры общего назначения операциями, специально разработанными для поддержки Lisp.

Примеры

Смотрите также: Штабелер § Коммерческие штабелеры

В Большие системы Берроуза (1961) были первыми HLLCA, разработанными для поддержки ALGOL (1959), одного из первых HLL. В то время это называлось «дизайном, ориентированным на язык». В Средние системы Берроуза (1966) были разработаны для поддержки КОБОЛ для бизнес-приложений. В Малые системы Берроуза (середина 1970-х, разработан с конца 1960-х) были разработаны для поддержки нескольких HLL с помощью записываемого магазин управления. Все это были мэйнфреймы.

В Ван 2200 (1973) были разработаны с БАЗОВЫЙ интерпретатор в микрокоде.

В Паскаль MicroEngine (1979) был разработан для UCSD Паскаль форма Паскаль, и использовал p-код (Байт-код компилятора Паскаля) в качестве его машинного кода. Это оказало влияние на более позднее развитие Java и Java-машин.

Лисп-машины (1970-е и 1980-е) были известной и влиятельной группой HLLCA.

Intel iAPX 432 (1981) был разработан для поддержки Ады. Это был первый 32-разрядный процессор Intel, который должен был стать основным семейством процессоров Intel в 1980-х годах, но коммерчески потерпел неудачу.

Рекурсив (середина 1980-х) была второстепенной системой, предназначенной для поддержки объектно-ориентированного программирования и Lingo язык программирования в оборудовании и поддерживаемый рекурсия на уровне набора команд, отсюда и название.

Ряд процессоров и сопроцессоров, предназначенных для реализации Пролог более непосредственно были разработаны в конце 1980-х - начале 1990-х годов, в том числе СБИС-PLM Беркли, его преемник ( СЛИВА), а реализация соответствующего микрокода. Также был ряд смоделированных конструкций, которые не производились как оборудование. [1], [2]. Как и Лисп, базовая модель вычислений Пролога радикально отличается от стандартных императивных проектов, и компьютерные ученые и инженеры-электрики стремились избежать узких мест, вызванных эмуляцией их базовых моделей.

Никлаус Виртс Лилит проект включал специальный процессор, ориентированный на Модула-2 язык.[2]

ИНМОС Транспьютер был разработан для поддержки параллельного программирования с использованием Оккам.

В AT&T Хоббит процессор, основанный на конструкции под названием CRISP (процессор с сокращенным набором команд на языке C), был оптимизирован для работы C код.

В конце 1990-х были планы Sun Microsystems и другие компании для создания процессоров, которые напрямую (или близко) реализовали стек на основе Ява виртуальная машина. В результате несколько Процессоры Java были построены и использовались.

Ericsson разработал ECOMP, процессор, предназначенный для работы Erlang.[3] Он никогда не производился в коммерческих целях.

Промежуточный уровень HSA (HSAIL) Гетерогенная системная архитектура (2012) предоставляет набор виртуальных инструкций для абстрагирования от базовых ISA, а также поддерживает функции HLL, такие как исключения и виртуальные функции, а также включает поддержку отладки.

Выполнение

HLLCA часто реализуются через штабелеукладчик (как в Burroughs Large Systems и Intel 432) и реализовал HLL через микрокод в процессоре (как в Burroughs Small Systems и Pascal MicroEngine). Tagged архитектуры часто используются для поддержки типов (как в машинах Burroughs Large Systems и Lisp). В более радикальных примерах используется архитектура не фон Неймана, хотя обычно это только гипотетические предложения, а не фактические реализации.

Заявление

Некоторые HLLC были особенно популярны в качестве машин для разработчиков (рабочих станций) из-за быстрой компиляции и низкоуровневого управления системой с помощью языка высокого уровня. Машины Pascal MicroEngine и Lisp - хорошие тому примеры.

HLLCA часто отстаиваются, когда HLL имеет модель вычислений, радикально отличающуюся от модели императивного программирования (которая относительно хорошо подходит для типичных процессоров), особенно для функционального программирования (Lisp) и логического программирования (Prolog).

Мотивация

Подробный список предполагаемых преимуществ приведен в Дитзель и Паттерсон (1980).

HLLCA интуитивно привлекательны, поскольку компьютер в принципе можно настроить для языка, что обеспечивает оптимальную поддержку языка и упрощает написание компилятора. Он может дополнительно поддерживать несколько языков, просто изменив микрокод. Ключевые преимущества для разработчиков: быстрая компиляция и подробные символическая отладка от машины.

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

Преимущество, которое вновь появляется после 2000 г., - это безопасность. Основные ИТ-службы в значительной степени перешли на языки с безопасностью типов и / или памяти для большинства приложений. Программное обеспечение, от которого зависит, от ОС до виртуальных машин, использует собственный код без защиты. В таком коде было обнаружено много уязвимостей. Одним из решений является использование процессора, специально созданного для выполнения безопасного языка высокого уровня или, по крайней мере, для понимания типов. Защита на уровне слова процессора затрудняет работу злоумышленников по сравнению с машинами низкого уровня, которые не видят различий между скалярными данными, массивами, указателями или кодом. Ученые также разрабатывают языки со схожими свойствами, которые в будущем могут интегрироваться с процессорами высокого уровня. Примером обеих этих тенденций является SAFE[4] проект. Сравнивать языковые системы, где программное обеспечение (особенно операционная система) основано на безопасном языке высокого уровня, хотя оборудование не обязательно: «доверенная база» может по-прежнему находиться на языке более низкого уровня.

Недостатки

Подробная критика дана в Дитзель и Паттерсон (1980).

Самая простая причина отсутствия успеха HLLCA заключается в том, что с 1980 г. оптимизация компиляторов привели к гораздо более быстрому коду и были проще в разработке, чем реализация языка в микрокоде. Многие оптимизации компилятора требуют сложного анализа и перестройки кода, поэтому машинный код сильно отличается от исходного исходного кода. Эти оптимизации невозможно или непрактично реализовать в микрокоде из-за сложности и накладных расходов. Аналогичные проблемы производительности имеют долгую историю с интерпретируемыми языками (начиная с Лиспа (1958)), и адекватно решаются для практического использования только с помощью своевременная компиляция, впервые в Себя и коммерциализирована в HotSpot Виртуальная машина Java (1999).

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

Более глубокая проблема, по-прежнему активно развивающаяся с 2014 года.,[5] заключается в том, что предоставление отладочной информации HLL из машинного кода довольно сложно, в основном из-за накладных расходов на отладочную информацию, а более тонко из-за того, что компиляция (особенно оптимизация) сильно затрудняет определение исходного источника машинной инструкции. Таким образом, отладочная информация, предоставляемая как важная часть HLLCA, либо серьезно ограничивает реализацию, либо добавляет значительные накладные расходы при обычном использовании.

Кроме того, HLLCA обычно оптимизированы для одного языка, хуже поддерживая другие языки. Подобные проблемы возникают в многоязычных виртуальных машинах, особенно в виртуальной машине Java (разработанной для Java) и .NET. общеязыковая среда выполнения (разработан для C #), где другие языки являются гражданами второго сорта и часто должны быть близки к основному языку в семантике. По этой причине ISA нижнего уровня позволяют хорошо поддерживать несколько языков, учитывая поддержку компилятора. Однако подобная проблема возникает даже для многих явно не зависящих от языка процессоров, которые хорошо поддерживаются C, и где транспиляция на C (а не напрямую на оборудование) дает эффективные программы и простые компиляторы.

Альтернативно преимущества HLLCA могут быть реализованы в HLL Computer Системы (языковые системы) альтернативными способами, в первую очередь через компиляторы или интерпретаторы: система по-прежнему написана на HLL, но есть надежная база в программном обеспечении, работающем на более низкоуровневой архитектуре. Этого подхода придерживаются примерно с 1980 года: например, система Java, в которой сама среда выполнения написана на C, а операционная система и приложения написаны на Java.

Альтернативы

С 1980-х годов основное внимание в исследованиях и внедрении компьютерных архитектур общего назначения уделялось RISC-подобным архитектурам, обычно богатым внутренними регистрами. загрузка / сохранение архитектур, с довольно стабильными ISA, не зависящими от языка, с несколькими регистрами, конвейерной обработкой и, в последнее время, с многоядерными системами, а не с языковыми ISA. Языковая поддержка сосредоточена на компиляторах и их средах выполнения, а также на интерпретаторах и их виртуальных машинах (особенно на JIT-машинах) с небольшой прямой аппаратной поддержкой. Например, текущий Цель-C среда выполнения для iOS реализует помеченные указатели, который он использует для проверки типов и сборки мусора, несмотря на то, что оборудование не является архитектурой с тегами.

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

Смотрите также

Рекомендации

  1. ^ См. Ссылки на Яохан Чу.
  2. ^ «Паскаль для малых машин - история Лилит». Pascal.hansotten.com. 28 сентября 2010 г.. Получено 12 ноября 2011.
  3. ^ http://www.erlang.se/euc/00/processor.ppt
  4. ^ http://www.crash-safe.org
  5. ^ Видеть LLVM и компилятор Clang.

дальнейшее чтение

  • Исследование компьютерного дизайна, ориентированного на язык, Дэвид Баркли Вортман, Департамент компьютерных наук, доктор философии. дипломная работа, Стэнфордский университет, 1972 г.
  • Hoevel, L.W. (Август 1974 г.). ""Идеал «Языки с прямым исполнением: аналитический аргумент в пользу эмуляции» (PDF). Транзакции IEEE на компьютерах. IEEE. 23 (8): 759–767. Дои:10.1109 / T-C.1974.224032.
  • Чу, Яохан (декабрь 1975 г.). «Концепции компьютерной архитектуры высокого уровня». Информационный бюллетень ACM SIGMICRO. 6 (4): 9–16. Дои:10.1145/1217196.1217197.
    • Чу, Яохан (1975). Концепции компьютерной архитектуры на языке высокого уровня. ACM '75 Труды ежегодной конференции 1975 г. С. 6–13. Дои:10.1145/800181.810257.
  • Чу, Яохань; Кэннон, Р. (июнь 1976 г.). "Интерактивная микропроцессорная система прямого исполнения на языке высокого уровня". IEEE Transactions по разработке программного обеспечения. 2 (2): 126–134. Дои:10.1109 / TSE.1976.233802.
  • Чу, Яохань (декабрь 1977 г.). «Архитектура компьютера прямого исполнения». Новости компьютерной архитектуры ACM SIGARCH. 6 (5): 18–23. Дои:10.1145/859412.859415.
  • Чу, Яохан (1978). Прямое выполнение в компьютерной архитектуре высокого уровня. ACM '78 Труды ежегодной конференции 1978 г. С. 289–300. Дои:10.1145/800127.804116.
  • Чу, Яохань; Абрамс, М. (июль 1981 г.). «Языки программирования и компьютерная архитектура прямого исполнения». Компьютер. 14 (7): 22–32. Дои:10.1109 / C-M.1981.220525.