Taalcomputerarchitectuur op hoog niveau - High-level language computer architecture

Een computerarchitectuur op hoog niveau ( HLLCA ) is een computerarchitectuur die is ontworpen om te worden getarget door een specifieke taal op hoog niveau , in plaats van dat de architectuur wordt gedicteerd door hardwareoverwegingen. Het wordt daarom ook taalgestuurd computerontwerp genoemd, bedacht in McKeeman (1967) en voornamelijk gebruikt in de jaren zestig en zeventig. HLLCA's waren populair in de jaren zestig en zeventig, maar verdwenen grotendeels in de jaren tachtig. Dit volgde op het dramatische falen van de Intel 432 (1981) en de opkomst van optimaliserende compilers en gereduceerde instructieset computing (RISC)-architectuur en RISC-achtige CISC-architecturen, en de latere ontwikkeling van just-in-time compilatie voor HLL's. Een gedetailleerd overzicht en kritiek is te vinden in Ditzel & Patterson (1980) .

HLLCA's dateren bijna uit het begin van HLL's, in de grote systemen van Burroughs (1961), die zijn ontworpen voor ALGOL 60 (1960), een van de eerste HLL's. De meest bekende HLLCA's zijn de Lisp-machines uit de jaren 70 en 80 (voor Lisp , 1959). Op dit moment zijn de meest populaire HLLCA's Java-processors , voor Java (1995), en deze zijn een gekwalificeerd succes, omdat ze voor bepaalde toepassingen worden gebruikt. Een recente architectuur in deze geest is de heterogene systeemarchitectuur (2012), die HSA Intermediate Layer (HSAIL) instructiesetondersteuning biedt voor HLL-functies zoals uitzonderingen en virtuele functies; dit gebruikt JIT om de prestaties te garanderen.

Definitie

Er is een grote verscheidenheid aan systemen onder deze noemer. Het meest extreme voorbeeld is een Directly Executed Language, waarbij de instructiesetarchitectuur van de computer gelijk is aan de instructies van de HLL, en de broncode direct uitvoerbaar is met minimale verwerking. In extreme gevallen is de enige vereiste compilatie het tokeniseren van de broncode en het rechtstreeks naar de processor voeren van de tokens; dit is te vinden in stapelgeoriënteerde programmeertalen die op een stapelmachine draaien . Voor meer conventionele talen worden de HLL-statements gegroepeerd in instructie + argumenten, en de volgorde van de infix wordt omgezet in de volgorde van prefix of postfix. DEL's zijn meestal alleen hypothetisch, hoewel ze in de jaren zeventig werden bepleit.

In minder extreme voorbeelden wordt de broncode eerst geparseerd tot bytecode , wat vervolgens de machinecode is die aan de processor wordt doorgegeven. In deze gevallen mist het systeem typisch een assembler, aangezien de compiler voldoende wordt geacht, hoewel in sommige gevallen (zoals Java) assemblers worden gebruikt om legale bytecode te produceren die niet door de compiler zou worden uitgevoerd. Deze benadering werd gevonden in de Pascal MicroEngine (1979) en wordt momenteel gebruikt door Java-processors.

Los daarvan kan een HLLCA eenvoudigweg een computerarchitectuur voor algemeen gebruik zijn met enkele functies die specifiek een bepaalde HLL of meerdere HLL's ondersteunen. Dit werd gevonden in Lisp-machines vanaf de jaren zeventig, die processors voor algemeen gebruik uitbreidden met bewerkingen die specifiek waren ontworpen om Lisp te ondersteunen.

Voorbeelden

Zie ook: Stapelmachine § Commerciële stapelmachines

De Burroughs Large Systems (1961) waren de eerste HLLCA, ontworpen om ALGOL (1959), een van de vroegste HLL's, te ondersteunen. Dit werd destijds 'taalgestuurd ontwerp' genoemd. De Burroughs Medium Systems (1966) zijn ontworpen om COBOL voor zakelijke toepassingen te ondersteunen . De Burroughs Small Systems (midden jaren 70, ontworpen vanaf eind jaren 60) zijn ontworpen om meerdere HLL's te ondersteunen door middel van een beschrijfbare besturingsopslag . Dit waren allemaal mainframes.

De serie Wang 2200 (1973) is ontworpen met een BASIC- interpreter in microcode.

De Pascal MicroEngine (1979) is ontworpen voor de UCSD Pascal- vorm van Pascal en gebruikte p-code (Pascal-compilerbytecode) als machinecode. Dit was van invloed op de latere ontwikkeling van Java en Java-machines.

Lisp-machines (jaren '70 en '80) waren een bekende en invloedrijke groep HLLCA's.

Intel iAPX 432 (1981) is ontworpen om Ada te ondersteunen. Dit was Intel's eerste 32-bits processorontwerp en was bedoeld als Intel's belangrijkste processorfamilie voor de jaren tachtig, maar faalde commercieel.

Rekursiv (midden jaren tachtig) was een klein systeem, ontworpen om objectgeoriënteerd programmeren en de Lingo- programmeertaal in hardware te ondersteunen, en ondersteunde recursie op het niveau van de instructieset, vandaar de naam.

Een aantal processors en coprocessors die bedoeld waren om Prolog directer te implementeren , werden eind jaren tachtig en begin jaren negentig ontworpen, waaronder de Berkeley VLSI-PLM , zijn opvolger (de PLUM ), en een gerelateerde microcode-implementatie . Er waren ook een aantal gesimuleerde ontwerpen die niet als hardware werden geproduceerd. Een op VHDL gebaseerde methode voor het ontwerpen van een Prolog-processor , een Prolog-coprocessor voor supergeleiders . Net als Lisp is het basismodel van Prolog voor berekeningen radicaal anders dan standaard imperatieve ontwerpen, en computerwetenschappers en elektrotechnici wilden graag ontsnappen aan de knelpunten die werden veroorzaakt door het emuleren van hun onderliggende modellen.

Niklaus Wirth 's Lilith project omvatte een aangepaste CPU gericht op de Modula-2 taal.

De INMOS Transputer is ontworpen om gelijktijdig programmeren te ondersteunen met behulp van occam .

De AT&T Hobbit- processor, afkomstig van een ontwerp genaamd CRISP (C-taal Reduced Instruction Set Processor), is geoptimaliseerd om C- code uit te voeren.

Aan het eind van de jaren negentig waren er plannen van Sun Microsystems en andere bedrijven om CPU's te bouwen die direct (of nauw) de op stapels gebaseerde Java- virtuele machine zouden implementeren . Als gevolg hiervan zijn er verschillende Java-processors gebouwd en gebruikt.

Ericsson ontwikkelde ECOMP, een processor die is ontworpen om Erlang te draaien . Het is nooit commercieel geproduceerd.

De HSA Intermediate Layer (HSAIL) van de Heterogeneous System Architecture (2012) biedt een virtuele instructieset om weg te abstraheren van de onderliggende ISA's, en heeft ondersteuning voor HLL-functies zoals uitzonderingen en virtuele functies, en biedt ondersteuning voor foutopsporing.

Implementatie

HLLCA worden vaak geïmplementeerd via een stapelmachine (zoals in de Burroughs Large Systems en Intel 432), en de HLL via microcode in de processor (zoals in Burroughs Small Systems en Pascal MicroEngine). Getagde architecturen worden vaak gebruikt om typen te ondersteunen (zoals in de Burroughs Large Systems en Lisp-machines). Meer radicale voorbeelden gebruiken een niet-von Neumann-architectuur , hoewel dit meestal slechts hypothetische voorstellen zijn, geen daadwerkelijke implementaties.

Sollicitatie

Sommige HLLC's zijn bijzonder populair geweest als ontwikkelaarsmachines (werkstations), vanwege de snelle compilaties en de controle op laag niveau van het systeem met een taal op hoog niveau. Pascal MicroEngine- en Lisp-machines zijn hier goede voorbeelden van.

HLLCA's zijn vaak bepleit wanneer een HLL een radicaal ander rekenmodel heeft dan imperatief programmeren (wat relatief goed past bij typische processors), met name voor functioneel programmeren (Lisp) en logisch programmeren (Prolog).

Motivatie

Een gedetailleerde lijst van vermeende voordelen wordt gegeven in Ditzel & Patterson (1980) .

HLLCA's zijn intuïtief aantrekkelijk, omdat de computer in principe kan worden aangepast voor een taal, waardoor de taal optimaal wordt ondersteund en het schrijven door compilers wordt vereenvoudigd. Het kan verder native meerdere talen ondersteunen door simpelweg de microcode te wijzigen. De belangrijkste voordelen zijn voor ontwikkelaars: snelle compilatie en gedetailleerde symbolische foutopsporing vanaf de machine.

Een ander voordeel is dat een taalimplementatie kan worden bijgewerkt door de microcode ( firmware ) bij te werken, zonder dat een volledig systeem opnieuw moet worden gecompileerd. Dit is analoog aan het updaten van een tolk voor een vertolkte taal.

Een voordeel dat na 2000 weer opduikt, is veiligheid of beveiliging. De reguliere IT is voor de meeste toepassingen grotendeels verplaatst naar talen met type- en/of geheugenbeveiliging. De software waarvan ze afhankelijk zijn, van besturingssysteem tot virtuele machines, maakt gebruik van native code zonder bescherming. In dergelijke code zijn veel kwetsbaarheden gevonden. Een oplossing is om een ​​processor te gebruiken die speciaal is gebouwd om een ​​veilige taal op hoog niveau uit te voeren of op zijn minst typen te begrijpen. Beveiligingen op woordniveau van de processor maken het werk van aanvallers moeilijker in vergelijking met machines op laag niveau die geen onderscheid zien tussen scalaire gegevens, arrays, pointers of code. Academici ontwikkelen ook talen met vergelijkbare eigenschappen die in de toekomst kunnen worden geïntegreerd met processors op hoog niveau. Een voorbeeld van beide trends is het SAFE-project. Vergelijk op taal gebaseerde systemen , waarbij de software (vooral het besturingssysteem) is gebaseerd op een veilige taal op hoog niveau, hoewel de hardware dat niet hoeft te zijn: de "vertrouwde basis" kan nog steeds in een taal van een lager niveau zijn.

nadelen

Een gedetailleerde kritiek wordt gegeven in Ditzel & Patterson (1980) .

De eenvoudigste reden voor het gebrek aan succes van HLLCA's is dat vanaf 1980 het optimaliseren van compilers resulteerde in veel snellere code en gemakkelijker te ontwikkelen was dan het implementeren van een taal in microcode. Veel compiler-optimalisaties vereisen een complexe analyse en herschikking van de code, dus de machinecode verschilt sterk van de oorspronkelijke broncode. Deze optimalisaties zijn ofwel onmogelijk ofwel onpraktisch om in microcode te implementeren, vanwege de complexiteit en de overhead. Analoge prestatieproblemen hebben een lange geschiedenis met geïnterpreteerde talen (daterend uit Lisp (1958)), die alleen adequaat worden opgelost voor praktisch gebruik door just-in-time compilatie , pionier in Self en gecommercialiseerd in de HotSpot Java virtual machine (1999).

Het fundamentele probleem is dat HLLCA's alleen de code-generatiestap van compilers vereenvoudigen , wat meestal een relatief klein onderdeel van compilatie is, en een twijfelachtig gebruik van rekenkracht (transistors en microcode). Er is minimaal tokenisatie vereist, en typisch syntactische analyse en elementaire semantische controles (onafhankelijke variabelen) zullen nog steeds worden uitgevoerd - dus er is geen voordeel voor de front-end - en optimalisatie vereist analyse vooraf - dus er is geen voordeel voor het middeneinde.

Een dieper probleem, nog steeds een actief ontwikkelingsgebied vanaf 2014, is dat het verstrekken van HLL-foutopsporingsinformatie uit machinecode vrij moeilijk is, voornamelijk vanwege de overhead van foutopsporingsinformatie, en subtieler omdat compilatie (met name optimalisatie) het bepalen van de oorspronkelijke bron maakt voor een machine-instructie behoorlijk ingewikkeld. Dus de foutopsporingsinformatie die als een essentieel onderdeel van HLLCA's wordt geleverd, beperkt de implementatie ernstig of voegt aanzienlijke overhead toe bij normaal gebruik.

Verder zijn HLLCA's doorgaans geoptimaliseerd voor een enkele taal, waardoor andere talen minder goed worden ondersteund. Soortgelijke problemen doen zich voor bij meertalige virtuele machines, met name de virtuele Java-machine (ontworpen voor Java) en de .NET Common Language Runtime (ontworpen voor C#), waar andere talen tweederangsburgers zijn en vaak nauw moeten aansluiten bij de belangrijkste taal in de semantiek. Om deze reden maken ISA's op een lager niveau het mogelijk om meerdere talen goed te ondersteunen, mits de compiler wordt ondersteund. Een soortgelijk probleem doet zich echter zelfs voor bij veel ogenschijnlijk taalneutrale processors, die goed worden ondersteund door C, en waar transpileren naar C (in plaats van direct op de hardware te richten) efficiënte programma's en eenvoudige compilers oplevert.

De voordelen van HLLCAs kan alternatief worden bereikt HLL Computer Systems ( talige systemen ) op alternatieve manieren, hoofdzakelijk via compilers en interpreters: het systeem nog steeds in een HLL geschreven, maar er is een betrouwbare basis in software op een lager- niveau architectuur. Dit is de benadering die sinds circa 1980 wordt gevolgd: bijvoorbeeld een Java-systeem waarbij de runtime-omgeving zelf in C is geschreven, maar het besturingssysteem en de applicaties in Java.

alternatieven

Sinds de jaren tachtig ligt de focus van onderzoek en implementatie in computerarchitecturen voor algemene doeleinden voornamelijk op RISC-achtige architecturen, doorgaans intern registerrijke load/store-architecturen , met vrij stabiele, niet-taalspecifieke ISA's, met meerdere registers, pipelining , en meer recentelijk multicore-systemen, in plaats van taalspecifieke ISA's. Taalondersteuning was gericht op compilers en hun runtimes, en interpreters en hun virtuele machines (met name JIT'ing-machines), met weinig directe hardware-ondersteuning. De huidige Objective-C runtime voor iOS implementeert bijvoorbeeld tagged pointers , die het gebruikt voor type-checking en garbage collection, ondanks dat de hardware geen tagged architectuur is.

In computerarchitectuur is de RISC-benadering in plaats daarvan erg populair en succesvol gebleken, en in tegenstelling tot HLLCA's, waarbij de nadruk ligt op een zeer eenvoudige instructieset-architectuur. De snelheidsvoordelen van RISC-computers in de jaren tachtig waren echter voornamelijk te danken aan de vroege invoering van on-chip cache en ruimte voor grote registers, in plaats van intrinsieke voordelen van RISC.

Zie ook

Referenties

Verder lezen