Link alla notizia: http://www.hwupgrade.it/news/apple/15454.html

La compagnia di Cupertino avrebbe chiesto ad Intel di consegnare i processori prima dei piani originariamente stabiliti

Click sul link per visualizzare la notizia.

dai, dai, che siamo impazienti di vedere i primi apple / intel........

Li facessero uscire anche 3 mesi dopo, ma partire direttamente con i Merom (dual core, 64bit, basso consumo) sarebbe la scelta giusta, secondo me...

ma sono cpu x86 o risc ?? :mbe:

non esiste più una netta distinzione tra x86 e risc (visto che hanno una parte risc)

ma sono cpu x86 o risc ?? :mbe:

sta storia non finirà mai....sono 15 anni che gli x86 sono risc...15..

internamente sono RISC, ma il set di istruzioni continua ad essere CISC

mentre invece i RISC internamente sono RISC, ma il set di istruzioni è diventato CISC

in pratica cambia il punto di partenza ma il punto di arrivo è simile :D


cmq per quanto riguarda Apple, era una cosa che mi chiedevo e di cui tra l'altro si è anche accennato sul forum... c'era chi sosteneva che sarebbe partita subito con il merom ma :read: roadmap (apple e intel) alla mano la cosa risultava poco proponibile... e tra l'altro apple, per quanto riguarda la richiesta di cpu, non ha nemmeno questi grandi numeri per fare più pressione di tot su intel... in praticolar modo sul discorso merom: non è mica uno scherzo anticipare un processore di un trimestre, in particolar modo quando hai messo in commercio il suo predecessore da pochi mesi...

le alternative imho sono due:
- la più sensata, ovvero che apple parta con lo yonah, comunque ottima cpu
- faccia come ha fatto con il g5, che dato che andava presentato a giugno l'ha presentato a giugno e iniziato a consegnare i primissimi esemplari a fine settembre :asd:

yonah e merom sono sullo stesso socket? dove posso trovare processori x note?

e tra l'altro apple, per quanto riguarda la richiesta di cpu, non ha nemmeno questi grandi numeri per fare più pressione di tot su intel... in praticolar modo sul discorso merom: non è mica uno scherzo anticipare un processore di un trimestre, in particolar modo quando hai messo in commercio il suo predecessore da pochi mesi...

Beh questo è più un "vantaggio" che uno svantaggio: un conto è avere pronto uno stock per le varie Dell e HP, un conto è averne uno per Apple. I numeri sono più piccoli, quindi lo potrebbe anche fare. Bisogna vedere se è disposta a concedergli questo vantaggio competitivo, però!
I Merom sono stati dimostrati qualche tempo fà, quindi sono già in preproduzione in questo momento... e a giugno manca quasi 1 anno!

ma yohan è a 32 bit giusto? mentre merom a 64......se uscisse anche yohan apple dovrebbe fare due versioni di os X, una a 32 bit e una a 64 bit. Effettivametne per apple converrebbe iniziare subito con merom visto che la casa di cupertino nn è solita aggiornare spesso l'hardware nei propri prodotti.

E' quello che ho pensato io quando ho letto la notizia ieri su AppleInsider (mi sembra). I volumi Apple sono ben inferiori a quelli di Dell HP o del mercato OEM, quindi dovendo assicurare volumi MOLTO più bassi potrebbero anche anticipare di qualche mese... considerando anche che Apple è (storicamente) simbolo di qualità e di immagine, quindi converrebbe anche ad Intel per farsi pubblicità. Secondo me i primi PowerBook Intel useranno il merom a 64 bit, yonah forse verranno usati per mac mini ibook ed eMac.

zephyr83, questo non è vero, infatti al momento i mac montano ppc a 32bit e a 64bit ma la versione di Osx è soltanto una. A dire il vero tra meno di un anno ci sarà una versione sola di OSx che funzionerà sia sui ppc che sugli Intel. Loro usano i fat binaries per fare queste cose, è una cosa ereditata da NeXT.

E' quello che ho pensato io quando ho letto la notizia ieri su AppleInsider (mi sembra). I volumi Apple sono ben inferiori a quelli di Dell HP o del mercato OEM, quindi dovendo assicurare volumi MOLTO più bassi potrebbero anche anticipare di qualche mese... considerando anche che Apple è (storicamente) simbolo di qualità e di immagine, quindi converrebbe anche ad Intel per farsi pubblicità. Secondo me i primi PowerBook Intel useranno il merom a 64 bit, yonah forse verranno usati per mac mini ibook ed eMac.

Se sul piano dell'immagine potrebbe anche essere vero, sul piano produttivo non credo che Intel si metta a produrre qualcosa in anticipo solo perchè Apple lo richiede. I costi di tale anticipo credo siano troppo elevati per poter essere bilanciati sia dagli introiti relativi alla vendita di CPU ad Apple sia dal ritorno d'immagine (e poi sarebbe ritorno di immagine quello della Apple?). Se poi aggiungiamo che a quel punto anche altri produttori (leggasi Dell o HP o chi altro si vuole, ed hanno più peso sulle scelte produttive di Apple) vorranno i merom in anticipo, ecco che Intel si ritroverebbe a non poter soddisfare la domanda e a dover scegliere se dare i processori a tutti o seguire la roadmap.

diabolik1981, mica si sta parlando di anni prima, si sta parlando di qualche mese prima, se Merom uscirà in grossi volumi per il mercato OEM a fine 2006, io penso che gli impianti siano già pronti pochi mesi prima, se hanno detto fine 2006 sarà perché a metà 2006 non riuscirebbero a garantire volumi adeguati... ma questo non vale per Apple. Insomma non penso che se un processore debutta in tutto il mondo un giorno X, gli impianti vengano messi su 3 giorni prima.

non credo proprio che Intel sia disposta a fare questa consegna anticipata :) mi sa che Apple si dovrà adattare come è giusto che sia adesso che è una produttrice equiparabile a DELL et simila ;)

Non sono d'accordo. Steve Jobs è uno che sa il fatto suo, come ha sfruttato l'alta popolarità e gli enormi volumi di vendita dell'iPod per strappare a Samsung memorie da 4GB a prezzi bassissimi rispetto agli altri, così sfrutterà i bassi volumi di vendita (e i prezzi relativamente alti) dei Macintosh per strappare a Intel i Merom in anticipo rispetto agli altri.

il problema è che Intel si gioca parecchie vendite se dovesse immettere sul mercato i processori con core Merom in tempi brevi nei confronti del core Yonah ;)

quindi Intel è più forte di Apple e quindi non credo proprio che succederà una cosa simile :)

Credo che agli occhi di Intel, Apple non possa avere una importanza maggiore rispetto a Dell & company, anzi, proprio in virtù dei minori volumi di vendita, caso mai è il contrario. Certo, è un partner importante, ma non tanto importante da rifilare un "pacco" del genere agli altri. Soprattutto, gli altri partner, che Intel si tiene buoni e fedeli in tutti i modi possibili e immaginabili, non potrebbero che sentirsi scavalcati da un'operazione del genere, mica sono fessi! Quella che definite giustamente come una mossa commerciale che porterebbe un bel guadagno di immagine ad Apple (di riflesso magari qualcosa ricadrebbe su Intel, in fondo avrebbe immesso sul mercato dei processori nuovi e "migliori"), pur trattandosi di pochi mesi (che poi in campo informatico contano sempre), si trasformerebbe in un danno di immagine per gli altri: Apple, l'ultima arrivata alla "corte" di Intel, e per di più quella con la "dote" (=volumi di vendite) inferiore diventerebbe di colpo la cortigiana "favorita", quella che ottiene le primizie. Pensate che Dell e compagnia bella starebbero con le mani in mano? Io dico che al primo sospetto concreto, come minimo, minaccerebbero di spalancare un portone ad AMD. Dite che per Intel il gioco potrebbe valere la candela?

Poi, in genere, l'ingresso sul mercato di un nuovo processore non mi pare avvenga in grossi volumi, specialmente quando si migra a un nuovo processo produttivo, e dubito che Intel voglia ripetere gli errori fatti con i primi Prescott. IMHO, ovviamente.

Personalmente ritengo che Apple dovrà limitarsi a presentare le macchine per poi consegnarle 3-4 mesi dopo.
Intel non può permettersi di favorire così apertamente Apple nei confronti di tutti gli altri produttori, specie se sono clienti fedeli.
Credo che Apple partirà con i processori attuali per la fascia bassa (eMac, macmini e iBook) per poi aggiornare la fascia pro e infine i server. Gli iMac dovranno aspettare se monteranno anche loro i Pentium-M.
Vedremo come finirà...

Apple non fa concorrenza nè a Dell nè tantomeno ad HP.. Nessun potenziale loro acquirente deciderebbe mai di comprare un Mac solo perchè monta un processore più nuovo. E non vale nemmeno il discorso OEM: se anche Intel concedesse ad Apple di usare i suoi processori migliori 3 mesi prima, cosa cambierebbe? Qualcuno immagina orde di smanettoni svaligiare gli Apple Store per acquistare un Powerbook, sventrarlo ed estrarne il prezioso Merom? Tutto si riduce ad una valutazione di fattibilità pratica, ed è più logico pensare che Intel, produzione permettendo, farà in modo di accontentare il buon vecchio Steve. Nessuno sa fare promozione come lui, già lo sento strillare al miracolo del processore piùùùùùù velocissimo dell'universo, con un marchio Intel ben in evidenza alle sue spalle...

Guardate che se è vero che Apple non è nulla a confronto con Intel in termini di volumi, è anche vero che in termini di immagine Apple dice la sua. Intel sono ANNI che prega Jobs di usare i suoi processori sui Macintosh, e questi ultimi sono i computer sui cui Intel vorrebbe presentare le sue nuove tecnologie. I primi sample di processori non sono mai disponibili in volumi enormi come ha già detto qualcuno, proprio per questo a Intel conviene che questi primi sample (a prezzi abbastanza alti) vengano venduti sui Mac piuttosto che sugli assemblati. Quale miglior mercato per una tecnologia disponibile col contagoccie, di un mercato in cui i computer sono venduti col contagoccie come quello di Apple? Una cosa simile è già stata fatta in passato con il Pentium3 1GHz, hanno fatto accordi perché su alcuni brand debuttasse qualche settimana prima rispetto al mercato OEM o per i piccoli assemblatori.
Io la vedo come una cosa possibilissima, e sono perfettamente d'accordo con LucaTortuga. Inoltre Steve Jobs ha a sua disposizione un'utenza disposta a spendere ben più soldi di quanto è generalmente disposta l'utenza media di Dell.

E da quando in qua i Mac non si possono considerare concorrenti degli IBM compatibili? Per espandersi nel mercato dei calcolatori elettronici, Apple non deve forse rosicchiare quote ai Pc-compatibili?

Per quanto ne so io, Apple campa sull'hardware, non certo sulle vendite di OS-X, tant'è che parlare di una versione del sistema operativo "abilitato" ad essere eseguito su macchine diverse dagli Apple, se non mi sono perso qualosa, per Jobs è bestemmia, e in questo Apple non è diversa da Dell o HP, anzi, volendo fare una panoramica a 360°, un server Apple con OS-X, come "tipologia", per me non è affatto differente da un server HP o IBM venduto con sistema operativo custom, spesso derivato da Linux o Unix.

Soprattutto adesso che l'hardware praticamente è lo stesso e l'unica differenza "esteriore", "trasparente" per l'utente finale (chi acquista una macchina già assemblata in genere non ci mette le mani dentro) è il sistema operativo, il "campo di battaglia" è sempre più "vicino". Ora, tutti qui sappiamo che Steve Jobs il suo mestiere sa farlo molto ma molto bene, se Intel acconsentisse una volta credete che Jobs non comincerebbe a ronzare, a pungere, a mordere, a insistere fino ad ottenere di avere sempre i nuovi processori in anticipo rispetto a tutti gli altri? Bene: in questo modo si alimenterebbe il mito, che poi mito non sarebbe, di un Apple che produce le migliori macchine x86 (perchè di questo, in fin dei conti stiamo parlando), che propone le più avanzate soluzioni tecnologiche anni luce rispetto agli altri (che volete che sia, per un abile stratega trasformare con un'abile campagna di marketing un trimestre in un millennio), e le fornisce di un sistema operativo avvolto in un alone quasi mistico di superiorità e perfezione, per molti nuovo e da imparare a conoscere, ma famoso per la sua semplicità d'uso, per la sua stabilità e sicurezza e propagandato come il meglio del meglio (notate che non c'è alcuna vena polemica o critica verso le caratteristiche, presunte o reali poco importa, di OS-X, voglio solo dipingere a tinte forti uno scenario che potrebbe via via prendere forma nell'immaginario collettivo).

Non credete che uno scenario del genere possa diventare una tentazione sempre più seducente, se non irresistibile, per alcuni o molti clienti di Dell e company? Non credete che Dell e company terrebbero in seria considerazione un'ipotesi del genere? In fondo le analisi di mercato non si fanno guardando solo al giorno dopo, così come la produzione di una cpu non si appronta tre giorni prima. Ma anche a voler guardare solo alla contingenza e considerarla nella sua peculiarità ed eccezionalità, in quanto venditori di hardware, io credo che Dell e company vorranno continuare a poter loro a gridare "Accorrete, gente, accorrete, ecco a voi il più nuovo, veloce, stupefacente processore che l'uomo abbia mai osato desiderare nei suoi sogni più intimi e nascosti! Accorrete e stupitevi difronte all'ultimo strabiliante, meraviglioso prodigio di Madama Intel!".

Naturalmente questa è la mia opinione personale, potrei benissimo essere fuori strada, non pretendo certo di aver ragione. Quella, ce l'hanno solo i fatti e ad essi si piegheranno le nostre elucubrazioni cervellotiche e logorroiche (qui ci sta un belllissimo: "parla per te, io ho detto solo due parole :Prr:" ).

I discorsi sull'immagine di Apple sono corretti, e sono vere le lusinghe fatte da Intel in passato, però non dimentichiamoci che Intel fa anche i salti mortali per far vendere il minor numero possibile di macchine con processori amd, quindi IMHO deve giocoforza mettere tutti sullo stesso piano: con Apple, in fondo, ha un contratto ben preciso che entrambe devono rispettare, mica Jobs può strapparlo e cambiare partner solo perchè ADESSO, a cose fatte, chiede qualcosa di diverso, e per di più in "anteprima esclusiva". Discorso un po' diverso per Dell, che non credo gradirebbe l'essere scavalcata: non dico che Intel non possa quantomeno prendere in considerazione, almeno per qualche microsecondo, una simile proposta/richiesta da parte di Jobs, ammesso che sia stata realmente avanzata e che Intel possa realmente soddisfarla con queste tempistiche, dico che Intel potrebbe ricevere delle pressioni da parte di qualcun'altro, e che questo qualcun'altro potrebbe avere un peso tuttosommato maggiore (parlando di quattrini).

Comunque, il discorso che facevo sulle nuove produzioni era un po' diverso: se Intel prevede di essere pronta per la produzione a fine 2006, e se è presumibile che anche allora, tenendo conto anche del nuovo processo produttivo, i volumi prodotti saranno limitati, quanto diventa plausibile ritenere che tre mesi prima Intel possa fornire ad Apple una quantità adeguata di processori. Per allora, forse, è più probabile che circolino i sample di preproduzione messi a disposizione delle riviste di settore per i test "di rito". Tutto, ovviamente, IMHO.

Bene: in questo modo si alimenterebbe il mito, che poi mito non sarebbe, di un Apple che produce le migliori macchine x86 (perchè di questo, in fin dei conti stiamo parlando), che propone le più avanzate soluzioni tecnologiche anni luce rispetto agli altri (che volete che sia, per un abile stratega trasformare con un'abile campagna di marketing un trimestre in un millennio), e le fornisce di un sistema operativo avvolto in un alone quasi mistico di superiorità e perfezione, per molti nuovo e da imparare a conoscere, ma famoso per la sua semplicità d'uso, per la sua stabilità e sicurezza e propagandato come il meglio del meglio (notate che non c'è alcuna vena polemica o critica verso le caratteristiche, presunte o reali poco importa, di OS-X, voglio solo dipingere a tinte forti uno scenario che potrebbe via via prendere forma nell'immaginario collettivo).

Bhe, una cosa è una campagna marketing, in cui si possono esaltare tutte le cose che si vogliono, ben altra cosa è la realtà, cove le macchine MAC sono anni luce indietro in quanto a tecnologia rispetto ai PC. Se poi per tecnologia intendiamo il design... allora ti do ragione.

E se... Intel volesse "favorire" Apple con l'intenzione di investirci poi un'alta percentuale di azioni, riducendo Dell alla "fame" per "fare tutto" in casa come e quando vuole? Puntando anche una pistola alla tempia di Gates, come vorrebbe fare IBM con Linux?

Ah gia', c'e' anche AMD...

xdiabolik1981

hypertransport di AMD, USB di Intel, Firewire ecc...
Chi ha dato manforte perche' divenissero degli "standard", con o senza consorzi?
Ma gli schermi Pivot degli anni ottanta della Radius gli hai mai visti e usati? Ora puoi con Win. E la possibilita' di usare piu' schermi come unico desktop (1988-89)? Potrei andare avanti per molto, ad esempio con i bus a 1+ GHz dal 2003, lasciando stare il controller della memoria integrato che non dipende da Apple ma da IBM.
Sei avanti anni luce per le schede video? Te lo concedo. Ma ricorda che sei avanti anni luce perche' una piccola societa' ha creduto in "certe" tecnologie ed ha rischiato nel volerle usare a tutti i costi.

Ti dice qualcosa il Wireless. Oggi tutti non fanno che parlarne, ma quale portatile lo ha implementato per primo, con larga diffusione dal 1997?

Staresti ancora usando i floppy da 5 1/4 se qualcuno nel 1980-81 non adottava quelli da 3 1/2... oops ma forse OGGI ne hai ancora una da 3 1/2 nel PC.

Samsalves, lascia stare, non tutti possono capire certe cose, stesso discorso lo facevo giorni fa riguardo l'iPod Nano e il suo harddisk allo stato solido, trovandomi però davanti a un muro di ignoranza. Quant'era più facile ed economico il disco rotante ora come ora, peccato che lo sviluppo tecnologico funzioni proprio così, grazie ad aziende come Apple che puntano tutto su tecnologie che si possono definire OGGETTIVAMENTE migliori, togliendo libertà di scelta a chi non ha diritto di averla (per questioni di ignoranza). Se non fosse stato per aziende come queste, ora avremmo ancora floppy da 5.25, tastiere ps/2, msdos versione 24.33 e gli schermi crt.
(Non parlo solo di Apple ovviamente).
Ma quant'è facile dire che Apple è indietro anni luce perché ha le gpu vecchie e monta poca ram eh?!

stesso discorso lo facevo giorni fa riguardo l'iPod Nano e il suo harddisk allo stato solido, trovandomi però davanti a un muro di ignoranza. Quant'era più facile ed economico il disco rotante ora come ora, hie e monta
:confused: :confused: :confused: Disco a stato solido? Disco rotante?intendi la memoria flash perchè non ho mai sentito questi due termini... :confused:
il primo credo che non esista mentre il secondo viene semplicemente chiamato:hard disk , microdrive o disco....(però ripensandoci in Goldrake o Mazinga poteva esserci il disco-rotante) :D :D :D :D

Memorie allo stato solido è un termine usatissimo. Disco rotante m'è venuto li per li... lasciamo stare dai, si capiva che intendevo i dischi tradizionali.

x diabolik1981

Col marketing sui Mhz Intel per quanto ci ha campato? Poi, dai, altro è parlare di dotazioni, altro è il livello tecnologico generale: non voglio entrare nel merito di confronti (quasi inevitabilmente) poliemici PPC vs x86, ma adesso, con l'imminente passaggio a x86, siamo sullo stesso piano. E se cominciano ad usare i processori più veloci e prima degli altri, per poter sfruttare appieno il ritorno di immagine dovranno per forza di cose abbinarli a memorie e gpu di ultimissima generazione, almeno su macchine per enthusiast.

x samslaves

Tutto è possibile, a patto che i tempi siano maturi: certi equilibri sono difficili da modificare in tempi brevi, e qui si potrebbe tirare in ballo il "vecchio" discorso di MS che tiene Apple per le pa@@e con Office, almeno finchè Apple non avrà tirato fuori un foglio di calcolo suo. Ok, ci sta lavorando, ma dopo averlo completato dovrà farlo crescere e attendere che diventi, insieme agli altri applicativi di office productivity che già possiede, e qui, a parte una buona dose di marketing, c'è poco da fare: la palla passa agli utenti. Io credo che la tua ipotesi possa essere molto plausibile, ma non praticabile prima di avere la certezza che OS-X possa affrontare a viso aperto Windows, e per questo servono riscontri positivi sul mercato. Per IBM è molto più semplice partire da lontano e far crescere linux come piattaforma software per le proprie macchine: in fondo, parliamo per lo più di server, ovvero macchine nelle quali è tutt'altro che raro trovare OS e software custom (ne sono un esempio i vari middleware della stessa IBM). Per Intel, invece, a mio modo di vedere la situazione è più complicata: se sceglie male la tempistica e accelera troppo i tempi rischia di trovarsi da un lato a scontrarsi con MS senza poter lottare ad armi pari (e perdendone ogni possibile forma di appoggio), dall'altro a rischiare di perdere l'appoggio, in parte o in tutto, di importanti partner commerciali come Dell, appunto: se per "ripicca" cominciasse a vendere in volumi e a prezzi marcatamente competitivi macchine basate su AMD, per Intel sarebbe un problemino mica da poco, non è che Apple possa rimpiazzare Dell dall'oggi al domani... (non dico che se Apple ottenesse per prima Merom Dell aprirebbe automaticamente ad AMD, ma potrebbe benissimo fare pressioni e indurre Intel a riconsiderare la questione). Insomma, mi trovi concorde sul piano delle possibilità anche concrete, ma la tempistica mi sembra un po' azzardata, anche solo per cominciare a tastare il terreno. Poi, può darsi che io mi sbagli del tutto.


x matteos

Intendeva memorie a stato solido, le memorie (di massa) statiche vengono indicate con questo termine per differenziarle dagli hard disk, a differenza dei quali non presentano parti in movimento, presentandosi come un blocco solido e immobile, compatto, appunto. Negli hard disk ciò che si muove sono le testine e... il disco! Voleva essere solo un parallelo un po' metaforico e un po' tecnico (la memoria statica, o a stato solido, sostituisce il disco, che ruota => disco solido vs disco rotante) per evidenziare con un'espressione d'impatto il contrasto tra le due tecnologie alternative. Dai, non cerchiamo sempre il pelo nell'uovo, altrimenti dalle polemiche non ne usciamo più...

Ecco, ha già risposto l'interessato... :P

xeal, no non intendevo evidenziare con un'espressione d'impatto il contrasto tra le due tecnologie alternative, tu mi sopravvaluti! E' semplicemente che a quell'ora ero stato chiamato per andare a cena, avevo fame, dovevo spicciarmi a finire di scrivere e ho messo i primi 2 termini che il mio contorto cervello ha tirato fuori :D

Be', diciamo che ho beccato l'associazione di idee cha hai fatto inconsciamente :p adesso mi informo con uno psicologo e ti mando una bella parcella :asd:

xdiabolik1981

hypertransport di AMD, USB di Intel, Firewire ecc...
Chi ha dato manforte perche' divenissero degli "standard", con o senza consorzi?
Ma gli schermi Pivot degli anni ottanta della Radius gli hai mai visti e usati? Ora puoi con Win. E la possibilita' di usare piu' schermi come unico desktop (1988-89)? Potrei andare avanti per molto, ad esempio con i bus a 1+ GHz dal 2003, lasciando stare il controller della memoria integrato che non dipende da Apple ma da IBM.
Sei avanti anni luce per le schede video? Te lo concedo. Ma ricorda che sei avanti anni luce perche' una piccola societa' ha creduto in "certe" tecnologie ed ha rischiato nel volerle usare a tutti i costi.

Ti dice qualcosa il Wireless. Oggi tutti non fanno che parlarne, ma quale portatile lo ha implementato per primo, con larga diffusione dal 1997?

Staresti ancora usando i floppy da 5 1/4 se qualcuno nel 1980-81 non adottava quelli da 3 1/2... oops ma forse OGGI ne hai ancora una da 3 1/2 nel PC.

vogliamo parlare di SATA, PCI-X et similia... cose che nei computer moderni si usano da un paio di anni e che sui mac in alcuni casi devono ancora comparire? E il caro e vecchio SCSI che sui PC continua a funzionare e che sui MAC non si sa per quale motivo (si sa... Steve è taccagno sull'uso dell'HW, vende ciofeche per lingotti d'oro) è scomparso? Ti bastano questi esempi? E non venirmi a dire che sui server MAC trovi SCSI, perchè sulle workstation grafiche sarebbero auspicabili ma nisba.

E' vero che a LIVELLO DI IMPLEMENTAZIONE un x86 moderno ha parecchio in comune con un RISC, ma rimane pur sempre un CISC.

x samslaves: nel 2003 l'HyperTransport di AMD viaggiava già a 1,6Ghz.

sul discorso delle "implementazioni" che apple ha portato per prima, vorrei far notare che tendenzialmente le tecnologie che introduce sono sempre già disponibili per pc (parliamo ad es. di wireless)... la differenza è una:
- apple ha un mercato blindato, ove non c'è scelta: se lei decide di mettere di serie il wireless, tutte le sue macchine ce l'hanno
- il mercato pc è aperto, dove trovi TUTTO, basta sapere dove andare a trovarlo: finchè il wireless non tira difficilmente lo si troverà di serie; tuttavia se lo vuoi c'è e c'è da prima (non è che il wireless l'ha inventato apple)

perciò dire che se non arrivava apple non ci sarebbe stato su pc è solo un pensiero da fanatico... su pc sarebbe arrivato quando è arrivato... vogliam parlare di altro? USB, l'ha inventato intel e s'è diffuso "di serie" su pc solo quando aveva un senso si diffondesse, prima prendevi la schedina aggiuntiva e la mettevi nel pc. parliamo invece di una cosa che ha effettivamente partorito apple: firewire. sapete perchè su pc è arrivato di serie solo recentemente? perchè le royalties che apple chiedeva per il firewire erano molto più onerose di usb e comunque non accettabili dai produttori di schede madri (ovvero: costi superiori ai benefici)... in questo caso, ovvero quando si è trovata in mano la tecnologia, apple ha RALLENTATO (tra l'altro in modo proprio stupido, se la firewire avesse preso piede in altro modo avrebbe fatto comunque un botto di soldi) il progresso dell'informatica...

insomma, io starei più cauto prima di cavalcare questi che sono più che altro luoghi comuni... apple essendo in una nicchia può... proporre prodotti di nicchia, può permettersi di infilare il wi-fi che tanto non c'è un concorrente che vende mac senza wi-fi a più basso costo, dire però che se non c'era lei sui pc chissà quando si sarebbe visto ripeto è solamente un luogo comune o una facile conclusione. basta vedere quella valanga di tecnologie che apple non ha mai implementato o ha implementato dopo per capire che la novità sui pc di serie arriva se il beneficio supera il costo, mentre se il costo supera il beneficio l'hai comunque a disposizione anche se non a livello "massa".

detto questo volevo fare due appunti per quel che riguarda il discorso yonah / merom:
a) credere che intel possa anticipare davvero, e parlo dal punto di vista tecnico, la produzione dei merom è ingenuo, perchè se davvero avesse potuto non avrebbe di certo fatto il passaggio intermedio con lo yonah... il merom sarà disponibile in volume il prima possibile: e il prima possibile è alla fine del 2006
b) che ad apple serva 1 milione o 10 milioni di pezzi, poco cambia: per produrre comunque 1 milione (ma fate anche solo qualche centinaio di migliaio) di processori devi avere comunque TUTTO FUNZIONANTE ALLA PERFEZIONE, ovvero la cpu a posto (adesso non è in pre-produzione, adesso ci sono i prototipi, che è un po' diverso) e il processo produttivo a posto... e scusate se è poco. giro la questione: se ci fosse stata la possibilità, allora dell grazie alla forza che ha (e agli accordi che ha con intel) le avrebbe già in passato richiesti BASSI volumi di cpu nuove IN ANTICIPO rispetto alla concorrenza per produrre bassi volumi (rispetto a quelli complessivi di dell) di macchine avanti rispetto agli altri produttori, no? ovviamente non è proponibile
c) c'è un altro aspetto: anche se per assurdo fosse tecnicamente possibile, intel per vendere circa una milionata di cpu in un anno (si sta parlando dei soli laptop eh) si va a sputtanare con tutti gli altri produttori di pc ai quali vende nel complesso oltre 150 milioni di processori l'anno? io penso di no
d) oltre a sputtanarsi con i suoi clienti, sputtanerebbe anche il mercato... se fai lo yonah e da lì a 2 mesi fai il merom sei un po' rintronato... è vero che ultimamente intel è un po' un pugile suonato, però dal punto di vista commerciale sa ancora come muoversi

cmq sinceramente non vedo perchè ostinarsi con il merom... lo yonah è comunque un ottimo processore, mac os x x86 è ancora a 32 bit, se si vuole l'ibook e il powerbook x86 a giugno si monta quello, se invece si vuole il merom a giugno si presentano i due laptop e li si commercializza a ottobre...

E' vero che a LIVELLO DI IMPLEMENTAZIONE un x86 moderno ha parecchio in comune con un RISC, ma rimane pur sempre un CISC.



Non esiste la frase "ha parecchio in comune"...i processori in produzione attualmente(in realtà da 15 anni) sono RISC...e l'unica reminiscenza del cosiddetto CISC è solo il set d'istruzioni..
Tra l'altro i processori attuali (ma questo ragionamento è vero praticamente dal Pentium in poi a livello commerciale) sono una evoluzione del RISC essendo in realtà dei processori VLIW vettoriali e superscalari.

x FX
Non sono d'accordo.
Il marketing (mito) di Apple si basa su un (presunto) primato nell'innovazione.
Il marketing di Dell & company sul contenimento dei prezzi e sui grandi volumi di vendita.
Ergo, mentre per Apple può essere fondamentale poter gridare ai 4 venti di avere a disposizione un processore nuovo e migliore, la cosa è assolutamente indifferente per Dell e per il 99,9% dei suoi clienti (le aziende ordinano 2000 PC da Dell perchè costa meno e la ritengono affidabile, non certo perchè monta questo o quel processore).
Se Intel può materialmente accontentare Jobs lo farà, sarà un vantaggio per Apple, un guadagno (seppur minimo) di immagine per la stessa Intel e nessun danno per gli altri clienti (Dell, HP e compagnia bella).

Originariamente inviato da scorpionkkk
Tra l'altro i processori attuali (ma questo ragionamento è vero praticamente dal Pentium in poi a livello commerciale) sono una evoluzione del RISC essendo in realtà dei processori VLIW vettoriali e superscalari.


Se i processori "dal Pentium in poi a livello commerciale" si chiamano Itanium allora hai perfettamente ragione (ma Itanium non ha niente di Cisc). Se invece si chiamano Pentium, Celeron, Duron, Athlon, Sempron, invece NO: gli x86 non sono assolutamente dei processori VLIW, non essendo le istruzioni né di lunghezza fissa, né tantomeno di lunghezza notevole (very long instruction word). I Transmeta (se non ricordo male) erano dei VLIW con instruction word di 256 bit (mi pare), ma con gli x86, a parte l'emulazione via software, non mi pare avessero granchè in comune.

e l'unica reminiscenza del cosiddetto CISC è solo il set d'istruzioni..

Che per definizione determina l'essere formalmente CISC o RISC... Diciamo che gli x86 attuali sono piuttosto degli ibridi che cercano di combinare il meglio delle due filosofie: un set di istruzioni sufficientemente ampio e "complesso" da consentire una rapida ottimizzazione del codice per impieghi general purpose e una implementazione interna con microoperazioni risc-like, che consentono di semplificare in qualche modo la complessità circuitale e velocizzare le operazioni (ma sono diverse dalle istruzioni risc: non sono certo pensate per un uso generale e "diretto", bensì studiate per risolvere il problema specifico dell'implementazione delle istruzioni cisc in modo semplice e veloce, ottimizzandone l'esecuzione).

Originariamente inviato da LucaTortuga
Il marketing di Dell & company sul contenimento dei prezzi e sui grandi volumi di vendita.
Ergo, mentre per Apple può essere fondamentale poter gridare ai 4 venti di avere a disposizione un processore nuovo e migliore, la cosa è assolutamente indifferente per Dell e per il 99,9% dei suoi clienti (le aziende ordinano 2000 PC da Dell perchè costa meno e la ritengono affidabile, non certo perchè monta questo o quel processore).


Questo è vero ogni qual volta vuoi guadagnare sui grandi numeri, devi fare un'adeguata politica sui prezzi, sul rapporto qualità/prezzo e un marketing appropriato, ma devi anche differenziare la tua clientela e cercare di soddisfare le diverse esigenze e tutte le eseigense di tutti i tuoi clienti: nel caso specifico non puoi non tener conto degli enthusiast, ed è quello che fa Dell, diversamente non si spiegano i modelli con processori dual core 840, o gli EE. Certo, rappresentano una quota infinitesima delle vendite e dei fatturati, ma sono comunque una quota importante per questioni di immagine, una quota che non si può in alcun modo trascurare.

Anche volendo puntare tutto sui grandi volumi e i prezzi contenuti, devi poter gridare ai quattro venti "Io ti posso offrire il MEGLIO e al MINOR prezzo", non basta parlare del minor prezzo o del rapporto qualità/prezzo, perchè la psicologia del compratore è strana, è contorta: la gente vorrebbe spendere sempre poco, in particolare sempre meno di quanto effettivamente spende, però, al contempo, tende ad associare un costo elevato ad una elevata qualità, e a guardare con sospetto, al primo impatto, un prodotto più o meno equivalente ma dal costo (sensibilmente) inferiore, teme sempre ci sia sotto qualcosa. Ed ecco che, comunque, servono dei prodotti di punta che tengano alta l'immagine del marchio, così come servono gli "specchietti per le allodole".

Un discorso simile si potrebbe fare per Ati e Nvidia: i guadagni VERI li fanno sulle schede di fascia media e bassa, prodotte in grandi volumi e vendute a prezzi contenuti (è vero che hanno trovato il modo di far alzare il costo "minimo" delle schede di una famiglia con la politica della differenziazion, ma questo è un altro discorso). Eppure, producono e vendono gpu molto più costose e molto più veloci, che contribuiscono in minima parte ai loro profitti; cionondimeno, fanno puntualmente a gara a chi presenta il chip più veloce e ottiene i punteggi più elevati nei benchmark, talvolta anche "barando", con prodotti che poi, spesso, sono introvabili sul mercato, diventando delle "phantom edition", e che, tuttosommato, non hanno grandissimo interesse a vendere, non potendone trarre grandi profitti. Perché affannarsi tanto allora? Questione di immagine.

Ora, Dell è il principale partner commerciale di Intel, o comunque uno dei principali, mentre Apple è l'ultima arrivata: se Intel, potendo materialmente farlo, fornisse dei processori in anticipo ad Apple, a livello di immagine questo rapporto di forze sarebbe sovvertito, e non credo che Dell e company lo gradirebbero. Il problema, a mio modo di vedere, non è se Intel abbia o meno l'interesse, potendo materialmente, o la volontà di favorire Apple in questo modo e in questo momento, e nemmeno se ciò costituirebbe un reale danno per Dell, ma se Dell a prescindere sia disposta ad accettare che ciò avvenga, a lasciare che un altro competitor diventi il primo partner tecnologico di Intel senza battere ciglio, e se Intel possa permettersi in questo momento di ignorare eventuali pressioni affinchè ciò non accada.

Tutto, sempre, IMHO.

Non esiste la frase "ha parecchio in comune"...
Guarda che non hai preso la frase, ma un pezzo della frase:

"a LIVELLO DI IMPLEMENTAZIONE [...] ha parecchio in comune"

l'avevo scritto anche a caratteri cubitali... ;)
i processori in produzione attualmente(in realtà da 15 anni) sono RISC...e l'unica reminiscenza del cosiddetto CISC è solo il set d'istruzioni..
Al contrario, da questo punto di vista non ci sono molte differenze fra CISC e RISC moderni: hanno tutti un set d'istruzioni vasto e abbastanza "complesso".

La caratteristicha che ancora oggi distingue sicuramente un processore CISC da un RISC è la presenza di un set d'istruzioni con opcode a lunghezza variabile, al contrario di quello fisso usato da questi ultimi.

Poi ci sarebbe da considerare anche la presenza di modalità d'indirizzamento più complesse (i RISC ne hanno di molto semplici) e la presenza di istruzioni non di load/store che accedono direttamente alla memoria (i RISC hanno soltanto load/store per accedere alla memoria, e tutte le altre istruzioni fanno uso di registri).

Questo in generale e prendendo soltanto gli elementi più significativi (non ho parlato di istruzioni specifiche, come può essere una AAD in un x86, né di microcodice, ad esempio).
Tra l'altro i processori attuali (ma questo ragionamento è vero praticamente dal Pentium in poi a livello commerciale) sono una evoluzione del RISC essendo in realtà dei processori VLIW vettoriali e superscalari.
Bisogna vedere cosa intendi con ciò.

A livello implementativo i CISC hanno iniziato a utilizzare tecnologie prima apparse sui RISC (che sono stati il "fiore all'occhiello" della ricerca e sviluppo nel campo dei microprocessori) per migliorare le prestazioni: mi riferisco alla presenza della cache (L1 e poi L2 ed L3), della separazione fra cache codice e dati, l'uso di bus multipli, di superpipeline che permettevano di eseguire più istruzioni, di esecuzione fuori ordine, di politiche di aggiornamento / consistenza dei dati (write through, write-back, bus snooping, ecc.).
80386, 80486, Pentium, 68020, 68030, 68040, 68060, ecc. hanno fatto parecchio uso di tutto ciò, ma sono pur sempre rimasti dei CISC... ;)

Soltanto a partire dal K5 di AMD (a cui ha fatto seguito Intel col PentiumPro) è stata integrata un'unità RISC-like per l'esecuzione delle istruzioni, per cui le istruzioni x86 veniva "tradotte" in una o più istruzioni "RISC-86" e poi eseguite.
Ma il K5 è rimasto sempre un CISC: non è diventato un RISC soltanto perché A LIVELLO IMPLEMENTATIVO (lo voglio sottolineare ancora una volta), si è fatto uso di un'architettura basata sulla "filosofia RISC".

E si badi bene: non a caso ho parlato di "filosofia". Questo perché arrivare alla conclusione che "i RISC sono migliori dei CISC perché ormai questi ultimi ne integrano uno" è quanto di più sbagliato si possa pensare di fare.
Quei "RISC" hanno motivo di esistere soltanto in seno all'architettura per cui sono stati pensati e utilizzati: non è possibile ipotizzare, ad esempio, che se fossero costruiti dei processori senza tutto "l'orpello" di cui sono circondati, e quindi con un'ISA "nativa" (verrebero eseguite direttamente le istruzioni RISC senza alcuna traduzione), avrebbero buone prestazioni e forse anche molto migliori; al contrario, il decadimento prestazionale sarebbe notevole.

Conclusione: i CISC continuano a rimanere sempre tali, e lo stesso vale per i RISC... ;)

Al contrario, da questo punto di vista non ci sono molte differenze fra CISC e RISC moderni: hanno tutti un set d'istruzioni vasto e abbastanza "complesso".

La caratteristicha che ancora oggi distingue sicuramente un processore CISC da un RISC è la presenza di un set d'istruzioni con opcode a lunghezza variabile, al contrario di quello fisso usato da questi ultimi.

Poi ci sarebbe da considerare anche la presenza di modalità d'indirizzamento più complesse (i RISC ne hanno di molto semplici) e la presenza di istruzioni non di load/store che accedono direttamente alla memoria (i RISC hanno soltanto load/store per accedere alla memoria, e tutte le altre istruzioni fanno uso di registri).

Questo in generale e prendendo soltanto gli elementi più significativi (non ho parlato di istruzioni specifiche, come può essere una AAD in un x86, né di microcodice, ad esempio).

1)l'opcode a lunghezza variabile non ha alcun senso..ciò che ha senso è solo l'opcode dell'istruzione effettivamente calcolata che poi è solo la microistruzione..non è un caso infatti che sia assolutamente impossibile progettare a livello hardware un processore senza definire il set d'istruzioni (e quindi la lunghezza in bit dell'opcode)..questo infatti comporta una minimizzazione e ottimizzazione dell'hardwrae sempre e comunque.
2)Modalità d'indirizzamento complesse sono tipiche solo dei DSP..che possono anche confondersi con processori "normali" ma non lo sono affatto..possono anche confondersi con processori CISC..ma anche in questo caso non lo sono affatto.
3)Ancora confusione con i DSP che non sono innaznitutto macchine CISC (e ci mancherebbe) ma sono solo macchine vettoriali con particolari istruzioni come la MAC che possono permettersi l'accesso in memoria.


Bisogna vedere cosa intendi con ciò.

A livello implementativo i CISC hanno iniziato a utilizzare tecnologie prima apparse sui RISC (che sono stati il "fiore all'occhiello" della ricerca e sviluppo nel campo dei microprocessori) per migliorare le prestazioni: mi riferisco alla presenza della cache (L1 e poi L2 ed L3), della separazione fra cache codice e dati, l'uso di bus multipli, di superpipeline che permettevano di eseguire più istruzioni, di esecuzione fuori ordine, di politiche di aggiornamento / consistenza dei dati (write through, write-back, bus snooping, ecc.).
80386, 80486, Pentium, 68020, 68030, 68040, 68060, ecc. hanno fatto parecchio uso di tutto ciò, ma sono pur sempre rimasti dei CISC... ;)

Soltanto a partire dal K5 di AMD (a cui ha fatto seguito Intel col PentiumPro) è stata integrata un'unità RISC-like per l'esecuzione delle istruzioni, per cui le istruzioni x86 veniva "tradotte" in una o più istruzioni "RISC-86" e poi eseguite.
Ma il K5 è rimasto sempre un CISC: non è diventato un RISC soltanto perché A LIVELLO IMPLEMENTATIVO (lo voglio sottolineare ancora una volta), si è fatto uso di un'architettura basata sulla "filosofia RISC".

E si badi bene: non a caso ho parlato di "filosofia". Questo perché arrivare alla conclusione che "i RISC sono migliori dei CISC perché ormai questi ultimi ne integrano uno" è quanto di più sbagliato si possa pensare di fare.
Quei "RISC" hanno motivo di esistere soltanto in seno all'architettura per cui sono stati pensati e utilizzati: non è possibile ipotizzare, ad esempio, che se fossero costruiti dei processori senza tutto "l'orpello" di cui sono circondati, e quindi con un'ISA "nativa" (verrebero eseguite direttamente le istruzioni RISC senza alcuna traduzione), avrebbero buone prestazioni e forse anche molto migliori; al contrario, il decadimento prestazionale sarebbe notevole.

Conclusione: i CISC continuano a rimanere sempre tali, e lo stesso vale per i RISC... ;)

Questa è una visione macroscopico-commerciale di un processore che comporta solo confusione.

A livello implementativo basta poco per definire una macchina RISC o comuqnue un approccio RISC:
1)Architettura Harvard
2)Architettura Load/store e operazioni registro/registro
3)formato istruzioni fisso (a livello ultimo)
4)durata fissa di una singola istruzione (1 ciclo o meno)
5)ISA modellato sulle applicazioni
6)istruzioni semplici e hardware esposto al compilatore..
7)Pipeline a più di 3 stadi.

ovvio che l'approccio esposto da questi punti si sia evoluto..ma l'evoluzione successiva è comuqnue partita da qui..e da qui non si è mossa.
Le macroistruzioni che sono rimaste ad essere spezzettate in microoperations non hanno alcun significato a livello progettuale se non quello di semplificare la comunicazione tra progettista ed hw...a livello progettuale tutto è partito da quio e da qui si è evoluto e da qui il "vero" CISC è morto.

PS:cache L1,L2,bus nooping,write back etc etc...sono cose macroscopiche a livello progettuale..non sono certo quelle che determinano la differenza tra architetture.Se si pensa infatti che il Pentium2 è stato il primo processore superscalare commerciale..eppure conteneva tutti questi elementi..senza parlare dell'evoluzione vliw o vettoriale.

1)l'opcode a lunghezza variabile non ha alcun senso..
Ha senso perché è l'unico parametro (assieme al load/store) che è rimasto in piedi per discriminare le due diverse tipologie di architetture...
ciò che ha senso è solo l'opcode dell'istruzione effettivamente calcolata che poi è solo la microistruzione..
Non è mica detto: un'istruzione dell'ISA "nativo" può essere scomposta anche in più microistruzioni in un'architettura dotata di unità d'esecuzione interna RISC-like.
non è un caso infatti che sia assolutamente impossibile progettare a livello hardware un processore senza definire il set d'istruzioni (e quindi la lunghezza in bit dell'opcode)..
Questo concetto mi sembra a dir poco lapalissiano, ma non capisco cosa c'entra con quanto scritto sopra...
questo infatti comporta una minimizzazione e ottimizzazione dell'hardwrae sempre e comunque.
Cosa intendi con ciò?
2)Modalità d'indirizzamento complesse sono tipiche solo dei DSP..
Al contrario: i CISC sono noti proprio perché generalmente hanno modalità d'indirizzamento MOLTO complesse. Vedi, ad esempio, i Motorola 68020+.
che possono anche confondersi con processori "normali" ma non lo sono affatto..possono anche confondersi con processori CISC..ma anche in questo caso non lo sono affatto.
I DSP sono casi particolari, perché spesso implementano diversi tipi di istruzioni "specializzate" e modalità d'indirizzamento, ma hanno sempre un'architettura molto semplice e lineare, e sono dotati di opcode di dimensione fissa. Possiamo pensarli come a dei RISC molto specializzati.
3)Ancora confusione con i DSP che non sono innaznitutto macchine CISC (e ci mancherebbe)
Infatti non lo sono e sono tutt'altro che confuso: ho chiari i concetti.
ma sono solo macchine vettoriali con particolari istruzioni come la MAC che possono permettersi l'accesso in memoria.
Generalmente anche i DSP hanno delle istruzioni load / store. Il fatto che siano macchine "vettoriali" non dice niente che possa aiutare a inquadrarli nella categoria dei CISC o dei RISC.
Questa è una visione macroscopico-commerciale di un processore che comporta solo confusione.
Ah, e la tua sarebbe quella dettagliatamente scientifica? Vediamo...
A livello implementativo basta poco per definire una macchina RISC o comuqnue un approccio RISC:
1)Architettura Harvard
E' soltanto una tecnologia.
2)Architettura Load/store e operazioni registro/registro
Sì, e già detto anche prima.
3)formato istruzioni fisso (a livello ultimo)
Benissimo. Proprio quello che ho detto io all'inizio.
4)durata fissa di una singola istruzione (1 ciclo o meno)
Fammi un esempio di RISC che rientra in questa categoria, perché non ne conosco: in genere esistono istruzioni che vengono eseguite in un numero variabile di cicli di clock.
5)ISA modellato sulle applicazioni
Ad esempio?
6)istruzioni semplici
Non è detto. Vedi le istruzioni di load / store multiple registers, ad esempio, che sono presenti in tante architetture RISC.

PowerPC e ARM (sia in modalità ARM che Thumb) sono degli ottimi esempi.
e hardware esposto al compilatore..
Non capisco cosa tu voglia dire. Chi scrive i compilatori in genere è a conoscenza di tutti i dettagli del funzionamento dell'ISA dell'architettura target, e questo vale per QUALUNQUE tipo di processore: poi sta a lui/loro sfruttarne le peculiarità, se possibile.
7)Pipeline a più di 3 stadi.
Anche questo, come l'architettura Harvard, è un mero dettaglio implementativo. Infatti il primo ARM di Acorn, apparso per la prima volta dentro l'Archimedes, aveva una pipeline a soli 3 stadi.
ovvio che l'approccio esposto da questi punti si sia evoluto..ma l'evoluzione successiva è comuqnue partita da qui..e da qui non si è mossa.
Direi proprio di no, invece. I punti base possiamo considerarli soltanto la lunghezza fissa degli opcode, e la presenza delle sole load/store per accedere alla memoria, come avevo già scritto tra l'altro. Il resto è soltanto tecnologia impiegata o un dettaglio implementativo...
Le macroistruzioni che sono rimaste ad essere spezzettate in microoperations non hanno alcun significato a livello progettuale se non quello di semplificare la comunicazione tra progettista ed hw...
Scherziamo? Per un progettista è molto più comodo lavorare con delle "macroistruzioni" (e microcodice) che avere un altro processore all'interno a cui passare una o più istruzioni da eseguire.

Se è stato pensato e realizzato questo approccio è per migliorare le prestazioni globali della CPU. Tant'è che anche IBM con Power 4/PPC970 e Power5 ha seguito la stessa strada: eppure sono dei RISC...
a livello progettuale tutto è partito da quio e da qui si è evoluto e da qui il "vero" CISC è morto.
Morto? A me pare più che vivo... :p Ha semplicemente cambiato col tempo la sua implementazione, ma è una cosa normalissima... ;)
PS:cache L1,L2,bus nooping,write back etc etc...sono cose macroscopiche a livello progettuale..non sono certo quelle che determinano la differenza tra architetture.
Infatti li ho portati, assieme agli altri, come esempi di TECNOLOGIE sperimentate prima coi RISC e approdate poi ai CISC...
Se si pensa infatti che il Pentium2 è stato il primo processore superscalare commerciale..
Infatti non lo è stato: è stato il Pentium il primo...
eppure conteneva tutti questi elementi..
Elementi che sono stati aggiunti nel tempo: Pentium ha aggiunto soltanto la divisione della cache dati e istruzioni (che comunque Intel non aveva realizzato col 486, mentre Motorola sì col "contemporaneo" 68040) e la superpipeline, e null'altro di tecnologicamente significativo.
senza parlare dell'evoluzione vliw o vettoriale.
Nessuna evoluzione VLIW. Inoltre di vettoriale dentro gli attuali CISC ci sono soltanto le unità SIMD, ma queste sono presente anche nei RISC...

1)proprio perchè la normale prassi da circa 15 anni è quella di scomporre un ISA completo in microistruzioni non ha senso parlare di opcode di lunghezza variabile come forma distintiva.
2)come ho già detto la progettazione e la minimizzazione del set d'istruzioni comporta la formazione dei cosiddetti "control path" e "data path" che definiscono i segnali di controllo e le risorse per il trattamento dei dati.Da queste entità iniziali di progetto dipende il numero di ALU,di registri di contatori etc etc..insomma di qualsiasi cosa intervenga all'interno del processore.e la cosa diventa ancora più importante in un general purpose.Ecco che quindi il set d'istruzioni condiziona pesantemente il progetto dell'hardwrae e la sua minimizzazione (inutile mettere risorse sottoutilizzate o inutilizzate come troppi moltiplicatori ad esempio che prendono spazio su chip..meglio abbondare ad esempio in addizion atori e registri).
3)gli indirizzamenti complessi di processori "CISC" erano uno dei modi che si aveva per sopperire all'assenza di un approccio RISC e di pipeline strutturate e cercare contemporaneamente di aumentare le prestazioni:erano uno stratagemma non certo un vanto.
Lo stesso tipo di stratagemma è,appunto,stato utilizzato nei DSP che,per problemi storici e di costi non possono sempre permettersi le stesse unità funzionali dei general purpose ma necessitano cmq di indirizzare grandi quantità di vettori in maniera efficace.
4)l'architettura Harvard non è una tecnologia. E' un principio generale di progetto che vede l'unità centrale comunicare contemporaneamente sia con la memoria del programma che con la memoria dei dati. L'architettura precedente (detta diu Von neumann) non aveva questa distinzione e quindi comportava un progetto meno efficace.
5)Tipicamente la MOV,la ST,la ADD,la MUL,la SUB hanno latenze (per calcoli non iterativi) di un ciclo di clock (la MUL solo con unità dedicate però).
la LD tipicamente due/tre cicli,la BR tipicamente dai 3 ai 4 (o anche due a volte)..etc etc.
6)un ISA modellato sulle applicazioni è scelto in modo da avere delle risorse su chip minime pur mantenendo l'efficacia di calcolo.
Ad esempio:non ha senso se si devono fare molte somme/sottrazioni su interi inserire sia sommatori che sottrattori (o segnali di controllo diversi per i sommatori)..mi è più utile eliminare l'istruzione di SUB per simularla con l'istruzione di ADD e l'utilizzo dei registri.
Un altro esempio: A meno che io non voglia una macchina vettoriale è inutile inserie moltiplicatori dedicati su chip e la relativa istruzione..tanto meglio utilizzare uno shifter con cui posso calcolare anche gli spazi d'indirizzamento.
alla fine del progetto quindi l?ISA è minimo e anche le risorse su chip sono minimizzate.
7)Come ho già detto..dalle basi del RISC si è poi partiti per i diversi approcci.Il motivo è abbastanza semplice..tutti gli approcci più evoluti comportano l'utilizzo di tutte le features dei RISC,soprattutto della sua pipeline strutturata..e non avrebbero senso senza.
8)Ribadisco inoltre che le macrositruzioni sono comode per fare ottimizzazione..cosi come è comodo lavorare sui programmi e sul codice(chessò il C del programma) per farle.E' dimostrato infatti che più si va a livello utente e più le ottmizzazioni sono efficaci.questo non toglie però che quando vado a progettare il processore i miei giochi li faccio sulle microoperations e non sul codice macroscopico..e se ho già scelto l'ISA del codice i giochi sono fatti.
9)anche le load/store mR sono istruzioni semplici..
10)"Hw esposto al compilatore" significa ottimizzare l'ISA per le applicazioni da compilare attraverso processi che minimizzino le nooperations (nop) e non sprechino quindi risorse (chessò durante un salto ad esempio).
Di solito quindi si definisce un set d'istruzione e si effettuano varie prove compilando programmi in modo da ottimizzare il set stesso a seconda del programma cone con il loop unrolling o altre mille3mila tecniche.
11)come fa la pipeline ad essere solo un dettaglio implementativo..è il cuore del calcolo e della progettazione..se fai una pipeline diversa hai fatto un progetto diverso.
12)Il processore Pentium è stato il primo ad implementare le microoperations..il primo processore Superscalare,come ho detto,è stato il Pentium2 dove per superscalare si intende la codifica e l'esecuzione di più istruzioni per ciclo..cosa che il Pentium faceva ma a metà visto che la soluzione era implementata con una seconda pipeline indipendente (quindi non era superscalare in maniera completa) che lavorava solo quando ce n'era bisogno (cioè quando una istruzione poteva essere mandata in parallelo) cioè molto raramente
13)quando ho parlato di evoluzioni successive mi riferivo all'approccio supercslare prima,al VLIW poi,al VLIW superscalare,e all'implementazione di approcci special purpose come macchine vettoriali,approcci SIMI e MIMD in macchine general purpose.Che poi sono la realtà degli anni passati a livello architetturale.

1)proprio perchè la normale prassi da circa 15 anni è quella di scomporre un ISA completo in microistruzioni non ha senso parlare di opcode di lunghezza variabile come forma distintiva.
Non è affatto la normale prassi, visto e considerato che ciò si verifica soltanto con alcuni processori (x86 dal K5 in poi e i POWER & derivati di IBM) e soltanto perché l'obiettivo da raggiungere era un miglioramento generale delle prestazioni.

Inoltre quando elencavi le caratteristiche di una macchina RISC o con approccio RISC hai scritto questo :

"3)formato istruzioni fisso (a livello ultimo)"

Che è chiaramente in contraddizione con quanto hai appena asserito e sul fatto che non abbia senso.

Ha senso, invece, perché non ho mai visto un RISC con opcode a lunghezza variabile e questa caratteristica invece la ritroviamo in tutti i CISC.
2)come ho già detto la progettazione e la minimizzazione del set d'istruzioni comporta la formazione dei cosiddetti "control path" e "data path" che definiscono i segnali di controllo e le risorse per il trattamento dei dati.Da queste entità iniziali di progetto dipende il numero di ALU,di registri di contatori etc etc..insomma di qualsiasi cosa intervenga all'interno del processore.e la cosa diventa ancora più importante in un general purpose.Ecco che quindi il set d'istruzioni condiziona pesantemente il progetto dell'hardwrae e la sua minimizzazione (inutile mettere risorse sottoutilizzate o inutilizzate come troppi moltiplicatori ad esempio che prendono spazio su chip..meglio abbondare ad esempio in addizion atori e registri).
Questo è vero soltanto quando si crea un'architettura completamente nuova.

Infatti il set d'istruzioni degli x86 dal 386 in poi è rimasto sostanzialmente lo stesso (escludendo le estensioni SIMD), ma i cambiamenti all'interno delle varie implementazioni sono stati tantissimi e molto profondi. Non è certo stato riprogettato da capo l'ISA x86 quando si è passati dal 386 al 486, e così via...
3)gli indirizzamenti complessi di processori "CISC" erano uno dei modi che si aveva per sopperire all'assenza di un approccio RISC e di pipeline strutturate e cercare contemporaneamente di aumentare le prestazioni:erano uno stratagemma non certo un vanto.
I CISC e le loro modalità d'indirizzamento esistevano prima ancora che IBM tirasse fuori il primo RISC.

Inoltre la presenza di modalità d'indirizzamento "complesse" non era certo una scelta "di ripiego". Al contrario, sono state aggiunte proprio perché molto comode e permettevano di scrivere codice molto compatto. Caratteristica questa, che è tipica proprio dei CISC.

Esempio:

move.l (a0)+,d0

è una modalità presente nei Motorola 68000 utilissima, usatissima, e sfruttata abbondantemente anche dai compilatori (es: Pippo = *Puntatore++;).

Altro esempio:

move eax,[ebx + ecx * 4]

per gli x86 è anche questa una modalità molto usata anche dai compilatori (es: Pippo = VettoreDiInt32[Indice];)

Le modalità di indirizzamento sono quindi un vanto delle architetture CISC, proprio perché permettono di scrivere velocemente codice, risparmiando anche spazio.
Al contrario, per realizzare le stesse cose coi RISC sono in genere necessarie più istruzioni e quindi più spazio occupato (e questo incide anche sulle cache).

Infine la struttura della pipeline non c'entra niente: è un dettaglio implementativo che non dipende strettamente dal tipo di architettura.
Lo stesso tipo di stratagemma è,appunto,stato utilizzato nei DSP che,per problemi storici e di costi non possono sempre permettersi le stesse unità funzionali dei general purpose ma necessitano cmq di indirizzare grandi quantità di vettori in maniera efficace.
Più che altro hanno bisogno di manipolare grandi quantità di dati, e per far questo non hanno certo bisogno di modalità d'indirizzamento complesse.
Al contrario, poiché sono progettati per elaborare grossi stream di dati, l'accesso alla memoria è spesso sequenziale (o comunque "localizzata").
Infatti i DSP hanno un design molto semplice.
4)l'architettura Harvard non è una tecnologia. E' un principio generale di progetto che vede l'unità centrale comunicare contemporaneamente sia con la memoria del programma che con la memoria dei dati. L'architettura precedente (detta diu Von neumann) non aveva questa distinzione e quindi comportava un progetto meno efficace.
Infatti l'ho anche chiamata architettura. ;) In ogni caso è assolutamente indipendente dal tipo di architettura, ed è questo ciò che conta in questo contesto.
5)Tipicamente la MOV,la ST,la ADD,la MUL,la SUB hanno latenze (per calcoli non iterativi) di un ciclo di clock (la MUL solo con unità dedicate però).
la LD tipicamente due/tre cicli,la BR tipicamente dai 3 ai 4 (o anche due a volte)..etc etc.
Questi dati dove li hai presi? Link?

RISC diversi hanno valori diversi, e tante volte vale anche per quelli che appartengono alla stessa famiglia.
6)un ISA modellato sulle applicazioni è scelto in modo da avere delle risorse su chip minime pur mantenendo l'efficacia di calcolo.
Ad esempio:non ha senso se si devono fare molte somme/sottrazioni su interi inserire sia sommatori che sottrattori (o segnali di controllo diversi per i sommatori)..mi è più utile eliminare l'istruzione di SUB per simularla con l'istruzione di ADD e l'utilizzo dei registri.
Un altro esempio: A meno che io non voglia una macchina vettoriale è inutile inserie moltiplicatori dedicati su chip e la relativa istruzione..tanto meglio utilizzare uno shifter con cui posso calcolare anche gli spazi d'indirizzamento.
alla fine del progetto quindi l?ISA è minimo e anche le risorse su chip sono minimizzate.
Questo, come ho già detto, capita soltanto quando si progettano delle architetture nuove. Anzi, quando capitava, visto che da parecchi anni a questa parte i RISC non hanno certo un set d'istruzioni "ridotto", ma molto ampio e da questo punto di vista in competizione con quello di tanti CISC.
7)Come ho già detto..dalle basi del RISC si è poi partiti per i diversi approcci.Il motivo è abbastanza semplice..tutti gli approcci più evoluti comportano l'utilizzo di tutte le features dei RISC,soprattutto della sua pipeline strutturata..e non avrebbero senso senza.
Quelle che hai elencato non sono tutte caratteristiche intrinseche dei RISC: per lo più si tratta di tecnologie che possono essere impiegate nell'implementazione delle architetture più disparate. Infatti le ritroviamo anche in tanti CISC.

Inoltre, come ho già detto, la struttura della pipeline non è strettamente legata al tipo di architettura. Infatti quella dei processori x86 ha subito notevoli e profonde modifiche col passare del tempo. Ma sempre CISC sono rimasti.
8)Ribadisco inoltre che le macrositruzioni sono comode per fare ottimizzazione..cosi come è comodo lavorare sui programmi e sul codice(chessò il C del programma) per farle.E' dimostrato infatti che più si va a livello utente e più le ottmizzazioni sono efficaci.
Non mi è chiaro: potresti spiegarti meglio, cortesemente?
questo non toglie però che quando vado a progettare il processore i miei giochi li faccio sulle microoperations e non sul codice macroscopico..e se ho già scelto l'ISA del codice i giochi sono fatti.
Appunto, l'ISA di un progetto non la puoi mica stravolgere: cambi soltanto la sua implementazione. E' quel che avvenuto sia coi RISC sia coi CISC. Basta prendere come riferimento le famiglia PowerPC e x86 rispettivamente, ad esempio.
9)anche le load/store mR sono istruzioni semplici..
Più semplici di una move, add, ecc. sicuramente no.
10)"Hw esposto al compilatore" significa ottimizzare l'ISA per le applicazioni da compilare attraverso processi che minimizzino le nooperations (nop) e non sprechino quindi risorse (chessò durante un salto ad esempio).
Di solito quindi si definisce un set d'istruzione e si effettuano varie prove compilando programmi in modo da ottimizzare il set stesso a seconda del programma cone con il loop unrolling o altre mille3mila tecniche.
Ma questo, appunto, si verifica soltanto quando si progetta una nuova architettura. E neanche tanto, visto che esistono tantissime tipologie di codice, anche all'interno della stessa applicazione; infatti difficilmente i processori hanno degli obiettivi talmente specializzati da rimuovere, ad esempio, l'istruzione SUB. Ha molto più senso quando si progetta un DSP per scopi specifici.

Quello dello spreco delle risorse è un problema più che altro dei processori VLIW (ed EPIC / Itanium).
11)come fa la pipeline ad essere solo un dettaglio implementativo..è il cuore del calcolo e della progettazione..se fai una pipeline diversa hai fatto un progetto diverso.
Hai fatto un'implementazione diversa dello stessa architettura, per essere precisi. Vedi ad esempio le differenze fra G3 e G4, che condividono la stessa ISA, ma che internamente sono implementati in maniera molto diversa.
12)Il processore Pentium è stato il primo ad implementare le microoperations..
No, è stato il K5 di AMD, come ho già detto.
il primo processore Superscalare,come ho detto,è stato il Pentium2 dove per superscalare si intende la codifica e l'esecuzione di più istruzioni per ciclo..
Questa è la definizione classica è quindi il Pentium ci rientra perfettamente.
cosa che il Pentium faceva ma a metà visto che la soluzione era implementata con una seconda pipeline indipendente (quindi non era superscalare in maniera completa) che lavorava solo quando ce n'era bisogno (cioè quando una istruzione poteva essere mandata in parallelo) cioè molto raramente
Che è praticamente il modo di lavorare delle architetture con superpipeline: le istruzioni seguenti alla prima vengono eseguite soltanto quando ci sono le condizioni.

Infatti Pentium aveva delle restrizioni sul tipo e l'ordine delle due istruzioni che poteva eseguire, né più né meno di qualunque processore con superpipeline.
Ad esempio PPC970 può eseguire 2 istruzioni intere, ma mica può farlo sempre: dipende dal tipo di istruzione e da eventuali conflitti.
13)quando ho parlato di evoluzioni successive mi riferivo all'approccio supercslare prima,al VLIW poi,al VLIW superscalare,e all'implementazione di approcci special purpose come macchine vettoriali,approcci SIMI e MIMD in macchine general purpose.Che poi sono la realtà degli anni passati a livello architetturale.
Gli x86 hanno avuto l'approccio superscalare prima, e poi l'uso di unità RISC-like (che era sempre superscalare). Nient'altro.
Se per approccio VLIW intendi quest'ultimo caso, allora ok, anche se non è corretto come termine, visto e considerato che tutt'oggi esistono ancora tante istruzione che vengono eseguite tramite microcodice...

1) Non c'è nessuna contraddizione...quando si progetta il set d'istruzioni non è definito finchè non è ottimizzato e le procedure di ottimizzazioni sono antecedenti al progetto del data path.

2)è ovvio che stiamo parlando di progettazione "full custom" visto che si parla dell'intera architettura.

3)E' risaputo che modalità d'indirizzamento complesse possono essere un vanatggio in alcune tipologie di calcolo ma non è questo il punto.
Le modalità d'indirizzamento usate nei CISC e nei DSP sono una soluzione a problemi diversi.
nei DSP servono ad un'analisi vettoriale completa non possibile con le macchine general purpose...nei CISC sopperivano alla mancanza di registri strutturati all'interno degli stadi delle (piccole) pipeline usate e sopperivano all'assenza degli stadi di interfaccia con la memoria più alti inseriti nella pipeline solo dall'approccio RISC.

4)i DSP non hanno bisogno di strutture d'indirizzamento ma utilizzano un algortimo sequenziale?
Da dove viene questa idea?
Storicamente è l'esatto contrario ed è proprio questo che distacca i DSP da eventuali architetture RISC.
Le strutture d'indirizzamento più usate sono:

incremento circolare
bit reversed (per il calcolo della FFT)
reversed
crossed (tra registri)


nessun DSP avrebbe le prestazioni che può ottenere se avesse solo indirizzamenti sequenziali dei vettori.

5)L'architettura indipendente dal tipo di architettura?
Ho capito ciò che vuoi dire...ma in realtà quella non si chiama architettura..ma semplicemente implementazione RTL che poi è il livello al quale si progettano i sistemi su processore a livello superiore a quello logico.

6)Nessun link...libri di microelettronica ed esperienza di progettazione...occhio che si parla di microoperations non di macroistruzioni.
Un esempio: la ADD(R2,R1) nel primo pentium(anzi nel pentium mmx) veniva spezzata in
load_aluop (R1)
load_aluop (R2)
add
store (R2) alures
quindi mi riferisco a queste ultime altrimenti che architettura risc sarebbe?

7)La distinzione tra tecnologie e architetture non ha senso.
Le architetture sono caratterizzate da tecnologie.
Le architetture self timed ad esempio sono caratterizzate dall'introduione di tecnologie self timed...adesso non posso andare da philips e dirle che i chip che mette nelle macchinette fotografiche non sono self timed ma sono CISC con una tecnologia self timed.
E cmq hennesy e Patterson parlarono chiaro al tempo sottolineando le caratteristiche della loro architettura nel RISC (il primo processore RISC si chiamava RISC).

8)Come ho detto..quando si progetta un processore si cerca di ottimizzarne l'hardware e quindi l'ISA a seconda delle applicazioni che dovranno girare su chip.E' dimostrato che la curva di ottimizzazione aumenta man mano che aumenta il livello in cui si fanno le ottimizzazioni.
Ad esempio: se io ottimizzo i miei transistor inserendone altri con caratteristiche e layout migliori l'ottimizzazione conseguente sarà limitata.
Se invece ottimizzo direttamente il codice del programma posso anche avere incrementi del 200%/300% nello Speed up di esecuzione.
Sembra una cosa ovvia..ma non lo è.

9)Ovvio che l'ISA non può essere cambiato DOPO la progettazione e l'ottimizzazione.Il piccolo particolare è che l?ISA di un CISC è completamente diverso dall'ISA di un RISC..e,visto che dall'ISA dipendono i data path e quindi la struttura delle risorse che devo mettere sul processore cosi come i segnali di controllo..i miei due processori saranno completamente diversi.
Non solo avranno data path diversissimi (il che potrebbe far gridare solo ad una differenza d'implementazione) ma anche control path diversi (più semplice quello del RISC) e quindi una architettura finale molto diversa.

10)Non è una gara di semplicità tra istruzioni.Dipende dal livello a cui operano.
SUB (R2,R1) è una istruzione complessa..load (R2) è una istruzione semplice...alusub è una istruzione semplice.E' il livello che garantisce la semplicità.

11)3 libri su 8 mi dicono pentium (gli altri non ne parlano)..non so che dire.

12)stiamo parlando di architetture..e quindi bisogna ddentrarsi nell'architettura in toto senza dare nulla per scontato proprio per carpirne le differenze.
Altrimenti è facile mettersi lì e bypassare qualsiasi problema usando il core relativo alla FPU,quello relativo all'unità di BP e cosi via...

13)ho capito che ci rientra..ma stiamo parlando di oggetti che funzionano e il Pentium da questo punto di vista funzionava poco e male...tra l'altro l'utilizzo di due pipeline è anche una soluzione di ripiego.

14)Come ho detto questa è una visione macroscopica.In realtà l'approccio superscalare mira ad avere entità interdipendenti tra loro per aumentare il parallelismo..mentre l'approccio del Pentium era quello di avere unità indipendenti tra di loro.
Pipeline dipendenti tra di loro non solo diminuiscono le noP dopo i salti,aumentano il parallelismo,diminuiscono i vincoli strutturali e quelli di RaW,WaW e WaR ma realizzano meglio la logica moderna con cui viene strutturata un'architettura superscalare:le Reservation stations.
Inoltre nel Pentium,per tanti motivi,non sfruttava appieno l'algortimo di Tomasulo e quindi aveva un basso livello di parallelismo.

15)Gli x86 non possono avere avuto un approccio superscalare antecedente ad unità RISC like semplicemente per il fatto che per avere un approccio superscalare è necessaria una pipeline strutturata e quindi un approccio RISC.
Senza questo approccio non solo è impossibile utilizzare le implementazioni tipiche come issue window+renamin o reservation stations..ma si hanno problemi anche con i vincoli strutturali e tutto il resto...
Certo..si potrebbero mettere pipeline non strutturate in parallelo..ma sarebbe come far correre una Renault5 GT nella F1...

io volevo solo dire:

quoto xeal su entrambi i post :D

io volevo solo dire:

quoto xeal su entrambi i post :D


ehehehe..si..è meglio finirla cò sti post chilometrici che annoiano chi legge e uccidono chi scrive

dai, dai, che siamo impazienti di vedere i primi apple / intel........

Io sinceramente non sono gran che entusiasta :stordita:

Apple non fa concorrenza nè a Dell nè tantomeno ad HP.. Nessun potenziale loro acquirente deciderebbe mai di comprare un Mac solo perchè monta un processore più nuovo. E non vale nemmeno il discorso OEM: se anche Intel concedesse ad Apple di usare i suoi processori migliori 3 mesi prima, cosa cambierebbe? Qualcuno immagina orde di smanettoni svaligiare gli Apple Store per acquistare un Powerbook, sventrarlo ed estrarne il prezioso Merom? Tutto si riduce ad una valutazione di fattibilità pratica, ed è più logico pensare che Intel, produzione permettendo, farà in modo di accontentare il buon vecchio Steve. Nessuno sa fare promozione come lui, già lo sento strillare al miracolo del processore piùùùùùù velocissimo dell'universo, con un marchio Intel ben in evidenza alle sue spalle...

Già è vero... Jobs quando parla pare pure simpatico.... :asd: :asd: :asd:

A me questo tipo di post non annoiano: se c'è qualcun altro interessato, possiamo continuare su un altro thread... ;)

Se lo aprite, posta il link, sicuramente sono interessato a leggere la continuazione della discussione ;)

La discussione continua qui (http://www.hwupgrade.it/forum/showthread.php?p=9703211#post9703211) per chi fosse interessato... ;)

ma sono cpu x86 o risc ?? :mbe:

Trattasi di CRISC (Complex Reducible Instruction Set Computer).

Sono CPU x86, e quindi CISC.

Sono CPU x86, e quindi CISC.

Intel definisce CRISC le CPU di classe P5 o superiore nel proprio documento IDC-22078 (Intel Confidential Document) del 22 Marzo 1993.

Potresti pero' aver ragione tu e torto Intel. Per fargli notare l'errore puoi scrivere a:

Intel Corporation
2200 Mission College Blvd.
Santa Clara, CA 95052
USA

Se è per questo, Intel definisce la "sua" (come ha affermato un suo manager :rolleyes: ) estensione a 64 bit EM64T e spaccia come caratteristica quella di permettere accedere a più di 4GB di memoria per applicazione, "dimenticandosi" tutto il resto... ;)

Comunque, il termine CRISC non è proprio da buttar via: suggerisce l'idea di un ibrido tra le due filosofie nel tentativo di unirne i pregi, che è il modo in cui mi piace pensare ai moderni CISC.

L'ISA, nel suo complesso, mi piace pensarla come CISC (non voglio uscire dal campo delle mie opinioni personali, nell'esporre il mio pensiero, perchè non ho la competenza necessaria per presentarle come una visione obiettiva e definitiva: mi limito a concordare con la "visione CISC" ), poichè le caratteristiche dell'instructin set sono quelle di un CISC e determinano il modo in cui il processore viene visto e trattato dall'esterno: il modo in cui verrà programmato, la cache dovrà essere gestita, ecc. - la conoscenza dell'implementazione interna, a mio avviso, può determinare un diverso riordino delle istruzioni o la scelta di workaround per evitare di incappare nell'esecuzione del microcodice, ma non, in generale, a uno stravolgimento totale nelle scelte inerenti la programmazione e l'ottimizzazione del codice: in generale, penso più a una influenza sulle scelte effettuate, scelte comunque possibili e valide a prescindere (le istruzioni e i possibili algoritmi sempre quelli sono), ma che possono assumere un diverso rilievo in un diverso contesto: dettagli su cui giocare per lavorare di fino, insomma, piuttosto che una "condicio sine qua non".

Di conseguenza, volendo assumere come punto di partenza nella progettazione l'idea suggerita in precedenza di un'ISA basata sulle applicazioni e un hardware esposto al compilatore, ritengo che l'instruction set x86, con le sue caratteristiche di "complessità", opcode a lunghezza variabile, ecc., non possa che essere la base imprescindibile nella progettazione dell'architettura interna, pur prevedendo, questa, un'implementazione RISC-like: ben più di una interfaccia "macroscopica", magari con funzioni di retrocompatibilità, come si potrebbe pensare dando troppo risalto alle caratteristiche RISC dell'implementazione interna. Tuttavia, proprio l'implementazione interna fa da "ponte" verso un instruction set ridotto e un'architettura "simil-RISC" che ha la sua importanza, pur non avendo ragion d'essere al di fuori del suo contesto: l'implementazione e l'esecuzione ottimizzata e veloce delle istruzioni x86 (mi piace molto il termine RISC-86, in riferimento ad una unità d'esecuzione RISC di per sé, ma creata e ottimizzata sulla base delle esigenze specifiche dell'ISA x86 da implementare: chi lo ha coniato?).

In questo senso, non mi dispiace il termine "CRISC", come tipologia implementativa o comunque variante in seno alla famiglia dei CISC che abbraccia in parte la filosofia RISC per trarre il meglio di entrambe. Un appunto: se R sta per Reducible può suggerire l'idea di una qualche modifica all'instruction set per farlo si rimanere di tipo "complex", ma al contempo renderlo, per l'appunto, "riducibile", sacrificando qualche istruzione o modificando in qualche modo l'opcode, o in qualunque altro modo, per facilitarne la "riduzione": che io sappia, nulla di tutto ciò è avvenuto, il tutto si riduce all'implementazione dell'architettura, o sbaglio? Personalmente troverei forse più attinente parlare di "Complex-to-Reduced Instruction Set Computer" - sperando di non fare pasticci con l'Inglese :D (ok, sto cercando il pelo nell'uovo :p).

Quanto a EM64T, beh, se c'è di mezzo il marketing ogni verità diventa opinabile... [acid-avoidable-mode on] poi, magari, l'indirizzamento è l'aspetto che hanno implementato meglio di AMD64 e fanno bene a metterlo in risalto, anche nel nome [acid-avoidable-mode off]

X repne scasb

Qualche tempo fa dicevi che negli A64 in modalità 64 bit è possibile che si manifesti un miglior riordino delle istruzioni e che l'uso di istruzioni "miste", in dipendenza delle dimensioni effettive dei dati contenuiti nei registri, o dei registri effettivamente utilizzati, potrebbe non portare ad un decadimento nelle prestazioni e anzi migliorarle, in alcuni casi: hai avuto altri riscontri in merito?

mamma mia quanto ho scritto, e io che speravo di non essere prolisso una volta tanto :D

forse avrei quel post starebbe meglio nell'altro thread, ma visto che l'argomento prosegue anche qui... magari con i prossimi, se ce ne saranno, ci spostiamo definitivamente la, che dite?

Se è per questo, Intel definisce la "sua" (come ha affermato un suo manager :rolleyes: ) estensione a 64 bit EM64T e spaccia come caratteristica quella di permettere accedere a più di 4GB di memoria per applicazione, "dimenticandosi" tutto il resto...

Questo e' vero. Ci sarebbe d'aggiungere pero' che quando Intel presenta la documentazione per gli sviluppatori, non tenta di nascondersi dietro un dito. Ti cito per completezza due documenti esemplificativi:

ID: 30083401 - 64-Bit Extension Technology Software Developer’s Guide Volume 1

ID:30083501 - 64-Bit Extension Technology Software Developer’s Guide Volume 2

utili per valutare anche le eventuali differenze rispetto al "modello" AMD64.

Qualche tempo fa dicevi che negli A64 in modalità 64 bit è possibile che si manifesti un miglior riordino delle istruzioni e che l'uso di istruzioni "miste", in dipendenza delle dimensioni effettive dei dati contenuiti nei registri, o dei registri effettivamente utilizzati, potrebbe non portare ad un decadimento nelle prestazioni e anzi migliorarle, in alcuni casi: hai avuto altri riscontri in merito?

No, in quanto il mio compilatore C-- e' in una fase di stallo per mancanza di tempo, e per tale motivo non sono stata in grado di testare il comportamente di codice mixed (8-16-32-64 bit) generato dal mio compilatore.

---------------------------------------

Un ultima annotazione sul termine Reducible: se ne parla solo nel documento confidenziale da me sopracitato, senza mai ritornare sull'argomento da parte di Intel. Non ho la piu' pallida idea di cosa volesse intendere Intel con il termine reducible nel 1993 a proposito del Pentium(P5).

Originariamente inviato da repne scasb
No, in quanto il mio compilatore C-- e' in una fase di stallo per mancanza di tempo, e per tale motivo non sono stata in grado di testare il comportamente di codice mixed (8-16-32-64 bit) generato dal mio compilatore.


Peccato, come prospettiva era sicuramente interessante. :)


Un ultima annotazione sul termine Reducible: se ne parla solo nel documento confidenziale da me sopracitato, senza mai ritornare sull'argomento da parte di Intel. Non ho la piu' pallida idea di cosa volesse intendere Intel con il termine reducible nel 1993 a proposito del Pentium(P5).

Beh, vorrà dire che ci rimarrà il dubbio sulle intenzioni :D Io, del resto, volevo solo riflettere sulle possibili implicazioni, impressioni, suggestioni connesse a un termine che si potrebbe accogliere (o "ricilare" eventualmente sotto un'altra veste) per inquadrare le scelte architetturali e implementative degli x86 attuali in una sottocategoria della famiglia CISC. Magari potremmo anche "inventarci" una categoria RRISC (Reduced-to-Reduced ISC) per descrivere l'approccio similare adottato sul versante RISC, con l'unità elaborativa interna "ancora più RISC" (ok, la smetto di giocare su dettagli praticamente fini a se stessi :p)

Questo e' vero. Ci sarebbe d'aggiungere pero' che quando Intel presenta la documentazione per gli sviluppatori, non tenta di nascondersi dietro un dito. Ti cito per completezza due documenti esemplificativi:

ID: 30083401 - 64-Bit Extension Technology Software Developer’s Guide Volume 1

ID:30083501 - 64-Bit Extension Technology Software Developer’s Guide Volume 2

utili per valutare anche le eventuali differenze rispetto al "modello" AMD64.
Indubbiamente. Ci mancherebbe che non fornisse agli sviluppatori tutta la documentazione necessaria per poter lavorare... ;)
Un ultima annotazione sul termine Reducible: se ne parla solo nel documento confidenziale da me sopracitato, senza mai ritornare sull'argomento da parte di Intel. Non ho la piu' pallida idea di cosa volesse intendere Intel con il termine reducible nel 1993 a proposito del Pentium(P5).
E' un termine che si trova anche in tanti altri posti, comunque.

A mio avviso intende forse il fatto che le istruzioni "complesse" dell'ISA x86 possono essere "ridotte" in microistruzioni per l'unità RISC-like.

x xeal: quando arrivarono l'80486 di Intel e il 68040 di Motorola, si cominciò a parlare di processori CRISP (Complex-Reduced Instruction Set Processor). Ma da allora (son passati 15 anni), non ne ho più sentito parlare...

http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

Qui c'è un'interessante analisi delle architetture RISC e CISC: anche se molto vecchia (risale al '99), val la pena leggerla... ;)

Beh, vorrà dire che ci rimarrà il dubbio sulle intenzioni :D Io, del resto, volevo solo riflettere sulle possibili implicazioni, impressioni, suggestioni connesse a un termine che si potrebbe accogliere (o "ricilare" eventualmente sotto un'altra veste) per inquadrare le scelte architetturali e implementative degli x86 attuali in una sottocategoria della famiglia CISC. Magari potremmo anche "inventarci" una categoria RRISC (Reduced-to-Reduced ISC) per descrivere l'approccio similare adottato sul versante RISC, con l'unità elaborativa interna "ancora più RISC" (ok, la smetto di giocare su dettagli praticamente fini a se stessi :p)


poco tempo per scrivere ma dico la mia:

l'opinione è interessante...è una forma di visione bootom-up e privilegia ciò che va verso l'utente più che privilegiare ciò che succede nella macchina.
Dal canto mio però preferisco una visione integrale (e integralista) della faccenda.
In ambito di progettazione infatti ciò con cui si ha a che fare è solo l'ISA ridotto..è grazie alla sua progettazione che si definisce l'hardwrae interno e le procedure di ottimizzazione.Da esso dipende il numero di risorse su chip e quindi le prestazioni e ovviamente anche i consumi.
Credo quindi che la denominazione di una categoria ne debba rispecchiare le caratteristiche e che quindi debba chiamarsi RISC...è inutile tirare fuori cose strane.

Se ho il motore di una ferrari e la scocca della 500 vedrò all'esterno una 500 ma sempre una ferrari rimane anche se le tecnologie si compenetrano.
Nel nostro caso abbiamo processori che hanno fuso entrambi gli approcci ma,personalmente,è più rilevante quello interno rispetto a quello esterno.

Se leggi l'articolo di cui ho fornito il link prima, non si può parlare nemmeno di RISC, visto che anche questi hanno "perso" le loro caratteristiche per cui sono nati.

Alla fine oggi non abbiamo dei RISC o dei CISC, ma un "misto" di entrambi.

D'altra parte se pensi a Power4/5 e G5, non è forse paradossale che si serva di un RISC ancora più semplice all'interno per eseguire le istruzioni PowerPC (che scompone nelle microistruzioni di questo "reduced" :D RISC)? Da questo punto di vista questi processori non potremmo più chiarmarli RISC, visto che ne contengono uno all'interno che fa il "vero" lavoro. :p

Questo se non vogliamo guardare la "carrozzeria", ma soltanto il motore. ;)

E' un punto di vista troppo limitato: IMHO bisogna considerare sempre la "macchina" nel suo insieme, visto che è fatta sia di carrozzeria sia di motore...

Se leggi l'articolo di cui ho fornito il link prima, non si può parlare nemmeno di RISC, visto che anche questi hanno "perso" le loro caratteristiche per cui sono nati.

Alla fine oggi non abbiamo dei RISC o dei CISC, ma un "misto" di entrambi.

D'altra parte se pensi a Power4/5 e G5, non è forse paradossale che si serva di un RISC ancora più semplice all'interno per eseguire le istruzioni PowerPC (che scompone nelle microistruzioni di questo "reduced" :D RISC)? Da questo punto di vista questi processori non potremmo più chiarmarli RISC, visto che ne contengono uno all'interno che fa il "vero" lavoro. :p

Questo se non vogliamo guardare la "carrozzeria", ma soltanto il motore. ;)

E' un punto di vista troppo limitato: IMHO bisogna considerare sempre la "macchina" nel suo insieme, visto che è fatta sia di carrozzeria sia di motore...


ricordiamoci però che la discussione nasce dalla solita contrapposizione tra CISC e RISC e al tentativo di attribuire la denominazione CISC ai processori attuali.
Ecco perchè stiamo poistando..come correttamente sottolineato dall'articolo si tratta di soluzioni che invece si sono susseguite nel tempo automigliorandosi e autosoppiantandosi...non scordiamo questa successione temporale a cui assistiamo ancora oggi.

Essendo un architettura CISC più lontana nel tempo ed obsoleta è ovvio che sia anche la più lontana dalle macchine attuali.

Infatti non la dimentico e l'ho ben presente. Sia chiaro però che, per una questione di coerenza, se non ha senso parlare di CISC, non ha più nemmeno senso parlare di RISC. Parliamo di processori che risolvono il problema della computazione in modo diverso... ;)

Personalmente rimango dell'idea che gli x86 sono dei CISC, come i PowerPC dei RISC, ecc. perché come programmatore l'ISA che viene esposto e che utilizzo abbraccia buona parte delle filosofie che hanno dato origine ai due termini.
Che dentro ci sia un RISC "ridotto all'osso", un'unità ad esecuzione diretta o una che fa uso di microcodice, francamente non me ne può fregare di meno: se posso usare una MOV EAX,[EBX + ECX * 4 + 1234567890] per me si tratta di un CISC... :p

Infatti non la dimentico e l'ho ben presente. Sia chiaro però che, per una questione di coerenza, se non ha senso parlare di CISC, non ha più nemmeno senso parlare di RISC. Parliamo di processori che risolvono il problema della computazione in modo diverso... ;)

Personalmente rimango dell'idea che gli x86 sono dei CISC, come i PowerPC dei RISC, ecc. perché come programmatore l'ISA che viene esposto e che utilizzo abbraccia buona parte delle filosofie che hanno dato origine ai due termini.
Che dentro ci sia un RISC "ridotto all'osso", un'unità ad esecuzione diretta o una che fa uso di microcodice, francamente non me ne può fregare di meno: se posso usare una MOV EAX,[EBX + ECX * 4 + 1234567890] per me si tratta di un CISC... :p

eh..ma è una visione dall'alto.
Seppur personalmente possa essere valida è corretta oggettivamente?
Seconod me no..poichè se per assurdo lo fosse allora non sarebbe corretta la definizione stessa di macchina RISC poichè esisterebbe sempre e cmq un livello vicino all'utente in cui non si riesce a distinguere le due architetture.

Secondo me è corretta perché un processore non viene realizzato per puro spirito accademico / di ricerca, ma per FAR GIRARE CODICE.

A chi interessa se internamente utilizza un'unità RISC-like? Soltanto agli "accademici".

A chi scrive software di sistema, applicativo, e in particolare compilatori, e si pone il problema della realizzazione del codice e di come farlo girare, questi dettagli non contano assolutamente. Quel che conta è l'ISA della macchina, il fatto che sia a lunghezza variabile o fissa, il fatto che esista l'istruzione XYZ che utilizza la modalità d'indirizzamento ABC.
Poco importa se passando da un'implementazione (della stessa ISA) a un'altra l'istruzione XYZ verrà "spezzettata" in una, due, tre o più microsistruzioni RISC-like.
E' stato fatto per migliorare la velocità di esecuzione del codice? Ottimo. Questa soluzione è la benvenuta.
Ma cos'è cambiato dal punto di vista del codice? Nulla. Le istruzioni che vengono "macinate" sono SEMPRE LE STESSE.

Da questo punto di vista, e credo che sia ben più importante dell'implementazione, ci sarà sempre una distinzione netta fra i tipi di architettura. IMHO, chiaramente.