Newsgroup: it.comp.hardware.cpu
Titolo: Cosa è un MHz?

Tranquilli, lo so cosa è.
Ma cosa misura di preciso la velocità di un processore?
La frequenza è l'inverso di un periodo, ma di quale periodo si sta parlando?
Forse di quanto ci mette il processore a fare un MOV AX,AX?
Non credo. Ergo... aiuto!
MaxArt

 
No. Allora... un processore e' un circuito digitale sincrono. Ergo 
possiede un clock (un segnale che, ciclicamente (con una certa 
frequenza) "accende" il processore (ok, non e' proprio cosi', il clock e' 
esterno e viene deciso in base a vari fattori). Quel clock e' la 
velocita'. 
-- 
* Jotaro Kujo *
 Can't you see the end
 Twentieth Century Man ? 

un giro di clock equivale ad un'istruzione...
credo...
e domando io..
istruzioni sono i vari if , for, while del c++?
oppure sono istruzioni anche return, cout e cin?
o non c'entra niente?
--
visita fRienDs iT biS:
http://www.friendsitbis.bbk.org
"Non siamo nemici ma amici. Non dobbiamo essere nemici.Anche se la
passione puo averci fatto vacillare non puo rompere i profondi legami 
del nostro affetto. Le corde mistiche della memoria risuoneranno 
quando verranno toccate come se a toccarle fossero i migliori angeli della
nostra natura." American History X




 o non c'entra niente?
Per istruzioni di solito si intende istruzioni macchina.
--
________________________________
per rispondermi iliasba(at)
tin.it
bye Brain

 o non c'entra niente?


 > o non c'entra niente?


un giro di clock equivale ad un'istruzione...
assolutamente no, un giro di clock equivale al tempo di
accensione\spegnimento dei transistor (moooolto semplificato...)
poi quanti cicli di clock siano necessari per un'istruzione (o quante
istruzioni sia possibile fare in un giro di clock) dipende da come
l'architettura e' realizzata, ma questo e' del tutto indipendente dal ciclo
di clock (in questo caso si parla di efficienza dell'architettura)
---
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
    I bimbi buoni vanno in paradiso.
    I bimbi cattivi vanno dove gli pare!

Ciao Stefano.


accensione\spegnimento dei transistor (moooolto semplificato...)
[cut]
Allora vediamo se ho capito....
| pipeline 1 | pipeline 2 |
|------------|------------|
|istr 1a     |istr 2a     | stadio a
|istr 1b     |istr 2b     | stadio b
|istr 1c     |istr 2c     | stadio c
|istr 1d     |istr 2d     | stadio d
|istr 1e     |istr 2e     | stadio e
|istr 1f     |istr 2f     | stadio f
|istr 1g     |istr 2g     | stadio g
|istr 1h     |istr 2h     | stadio h
Da quanto detto da Brain deduco che le pipeline sono degli stack di
tipo LILO (last in last out) delle istruzioni, che ad ogni ciclo di
clock vengono portate avanti in PARALLELO, così ad esempio l'istr 1a e
l'istr 2a passano dallo stadio a allo stadio b.
Da quanto detto da Maurizio invece deduco che ad OGNI ciclo di clock
viene mandato, per così dire, un picco di energia alla CPU che
rilegge, e fa avanzare, lo stack.
Ora, ragionandoci su deduco che quelle che nel mio schemino sono
chiamate istr1a(b, c, ...) e istr2a(b, c, ...) sono le istruzioni BASE
contenute nei registri del processore (ad es il set di istruzioni x86)
mentre l'istruzione a cui si riferisce MaxArt (una istruzione
assembler che credo sposti dei dati contenuti in un registro di
memoria ad un altro) sia un qualcosa di già a più alto livello.
Esempio per accedere alla ram devo prima mandare un msg al bus e poi
attendere la risposta, quindi almeno 2 cicli di clock. Altro esempio è
l'istruzione fdiv (citata da Simone Tugnoli nel post 1GHz: Attila vs.
Cumine) che utilizza 6 cicli di clock.
Non sono un esperto di questi argomenti però mi interessano molto, stò
raccogliendo in proposito molte domande che vengono fatte sul NG a
proposito dell'architettura dei processori per farne una FAQ, se
qualcuno volesse collaborare ne sarei molto contento.
Ciao Stefano.

grazie mille ad entrambi

 memoria ad un altro) sia un qualcosa di già a più alto livello.
No, le istruzioni assembler corrispondono (quasi biunivocamente) con le
istruzioni del codice macchina x86.
istr1 corrisponde ad una istruzione macchina/assembler, le cpu di adesso le
suddividono in passi a,b,c ma questo non so come funzioni.


qualcuno volesse collaborare ne sarei molto contento.
Salve!
Se ti interessa, qui trovi una guida (in inglese) di piů di mille 
pagine sul linguaggio assembly. Risale a qualche anno fa, ma nei 
capitoli introduttivi si fa anche riferimento (in termini 
divulgativi, entry level direi) alla struttura hardware di un pc.
Ecco il link:
http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/ArtofAsm.html
-- 
Bye.
       Lem
----------------- 'CLOCK is what you make of it' -----------------
Ricerca nuovi numeri primi: 
www.entropia.com/primenet/status.shtml

 o non c'entra niente?
Non c'entra niente... :-\
Il C++ è un linguaggio costruito, e *non è* il linguggio con cui opera il
processore.
Quello è il linguaggio macchina, o assembler. Il linguaggio C++ viene
"tradotto", quando viene compilato, in linguaggio macchina.
Adesso, se non ho capito male dalle altrui risposte, un'istruzione basilare
assembler corrisponde ad un ciclo di clock...
MaxArt

 macchina ) in un secondo.
Sin qui lo sapevo bene. Quello che mi chiedevo è: cosa fa un processore in
un ciclo?
MaxArt

 it.polemica.intelvsamd o una costola di i.c.h.o) dove meglio che qui?
DEO GRATIAS, una cosa che in nulla e per nulla è OT :-)
Fatemi i complimenti, eheh
MaxArt

Non ci ho capito una mazza ^__^
beh, allora, sia Intel che NexGen (in effetti l'idea la ha avuta per prima
NexGen, ma dati i "problemini" di questa casa (1) intel ne e' uscita per
prima con il risultato pratico) hanno deciso di trovare una soluzione al
vecchio problema che verteva su come ridurre drasticamente il numero
assurdo di transistor necessari per far girare un set di istruzioni
incasinatissimo come quello x86.
perche' fra modo reale, modo protetto, modo (put your mode here), i
processori x86 avevano preso decisamente una brutta china, virtualmente
impossibile da sviluppare ulteriormente senza tirar fuori die grossi come
tavolini da pocker.
i tipi di NexGen provarono un po' a dare un occhiata alle architetture
"risc" (2) e si accorsero (facile...) che a pari prestazioni un unita' risc
poteva avere un numero di transistor di _unita' di misura_ inferiore....
facendo due somme, dissero, se noi mettiamo su un sistema "pseudo risc" che
si basi sulle istruzioni x86 ridotte ai minimi comuni denominatori, con
sopra un secondo preprocessore che si occupi unicamente della traduzione
fra la versione "complessa" del codice x86 e quella ridotta Risc86 (questa
e' la denominazione ufficale...), siamo capaci di velocizzare enormemente
l'esecuzione del codice, garantirci una strada aperta a sviluppi futuri,
riduciamo il die-size a dimensioni ragionevoli ed, infine, risparmiamo
perfino un casino di soldi sia in fase di sviluppo (grazie alla ridotta
complessita' dell'architettura) che di produzione (grazie al ridotto numero
di transistors), il che male non fa di certo.
Intel si butto' su questa idea a pesce, e approfittando dei ritardi di
NexGen riusci' a tirar fuori i propri processori con amplio anticipo....
ora, tralasciando questa storiella che non e' proprio del tutto esatta ma
e' quanto di meglio sono riuscito a tirar fuori in dieci minuti (chiedo
scusa.... :-), il punto e' al giorno d'oggi i compilatori continuano a
tirar fuori codice x86, ottimizzato - certamente, ma al codice interno
Risc86 nessuno puo' accedere direttamente! certo, sarebbe _tanto_
divertente poter disabilitare il preprocessore e giocherellare con il core
"risc", ma i processori non lo permettono purtroppo.
personalmente non sono riuscito a trovare i riferimenti diretti sui timing
di traduzione x86-risc86 (ovvero, quando tu passi al processore
un'istruzione x86 "complessa", in quante risc86 viene trasformata? e come
vengono eseguite queste?) e i timing esecutivi delle istruzioni risc86 (ma
non e' che mi ci sia sbattuto piu' di tanto nella ricerca.... :-), puo'
darsi che spulciando in giro tu trovi qualcosa....
(1) NexGen si lancio' nel progetto K6, un processore rivoluzionario che
avrebbe dovuto spedirla direttamente nel settore server, anticipando e
obnubilando (si, beh, la loro idea era questa, insomma.... :-)  i
PentiumPro, con prezzi inferiori e prestazioni ben superiori - peccato che
nella fase finale del progetto (come succede inevitabilmente ai "piccoli"
con idee piu' grandi di loro) i soldi finirono, alla fine AMD si incorporo'
tutto quanto e fini' per lanciare il k6 (che noi tutti amiamo... :-) giusto
giusto con qualche ritocchino (Ad esempio le MMX ancora non esistevano
all'epoca del progetto originale) - peccato che fra il rallentamento dello
sviluppo per carenza di fondi, il periodo fallimentare, l'incorporazione in
amd, la ristrutturazione ed i ritocchi alla fine il k6 e' giunto sul
mercato anni dopo il target iniziale - cosa che ha trasformato un
prospettivo prodotto rivoluzionario nella fascia server in un processore
home economico. 
(2) i termini Risc e Cisc sono stati abusati dai produttori di cpu fino
dalla loro piu' tenera eta'.
visto che purtroppo nessuno ha pensato ad avvertire il TelefonoAzzurro, ci
dobbiamo rasegnare a continuare ad usarli nonostante siano palesemente
inadatti a rappresentare i processori odierni.


NexGen, ma dati i "problemini" di questa casa (1) intel ne e' uscita per
ah, un piccolo addendum che  mi e' venuto a mente - giusto per confondere
ulteriormente le idee: 
In realta' l'idea di ridurre il set di istruzioni senza perdere la
compatibilita' e' stata implementata per prima da Motorola nel suo 68040
(per lo meno parlando di processori mainstream....) che aveva una fpu
integrata con un set di istruzioni ridotto alle operazioni elementari.
purtroppo in questo caso l'implementazione non era delle migliori - l'fpu
si appoggiava ad un "integratore" software che ricreava le istruzioni fp
mancanti appoggiandosi alla alu.
in questo modo avevano ottenuto una fpu estremamente veloce con codice
ultraottimizzato (dalle 4 alle 8 volte piu' veloce di un 68882 di pari
frequenza, rispetto ad un 486 proprio non c'era paragone), ma con codice
standard IIEE i risultati erano penosi a dire poco (sempre migliori che con
un 486.... Intel ha capito come si fanno le fpu solo a partire dai
Pentium.... ^____^)


processore.
questo lo so...quello che volevo dire è se in un civclo di clock il
processore riesce a fare un'istruzione di quel tipo tradotta da c++ a
linguaggio macchina...
(credo che mi sono spiegato malissimo :((()


I Mhz sono l'unità di misura della frequenza di clock. L'inverso dei
Mhz, quindi, è il 'tempo di ciclo'.
Una cpu è una 'rete sequenziale' ed al suo interno si trovano
alcuni elementi di memoria, nella fattispecie i registri.
Ad ogni colpo di clock, esempio ad ogni arrivo di un fronte di salita,
tutti gli elementi di memoria vengono scritti. Ad esempio cosa
succede ad un registro? Agli ingressi del registro si troverà un certo
valore, quando arriva il fronte di salita tale valore sarà memorizzato
dal registro, e prima che arrivi il fronte di discesa le uscite del
registro dovranno essere stabili.
Supponiamo ora di avere una cpu a pipeline, ogni stadio di essa compirà
una 'passo elementare'. Cioè l'esecuzione di ogni istruzione viene scomposta
in una serie passi elementari successivi. Ogni stadio porterà a termine
uno di questi passi.
La durata del tempo di ciclo sarà determinata dal tempo impiegato dallo
stadio più lento. Cioè il clock scandirà il fluire attraverso la pipeline,
ma ovviamente questo flusso dovrà aspettare che ogni stadio abbia finito. In
definitiva, quindi, dovrà aspettare lo stadio più lento (che fa da collo
di bottiglia).
Se ne deduce che nessun overclocker potrà mai abbreviare il tempo di ciclo
della sua sventurata cpu, oltre il tempo impiegato dallo stadio più lento.
Una cpu RISC è fortemente orientata ad far scorrere le istruzioni di 
un passo ad ogni ciclo, mentre una CISC permette a certi stadi molto
lenti, di impiegare più cicli. Questo crea degli 'ingolfamenti', in quanto
se uno stadio si prende molti cicli, anche tutti gli altri dovranno
aspettarlo. Ovvero il fluire delle istruzioni sarà bloccato per un 
certo periodo.
Dopo tutto questo sproloquio, forse ti sarà meno chiaro che mai che un
mhz non si misura sul tempo impiegato per effettuare una MOV, una JMP o
quant'altro. E' solo (semplificando) determinato dal tempo impiegato 
dalla pipeline 'per fare un scatto in avanti'.
Nota : perchè le cpu moderne hanno sempre più stadi? Poichè se si esegue
la stessa istr con 10 stadi, anzichè con 5, significa che ogni stadio
dovrà fare meno cose e quindi sarà più veloce. Di conseguenza lo stadio
più lento sarà (si spera) più veloce e così si potrà aumentare il clock.
Comqune non è così semplice, ci sono anche effetti negativi.
Se vuoi imparare la 'teoria' della cpu non leggere il newsgroup, leggi i libri.
Oppure come ripiego siti fatti bene, su 
www.aceshardware.com
 puoi trovare in 
archivio articoli, a mio giudizio, buoni.
byez

 I Mhz sono l'unità di misura della frequenza di clock.
Sarebbe come dire che gli anni sono l'unità di misura del tempo!! L'unità di
misura della frequenza sono gli Hz, i MHz semmai sono un suo multiplo!!
Scusa per la pedanteria ma è tanto che non scrivo un msg decente sul NG
:-))) !!
Ciao,
Marco77.

 istruzioni del codice macchina x86.
D'accordo che e' da suicidio, ma non sarebbe una
ottima cosa se i developers trovassero un modo
per sfruttare l'assembly, o i compilatori ottimizzassero
al max con qualche sorta di intelligenza artificiale il
codice compilato?  Lo so che la tendenza e' opposta
(Java), pero' e' tutto un gran spreco... sui 386 si
facevano miracoli :'(
Saluti,
    Dido

 ad 1 il voltaggio si innalza sino a 1volt nel preciso istante t. Ciň č
...............

 tradotto in codice Risc86 (a cui il programmatore _NON_ ha accesso,
Perche ?
Se la mia domanda e' scema, ti prego di scusarmi, ma mi sto appassionando al
discorso (anche se non riesco a capirvi sino in fondo) .
Ciao
Aldo

 perche' fra modo reale, modo protetto, modo (put your mode here), i
Mi sono sempre chiesto cosa si intende con questi due termini.
Non e' che ti andrebbe di "illuminarmi" un po' ?
Grazie
Aldo

 facevano miracoli :'(
E sul Commodore 64 allora ...... ?
Anche se non sono un esperto (come voi)  credo si possa affermare che hanno
fatto fare cose a quel 6510 che oggi sarebbero "fantascienza allo stato
puro" o meglio, se riuscissero a sfruttare gli
attuali processori come hanno fatto per il C64, credo che basterebbe un
486DXII/66 per giocare a Quake III con 50fps (credo) !!!
:-))
Ciao
Aldo
P.S.
Andate avanti cosi che siete troppo forti !!!



486DXII/66 per giocare a Quake III con 50fps (credo) !!!
heheh.. credi male , credi male... il codice di qIII e' parecchio ottimizzato 
e sfrutta molto bene le fpu... quella che trova.. e quella di un dxII/66 ..beh..
ciao r.d.

un giro di clock equivale ad un'istruzione...
Assolutamente no. Una istruzione puo' durare piu' cicli di clock, o
addirittura meno. Sul sito Papero ho un piccolo bench idiota su un
loop stretto. Calcolando il tempo totale per uscire dal loop, e
facendo l'ipotesi che ogni istruzione durasse un ciclo di clock si
potrebbe risalire alla frequenza del processore.
Il mio PII 400 secondo il bench, secondo queste ipotesi, avrebbe una
frequenza di circa 1 Ghz. Come diavolo si possa arrivare a simili
ottimizzazioni non lo so. Va bene che il processore di fatto riesce a
parallelizzare parzialmente il loop, pero', simili risultati non me li
aspettavo.
--
Tieni per te il Papero se vuoi la mia email
E' arrivata la Quack Template Library per il VB!
Sito Papero -> 
http://utenti.tripod.it/papero

486DXII/66 per giocare a Quake III con 50fps (credo) !!!
purtroppo credi male: i programmatori di oggi non sono certo piu' imbecilli
di quelli che lavoravano sul c64 e tutti i trucchi sviluppati in quel
periodo sono stati portati avanti e perfezionati anche sulle macchine
odierne.
quello che tu definisci "mancanza di ottimizzazione" e' soltanto
un'inevitabile compromesso per far girare il soft sull'assurdamente ampio
parco di hardware incompatibili fra di loro.
se Quake avesse girato _SOLO_ su un computer con scheda madre Intel, cpu
pentium 200mmx, 32mb di ram (non uno di piu', non uno di meno), 200mb di hd
(idem), scheda grafica S3 trio 64, acceleratore 3d 3dfx voodoo1 (Solo e
soltanto questa),  ne saresti stato contento?
ti ricordo che ad esempio il 50% dei giochi scritti per Amiga 500,
kickstart 1.2, 512kb chipram, 512slowfastmem, su un amiga 2000 con 1mb
chipmem, kickstart 1.3 _NON CI GIRAVANO!_ (*)
 
non ti incazzeresti un attimino in questo caso?
una minima perdita in prestazioni non e' un grosso prezzo da pagare quando
quello che si guadagna e' il crollo dei prezzi portato dalla
concorrenza.... pensaci.
(*) salvo fare salti mortali di varia natura, ma anche in questo caso una
certa percentuale di giochi continuava a rimanere incompatibile.


 addirittura meno.
No un'istruzione non puň durare meno di un ciclo di clock, al massimo nello
stesso ciclo di clock puoi ottenere il risultato di piů istruzioni perchč
vengono "calcolate" in parallelo


 facevano miracoli :'(
Il fatto è che coloro che producono software sono nella maggior parte dei
casi delle aziende a fini di lucro, sviluppare un applicazione in assembler
può essere decine (forse anche centinaia) di volte più lungo in termini di
tempo che con un linguaggio di programmazione ad oggetti.
Ora queste aziende che devono guadagnarci dalla vendità del software
spenderebbero decine di volte di più per pagare i loro programmatori ed
ingegneri e alla fine fallirebbero ;-)
Poi scrivere direttamente in assembler migliaia di istruzioni aumenterebbe
molto di più il rischio di commettere errori che scrivere qualche decina di
righe in C++, e avremmo un mucchio di software ancor più pieno di bug.


 linguaggio macchina...
Dipende a seconda del tipo di istruzioni, per esempio data una variabile v
intera di tipo register
v++;
(solo se v č una veriabile register) viene tradotto in una sigola istruzione
assembler
ADD AX,1
(cosiderando v contenuta nel registro AX).
Mentre per esempio un
while(...)
deve essere tradotto in una serie di istruzioni assembler che valutano il
contenuto della parentesi piů un istruzione di salto condizionato ad un
altri punti del codice, se mi ricordo bene.


 e sfrutta molto bene le fpu... quella che trova.. e quella di un dxII/66
..beh..
Lo sapevo che mi sarei infilato in un tunnel dal quale ne sarei uscito male
!!!
:-(
Vabbe' ..... abbiate pieta' di me !
Ciao
Aldo

 parco di hardware incompatibili fra di loro.
------cut-----
Ok.
Come ho gia' ammesso al tuo "collega" r.d.b., mi cospargo il capo di cenere
e ti ringrazio per aver dimostrato (se mai ce n'era bisogno) di quanto lo
sparata grossa.
:-)
In effetti non ho tenuto conto di questi aspetti.
Grazie comunque per la tua "comprensione".
;-)
Ciao
Aldo

un'istruzione x86 "complessa", in quante risc86 viene trasformata? e come
Penso che siano informazioni piu' segrete di un segreto militare...
Ciao,
  Lonewolf.
Le faq di Galandil sulla K7M le trovate su:
http://digilander.iol.it/lln
--------------------------------------
Vuoi entrare in Internet?
Compra un modem, non un Pentium 3!!
--------------------------------------

Grazie ragazzi !
era un secolo che non mi facevo tante risate !!!!  :-))))

 tempo che con un linguaggio di programmazione ad oggetti.
Lo so, ma esistono compilatori che ottimizzano al massimo
il codice compilato in base al codice sorgente tramite una sorta
di intelligenza artificiale che sfrutti trucchi vari, tipo eliminando
parti di codice generiche che potrebbero risultare inutili nel
caso specifico, o cose del genere?
Se le cose non sono cambiate da 2-3 anni in qua, lo GNU C(++)
e' il piu' ottimizzante, ma non ho idea fino a che punto...e poi
sotto windozz usano tutti roba visual by m@cro$oft ....
Saluti,
    Dido

caso specifico, o cose del genere?
ragazzo mio, tu vorresti la senzienza artificiale - e' ancora da dimostrare
che lo siano i programmatori, figurati se sono senzienti i compilatori da
loro scritti... ^_____^


vengono "calcolate" in parallelo
DDR....


 Aldo
il processore 8086 disponeva di un bus (bus indirizzi) a 20 bit (2^20=1M memoria
indirizzabile) ma di registri di soli 16 bit. Ora, con 16 bit non si poteva
indirizzare tutta la memoria, occorreva quindi uno stratagemma.
L'8086 operava in quello chiamato 'modo reale'. Ovvero l'indirizzo veniva
calcolato a partire da:
- un OFFSET, contenuto in un registro (in un general-purpose register);
- un SEGMENTO, contenuto in un registro di segmento. Poichè anche esso è
  di 16 bit se ne deduce che il numero totale di segmenti sia 2^16 = 65536.
  Ogni segmento sarà lungo 16 bytes, poichè 1M / 65536 = 16.
L'indirizzo in modo reale veniva così calcolato:
 Address = 16*segment + offset.
nota: questo calcolo significa shiftare a sinistra il segmento di 4 bit, 
riempiendo i bit meno significativi con zeri. Poi sommare l'offset.
Per la prima volta nel processore 80286 esordisce il modo 'protetto'. Lo scopo
è di proteggere differenti task, in esecuzione in sistemi multitasking, contro
accessi non autorizzati (Il modo reale non forniva alcun meccanismo di
protezione). Queste sono le differenze principali dal modo reale:
- diverso modo calcolo indirizzi;
- implementazione del controllo degli accessi.
Non posso qui dilungarmi su come avviene il calcolo dell'indirizzo in questa
modalità, ma tieni conto che ci sarà un registro che conterrà (tra le varie
cose) un indice,  questo indice sarà usato per prendere un elemento da una
tabella. Questo elemento descriverà il segmento che mi interessa. Nel Pentium
questi segmenti non saranno più di 16 bytes (come nell'8086) ma potranno
raggiungere (al massimo. Possono essere più corti) 1M o 4Gb, a seconda della
granularità. Inoltre segmenti sequenziali potranno non essere fisicamente
adiacenti in memoria.
Il modo reale permette di indirizzare un massimo di 64Tb (TERA!!) per ogni 
task! Quindi si ha uno spazio di indirizzamento logico, molto maggiore
dei 4Gb di spazio di indirizzamento fisico dei Pentium (ma anche dei 486 e 386).
Ovviamente ci sarebbe da scrivere un fiume di parole, ma ora basta! ;-)
Ah, per inciso un Pentium può operare in entrambi i modi ed in altri ancora.....
byez

> DDR....
ooops..


 > negli hanni 70 venivano usati come mainframe.... :)
Proprio l'altro giorno il mio prof. di elettrotecnica ci raccontava quando
al centro di calcolo di Casalecchio(BO) portarono uno dei primi pdp64...
A quei tempi si dovevano scervellare per far girare dei programmi per
risolvere dei circuiti per elettrotecnica che girassero in 64k....


 caso specifico, o cose del genere?
Non esageriamo, esistono tecniche di ottimizzazione basate
su algoritmi tipo ricerca di minimo, etc.
Alcuni trucchi, tipo loop unrolling (da verificare).
Profiling e ricompilazione.
Il problema e` che serve una profonda conoscenza dell'architettura
della CPU, non sempre attuabile in breve tempo.
bye,
--
  Piergiorgio Sartor

risolvere dei circuiti per elettrotecnica che girassero in 64k....
figurati, la Digital li produsse su progetto del Mit come macchine di punta
del loro centro di supercalcolo... :-)
mi sa che ora usano qualcos'altro... ^____^


 Dove posso trovarne?
Prova sul sito della Intel: sono anni che produce merda!
Più biologiche di così! ^_^
m[a]v @ AzzurraNet || 
mav...@yahoo.com
 || ICQ UIN# 22579106
*****************************************************

No un'istruzione non può durare meno di un ciclo di clock, al massimo
Dove sarebbe la differenza? E' vero che la singola istruzione presa a
se stante non puo' durare meno di un ciclo di clock, pero' i programmi
non sono fatti di una singola istruzione.
Sono un programmatore e non un progettista di CPU. Io faccio un
programma di 1000 istruzioni in assembly. Quanto ci tempo ci mette il
processore ad eseguirle? Ci mette 500 cicli di clock? Ebbene io ho
misurato che la durata media di una istruzione (in quel contesto, in
quel processore, con quelle particolarissime condizioni al contorno)
e' di 2 istruzioni per clock.
Se il processore tra fetch, prefetch, e chissa che diavolo riesce a
parallellizzare le istruzioni quello che io misuro sono velocita'
superiori al ciclo di clock. Misurare il tempo di una singola
istruzione non mi interessa. Mi interessano i tempi "apparenti", i
tempi con cui io vedo che la black box chiamata "processore" elabora
le informazioni.


 mi sa che ora usano qualcos'altro... ^____^
Gli Zilog Z80 con ben 256 Kb di memoria!!!
MaxArt

 ha scritto nel messaggio
news:8bh65s$gnb$1...@lacerta.tiscalinet.it...
