linux user group brescia

On Tue, May 13, 2003 at 11:18:20AM +0200, Marcello Urbani wrote:
> 
> 
> 
> Bauno wrote:
> 
> >On Monday 12 M
> >
> >I registri degli x86 (dal 386 in poi, athlon compreso) sono a 32 bit.
> >Saprai senz'altro (almeno, lo spero! :) che, prima di eseguire una
> >qualunque operazione, devi caricare gli operandi nei registri. Ne
> >
> Scusa la pedanteria, ma questo avviene nei processori RISC, su x86 si 
> può indirizzare direttamente la memoria (e spesso i compilatori lo 
> fanno, anche perchè questa architettura soffre di una cronica carenza di 
> registri).
> 
Mah... prima di eseguire una qualunque operazione gli operandi DEVONO
essere caricati nei registri... talvolta lo fa il processore per te
(usando alcuni dei suoi registri interni)... l'architettura di tutti
i processori moderni e' RISC-like ... il tempo per modificare direttamente
una locazione di memoria e' semplicemente esagerato [in quanto
dovresti pure usare il write-through, e ignorare la cache]

Venendo all'architettura ia32... non e' vero che ci sono pochi registri!
almeno, non e' vero che ci sono pochi registri sui processori prodotti
dopo il pentium; sono pochi (e questo e' seccante) i registri direttamente
indirizzabili... 

> >consegue che puoi operare al massimo su 32 bit x volta. Se usi variabili
> >a 64 bit, queste vengono caricate e manipolate un pezzo alla volta.
> >L'incremento prestazionale è nullo.
> >

Non e' del tutto corretto questo... le istruzioni SIMD (SSE1/2, 3DNOW,
pure MMX in piccola misura) consentono di lavorare con blocchi di 64 o
anche 128 bits... questo non rende la CPU un "processore a 128 bits",
pero'... Solitamente il "32 bits" si applica alla dimensione di indirizzamento
possibile direttamente e alle dimensioni native dei registri "general purpose";
non e' il numero massimo di bits su cui si puo' operare per volta
[ad es. l'FPU da sempre lavora con registri di 80bits (64 significativi)
ma il 387 non e' un processore ad 80 bits!]

Quello che interessa e' l'insieme di registri/unita' di indirizzamento/
pathways interne.

[paradossalmente la larghezza di bus c'entra poco: i primi alpha (EV4/EV45)
 erano processori a 64 bits (spazio di indirizzi di 64 bits, pathways 
 interne a 64 bits) ma avevano un bus a 32]

> Non ne sarei così sicuro: se non ricordo male il vecchio Z80, che aveva 
> i registri ad 8 bit, era in grado di fare alcune operazioni a 16 bit 
> accoppiandone due; comunque per lavorare su stringhe di bit la cosa è 
> irrilevante.
> 
Si'... questo e' vero e quei comandi erano (con terminologia moderna) di
tipo "simd" (Single Instruction, Multiple Data). Nel caso dello Z80, pero'
devi tenere conto che pure il bus era ad 8 bits... d'altro canto le
macchine "vecchie" erano progettate in modo molto diverso. Per intenderci,
 sino agli anni 90 il collo di bottiglia era il processore e NON la ram
come oggi.


> >Un'eccezione in realtà c'è, puoi usare il coprocessore matematico che ha
> >registri + lunghi (128 bit, se non mi ricordo male) x fare operazioni su
> >interi, xò tieni presente che:
> >1) Caricare gli operandi nei registri della FPU è dispendioso in termini
> >di cicli di CPU.
> >2) Devi forzare la cosa in assembly.
> >

Mah... la FPU disegnata per gli ia32 e' una cosa abbastanza 
agghiacciante... la cosa che suggerisci (senza usare le istruzioni SSE che
sono su registri "aliasati" a quelli della FPU) e' fattibile anche a
livello di compilatore (gcc 3.3), ma rende poco anche perche' il
coprocessore matematico come presente sui PC non consente l'accesso
diretto ai registri FPU ma solo tramite uno stack.

[tutto cambia se tu sfrutti SSE/SSE2, ma questa e' una altra storia]

> >Non sono peraltro aggiornato sulle prestazioni della FPU sulle
> >operazioni "tra interi", non giurerei sulla velocità...
> >  

Non e' il caso... credimi, non e' il caso di farlo... ripeto: io
non sono un sostenitore di intel, ma SSE2 e' veramente un miglioramento
per la virgola mobile.

> >
> Se non sbaglio (non conosco bene l'assembler) esiste una operazione per 
> passare il controllo dal processore al coprocessore matemetico, che sui 
> 386 richiedeva molto tempo, ma credo che ora sia stata ottimizata ad un 
> ciclo o 0, non so come influenza la pipeline.


Il problema non e' tanto il prefisso per passare il controllo alla FPU
quanto riorganizzare i registri in modo da poter agire sugli operandi
corretti... e questo richiede

0 cicli su Athlon e P-III
1 ciclo su P-IV

E' una cattiva idea comunque, anche se non provoca stallo della
pipeline: le istruzioni devono essere ridecodificate e questo 
richiede tempo.

> Comunque i registri del coprocessore sono organizzati a stack, e non so 
> se esistono opcode per accedere ai singoli bit, per cui temo sia una 
> cosa molto lenta.

No, no ci sono  tali istruzioni... per l'organizzazione a stack vedi
 sopra (in realta'
i registri sono accessibili direttamente, ma bisogna passare da una
"emulazione di stack" che non consuma cicli ma spazio nella pipeline)

Piu' che la velocita' (che non e' esaltante... nel caso del P-IV le
prestazioni della FPU `nativa' sono molto basse; sull'athlon e' una
storia diversa) e' la complessita' del tutto, i rischi di stallo
e il problema della parallelizzazione del codice che mi preoccupano
in questi casi...

> Comunque se lasci fare al compilatore non li usa (a meno di usare un 
> tipo di intero progettato apposta, credo che GCC ce l'abbia; ovviamente 
> queste features non sono portabili).
> 

Si'... concordo appieno... al compilatore e/o ad alcune librerie da
ottimizzare al massimo tipo la gmp (aritmetica in precisione multipla).

ciao,
 lg


> Marcello

--