Hochsprachen-Computerarchitektur - High-level language computer architecture

Eine High-Level Language Computer Architecture ( HLLCA ) ist eine Computerarchitektur, die so konzipiert ist, dass sie von einer bestimmten High-Level-Sprache angesteuert wird , anstatt dass die Architektur von Hardware-Überlegungen diktiert wird. Es wird dementsprechend auch als sprachgesteuertes Computerdesign bezeichnet, geprägt von McKeeman (1967) und vor allem in den 1960er und 1970er Jahren verwendet. HLLCAs waren in den 1960er und 1970er Jahren populär, verschwanden jedoch in den 1980er Jahren weitgehend. Dies folgte dem dramatischen Versagen des Intel 432 (1981) und dem Aufkommen von optimierenden Compilern und einer Architektur mit reduziertem Befehlssatz (RISC) und RISC-ähnlichen CISC-Architekturen und der späteren Entwicklung der Just-in-Time-Kompilierung für HLLs. Eine ausführliche Übersicht und Kritik findet sich bei Ditzel & Patterson (1980) .

HLLCAs stammen fast aus den Anfängen der HLLs, in den Burroughs-Großsystemen (1961), die für ALGOL 60 (1960), eine der ersten HLLs, entwickelt wurden. Die bekanntesten HLLCAs sind die Lisp-Maschinen der 1970er und 1980er Jahre (für Lisp , 1959). Gegenwärtig sind die beliebtesten HLLCAs Java-Prozessoren für Java (1995), und diese sind ein qualifizierter Erfolg, da sie für bestimmte Anwendungen verwendet werden. Eine neuere Architektur in diesem Sinne ist die Heterogeneous System Architecture (2012), die HSA Intermediate Layer (HSAIL) bietet Befehlssatzunterstützung für HLL-Features wie Ausnahmen und virtuelle Funktionen; dies verwendet JIT, um die Leistung sicherzustellen.

Definition

Unter dieser Überschrift gibt es eine Vielzahl von Systemen. Das extremste Beispiel ist eine Directly Executed Language, bei der die Befehlssatzarchitektur des Computers den Befehlen der HLL entspricht und der Quellcode mit minimaler Verarbeitung direkt ausführbar ist. In extremen Fällen ist die einzige erforderliche Kompilierung das Tokenisieren des Quellcodes und das direkte Einspeisen der Token in den Prozessor; dies findet man in Stack-orientierten Programmiersprachen, die auf einem Stack-Rechner laufen . Für konventionellere Sprachen werden die HLL-Anweisungen in Anweisungen + Argumente gruppiert, und die Infix-Reihenfolge wird in die Präfix- oder Postfix-Reihenfolge umgewandelt. DELs sind normalerweise nur hypothetisch, obwohl sie in den 1970er Jahren befürwortet wurden.

In weniger extremen Beispielen wird der Quellcode zuerst syntaktisch analysiert Bytecode , den dann der Maschinencode , der an den Prozessor übergeben wird. In diesen Fällen fehlt dem System typischerweise ein Assembler, da der Compiler als ausreichend erachtet wird, obwohl in einigen Fällen (wie Java) Assembler verwendet werden, um zulässigen Bytecode zu erzeugen, der vom Compiler nicht ausgegeben würde. Dieser Ansatz wurde in der Pascal MicroEngine (1979) gefunden und wird derzeit von Java-Prozessoren verwendet.

Genauer gesagt kann eine HLLCA einfach eine Allzweck-Computerarchitektur mit einigen Merkmalen sein, die speziell eine gegebene HLL oder mehrere HLLs unterstützen. Dies wurde in Lisp-Maschinen ab den 1970er Jahren gefunden, die Allzweckprozessoren mit Operationen erweiterten, die speziell für die Unterstützung von Lisp entwickelt wurden.

Beispiele

Siehe auch: Stapelmaschine § Kommerzielle Stapelmaschinen

Die Burroughs Large Systems (1961) waren die ersten HLLCA, die entwickelt wurden, um ALGOL (1959), eine der frühesten HLLs, zu unterstützen. Dies wurde damals als "sprachgesteuertes Design" bezeichnet. Die Burroughs Medium Systems (1966) wurden entwickelt, um COBOL für Geschäftsanwendungen zu unterstützen . Die Burroughs Small Systems (Mitte der 1970er Jahre, entworfen ab Ende der 1960er Jahre) wurden entwickelt, um mehrere HLLs durch einen beschreibbaren Kontrollspeicher zu unterstützen . Das waren alles Großrechner.

Die Serie Wang 2200 (1973) wurde mit einem BASIC- Interpreter in Mikrocode entwickelt.

Die Pascal MicroEngine (1979) wurde für die UCSD-Pascal- Form von Pascal entwickelt und verwendet p-Code (Pascal-Compiler-Bytecode) als Maschinencode. Dies war einflussreich auf die spätere Entwicklung von Java und Java-Maschinen.

Lisp-Maschinen (1970er und 1980er) waren eine bekannte und einflussreiche Gruppe von HLLCAs.

Intel iAPX 432 (1981) wurde entwickelt, um Ada zu unterstützen. Dies war Intels erstes 32-Bit-Prozessordesign und sollte Intels Hauptprozessorfamilie für die 1980er Jahre sein, scheiterte jedoch kommerziell.

Rekursiv (Mitte der 1980er Jahre) war ein kleineres System, das die objektorientierte Programmierung und die Lingo- Programmiersprache in Hardware unterstützte und Rekursion auf Befehlssatzebene unterstützte , daher der Name.

Eine Reihe von Prozessoren und Coprozessoren, die Prolog direkter implementieren sollten, wurden in den späten 1980er und frühen 1990er Jahren entwickelt, darunter der Berkeley VLSI-PLM , sein Nachfolger (der PLUM ) und eine verwandte Mikrocode-Implementierung . Es gab auch eine Reihe von simulierten Designs, die nicht als Hardware erstellt wurden Eine VHDL-basierte Methodik zum Entwerfen eines Prolog-Prozessors , Ein Prolog-Coprozessor für Supraleiter . Wie bei Lisp unterscheidet sich das grundlegende Berechnungsmodell von Prolog radikal von den üblichen Imperativ-Designs, und Informatiker und Elektroingenieure waren bestrebt, den Engpässen zu entgehen, die durch die Emulation ihrer zugrunde liegenden Modelle verursacht wurden.

Das Lilith- Projekt von Niklaus Wirth beinhaltete eine benutzerdefinierte CPU, die auf die Modula-2- Sprache ausgerichtet war.

Der INMOS Transputer wurde entwickelt, um die gleichzeitige Programmierung mit occam zu unterstützen .

Der AT&T Hobbit- Prozessor, der aus einem Design namens CRISP (C-language Reduced Instruction Set Processor) stammt, wurde für die Ausführung von C- Code optimiert .

In den späten 1990er Jahren gab es Pläne von Sun Microsystems und anderen Unternehmen, CPUs zu bauen, die direkt (oder eng) die Stack-basierte Java Virtual Machine implementierten . Als Ergebnis wurden mehrere Java-Prozessoren gebaut und verwendet.

Ericsson hat ECOMP entwickelt, einen Prozessor, der entwickelt wurde, um Erlang auszuführen . Es wurde nie kommerziell hergestellt.

Die HSA Intermediate Layer (HSAIL) der Heterogeneous System Architecture (2012) stellt einen virtuellen Befehlssatz bereit, um von den zugrunde liegenden ISAs zu abstrahieren und unterstützt HLL-Features wie Ausnahmen und virtuelle Funktionen sowie Debugging-Unterstützung.

Implementierung

HLLCA werden häufig über eine Stack-Maschine implementiert (wie bei Burroughs Large Systems und Intel 432) und die HLL über Mikrocode im Prozessor implementiert (wie bei Burroughs Small Systems und Pascal MicroEngine). Architekturen mit Tags werden häufig verwendet, um Typen zu unterstützen (wie bei den Burroughs Large Systems- und Lisp-Maschinen). Radikalere Beispiele verwenden eine Nicht-von-Neumann-Architektur , obwohl dies typischerweise nur hypothetische Vorschläge sind, keine tatsächlichen Implementierungen.

Anwendung

Einige HLLCs sind aufgrund der schnellen Kompilierung und der Low-Level-Steuerung des Systems mit einer High-Level-Sprache besonders beliebt als Entwicklermaschinen (Workstations). Pascal MicroEngine- und Lisp-Maschinen sind dafür gute Beispiele.

HLLCAs wurden oft befürwortet, wenn eine HLL ein radikal anderes Berechnungsmodell hat als die imperative Programmierung (die relativ gut zu typischen Prozessoren passt), insbesondere für die funktionale Programmierung (Lisp) und die Logikprogrammierung (Prolog).

Motivation

Eine detaillierte Liste vermeintlicher Vorteile findet sich in Ditzel & Patterson (1980) .

HLLCAs sind intuitiv ansprechend, da der Computer prinzipiell an eine Sprache angepasst werden kann, was eine optimale Unterstützung der Sprache ermöglicht und das Compiler-Schreiben vereinfacht. Es kann außerdem mehrere Sprachen nativ unterstützen, indem einfach der Mikrocode geändert wird. Entscheidende Vorteile für Entwickler: schnelles Kompilieren und detailliertes symbolisches Debugging von der Maschine aus.

Ein weiterer Vorteil besteht darin, dass eine Sprachimplementierung durch Aktualisieren des Mikrocodes ( Firmware ) aktualisiert werden kann , ohne dass ein gesamtes System neu kompiliert werden muss. Dies ist analog zum Aktualisieren eines Dolmetschers für eine gedolmetschte Sprache.

Ein Vorteil, der nach 2000 wieder auftaucht, ist die Sicherheit. Die Mainstream-IT hat sich für die meisten Anwendungen weitgehend auf Sprachen mit Typ- und/oder Speichersicherheit verlagert. Die Software, von der sie abhängen, vom Betriebssystem bis hin zu virtuellen Maschinen, nutzt nativen Code ohne Schutz. In diesem Code wurden viele Schwachstellen gefunden. Eine Lösung besteht darin, einen speziell entwickelten Prozessor zu verwenden, um eine sichere Hochsprache auszuführen oder zumindest Typen zu verstehen. Schutzmaßnahmen auf der Wortebene des Prozessors erschweren die Arbeit von Angreifern im Vergleich zu Maschinen auf niedriger Ebene, die keinen Unterschied zwischen skalaren Daten, Arrays, Zeigern oder Code erkennen. Akademiker entwickeln auch Sprachen mit ähnlichen Eigenschaften, die in Zukunft in High-Level-Prozessoren integriert werden könnten. Ein Beispiel für diese beiden Trends ist das SAFE-Projekt. Vergleichen Sie sprachbasierte Systeme , bei denen die Software (insbesondere das Betriebssystem) auf einer sicheren Hochsprache basiert, obwohl die Hardware nicht unbedingt erforderlich ist: Die "vertrauenswürdige Basis" kann immer noch in einer niedrigeren Sprache vorliegen.

Nachteile

Eine ausführliche Kritik findet sich in Ditzel & Patterson (1980) .

Der einfachste Grund für den mangelnden Erfolg von HLLCAs ist, dass die Optimierung von Compilern ab 1980 zu viel schnellerem Code führte und einfacher zu entwickeln war, als eine Sprache in Mikrocode zu implementieren. Viele Compiler-Optimierungen erfordern eine komplexe Analyse und Neuanordnung des Codes, sodass sich der Maschinencode stark vom ursprünglichen Quellcode unterscheidet. Diese Optimierungen sind aufgrund der Komplexität und des Overheads entweder unmöglich oder unpraktisch in Mikrocode zu implementieren. Analoge Performance-Probleme haben eine lange Geschichte mit interpretierten Sprachen (bis Lisp (1958)), die erst durch Just-in-Time-Kompilierung praxisgerecht gelöst , in Self entwickelt und in der HotSpot Java Virtual Machine (1999) kommerzialisiert wurden .

Das grundlegende Problem besteht darin, dass HLLCAs nur den Codegenerierungsschritt von Compilern vereinfachen , der typischerweise ein relativ kleiner Teil der Kompilierung ist, und einen fragwürdigen Verbrauch von Rechenleistung (Transistoren und Mikrocode). Zumindest ist eine Tokenisierung erforderlich, und in der Regel werden weiterhin syntaktische Analysen und grundlegende semantische Prüfungen (ungebundene Variablen) durchgeführt – das Front-End hat also keinen Vorteil – und die Optimierung erfordert eine Vorabanalyse – es gibt also keinen Nutzen für das mittlere Ende.

Ein tieferes Problem, das 2014 immer noch ein aktives Entwicklungsgebiet ist, besteht darin, dass die Bereitstellung von HLL-Debugging-Informationen aus dem Maschinencode ziemlich schwierig ist, im Wesentlichen wegen des Overheads von Debugging-Informationen und subtiler, weil die Kompilierung (insbesondere die Optimierung) die Ermittlung der Originalquelle erfordert für eine Maschinenanweisung recht aufwendig. Somit schränken die Debugging-Informationen, die als wesentlicher Teil von HLLCAs bereitgestellt werden, entweder die Implementierung stark ein oder fügen bei normaler Verwendung einen erheblichen Overhead hinzu.

Außerdem sind HLLCAs typischerweise für eine einzelne Sprache optimiert und unterstützen andere Sprachen schlechter. Ähnliche Probleme treten bei mehrsprachigen virtuellen Maschinen auf, insbesondere bei der Java Virtual Machine (entwickelt für Java) und der .NET Common Language Runtime (entwickelt für C#), wo andere Sprachen Bürger zweiter Klasse sind und oft eng an die Hauptsprache anknüpfen müssen Sprache in der Semantik. Aus diesem Grund ermöglichen ISAs auf niedrigerer Ebene die gute Unterstützung mehrerer Sprachen, sofern Compilerunterstützung gegeben ist. Ein ähnliches Problem tritt jedoch sogar bei vielen scheinbar sprachneutralen Prozessoren auf, die von C gut unterstützt werden und bei denen die Übertragung auf C (anstatt direkt auf die Hardware abzuzielen) effiziente Programme und einfache Compiler ergibt.

Die Vorteile von HLLCAs können alternativ in HLL - Computer erreicht werden Systeme ( sprachbasierte Systeme ) auf andere Weise, in erster Linie über Compiler oder Interpreter: das System noch in einem HLL geschrieben wird, aber es ist eine vertrauenswürdige Basis in Software auf einem Nieder- läuft Ebene Architektur. Dieser Ansatz wird seit etwa 1980 verfolgt: zum Beispiel ein Java-System, bei dem die Laufzeitumgebung selbst in C geschrieben ist, das Betriebssystem und die Anwendungen jedoch in Java.

Alternativen

Seit den 1980er Jahren liegt der Fokus der Forschung und Implementierung in Allzweck-Computerarchitekturen hauptsächlich auf RISC-ähnlichen Architekturen, typischerweise intern registerreichen Lade-/Speicherarchitekturen , mit ziemlich stabilen, nicht sprachspezifischen ISAs, die mehrere Register aufweisen, Pipelining , und neuerdings Multicore-Systeme anstelle von sprachspezifischen ISAs. Die Sprachunterstützung hat sich auf Compiler und ihre Laufzeiten sowie Interpreter und ihre virtuellen Maschinen (insbesondere JIT-basierte) konzentriert, mit wenig direkter Hardwareunterstützung. Beispielsweise implementiert die aktuelle Objective-C- Laufzeit für iOS Tagged Pointer , die sie für die Typprüfung und die Garbage Collection verwendet, obwohl es sich bei der Hardware nicht um eine Tagged-Architektur handelt.

In der Computerarchitektur hat sich stattdessen der RISC-Ansatz als sehr beliebt und erfolgreich erwiesen und steht im Gegensatz zu HLLCAs, da er eine sehr einfache Befehlssatzarchitektur betont. Die Geschwindigkeitsvorteile von RISC-Computern in den 1980er Jahren waren jedoch in erster Linie auf die frühe Einführung des On-Chip-Cache und Platz für große Register zurückzuführen und nicht auf die intrinsischen Vorteile von RISC.

Siehe auch

Verweise

Weiterlesen