[ASM] La vostra architettura preferita

[Z80Fan]

Originariamente inviato da MaxArt

Vero. Forse in elenco ci doveva essere l'Alpha piuttosto che, ad esempio, il poco significativo IA-64 di Intel.

Per elenco intendi il sondaggio? Se si, l'Alpha è incluso nella lista

Originariamente inviato da MaxArt

Comunque, complimenti Z80Fan: ci vuole qualcuno di davvero "hardcore" ogni tanto

Ti ringrazio Hai già visto il mio thread dove programmo un sistema operativo?

[MaxArt]

Originariamente inviato da Z80Fan

Per elenco intendi il sondaggio? Se si, l'Alpha è incluso nella lista

Devo essere cieco...

Ti ringrazio Hai già visto il mio thread dove programmo un sistema operativo?

E come si fa a non vederlo? Lascia tutti così:
Mi dispiace di non poterlo seguire come si deve, un lavoro a tempo pieno non mi consente di fare molto

[Z80Fan]

Chiedo un vostro parere su questa idea:
Facciamo che devo costruire un processore quasi-RISC. Per aumentare le prestazioni decido di usare una pipeline. Nonostante progetto bene il set di istruzioni, vedo che in molti casi si potrebbero verificare stalli sulla pipeline, e questo mi costa molto lavoro nella circuiteria di controllo. Secondo voi è meglio creare la circuiteria complessa, e che mi impone una frequenza inferiore, o creare una pipeline che non esegue una istruzione ogni ciclo di clock, ma che non mi crea stalli e mi permette di innalzare la frequenza?

[cionci]

Un po' troppo generica la domanda. Mi immagino che tu abbia già un branch predictor. A cosa sono dovuti gli stalli della pipeline ? Al fallimento del branch predictor ? Ai cambi di contesto ? La pipeline è corta o è profonda (stile P4) ?
Se aumenti la circuiteria di controllo (mi immagino il branch predictor) od ottieni un critical path maggiore di quello dello stage più lento allora devi per forza diminuire gli stage.

[Z80Fan]

Originariamente inviato da cionci

Un po' troppo generica la domanda. Mi immagino che tu abbia già un branch predictor. A cosa sono dovuti gli stalli della pipeline ? Al fallimento del branch predictor ? Ai cambi di contesto ? La pipeline è corta o è profonda (stile P4) ?
Se aumenti la circuiteria di controllo (mi immagino il branch predictor) od ottieni un critical path maggiore di quello dello stage più lento allora devi per forza diminuire gli stage.

Ok, rettifico:
La pipeline è corta, con non più di 5-6 stadi. Al branch predictor non ci avevo pensato, presumiamo che non ci sia (anche perchè penso sia anch'esso un elemento complesso, e torniamo al discorso di prima), gli stalli avvengono per dipendenze dei dati.

Cmq forse è meglio che chiarisco il dubbio:
mettiamo che l'unico problema sia la dipendenza dei dati. I dati vengono presi direttamente dai registri e calcolati nel blocco execute, poi c'è un blocco di accesso alla memoria, e poi c'è il blocco di scrittura registri. Avendo la stessa pipeline, è meglio aggiungerli il controllo degli stalli ma facendola andare ad una frequenza inferiore (con caso ideale = una istr. ogni clock), o intervallare tutte le istruzioni con 2 nop in modo che sono assolutamente sicuro che quando una istruzione arriva in execute, l'istruzione precedente ha già eseguito il salvataggio dei registri (o lo sta facendo in quel momento, precisando che l'execute prende i dati aggiornati), ma avendo una frequenza più alta visto che si semplifica il circuito (qui il caso ideale è una istr ogni 2 cicli di clock).

[cionci]

E' in-order o out-of-order ?

[Z80Fan]

Originariamente inviato da cionci

E' in-order o out-of-order ?

in-order

[MaxArt]

Originariamente inviato da Z80Fan

in-order

Ci credo, se lo vuoi tenere semplice.

Si può ancora considerare semplice se ci aggiungi un quintale di cache?

[cionci]

Originariamente inviato da Z80Fan

in-order

Data la pipeline corta, il risultato che crea dipendenza può essere reso disponibile all'istruzione successiva subito prima dell'esecuzione del calcolo nella ALU.
La ALU può aggiornare il register file (temporaneo, non quello disponibile al programmatore) con il risultato dell'esecuzione dell'istruzione precedente.

Ad esempio:

|F|D|X|M|W|
  |F|D|X|M|W|

Se c'è dipendenza, in ogni caso la fase di esecuzione lavorerà comunque con il risultato aggiornato ottenuto dalla fase di esecuzione dell'istruzione precedente. In pratica l'uscita viene subito scritta in un register file temporaneo da cui viene preso il valore per l'esecuzione successiva.

[cionci]

Altrimenti c'è la cosiddetta tecnica delle bubble, cioè si ritarda l'esecuzione di tutte le istruzioni successive nella pipeline di tot cicli necessari a risolvere la dipendenza.

[Z80Fan]

Originariamente inviato da MaxArt

Si può ancora considerare semplice se ci aggiungi un quintale di cache?

Solo se è cache direct mapped, che è semplice da implementare

Originariamente inviato da cionci

Data la pipeline corta, il risultato che crea dipendenza può essere reso disponibile all'istruzione successiva subito prima dell'esecuzione del calcolo nella ALU.
La ALU può aggiornare il register file (temporaneo, non quello disponibile al programmatore) con il risultato dell'esecuzione dell'istruzione precedente.

Ad esempio:

|F|D|X|M|W|
  |F|D|X|M|W|

Se c'è dipendenza, in ogni caso la fase di esecuzione lavorerà comunque con il risultato aggiornato ottenuto dalla fase di esecuzione dell'istruzione precedente. In pratica l'uscita viene subito scritta in un register file temporaneo da cui viene preso il valore per l'esecuzione successiva.

è una buona idea, ma non funziona se il risultato precedente deve essere prelevato dalla memoria. In questo caso, l'execute deve fermarsi per 1 ciclo (EDIT: passo) (presumendo che anche la fase di memoria scrive nei registri shadow, ma in questo caso non servirebbe neanche la fase di scrittura registri)

Originariamente inviato da cionci

Altrimenti c'è la cosiddetta tecnica delle bubble, cioè si ritarda l'esecuzione di tutte le istruzioni successive nella pipeline di tot cicli necessari a risolvere la dipendenza.

Ecco, io pensavo di applicare una bubble di un ciclo (EDIT: passo) indiscriminatamente a qualsiasi istruzione, per evitare qualsiasi tipo di controllo. Può funzionare?

[cionci]

Originariamente inviato da Z80Fan

è una buona idea, ma non funziona se il risultato precedente deve essere prelevato dalla memoria. In questo caso, l'execute deve fermarsi per 1 ciclo (presumendo che anche la fase di memoria scrive nei registri shadow, ma in questo caso non servirebbe neanche la fase di scrittura registri)

Per le dipendenze in memoria non ci sono soluzioni valide, se non la cache. Bisognerebbe anche vedere quanti cicli occupa la lettura dalla cache. Ed in ogni caso se c'è un cache miss siamo punto e a capo. Un lettura dalla memoria occupa molti più di un ciclo...

[Z80Fan]

Originariamente inviato da cionci

Per le dipendenze in memoria non ci sono soluzioni valide, se non la cache. Bisognerebbe anche vedere quanti cicli occupa la lettura dalla cache. Ed in ogni caso se c'è un cache miss siamo punto e a capo. Un lettura dalla memoria occupa molti più di un ciclo...

Anche questo è vero...
Cmq sopra intendevo dire "l'execute deve fermarsi per 1 passo di pipeline ", visto che cmq abbiamo detto che non è out-of-order. La dipendenza non la intendevo come lentezza nell'aspettare la memoria, più che altro intendevo che la scrittura del dato cmq deve farla al passo successivo.
Sulla bubble indiscriminata cosa ne pensi?

[cionci]

Non ho capito cosa intendi... Lasciamo da parte le dipendenze in memoria e il bubble. La scrittura vera la può fare quando vuole, l'importante è che il dato aggiornato si trovi nel register file invisibile intermedio non appena finisce lo stage X.

[Z80Fan]

Originariamente inviato da cionci

Non ho capito cosa intendi...

Tranquillo, mi sono accorto di aver creato un po' di confusione

Originariamente inviato da cionci

Lasciamo da parte le dipendenze in memoria e il bubble. La scrittura vera la può fare quando vuole, l'importante è che il dato aggiornato si trovi nel register file invisibile intermedio non appena finisce lo stage X.

Ok, fin qui non ci piove. Io avevo cominciato a discutere nel caso avessimo una situazione del genere:

...
1] carica R1 da memoria
2] operazione con R1
...

Avevo preso come riferimento lo schemino che avevi fatto tu (|F|D|X|M|W|), dove X doveva aspettare la fine di M (o la fine di W se M non aggiorna i registri shadow alla fine dell'operazione, come abbiamo ipotizzato per X) prima di operare. Se non volessimo avere nessun sistema di controllo di stalli, imponevamo che qualsiasi istruzione fosse intervallata dall'altra di un passo di pipeline, così avevamo:

|F1|..|..|..|..|
|..|D1|..|..|..|
|F2|..|X1|..|..|
|..|D2|..|M1|..|     // M1 prende dalla memoria (eventualmente bloccando tutto il processore finché non ha finito) e scrive subito il ris. nei registri shadow
|F3|..|X2|..|W1|     // X2 prende i dati giusti dai registri shadow mentre W1 aggiorna i registri "ufficiali"

e non si creavano stalli per dipendenze di dati.

[cionci]

In questo caso ci vuole una cache L1 per i dati. Difficile farne a meno.

[Z80Fan]

Originariamente inviato da cionci

In questo caso ci vuole una cache L1 per i dati. Difficile farne a meno.

Ok. Grazie mille per le risposte

[Z80Fan]

Se io ho un ciclo come questo:

for(...)
{
    if(condizione)
    {
        codice1
    }
    else
    {
        codice2
    }
}

premettendo che la condizione rimane costante per tutto il ciclo (è sempre o vera o falsa), il branch predictor dovrebbe "capire" che il salto dato dalla condizione dell'if è sempre preso (o non preso), quindi non ci dovrebbero essere stalli ad ogni ciclo per via del mancato salto dopo la condizione, vero?
Devo scrivere un codice del genere che deve avere alte prestazioni, ed ero indeciso se fare così, o scrivermi dei for separati scelti in base alla condizione.

[cdimauro]

Se la condizione è statica, meglio due for separati, ma se sei sicuro che la CPU implementa un branch predictor, allora puoi star tranquillo.

Solo che i due for separati in ogni caso ti garantiscono l'esecuzione di meno istruzioni (non c'è il check e il branch).

[MaxArt]

Anche se è meno elegante, for separati tutta la vita. In ogni caso sono più performanti, o almeno non mi risulta alcuna architettura in cui possa verificarsi il contrario (né mi viene in mente come potrebbe accadere).

Questi ragionamenti li devo fare di continuo sviluppando in JavaScript, dove l'ottimizzazione è ridotta a zero o quasi.