Языковая компьютерная архитектура высокого уровня

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

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

Определение

В этом разделе представлено большое разнообразие систем. Самым крайним примером является язык прямого выполнения (DEL), где архитектура набора команд (ISA) компьютера равна инструкциям HLL, а исходный код исполняется напрямую с минимальной обработкой. В крайних случаях единственная необходимая компиляция — это токенизация исходного кода и подача токенов непосредственно в процессор; это встречается в стековых языках программирования, работающих на стековой машине . В более традиционных языках операторы HLL группируются в инструкции + аргументы , а инфиксный порядок преобразуется в префиксный или постфиксный порядок. DEL обычно являются лишь гипотетическими, хотя их пропагандировали в 1970-х годах.

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

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

Примеры

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

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

Серия Wang 2200 (1973) была разработана с использованием интерпретатора BASIC в микрокоде.

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

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

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

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

Ряд процессоров и сопроцессоров, предназначенных для более непосредственной реализации Пролога, были разработаны в конце 1980-х и начале 1990-х годов, в том числе Berkeley VLSI-PLM , его преемник ( PLUM ) и связанная с ним реализация микрокода . Также существовал ряд смоделированных проектов, которые не были созданы в виде аппаратного обеспечения. Методика проектирования процессора Prolog на основе VHDL , Сопроцессор Prolog для сверхпроводников . Как и Лисп, базовая модель вычислений Пролога радикально отличается от стандартных императивных проектов, и ученые-компьютерщики и инженеры-электрики стремились избежать узких мест, вызванных эмуляцией лежащих в их основе моделей.

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

INMOS Transputer был разработан для поддержки параллельного программирования с использованием occam .

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

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

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

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

Выполнение

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

Приложение

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

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

Мотивация

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

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

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

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

Недостатки

Подробная критика дана в Ditzel & Patterson (1980) .

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

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

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

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

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

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

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

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

См. также

• ASIC
• Java-процессор
• Языковая система
• Лисп-машина
• Пролог#Реализация в аппаратном обеспечении
• Кремниевый компилятор

Ссылки

• Маккиман, Уильям М. (14–16 ноября 1967 г.). Компьютерный дизайн, ориентированный на язык (PDF) . AFIPS '67 (осень) Материалы осенней объединенной компьютерной конференции 14–16 ноября 1967 г. Том. 31.
  • Кейрстед, Ральф Э. (март 1968 г.). «Компьютерный дизайн, ориентированный на язык R68-8» (PDF) . Транзакции IEEE на компьютерах . 17 (3): 298. doi : 10.1109/TC.1968.229106 . S2CID   41983403 . - обзор
• Дитцель, Дэвид Р.; Паттерсон, Дэвид А. (1980). «Ретроспектива компьютерной архитектуры языка высокого уровня» (PDF) . Материалы 7-го ежегодного симпозиума по компьютерной архитектуре - ISCA '80 . ISCA '80 Материалы 7-го ежегодного симпозиума по компьютерной архитектуре. АКМ. стр. 97–104. дои : 10.1145/800053.801914 . Проверено 18 ноября 2014 г.
• Пекарская дюжина: заблуждения и подводные камни в проектировании процессоров Грант Мартин и Стив Лейбсон, Tensilica (начало 2000-х), слайды 6–9

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

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