In che modo le lingue hanno influenzato la progettazione della CPU? [chiuso]

Spesso ci viene detto che all'hardware non importa in quale lingua è scritto un programma poiché vede solo il codice binario compilato, tuttavia questa non è tutta la verità. Ad esempio, considera l'umile Z80; le sue estensioni al set di istruzioni 8080 includono istruzioni come CPIR che è utile per scansionare stringhe di tipo C (terminate con NULL), ad es. per eseguire strlen(). I progettisti devono aver identificato che l'esecuzione di programmi C (al contrario di Pascal, in cui la lunghezza di una stringa è nell'intestazione) era qualcosa per cui il loro progetto sarebbe stato probabilmente utilizzato. Un altro esempio classico è la macchina Lisp .

Quali altri esempi ci sono? Ad esempio istruzioni, numero e tipo di registri , modalità di indirizzamento, che rendono un processore particolare favorevole alle convenzioni di una lingua particolare? Sono particolarmente interessato alle revisioni della stessa famiglia.

Le risposte esistenti si concentrano sui cambiamenti ISA . Ci sono anche altre modifiche hardware. Ad esempio, C ++ usa comunemente vtables per le chiamate virtuali. A partire da Pentium M , Intel ha un componente "predittore di filiali indirette" che accelera le chiamate di funzione virtuale.

Il set di istruzioni Intel 8086 include una variante di "ret" che aggiunge un valore al puntatore dello stack dopo aver visualizzato l'indirizzo di ritorno. Ciò è utile per molte implementazioni Pascal in cui il chiamante di una funzione spingerà gli argomenti nello stack prima di effettuare una chiamata di funzione e li farà saltare in seguito. Se una routine accettasse, ad esempio, parametri di quattro byte, potrebbe finire con "RET 0004" per ripulire lo stack. In assenza di tale istruzione, una convenzione di chiamata del genere avrebbe probabilmente richiesto che il codice inserisse l'indirizzo di ritorno in un registro, aggiornasse il puntatore dello stack e quindi passasse a quel registro.

È interessante notare che la maggior parte del codice (comprese le routine del sistema operativo) sul Macintosh originale utilizzava la convenzione di chiamata Pascal nonostante la mancanza di istruzioni di facilitazione nel 68000. L'uso di questa convenzione di chiamata ha salvato 2-4 byte di codice in un tipico sito di chiamata, ma ha richiesto un extra 4-6 byte di codice nel sito di ritorno di ogni funzione che ha assunto parametri.

Un esempio è MIPS, che ha sia adde adduper il trapping e l'ignoramento rispettivamente dell'overflow. (Anche sube subu.) Aveva bisogno del primo tipo di istruzione per linguaggi come Ada (penso - non ho mai usato Ada in realtà) che si occupano esplicitamente di overflow e il secondo tipo per linguaggi come C che ignorano gli overflow.

Se ricordo bene, la CPU effettiva ha alcuni circuiti aggiuntivi nell'ALU per tenere traccia degli overflow. Se l'unica lingua a cui la gente tenesse era C, non ne avrebbe bisogno.

La serie 5000 di Burroughs è stata progettata per supportare in modo efficiente ALGOL e l'iAPX-432 di Intel è stata progettata per eseguire in modo efficiente Ada. Inmos Transputer aveva la sua lingua, Occam. Penso che il processore "Propeller" di Parallax sia stato progettato per essere programmato usando la sua variante di BASIC.

Non è un linguaggio, ma il set di istruzioni VAX-11 ha una singola istruzione per caricare un contesto di processo, che è stato progettato su richiesta del team di progettazione VMS. Non ricordo i dettagli, ma ISTR ha impiegato così tante istruzioni per implementare che ha messo un limite massimo al numero di processi che potevano programmare.

Una cosa che nessuno sembra aver menzionato finora è che i progressi nell'ottimizzazione del compilatore (dove il linguaggio di base è in gran parte irrilevante) ha spinto il passaggio dai set di istruzioni CISC (che erano in gran parte progettati per essere codificati dagli umani) a set di istruzioni RISC (che erano in gran parte progettato per essere codificato dai compilatori.)

La famiglia Motorola 68000 ha introdotto alcuni modi di indirizzamento automatico che hanno reso la copia dei dati attraverso la cpu molto efficiente e compatta.

[Esempio aggiornato]

questo era un codice c ++ che influenzava l'assemblatore 68000

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

implementato in assemblatore convenzionale (pseudocodice, ho dimenticato i comandi dell'assemblatore 68000)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

con la nuova modalità indirizzo è diventato qualcosa di simile

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

solo due istruzioni per loop anziché 4.

Il mainframe della serie Z di IBM, è il discendente dell'IBM 360 dagli anni '60.

Ci sono state diverse istruzioni che sono state messe lì appositamente per accelerare i programmi COBOL e Fortran. L'esempio classico è il BXLE- "Branch on Index Low or Equal" che è la maggior parte di un forciclo Fortran o un COBOL PERFORM VARYING x from 1 by 1 until x > nincapsulato in una singola istruzione.

Esiste anche un'intera famiglia di istruzioni decimali impaccate per supportare l'aritmetica decimale a virgola fissa comune nei programmi COBOL.

Le prime CPU Intel avevano le seguenti funzionalità, molte delle quali ormai obsolete in modalità 64 bit:

• ENTER, LEAVE e RET nn istruzioni [i primi manuali spiegavano esplicitamente quelli introdotti per i linguaggi strutturati a blocchi, ad esempio Pascal, che supporta le procedure nidificate]
• istruzioni per accelerare l'aritmetica BCD (AAA, AAM, ecc.); anche supporto BCD in x87
• Istruzioni JCXZ e LOOP per l'implementazione di loop contati
• INTO, per generare una trappola sull'overflow aritmetico (ad es. In Ada)
• XLAT per ricerche da tavolo
• BOUND per il controllo dei limiti dell'array

Il flag di segno, che si trova nel registro di stato di molte CPU, esiste per eseguire facilmente l'aritmetica con segno E senza segno.

Il set di istruzioni SSE 4.1 introduce le istruzioni per l'elaborazione delle stringhe, sia conteggio che a terminazione zero (PCMPESTR, ecc.)

Inoltre, potrei immaginare che una serie di funzionalità a livello di sistema siano state progettate per supportare la sicurezza del codice compilato (controllo del limite di segmenti, porte di chiamata con copia dei parametri, ecc.)

Alcuni processori ARM, principalmente quelli nei dispositivi mobili, includono (d) l'estensione Jazelle, che è un interprete JVM hardware; interpreta direttamente il bytecode Java. JVM consapevole di Jazelle può utilizzare l'hardware per accelerare l'esecuzione ed eliminare gran parte di JIT, ma il fallback al software VM è ancora garantito se il bytecode non può essere interpretato su chip.

I processori con tale unità includono l'istruzione BXJ, che mette il processore in una speciale "modalità Jazelle", o se l'attivazione dell'unità non è riuscita, viene semplicemente interpretata come normale istruzione di diramazione. L'unità riutilizza i registri ARM per mantenere lo stato JVM.

Il successore della tecnologia Jazelle è ThumbEE

Per quanto ne so, questo era più comune in passato.

C'è una sessione di domande in cui James Gosling ha affermato che c'erano persone che cercavano di creare hardware in grado di gestire meglio il bytecode JVM, ma poi queste persone avrebbero scoperto un modo per farlo con il comune intel x86 "generico" (forse compilando il bytecode in qualche modo intelligente).

Ha detto che esiste un vantaggio nell'uso del chip generico generico (come quello di Intel) perché ha una grande società che lancia ingenti somme di denaro sul prodotto.

Vale la pena dare un'occhiata al video. Ne parla al minuto 19 o 20.

Ho fatto una rapida ricerca di pagine e sembra che nessuno abbia menzionato CPU sviluppate appositamente per eseguire Forth . Il linguaggio di programmazione Forth è basato su stack, compatto e utilizzato nei sistemi di controllo.

La CPU Intel iAPX è stata progettata specificamente per i linguaggi OO. Tuttavia, non ha funzionato del tutto.

L' iAPX 432 ( intel Advanced Processor architecture ) è stato il primo design a microprocessore a 32 bit di Intel, introdotto nel 1981 come set di tre circuiti integrati. Doveva essere il principale progetto di Intel per gli anni '80, implementando molte funzionalità avanzate di multitasking e gestione della memoria. Il design è stato quindi chiamato Micromainframe ...

L'iAPX 432 è stato "progettato per essere programmato interamente in linguaggi di alto livello" , con Ada come principale e supportava la programmazione orientata agli oggetti e la garbage collection direttamente in hardware e microcodice . Il supporto diretto per varie strutture di dati era inoltre destinato a consentire l'implementazione dei moderni sistemi operativi per iAPX 432 utilizzando un codice di programma molto inferiore rispetto ai normali processori. Queste proprietà e caratteristiche hanno portato a una progettazione hardware e microcodice molto più complessa rispetto alla maggior parte dei processori dell'epoca, in particolare i microprocessori.

Utilizzando la tecnologia dei semiconduttori del suo tempo, gli ingegneri di Intel non sono stati in grado di tradurre il progetto in una prima implementazione molto efficiente. Insieme alla mancanza di ottimizzazione in un compilatore Ada prematuro, ciò ha contribuito a sistemi di computer piuttosto lenti ma costosi, eseguendo benchmark tipici a circa 1/4 della velocità del nuovo chip 80286 alla stessa frequenza di clock (all'inizio del 1982).

Questo gap prestazionale iniziale con il profilo piuttosto basso e la linea 8086 a basso prezzo era probabilmente il motivo principale per cui il piano di Intel di sostituire quest'ultimo (in seguito noto come x86) con l'iAPX 432 non è riuscito. Sebbene gli ingegneri abbiano visto modi per migliorare un design di nuova generazione, l' architettura iAPX 432 Capability ora aveva iniziato a essere considerata più come un overhead di implementazione piuttosto che come il supporto semplificante che doveva essere.

Il progetto iAPX 432 è stato un fallimento commerciale per Intel ...

Il 68000 aveva MOVEM che era più adatto a spingere più registri nello stack in un'unica istruzione, che è ciò che molte lingue si aspettavano.

Se hai visto MOVEM (MOVE Multiple) che precede JSR (Jump SubRoutine) in tutto il codice, allora generalmente sapevi che hai a che fare con il codice C rispettato.

MOVEM ha consentito l'incremento automatico del registro di destinazione, consentendo a ciascun utilizzo di continuare a impilare sulla destinazione o di rimuoverlo dallo stack in caso di decremento automatico.

http://68k.hax.com/MOVEM

L'architettura AVR di Atmel è interamente progettata da zero per essere adatta per la programmazione in C. Ad esempio, questa nota applicativa elabora ulteriormente.

L'IMO è strettamente correlato con l'eccellente risposta di rockets4kids , con i primi PIC16 sviluppati per la programmazione diretta dell'assemblatore (40 istruzioni in totale), con le famiglie successive destinate a C.

Quando è stato progettato il coprocessore numerico 8087, era abbastanza comune per le lingue eseguire tutte le operazioni matematiche in virgola mobile utilizzando il tipo di massima precisione e arrotondare il risultato solo per ridurne la precisione quando lo si assegna a una variabile di precisione inferiore. Nello standard C originale, ad esempio, la sequenza:

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

favorirebbe ae bad double, aggiungerli, di promuovere ca double, inserirlo, e quindi memorizzare il risultato arrotondato a float. Anche se in molti casi sarebbe stato più veloce per un compilatore generare codice che avrebbe eseguito operazioni direttamente sul tipo float, era più semplice disporre di una serie di routine in virgola mobile che avrebbero funzionato solo sul tipo double, insieme alle routine da convertire in / da float, piuttosto che avere serie separate di routine per gestire le operazioni su floate double. L'8087 fu progettato attorno a quell'approccio all'aritmetica, eseguendo tutte le operazioni aritmetiche usando un tipo a virgola mobile a 80 bit [80 bit fu probabilmente scelto perché:

1. Su molti processori a 16 e 32 bit, è più veloce lavorare con una mantissa a 64 bit e un esponente separato rispetto a lavorare con un valore che divide un byte tra la mantissa e l'esponente.

2. È molto difficile eseguire calcoli che siano accurati con la massima precisione dei tipi numerici che si stanno utilizzando; se si sta tentando, ad esempio, di calcolare qualcosa come log10 (x), è più facile e veloce calcolare un risultato che è accurato entro 100 ppm di un tipo a 80 bit piuttosto che calcolare un risultato che è preciso entro 1 ppm di un 64 bit digitare e arrotondare il primo risultato alla precisione a 64 bit produrrà un valore a 64 bit che è più accurato del secondo.

Sfortunatamente, le versioni future della lingua hanno cambiato la semantica di come dovrebbero funzionare i tipi a virgola mobile; mentre la semantica 8087 sarebbe stata molto piacevole se le lingue li avessero supportati in modo coerente, se le funzioni f1 (), f2 (), ecc. restituiscono il tipo float, molti autori di compilatori si prenderebbero il caso di creare long doubleun alias per il doppio tipo a 64 bit piuttosto che il tipo a 80 bit del compilatore (e non fornisce altri mezzi per creare variabili a 80 bit) e per valutare arbitrariamente qualcosa come:

double f = f1()*f2() - f3()*f4();

in uno dei seguenti modi:

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

Si noti che se f3 e f4 restituiscono gli stessi valori di f1 e f2, rispettivamente, l'espressione originale dovrebbe restituire chiaramente zero, ma molte di queste ultime espressioni potrebbero non esserlo. Ciò ha portato le persone a condannare la "precisione in più" dell'8087 anche se l'ultima formulazione sarebbe generalmente superiore alla terza e - con un codice che utilizzava il doppio tipo esteso in modo appropriato - raramente sarebbe inferiore.

Negli anni successivi, Intel ha risposto alla tendenza del linguaggio (sfortunato IMHO) a forzare i risultati intermedi da arrotondare alla precisione degli operandi progettando i loro processori successivi in ​​modo da favorire quel comportamento, a scapito del codice che trarrebbe vantaggio dall'uso di precisione sui calcoli intermedi.