Newsgroup: it.comp.hardware.cpu
Titolo: considerazioni RAM

In "Architettura dei processori" si parla di "Gerarchia della Memoria" per
certi principi:
1)  Il principio "Smaller" is "Faster"
2)  vi e' una disposizione (sintetica) a triangolo nel senso che:
scusate per la grafica schifosa...
                                                             _____
                                                             /
                                                            /
                           ______________/
                  ____/
                 /
  Registri(L1)       L2                    RAM           ---> dischi
                 \____
                           \_____________
                                                           \_______
                         -------------------> piu'  grande
                       piu' veloce       <-----------------
Il dato o l'istruzione viene cercata prima nella memoria che piu' e' vicina
poi a scendere dal triangolo fino eventuale ai dischi
1) La cache di primo livello e' sempre (per quel che ne so...) all'interno
della
    CPU
     Nei PMMX, P2 e nei K6 e' 32Kb (16 per i dati e 16 per le istruzioni),
mentre
     nei pentium normali e' di 16 in totale.
    Si utilizza in questo caso la SRAM (RAM Statica) perche' siccome non
    necessita nessun rinfresco dei dati risulta molto veloce(ma piu' costosa
    e ingombrante)  Le celle (i Bit) sono costituiti da qualche (4 o 5)
transistor
    bipolare, in pratica essi formano un Flip-Flop. Proprio per questo
necessi
   tano tanto spazio.
   L' Unita' Logico Aritmatica (ALU) che e' il "cuore" della
    CPU la utilizza per riporvi gli ultimi dati utilizzati, secondo il
principio che
    molto spesso questi dati vengono riutilizzati piu' volte nello spazio di
    pochi clock. Tutte le informazioni che stanno nella L1 stanno automatica
    mente anche nella L2 e nella RAM di sistema.
2)La cache di secondo livello (L2) puo' essere o sulla scheda madre, o allo
    interno della cartuccia della CPU o addiritura nella CPU stessa.
    Il tipo di memoria utilizzatata  e' anche in questo caso statica. Ma
meno
    veloce della L1 (anche nel caso di parita' di clock) perche' piu'
distante
    dalla ALU (credo anche nel caso che sia interna alla CPU)
3) La RAM di sistema e' invece di tipi DRAM (dinamico) e quindi:
  a) Siccome l'informazione e' sotto forma di carica di un condensatore
       (si usano infatti dei transistors MOS ad alta impedenza che possono
        fungere da condensatori) La memoria Necessita il rinfresco del dato
        ogni 2 o al massimo 4millisecondi  (attualmente  forse durano un po'
piu')
       altrimenti il "condesatore si scarica" e perdo il dato!
     b) per questo motivo la memoria e' un po' piu' lenta della SRAM
    c) in compenso' pero' occupa poco spazio ==> Grandi Capacita'
    d) il refresh puo' essere gestito internamente (Pseudo Static RAM)
Per rispondere a Maurizio, se hai una cache L2 piu' grande puo' contenere
piu' informazioni veloci, dunque arrivano piu' velocemente alla ALU e ne
consegue che hai prestazioni migliori.
Ciao Attilio.
P.S. Per Paolo: Tutti i dati che fornisco sono ricavati da un corso cui ho
                            partecipato al secondo anno della scuola di
ingegneria
                            informatica di Manno (Lugano), inoltre abbiamo
discusso
                           delle memorie, e quindi dei transistor alla
scuola che ho
                            frequantato prima di iscrivermi in ingegneria
"Scuola
                            degli elettronici in Audio e Video (SCEAV)".
           Questo lo dico solo per garantire l'affidabilita' delle
informazioni.

consegue che hai prestazioni migliori.
beh dipende dall'algoritmo di caching che stai usando. in genere e' vero ma
le prestazioni oltre un certo quantitativo di cache aumentano di mooooolto
poco. diciamo che tra 512k e 1M con i processori attuali la differenza si
sente solo con un multitasking pesante (e ovviamente nei bench, che pero'
servono a poco). 2M in pratica servono solo per i grandi server.
ciao
PS complimenti per le spiegazioni e la chiarezza (NON E' IRONICO)

Gtrevize)
tutto abbastanza giusto, permettimi solo un paio di precisazioni "a latere".
il fatto che le memorie veloci sono in genere piccole dipende essenzialmente
da fattori economici (una cella SRAM magari in tecnologia GaAsFET che regge
clock di qualche decina di GHz costa indubbiamente moooooooolto di + di una
classica MOS). in effetti esistono anche problemi tecnici, in particolare di
dissipazione, ma sono secondari.
Attilio 2a risposta)
Questo e' vero ma c'e' da dire che anche se si potesse spendere senza
problemi, non sarebbe molto + efficace dal punto di vista delle prestazioni
poiche' dopo una certa quantita' non ha piu' molto senso (siccome di cache
si
parla). Allora piuttosto di avere (paragone estremo nel caso potessi
spendere
tutto quello che voglio) 32MB di cache che rendono poco piu' di 1MB di cache
dello stesso tipo , uso quella memoria direttamente come RAM si sistema
che come tale e' gestita (per cui vi sono tutti i file che necessitano al
S.O. per
far girare il kernel, e tutti i file per i miei programmi; invece la cache
non
renderebbe perche' e' gestita in tutt'altro  modo , come descritto
brevemente
prima.
Gtrevize)
i k6 hanno 32k per i dati e 32k per il codice in modalita' non sovrapposta
(non-sharing).
si utilizza la SRAM come cache, oltre giustamente al fatto che non necessita
di refresh, perche' e' + veloce come tempo di accesso ai dati e puo'
tecnicamente reggere clock molto alti. btw si puo'
tecnicamente fare una SRAM anche a MOS.
Attilio2)
Certamente, la frequenza e' data dall'inverso del tempo di accesso...
Ma perche' dovresti usare i MOS per fare le SRAM , che ti costerebbe
sicuramente di piu'? Che poi si possa fare non ci sono dubbi  ):-)
,,,\
Attilio 1)
 L' Unita' Logico Aritmatica (ALU) che e' il "cuore" della
CPU la utilizza per riporvi gli ultimi dati utilizzati, secondo il
principio che
molto spesso questi dati vengono riutilizzati piu' volte nello spazio di
pochi clock. Tutte le informazioni che stanno nella L1 stanno
Gtrevize)
mmmmhhhh.... in genere per questo particolare tipo di operazioni si usano
dei buffers ad uso esclusivo della (anzi delle) ALU. in pratica sono dei
registri ad uso riservato. se invece il dato serve a + istruzioni
consecutive allora e' esatto, ma non e' la alu a gestire la cache. esiste
uno speciale controller che sovrappone logicamente gli indirizzi di memoria
con le locazioni fisiche della cache (l'ho proprio semplificata al max!!)
che rende il tutto trasparente alla cpu.
non vorrei sbagliare ma mi ricordavo un refresh un tantino + rapido di 1ms
per la DRAM... (forse intendevi us?).
Attilio 2)
I buffers che dici tu sono: l'accumulatore (che pero' contiene una sola
parola
di 4byte normalmente, ed e' per i Dati) che e' collegato direttamente all'
ALU
ed alla parte di cache L1 che contiene i dati, per lavorare come segue:
  1) Il dato viene preso dalla L1 per essere trasferito nell' accumulatore.
       Solo se si necessita di due operandi.
        In questo modo si ha un operando pronto a essere utilizzato dall'ALU
  2) Un altro dato e' pronto nella L1 (anche lei collegata all'ALU)
        Secondo operando. O primo se ne richiede uno solo.
  3)Non appena l'ALU riceve il tipo di istruzione da eseguire (che e' stata
caricata
        in un secondo accumulatore, spesso ACC X, per l'istruzione, e che
proviene
        dall' Instruction Register (IR) ) allora il calcolo viene effettuato
ed il
       risultato viene a sua volta messo nell' ACC A (cosicche' e' pronto a
essere
      riutilizzato o a essere restituito).
Ci sono inoltre dei Flag che sono per esempio: carry, overflow, ed altri che
servono per il salto condizionale (in assembler: BCS Branch if Carry Set ed
altri) che nient'altro sono che dei singoli bit.
Chiaramente a gestire la L1 non e' l'ALU, ma la Control Unit che si occupa
comunque di controllare quasi tutto all'interno della CPU (tranne gli I/O).
Ma quelli che definisci "Registri ad uso riservato" e' in effetti proprio la
L1.
(Sono i famosi registri che in C si usano per allocare le variabili con la
parola chiave REGISTER, ma che a volte il compilatore, pur non segnalando
errore, non lo permette per motivi di spazio)
Attilio 1)
Per rispondere a Maurizio, se hai una cache L2 piu' grande puo' contenere
piu' informazioni veloci, dunque arrivano piu' velocemente alla ALU e ne
consegue che hai prestazioni migliori.
Gtrevize)
beh dipende dall'algoritmo di caching che stai usando. in genere e' vero ma
le prestazioni oltre un certo quantitativo di cache aumentano di
mooooolto>poco. diciamo che tra 512k e 1M con i processori attuali la
differenza si
sente solo con un multitasking pesante (e ovviamente nei bench, che pero'
servono a poco). 2M in pratica servono solo per i grandi server.
ciao
PS complimenti per le spiegazioni e la chiarezza (NON E' IRONICO)
Attilio 2)
Hai perfettamente ragione, e' stata una mia dimenticanza.
Pero' 1MB non mi dispiacerebbe comunque...  :-)
Ciao, Attilio.

Scusa una dimenticanza:
i dati che ho io parlano di "da 2 a 4 millisecondi" ma potrebbe esserci
un'errore
(anche se dubito) . Cmq se fossero microsecondi sarebbe peggiore la
situazione, rispetto ai ms, perche' bisognerebbe rinfrescare l'informazione
mille volte di piu'.
Ciao, Attilio.

errore, non lo permette per motivi di spazio)
no, mi dispiace, ma qui sbagli. l'architettura che hai descritto e' quella
tipica dei 386 (che infatti per fare una divisione FP impiegavano + di 100
clock), attualmente, se proprio vogliamo fare un discorso tecnico, ad ogni
ALU vengono assegnati 2 (ma possono essere di piu' nei processori tipo
l'alpha) registri in cui mantenere i risultati parziali di un singola
microistruzione (non il codice macchina, nota bene). infatti se ho un
sistema pipelined, magari a molti stadi, e mi servono (per esempio) 20 clock
per completare una singola istruzione in FP (tipo una FDIV), se dovessi ogni
volta richiedere il dato di un calcolo intermedio alla cache mi
occorrerebbero minimo altri 40 clock (supponendo, e non e' vero, che la
cache tiri fuori il dato in 1 clock) cioe' in tutto 60. si avrebbe cioe' un
rallentamento drammatico, con svuotamento della pipeline. invece dal 486 ( o
dal P5, non mi ricordo) in poi si usano questi buffers, o registri, che non
sono accesibili, messi sui due canali di accesso della alu (eventualmente
con una configurazione a stack, come nell'alpha). il tuo disorso sarebbe
giusto se (anzi quando, visto che ci stiamo arrivando) le istruzioni date
alla cpu (ADD, MOV, etc) fossero completate in un singolo clock, cioe' 1
clock per il fetch, 1 per il decode, 1 per l'execute (e' proprio
quest'ultimo il problema).
ciao


scusa, non mi ero accorto che avevi postato anche sul NG
ciao