I informatikk er tolk eller tolk et dataprogram som er i stand til å analysere og kjøre andre programmer. Tolker skiller seg fra kompilatorer eller sammenstillere ved at mens kompilatorer oversetter et program fra beskrivelsen i et programmeringsspråk til systemets maskinkode , utfører tolker bare oversettelsen etter behov, typisk instruksjon for instruksjon. , og lagrer normalt ikke resultatet av nevnte oversettelse.
Ved å bruke en tolk kan en enkelt kildefil gi de samme resultatene selv på vidt forskjellige systemer (f.eks. en PC og en PlayStation 4 ). Ved å bruke en kompilator kan en enkelt kildefil produsere de samme resultatene bare hvis den er kompilert til forskjellige systemspesifikke kjørbare filer.
Tolkede programmer er vanligvis tregere enn kompilerte på grunn av behovet for å oversette programmet mens det kjører, men til gjengjeld er de mer fleksible som programmerings- og feilsøkingsmiljøer (som for eksempel betyr at det er lettere å erstatte deler). programmet eller legge til helt nye moduler), og la det tolkede programmet tilbys et miljø som ikke er avhengig av maskinen der tolken kjøres, men av selve tolken (det som vanligvis kalles en virtuell maskin ).
For å forbedre ytelsen kan noen implementeringer av noen programmeringsspråk tolke eller kompilere den originale kildekoden til en mer kompakt mellomform, og deretter oversette den til maskinkode (f.eks . Perl , Python , MATLAB og Ruby ). Noen godtar kildefiler som er lagret i denne mellomrepresentasjonen (f.eks. Python, UCSD Pascal og Java ).
For øyeblikket er et av de vanligste miljøene der tolker brukes i nettlesere , på grunn av deres evne til å kjøre plattformuavhengig.
Det er et spekter av muligheter mellom tolkning og kompilering, avhengig av mengden analyse utført før programmet kjøres. For eksempel er Emacs Lisp kompilert til bytecode , som er en svært komprimert og optimalisert representasjon av Lisp - kildekoden , men det er ikke maskinkode (og dermed ikke knyttet til noen spesiell maskinvare). Denne bytekoden tolkes deretter av en bytekodetolker (som er skrevet i C ). I dette tilfellet er den kompilerte koden maskinkoden for en virtuell maskin , som ikke er implementert i maskinvare, men i bytekode-tolkeren. Den samme tilnærmingen brukes med Forth -koden som brukes i Open Firmware -systemer : kildespråket er kompilert til "F-kode" (en bytekode).
Den største ulempen med tolker er at når et program tolkes, går det vanligvis saktere enn om det hadde blitt kompilert. Forskjellen i hastigheter kan være liten eller stor; ofte en størrelsesorden og noen ganger mer. Det tar vanligvis mer tid å kjøre et program under en tolk enn det gjør å kjøre den kompilerte koden, men det kan ta kortere tid å tolke den enn den totale tiden som kreves for å kompilere og kjøre den. Dette er spesielt viktig hvis du prototyper og tester kode når en tolks redigerings-, tolkings- og feilsøkingssyklus ofte kan være mye kortere enn kompilatorens redigerings-, kompilerings-, kjørings- og feilsøkingssyklus.
Å tolke kode er tregere enn å utføre kompilert kode fordi tolkeren må analysere hver setning i programmet hver gang den kjøres og deretter utføre ønsket handling, mens kompilert kode kun utfører handlingen innenfor en bestemt fast kontekst for kompileringen. Denne kjøretidsanalysen er kjent som "tolkende overbelastning." I en tolk er variabel tilgang også tregere fordi kartleggingen av identifikatorer til lagringsplasseringer må gjøres gjentatte ganger under kjøring i stedet for ved kompilering . Det er ulike avveininger mellom utviklingshastigheten ved bruk av tolk og utførelseshastigheten ved bruk av kompilator. Noen systemer (f.eks. noen LISP-er ) lar tolket og kompilert kode kalle hverandre og dele variabler. Dette betyr at når en rutine først er testet og feilsøkt under tolken, kan den kompileres og dermed dra nytte av raskere utførelse mens andre rutiner utvikles. Mange tolker kjører ikke kildekoden som den er, men konverterer den til en mer kompakt intern form. Noen BASIC- tolkere erstatter for eksempel nøkkelord med enkeltbyte -tokens som kan brukes til å finne instruksjonen i en grentabell . En tolk kan godt bruke den samme leksikale analysatoren og parseren som kompilatoren og deretter tolke det resulterende abstrakte syntakstreet .
På spekteret mellom tolkning og kompilering er en annen tilnærming å transformere kildekoden til et optimalisert abstrakt syntakstre (AST), og deretter fortsette å kjøre programmet etter denne trestrukturen . [ 1 ] I denne tilnærmingen trenger hver setning kun å analyseres én gang. Som en fordel fremfor bytekode opprettholder AST den generelle programstrukturen og relasjonene mellom setninger (som går tapt i en bytekoderepresentasjon), og gir en mer kompakt representasjon. [ 2 ]
Dermed har AST blitt foreslått som et bedre mellomformat for just-in-time kompilatorer enn bytekode. Det gir også en bedre analyse under utførelsestiden. En AST-basert Java-tolk har vist seg å være raskere enn en lignende bytekode-basert tolk, [ 3 ] takket være de kraftigere optimaliseringene som er tillatt ved å ha hele programstrukturen, samt datatyper på høyere nivå , tilgjengelig under utførelse. henrettelse.
For ytterligere å viske ut skillet mellom tolker, bytekodetolkere og kompilering, er det just-in-time (eller JIT) kompilering, en teknikk der mellomrepresentasjonen kompileres til innebygd maskinkode ved kjøring. Dette gir effektiviteten ved å kjøre innfødt kode, på bekostning av oppstartstid og økt minnebruk når bytekoden eller AST først kompileres. Adaptiv optimalisering er en komplementær teknikk der tolken utfører en ytelsesanalyse av det kjørende programmet (profilering) og kompilerer dets mest utførte deler til opprinnelig kode. Begge teknikkene er noen tiår gamle, og dukket opp på språk som Smalltalk på 1980-tallet.
I de siste årene har just-in-time kompilering fått oppmerksomheten til de fleste programmeringsspråkimplementere, med Java , Python og Microsoft .NET Framework som nå inkluderer JIT-er.
Noen eksempler på tolker:
Et tolket språk er et programmeringsspråk der de fleste av implementeringene utfører instruksjonene direkte, uten forutgående kompilering av programmet til maskinspråkinstruksjoner . Tolken kjører programmet direkte, og oversetter hver setning til en sekvens av en eller flere underrutiner som allerede er kompilert til maskinkode.
Begrepene tolket språk og kompilert språk [ 4 ] er ikke godt definert fordi, i teorien, kan et hvilket som helst programmeringsspråk tolkes eller kompileres. Det blir mer og mer populært, i nyere implementeringer av et programmeringsspråk, å tilby begge alternativene.
Tolkede språk kan også skilles fra maskinspråk . Funksjonelt betyr både utførelse og tolkning det samme - å hente neste instruksjon/utsagn fra programmet og utføre den. Selv om tolket bytekode også er identisk med maskinkodeformen og har en sammenstillingsrepresentasjon , er begrepet "tolket" i praksis reservert for "programvarebehandlede" språk (som virtuelle maskiner eller emulatorer ) ved på toppen av native prosessering ( for eksempel etter maskinvare).
I prinsippet kan programmene til mange språk kompileres eller tolkes, emuleres eller kjøres naturlig, så denne betegnelsen gjelder bare for den mest vanlige praktiske implementeringen, i stedet for å representere en viktig egenskap ved språket. I likhet med prosessorens mikrokode faller mange tolker internt tilbake på en kjøretidskompilering .
Ved å unngå kompilering er tolkede programmer lettere å utvikle under utvikling og utførelse (noen ganger transformeres fra det ene til det andre). På den annen side, siden kompilering innebærer en oversettelse til et mer maskinvennlig format, kjører tolkede programmer saktere og mindre effektivt (dvs. de bruker betydelig mer strøm). Dette gjelder spesielt for skriptspråk , hvis setninger er mer komplekse å analysere sammenlignet med maskininstruksjoner.
Mange språk har blitt implementert ved bruk av både kompilatorer og tolker, inkludert BASIC , C , Lisp , Pascal og Python . Java og C# er kompilert til bytecode, det tolkede språket som er spesifikt for den virtuelle maskinen. Mange Lisp-implementeringer kan fritt blande tolket og kompilert kode.
I de tidlige dagene med databehandling ble språkdesign sterkt påvirket av beslutningen om å bruke kompilering eller tolkning som utførelsesmodus. For eksempel krever noen kompilerte språk at programmer eksplisitt må indikere datatypen til en variabel på det tidspunktet den er deklarert eller når den brukes første gang, mens noen tolkede språk utnytter de dynamiske aspektene ved tolkning for å gjøre slike unødvendige utsagn. For eksempel lar Smalltalk (1980), som ble designet for å bli tolket under kjøretid, generiske objekter dynamisk samhandle med hverandre.
Opprinnelig ble tolkede språk kompilert linje for linje, det vil si at hver linje ble kompilert etter hvert som den var i ferd med å bli utført, og hvis en sløyfe eller subrutine førte til at visse linjer ble utført flere ganger, ville de gjentatte ganger bli kompilert på nytt. Dette har blitt mye mindre vanlig. De fleste tolkede språk bruker en mellomrepresentasjon , som kombinerer både kompilering og tolkning. I dette tilfellet kan en kompilator produsere bytecode eller threaded code , som deretter utføres av en bytecode-tolker .
Eksempler inkluderer:
Mellomrepresentasjonen kan kompileres én gang (som i Java), hver gang den skal kjøres (som i Perl eller Ruby), eller hver gang en endring oppdages i kildekoden før kjøring (som i Python ). ).
Å tolke et språk gir implementeringer ekstra fleksibilitet i forhold til kompilerte implementeringer. Noen funksjoner er lettere å implementere i tolker enn kompilatorer er (men ikke begrenset til):
Den største ulempen med å tolke er en mye langsommere programutførelseshastighet, sammenlignet med direkte utføring av maskinkode på datamaskinens CPU . En teknikk som brukes for å forbedre ytelsen er kjøretidskompilering, som konverterer de oftest utførte skriptene til maskinkode på datamaskinen.
Mange tolkede språk kompileres først til bytekode, som deretter normalt tolkes av den virtuelle maskinen ved hjelp av runtime-kompilering, fra bytekode til opprinnelig kode. Noen ganger kan imidlertid bytekode også kompileres til en naturlig binær ved å bruke en forhåndskompilering , eller kjøres naturlig av maskinvareprosessoren.