di  -  mercoledì 15 luglio 2009

Con Alessio Di Domizio condividiamo la passione per i microprocessori, e non poche volte abbiamo affrontato il tema sia qui sia su Messenger, dove abbiamo speso fiumi di parole in chattate sui più svariati argomenti a esso attinenti.

Se parliamo molto è anche perché a volte non c’è piena sintonia, ma questo non è certamente un difetto, quanto un pregio, perché la diversa esperienza vissuta e i diversi punti di vista offrono ai lettori di AD una panoramica a più ampio raggio e una maggior ricchezza di informazioni, fortificando il proprio bagaglio culturale.

Su un punto, però, abbiamo trovato assoluto e pieno accordo fino dall’inizio: l’eccessivo consumo di potenza dei microprocessori della famiglia x86 rispetto ai ben più parchi ARM, tenendo ovviamente conto delle prestazioni…

Sull’argomento è intervenuto qualche giorno fa il CEO di VMWare (nota azienda che opera nel campo della virtualizzazione) a ribadire il concetto in maniera abbastanza dura, secondo il quale l’architettura x86 si porterebbe dietro anni di pezze (termine mio; lui parla molto più gentilmente di complessità) che fagocitano potenza (consumata).

Fin qui non afferma nulla che gli addetti ai lavori non sapessero già, ma tira anche in ballo l’architettura StrongARM (poi evolutasi in XScale) realizzata da Intel per entrare nel mercato dei dispositivi a bassa potenza, ma anche, a suo dire, poco profittevoli, che ha poi dismesso.

Infatti la divisione ARM fu poi venduta a Marvell qualche anno fa, ufficialmente per dedicare le risorse al suo core business (ovviamente gli x86) e alle tecnologie wireless.

Tutto bene, salvo poi tornare nuovamente in questo settore, presentando la sua piattaforma Atom e andando a ripescare il design del… buon vecchio Pentium (ma con l’ISA aggiornata, hyperthreading e altre migliorie), che è un processore in-order, anche se superscalare (dotato di due pipeline di esecuzione, quindi due istruzioni eseguibili entrambe in assenza di dipendenze, o ancora in thread diversi nel caso di Atom).

Questo perché, che Intel lo voglia ammettere o no, i dispositivi embedded, gli smartphone e i netbook sono tutt’altro che “poco profittevoli”, visto il giro d’affari enorme che ruota attorno a essi. Rispetto a soluzioni server sicuramente i guadagni sono di gran lunga inferiori, ma in questo campo è il gran numero di pezzi venduti a fare da “moltiplicatore” generando utili consistenti.

Insomma, un modello di business completamente diverso, ma molto interessante per una società che rimane pur sempre votata al lucro. E Intel con la sua forza non avrebbe certo avuto problemi a entrarvi prepotentemente, se non fosse che questi dispositivi non richiedono soltanto componentistica più economica, ma spesso anche un’autonomia molto più elevata e, di conseguenza, la necessità di consumi decisamente ridotti, vera piaga di x86 e dintorni.

Torniamo pertanto al nocciolo del problema citato dal CEO di VMWare, le cui radici affondano lontane nel tempo, risalendo fino al progenitore della famiglia, l’8086. Questa CPU fa parte della grande famiglia dei CISC, per cui è dotata di un set d’istruzioni a lunghezza variabile che le consente di “compattare” l’informazione maggiormente utilizzata, risparmiando quindi sulla dimensione del codice.

Al contrario i RISC sono dotati di un’ISA a lunghezza fissa, che racchiude istruzioni abbastanza semplici in un preciso spazio, e pertanto risulta una sorta di compromesso fra quelle maggiormente utilizzate e quelle più rare, richiedendo, quindi, uno spazio maggiore rispetto ai CISC.

Due filosofie completamente diverse, insomma, e ognuna rispettabilissima negli intenti e nel pensiero di chi le ha sviluppate, ma che pone i RISC in posizione di netto vantaggio per quanto riguarda la decodifica delle istruzioni, che risulta molto più facile e impiega una logica anch’essa ridotta. Meno logica di decodifica significa meno transistor, minor consumo di corrente, e meno calore generato.

Viceversa, i CISC richiedono una logica di decodifica tanto più complessa quanto più contorta risulta l’ISA del microprocessore, e l’8086 (ma soprattutto i derivati) penso sia secondo soltanto a un’altra creatura di Intel, lo iAPX 432 di ho parlato di recente proprio in questa rubrica.

A prescindere dall’ideologia che vi sta dietro, è pacifico che un processore possa eseguire i compiti richiesti dall’istruzione soltanto se è in grado di “conoscerla” per intero, cioé se è in possesso di tutte le informazioni necessarie per poterla “servire”. Sembra una cosa lapalissiana, ma tanto ovvia non è, perché per arrivarci può esserci molto lavoro dietro, ed è qui che si cominciano a marcare le differenze fra RISC e CISC.

In particolare, come si può vedere dal datasheet dell’ARM alla pagina A3-2 (68), lo schema della codifica delle istruzioni è estremamente semplice e abbastanza lineare. La dimensione utilizzata per gli opcode è sempre di 32 bit, per cui eseguitone il fetch il processore ha già tutto ciò che gli serve: sa cosa deve fare, quali registri sono coinvolti, se deve leggere o scrivere dalla memoria, se deve saltare, ecc..

E’ uno schema che si ritrova in maniera similare in tantissimi altri RISC, ed è talmente semplice che spesso nella fase di decodifica viene già eseguito anche l’accesso ai registri (vedi “Modern processor design” di Shen & Lipasti), risparmiando uno stadio della pipeline (quello che generalmente viene indicato come register access) proprio perché c’è talmente poco da “decodificare” che si può già pensare di “andare avanti” col lavoro.

Lo schema degli x86 è invece talmente complesso che non basta di certo una paginetta per descrivere tutti i casi e le famiglie di istruzioni, complice anche una codifica pseudo-causale delle stesse (in pratica gli opcode sono stati inseriti sostanzialmente “dove c’era spazio”; non trovo altra spiegazione logica alla cosa).

Da quello generale qui sopra riportato risulta già evidente che il processore è costretto a “sbirciare” in diversi “posti” per poter risalire sia alla lunghezza completa dell’istruzione che a tutte le informazioni che si trascina dietro. La parte più complicata rimane, comunque, quella iniziale, cioé dei prefissi delle istruzioni.

I prefissi sono dei particolari opcode che occupano esattamente un byte e che vengono utilizzati per alterare il normale funzionamento dell’istruzione vera e propria. Attualmente ne esistono di cinque tipi (un sesto, chiamato REX, è stato aggiunto da AMD con gli x86-64 e, se usato, deve necessariamente seguire gli altri prefissi, denominati spesso legacy):

Ogni istruzione x86 può specificare fino a quattro prefissi (quello di LOCK e quelli di ripetizione sono mutuamente esclusivi: non possono essere usati entrambi nella stessa istruzione) in totale (cinque per x86-64, come già detto) e in qualunque ordine.

Ma se ai tempi dell’8086 ciò era facilmente implementabile e a un costo irrisorio (le istruzioni richiedevano anche diverse decine di cicli di clock; inoltre i prefissi “abilitavano” precise caratteristiche), oggi che le prestazioni si “misurano” col numero di istruzioni eseguite per singolo ciclo di clock questo schema risulta non soltanto obsoleto, ma particolarmente castrante, richiedendo non poche risorse già soltanto per la decodifica delle istruzioni.

Giusto per rendere l’idea, Jon Stokes nel suo “Inside the machine” parla di una stima pari a circa il 30% dei transistor per la sola logica di decodifica delle istruzioni del primo Pentium (P5), e di ben il 40% per il suo successore, il PentiumPro (P6). Numeri che sono a dir poco impressionanti, in quanto buona parte del chip sono dedicati esclusivamente per questa funzionalità.

Tra l’altro si tratta di una circuiteria che non si può certo “spegnere”, come si fa nei microprocessori più moderni (cache L2, ALU, FPU, unità SIMD, ecc.), perché se si devono eseguire le istruzioni (!), queste devono per forza di cosa essere decodificate. Per cui quest’area risulta costantemente stressata, affamata di corrente e, di conseguenza, particolarmente “calda”.

E’ facile comprendere a questo punto perché gli ARM, come tanti altri RISC, siano in netto vantaggio rispetto agli x86 dal punto di vista dei costi e, soprattutto, dei consumi: essendo del tutto trascurabile la logica di decodifica, viene a mancare un elemento che incide pesantemente nel bilancio.

Per correttezza preciso che ciò è tanto più vero quanto più piccolo è il chip, cioé rispetto al numero di transistor utilizzati per realizzarlo. Questo perché, una volta raggiunto lo “stato dell’arte” per quanto riguarda la circuiteria di decodifica, non si assiste più a un aumento lineare dei transistor utilizzati allo scopo, ma, sembra incredibile, avviene una diminuzione in percentuale.

Ciò è facilmente spiegabile dal fatto che col passare del tempo il maggior numero di transistor viene impiegato per migliorare e/o aumentare le unità di calcolo e la dimensione e/o efficienza delle cache, mentre l’area di decodifica viene leggermente aggiornata per supportare eventuali nuove istruzioni aggiunte all’ISA.

Quindi si tratta di una zona del chip che tenderà a occupare sempre meno spazio e risorse, se consideriamo che il Pentium era costituito da circa 3 milioni di transistor, e il PentiumPro da 5,5, mentre da poco abbiamo superato la soglia del miliardo di transistor che, però, sono utilizzati nella stragrande maggioranza per le cache (in particolare le abbondanti L3).

Con Atom, invece, Intel ha dovuto effettuare una sorta di marcia indietro, presentando un chip realizzato con 47 “miseri” milioni di transistor, perché l’obiettivo era quello di offrire una soluzione a basso costo e, soprattutto, con bassi consumi; condizioni entrambe necessarie per attaccare il nascente segmento dei netbook, ma anche quello degli smartphone e in generale dei dispositivi embedded e SOC.

E’ chiaro che, con questi numeri in gioco, una sezione di decodifica delle istruzioni che si porta via un po’ di milioni di transistor diventa tutt’altro che trascurabile nel bilancio economico, ma soprattutto energetico (come dicevo prima, è un’area che non si può certo “spegnere”).

Per confronto e andando a guardare in casa ARM, vediamo che il solo core dell’ARM7TDMI (quindi senza considerare cache, DSP, unità SIMD, ecc.) è accreditato per 36mila (sì, non milioni, ma migliaia) transistor, e che le tipiche implementazioni che troviamo in giro stanno sull’ordine delle centinaia di migliaia di transistor (100mila per il modello utilizzato nel Nintendo DS, e soltanto 50mila per il Cortex M0, modello economico e specificamente orientato al bassissimo consumo).

Ovviamente le soluzioni più performanti che da qualche tempo hanno cominciato a fare capolino integrano cache di dimensioni elevate, MMU, DSP e/o unità SIMD, e altro, ma non arriviamo sicuramente ai livelli dell’Atom di Intel, che si porta dietro tutti i difetti dell’ISA x86.

Insomma, quella dei consumi è certamente una battaglia persa in partenza per Intel, a parità di tecnologie costruttive e di prestazioni, con l’unico vantaggio “di spessore” rappresentato dal fatto che, nel bene e nel male, x86 rimane comunque la più diffusa e utilizzata architettura da chi sviluppa il software.

Perché, quindi, Intel ha buttato via le soluzioni ARM (StrongARM e XScale) che aveva realizzato proprio per il segmento dei dispositivi a basso consumo? Il CEO di VMWare, come già riportato, sostiene che si è trattato di errore strategico e che Atom nasce sostanzialmente per “porvi rimedio”.

Io ho un’opinione completamente diversa. Intel ha ceduto a Marvell la divisione ARM nel giugno 2006, mentre ha presentato Atom a marzo del 2008. Troppo poco il tempo per “accorgersi dell’errore” e avere quello sufficiente per “porvi rimedio”, studiando una soluzione ad hoc.

Evidentemente Atom era un progetto già in lavorazione, che presentava delle ottime prospettive sul piano dei costi e in particolare su quello dei consumi, e Intel ha pensato bene di sbarazzarsi di una divisione che sarebbe entrata in concorrenza col suo nuovo gioiello, che tra l’altro portava in dote l’architettura che le ha regalato il successo.

Non so a voi, ma a me i conti tornano. Perché non si sviluppa un’architettura come quella di Atom nel giro di pochissimi mesi, per quante similitudini possa avere col vecchio Pentium e per quanta tecnologia sia stata “prelevata” dai modelli più recenti.

Difficile però prevedere quale soluzione dominerà il segmento su cui si va a inserire Atom. Se dovessi guardare ai soli consumi, come ho già detto, Intel non avrebbe scampo: è impensabile che possa rivaleggiare con ARM.

Ma Atom ha dalla sua l’ISA x86, con tutta la montagna di software che gira già senza bisogno di andare a scomodare compilatori e, soprattutto, software house. In particolare ciò vale per colossi come Microsoft, ben poco incline a tirare fuori un’altra versione di Windows (e questo Intel l’ha già potuto sperimentare sulla sua pelle col “progetto” Yamhill).

51 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    megawati
     scrive: 

    E con questo, tanti cari saluti a chi considera gli x86 come “i migliori processori del mondo”… sono soltanto i più economici. E soltantoi per le economie di scala dettate dall’enorme produzione di chip, chipset e motherboard.

    Il futuro, amici miei, è RISC. Rassegnatevi…

  • # 2
    Cesare Di Mauro
     scrive: 

    Cerchiamo di non estendere a qualunque contesto i dati e le opinioni dell’articolo, che hanno un loro ben preciso dominio applicativo. ;)

  • # 3
    Caterpillar
     scrive: 

    Secondo me APPLE è passata agli X86 per permettere anche l’installazione di XP ed entrare nel core business delle persone cui serve anche il suddetto sistema operativo (senza che venga semplicemente emulato).
    E soprattutto anche per facilitare agli utonti la comprensione delle caratteristiche del computer quando vanno a comprarlo da mediaworld.
    Si poi ci sono anche molte altre motivazioni, però penso che queste 2 siano le principali.

    Spero in un prossimo futuro che gli X86 vadano in pensione

  • # 4
    The3D
     scrive: 

    Non è che il futuro è risc, il futuro dovrebbe essere di una qualsiasi architettura che presenti un’ISA decente. Purtroppo l’x86 è tutto tranne che decente, e inoltre continuano ad aggiungere set di istruzioni su set di sitruzioni, per peggiorare ancora la situazione.

    cmq un plauso per lo screenshot di sf ;)

  • # 5
    Marco
     scrive: 

    Concordo su tutto, anche se ormai denominare RISC o CISC una CPU ha molto meno senso di 20 anni fa.
    Un ARM attuale diciamo che obbligatoriamente deve avere almeno le estensioni SIMD (neon) e Jazelle, e di solito viene implementato anche il set Thumb (come hai detto, con particolari memory constraints e/o motivi prestazionali il codice a 32 bit non e’ il piu’ adatto, occupa troppo spazio e soprattutto rende la cache L1 meno efficiente).
    Un’altra estensione gradita e’ l’unita’ “crypto engine” (non ricordo come la chiamano, cmq l’analoga del VIA Padlock) e l’unita’ FP (che ha un suo set di istruzioni aggiuntivo).
    Che dire, siamo molto distanti da quello che era ARM2 (che cmq contava sempre 30K transistor e dava la paga a MC68K e 286, gia’ allora molto piu’ complessi) negli anni ’80.
    Tutto questo, come giustamente concludi, fortunatamente non ha ridotto di tanto la power efficiency, ed e’ ancora molto piu’ avanti di x86.
    Ultima nota: l’ISA piu’ complessa in assoluto (fra quelle che conosco) e’ quella del DEC VAX (microprogrammato fra l’altro), oggetto di scherno gia’ all’epoca, che puo’ vantare opcodes lunghi fino a 56 bytes XD

  • # 6
    Cael
     scrive: 

    Ottimo articolo come sempre. Mi viene però una domanda. In questo scenario i processori della famiglia Power di IBM come si collocano in termini di consumo/performance/complessità?

  • # 7
    D
     scrive: 

    Si può dire tutto quello che si vuole ma senza un os degno di questo nome, con windows ben piazzato su x86 e linux che vive sempre alla giornata, arm non può che continuare ad esistere in settori quali telefonini e videogiochi.
    Mi chiedo però una cosa: perchè i nuovi amiga continuano a farli con schede ppc che oramai non vengono più sviluppate seriamente ? Non sarebbe meglio se rinascesse seriamente su arm ?

  • # 8
    avve
     scrive: 

    I consumi della cpu non sono tutto.
    IL ragionamento dell’articolista quindi imho è correttissimo.
    La valutazione di INTEL imho è stata la seguente:
    due netbook, uno con atom e uno con arm che consuma 10 volte meno.
    Ma lo stesso chipset.
    Lo stesso schermo, lo stesso hardware, la stessa dotazione i/o.
    Alla fine la riduzione di consumo c’è, ma di qualche punto percentuale, sul complesso complessivo.

    Ok, voi come clienti, comprereste l’arm che non fa girare altro che linux o altri so ad-hoc e applicazioni relative barra ricompilabili barra cross-platform;
    oppure comprereste un x86 anche se la batteria vi dura 10 minuti meno?

    se poi smettiamo di parlare di netbook e iniziamo a parlare di smartphone e simili, allora è un altro film, ma infatti ancora smartphone x86 non è che se ne siano visti.

  • # 9
    megawati
     scrive: 

    Se davvero il punto debole degli x86 è il set di istruzioni, perché la Intel non crea un set di istruzioni che sia RISC, più semplice da decodificare, ma abbastanza simile a quello vecchio da poter essere “tradotto al volo”? Chiamiamola architettura R-86: i programmi nativi sono nativi e amen, per i vecchi programmi ci sarebbe una cosa tipo compiler just-in-time Java: verrebbero compilati al volo da x86 a R-86 e poi eseguiti. Dovrebbe essere fattibile facilmente, SE tutto il resto dell’architettura è identico (registri, privilegi, flag, tabelle descrittori globali, locali e dei task ecc. ecc.) e cambi solo il set di istruzioni.

  • # 10
    WP
     scrive: 

    Come giustamente fà notare l’autore, all’aumentare del numero dei transistor integrati in uni chip, la percentuale di questi dedicata alla decodifica diminuisce, indipendemente dalla complessità dell’ISA. Penso che anche sui 47 milioni di transistor di ATOM, il numero di transistor dedicati alla decodifica non incida più di tanto. Sarebbe interessante se ci fossero dei numeri al riguardo, altrimenti rimangono solo speculazioni. Ad ogni modo il numero di transistor integrati nei chip continuerà ad aumentare sia nei desktop, sia nei netbook, sia nei telefonini, rendendo ma mano questa percentuale sempre più piccola in tutti i settori.

    Per quanto riguarda il confronto di ARM sarei curioso di sapere se esistono benchmark che ne confrontino le prestazioni e i rapporti prestazioni/consumi rispetto ad ATOM. Per come la vedo io ATOM è una CPU nata per i netbook e cerca un buon compromesso tra prestazioni e consumi. Se Intel avesse voluto fare una CPU x86 che consumasse di meno avrebbe sicuramente potuto farlo, ma a discapito delle prestazioni.

    Inoltre, come ha fatto notare da un utente prima di me, dimezzare il consumo di ATOM inciderebbe poco sui consumi totali del netbook.

  • # 11
    Cesare Di Mauro
     scrive: 

    @Caterpillar: Apple è passata agli x86 perché questi avevano ormai un miglior rapporto prestazioni / consumi & costi.

    @The3D: aduuuuukeeeen! Oops, scusa. :D Purtroppo non vedo all’orizzonte architetture in grado di poter scalzare x86 dal mercato desktop.

    @Marco: non oso immaginare che tipo di istruzioni potessero essere codificate in 56 byte. Già i 22 byte dei 68020+ mi sembravano troppi. :D Spero di trovare un datasheet del VAX per colmare la lacuna.

    @Cael: i POWER e i PowerPC sono abbastanza complessi come RISC. In particolare POWER e G5 di IBM hanno un’architettura che somiglia molto ai Pentium 4 di Intel, con pipeline molto lunghe per cercare di scalare in frequenza, ma hanno poi avuto gli stessi problemi della CPU di Intel, quindi con consumi troppo elevati.

    @D: penso che la sorte dell’Amiga sia contrassegnata dalla troppa sfiga, causa management inadeguato. Sono ancora convinti di volersi differenziare, quando persino Apple ha abbandonato l’architettura PowerPC che lei stessa ha contribuito a creare.

    Irrecuperabili.

    @avve: attualmente per questo tipo di mercato il componente che consuma di più sembra essere il chipset.

    @megawati: c’ha provato già Transmeta proponendo RISC (VLIW, per la precisione) che compilavano al volo codice x86, e a livello prestazionale è stata un’esperienza fallimentare.

    Comunque un RISC all’interno delle CPU x86 c’è da parecchi anni ormai, ed è stato introdotto da AMD col K5 e da Intel col PentiumPro. Viene chiamato RISC86 (per lo meno da AMD, se non ricordo male), e le istruzioni x86 vengono convertite in una o più istruzione RISC86 per poi essere eseguite.

    Mi dirai: perché non programmare direttamente con questa ISA, come chiedevi tu (se non ho capito male)? Semplice: perché le prestazioni sarebbero scandalosamente scarse. Sembra stranissimo, vero? Di questo ne parlerò più approfonditamente in uno dei prossimi articoli. ;)

    @WP: considera che per il PentiumPro il 40% di transistor dedicati alla sola decodifica delle istruzioni x86 equivale a circa 2,2 milioni di transistor, e non è che questa sezione del chip rappresenti lo stato dell’arte; tutt’altro. Personalmente sono dell’idea che almeno 4-5 milioni siano una cifra abbastanza realistica (forse anche sottostimata) per una CPU x86 moderna.

    Su Atom credo che incida in maniera considerevole per quanto detto nell’articolo: è uno dei componenti che rimane sempre attivo, molto stressato, e che non si può “spegnere”. Tra l’altro Atom implementa anche l’Hyperthreading, per cui dev’essere possibile decodificare istruzioni di entrambi i thread attivi e, quindi, l’area di decodifica potrebbe benissimo essere stata duplicata allo scopo (aumentando ancora di più il peso di questa parte del processore).

    Pertanto rimango della mia idea: la logica di decodifica va a pesare in maniera pesante sui consumi di questa “nuova” architettura.

    Per quanto riguarda le prestazioni, se ne parla un po’ qui: http://www.appuntidigitali.it/2969/il-futuro-del-mercato-netbook/

  • # 12
    WP
     scrive: 

    Se non sbaglio il SMT non ha bisogno di decodificare le istruzioni dei due thread contemporaneamente. Viene decodificato il flusso di istruzioni di un thread soltanto e si passa all’altro solo quando ci sono stalli di lunghi durata, come un cache miss.

    Dei benchmark comparitivi non ci sono? Mi sembra di aver letto che le versioni di notebook per ATOM consumino circa 2W. Sarebbe interessante vedere quanto consuma un processore ARM dalle prestazioni simili. Sicuramente i processori ARM per cellulari consumeranno meno, ma hanno anche prestazioni nettamente inferiori. Inoltre non penso che quello dei cellulari o dispositivi ultraportatili sia il mercato che interessa, per il momento, a Intel.

  • # 13
    Cesare Di Mauro
     scrive: 

    Con Atom è diverso: può eseguire o due istruzioni di un thread, oppure una per ognuno dei due thread. Quindi per sfruttare al meglio la possibilità di eseguire due istruzioni per ciclo di clock, deve aver già decodificato le istruzioni di entrambi i thread.

    Questo si risolve in due modi: duplicando la logica di decodifica (come avevo detto), oppure sfruttandola alternativamente decodificando le istruzioni prima di un thread e poi (nel ciclo successivo) dell’altro. Ovviamente in quest’ultimo caso le prestazioni saranno peggiori eseguendo codice non all’interno di loop.

    Per quanto riguarda le prestazioni, se leggi l’articolo e in particolare i commenti troverai qualche informazione.

    Sui consumi non ricordo onestamente le differenze fra le macchine testate.

  • # 14
    andrea
     scrive: 

    AmigaOS su ARM…

  • # 15
    pleg
     scrive: 

    @megawati
    Un’ISA non e’ solo un insieme di istruzioni: descrive anche ad esempio il numero di registri, il modello di memoria, eccetera.
    Se Intel creasse una nuova ISA… sarebbe nella stessa situazione di ARM: bisogna ricompilare tutti i programmi per farceli girare (anzi, sarebbe peggio, perche’ dovrebbe anche scrivere tutti i compilatori per farlo, mentre i compilatori per ARM ci sono gia’).

    L’importanza della compatibilita’ binaria e’ enorme, e spesso sottovalutata. Semplicemente, ormai x86 e’ usato in cosi’ tanti programmi e cosi’ tanti ambiti che non e’ possibile cambiare le cose. Nei desktop, x86 restera’ per mooolto tempo ancora.
    Per il mondo netbook eccetera, la battaglia e’ appena cominciata :)

  • # 16
    pleg
     scrive: 

    @ Cesare di Mauro
    Approposito di RISC86 (se e’ il nome giusto, non lo so, ma ci si intende).
    Il punto cruciale secondo me’… che non e’ un’ISA! Cioe’, non e’ un “contratto” tra l’hardware e il software: Intel potrebbe cambiare, se volesse, le sue istruzioni RISC interne quando e come le pare, da chip a chip, se le servisse per ottimizzare le prestazioni o i consumi. E questo e’ assolutamente lecito, proprio perche’ non e’ esposta all’esterno (nno e’ rpogrammabile direttamente), quindi non c’e’ nessun problema di compatibilita’ software.
    Intel garantisce x86; poi, come lei lo macina all’interno (o come AMD lo macina, che saranno modi diversi) riguarda solo il fabbricante di chip.

  • # 17
    megawati
     scrive: 

    @Cesare Di Mauro: non ci siamo capiti.
    So tutto sul RISC interno agli x86: nel nostro caso non serve a niente, la decodifica delle istruzioni va fatta comunque e la traduzione in RISC86 (sì, ti ricordi bene) peggiora tutto perché è un passo in più da fare. Necessario, se uno vuole “dar da mangiare” a più unità di esecuzione contemporanee, ma comunque aggiunge peso a un compito già pesante di suo. Transmeta lavorava all’interno del processore, con lotti di N istruzioni (poche): io penso invece a un compilatore che compili in fase di caricamento del programma o della DLL in RAM da un codice assembler x86 a un secondo assembler analogo ma RISC (apposta facevo l’esempio del compilatore just-in-time di java). Il processore di suo NON avrebbe più risc86 nè unità di esecuzione risc “nascoste” ma sarebbe un vero risc che esegue il codice analogo-ma-risc (che NON sarebbe risc86)…

    Stando così le cose sarebbe pure pensabile, e secondo me auspicabile, di scrivere un compilatore standalone che prenda un .EXE o una DLL di un qualsiasi programma, ne traduca il codice e ne salvi una versione in codice analogo-ma-risc. Non ci sarebbe bisogno di ricompilare i sorgenti in C o in VB o in quello che è: tutto quello che ci sarebbe da fare sarebbe tradurre il codice oggetto, perché tutto il resto dell’architettura sarebbe identico.

  • # 18
    Cesare Di Mauro
     scrive: 

    @pleg: esattamente, e infatti ha cambiato più volte l’implementazione di RISC86 (come ha fatto anche AMD) proprio perché può farci quel che vuole essendo “interna” alla CPU e del tutto trasparente (nonché inaccessibile) al codice x86, che è l’unico vero riferimento per i programmatori.

    Tra l’altro sarebbe assolutamente controproducente esporre l’ISA di RISC86 sia per il fatto che ci si legherebbe mani e piedi (effettuare modifiche anche radicali non sarebbe più possibile a causa della retrocompatibilità da mantenere), ma soprattutto perché le prestazioni risulterebbero disastrose.

    @andrea: avrei visto bene AmigaOS su x86 per i desktop, e su ARM per set-top-box, smartphone, PDA, cellulari e in generale per i dispositivi embedded e/o a basso costo / consumo.

    Trovo che questo s.o. sia assolutamente perfetto per queste esigenze.

    Per i desktop andrebbe aggiornato aggiungendo quanto meno la protezione della memoria e il resource tracking.
    Della memoria virtuale penso si possa fare tranquillamente a meno grazie al consumo estremamente ridotto di memoria e alla gran quantità di questa risorsa ormai disponibile da un bel po’ di anni a questa parte.

  • # 19
    pleg
     scrive: 

    @megawati
    Se ho capito cosa intendi, potresti fare la stessa cosa con ARM, giusto? Cioe’, avere degli eseguibili x86 che “girano” su ARM grazie ad una ricompilazione al momento.
    Qualcuno sa se e’ mai stato fatto? L’unica cosa di simile che mi viene in mente sono le tecniche di Dynamic Binary Traslation , ma devi tenere conto:
    1. del tempo che ci vuole a fare la traduzione
    2. dell’energia che ci vuole a fare la traduzione
    3. del fatto che il codice si espandera’, occupando piu’ risorse (main memory, cache, TLB…)

    In totale, sarebbe piu’ efficiente? Penso di no… se no qualcuno l’avrebbe gia’ fatto :)
    (o magari qualcuno l’ha fatto, e non l’ho mai sentito, possibilissimo :)

  • # 20
    Cesare Di Mauro
     scrive: 

    @megawat: in questo caso sarebbe sufficiente scegliere una qualunque architettura RISC già esistente (inutile inventarne nuovamente un altro).

    Il problema è che quanto meno il s.o. dovrebbe essere adattato per poter caricare EXE e DLL ed effettuare la conversione al volo del codice da x86 a questo RISC “target”.
    Insomma, lavoro per Microsoft principalmente.

    La compilazione integrale di EXE e DLL da codice x86 a RISC realizzata generando il nuovo codice oggetto nativo per quest’ultimo è, invece, impossibile a causa della notevole complessità che può avere il codice e che un analizzatore statico di questo tipo non potrebbe tradurre tutto in una sola volta.

    Comunque una soluzione a questo problema esiste già, e si chiama .NET.
    Gli assembly generati sono compilabili per qualunque architettura per la quale sia stato sviluppato il runtime. Ciò avviene o al volo (tramite JIT) oppure una sola volta traducendo l’intero codice intermedio in quello nativo.

    Quest’ultima soluzione è possibile perché gli assembly si portano dietro tutte le informazioni necessarie per poterlo compilare integralmente. Al contrario dei normali EXE e DLL.

  • # 21
    pleg
     scrive: 

    @ Cesare di Mauro

    Ma la memoria virtuale ti da’ un meccanismo di protezione importantissimo!
    Coi dispositivi sempre connessi a internet, con la valangata di virus che girano e ci si becca, senza nemmeno quella protezione sarebbe la fine!

  • # 22
    Cesare Di Mauro
     scrive: 

    Penso che la protezione della memoria sia sufficiente allo scopo.

    Gestire più memoria di quella fisicamente disponibile, invece, non credo che comporti un qualche miglioramento sul fronte della sicurezza.

    EDIT: per quanto riguarda la traslazione da un’ISA a un’altra, c’è il progetto QEMU che è molto interessante. http://www.qemu.org/about.html

  • # 23
    D
     scrive: 

    “@D: penso che la sorte dell’Amiga sia contrassegnata dalla troppa sfiga, causa management inadeguato. Sono ancora convinti di volersi differenziare, quando persino Apple ha abbandonato l’architettura PowerPC che lei stessa ha contribuito a creare.

    Irrecuperabili.”

    Beh per differenziarsi ci riescono benissimo, solo che proponendo una scheda che si vanta di reggere 800Mhz di picco non so quanti software professionali potranno mai sperare di vedere in futuro.
    Sinceramente però non capisco perchè non tentare qualcosa tipo un iphone pompato quindi cpu arm e gpu power vr sgx

    “AmigaOS su ARM…”

    Sarebbe il miglior os che ARM potrebbe permettersi in questo momento visto che Symbian non è un prodotto per computer (al massimo palmari) e Linux francamente è una barzelletta (la piattaforma meglio supportata è ancora una volta x86-32 neanche 64 bit, mentre la stragrande maggioranza dei port su altre cpu sono più esperimenti che progetti seri)

  • # 24
    pleg
     scrive: 

    @ Cesare di Mauro

    Cosa intendi per protezione della memoria? Mi riferivo alla memoria virtuale per l’isolamento dei processi — cio’ che un processo non vede, non puo’ toccare.

  • # 25
    Cesare Di Mauro
     scrive: 

    Per protezione della memoria intendevo esattamente questo. ;)

    @D: anch’io penso che Amiga & AmigaOS meriterebbero molto di più, ma purtroppo continuano a fare scelte sbagliate. Non credo più in un futuro, nemmeno di nicchia, per queste glorie del passato.

  • # 26
    andamsu
     scrive: 

    Ciao,
    il brand “Risc86″ lo ha inventato la NextGen per la sua prima cpu Nx586, con ISA compattibile con l’ i386 (anche se superscalare e con alcune istruzioni ì486 emulate da bios) e privo di FPU integrata, ma comunque in grado di rivaleggiare sugli Integer con i Pentium di pari frequenza, seguito poi dall’ Nx586PF (soluzione di tipo MCM con due die CPU + FPU). In seguito prima dell’ introduzione del Nx686 venne aquista da AMD che trasformo quest’ultimo nel K6 (da qui l’associazione del brand Risc86 ad AMD)

  • # 27
    Cesare Di Mauro
     scrive: 

    Grazie per la precisazione. :)

  • # 28
    pabloski
     scrive: 

    suvvia, chiunque abbia un minimo di dimestichezza con le architetture dei processori sa che gli x86 fanno pena e nessuno di questi soggetti si è ma permesso di dire che sono i migliori al mondo

    però il mercato fa le leggi purtroppo e la stessa intel con itanium ha preso solo mazzate

    realisticamente gli x86 ormai non li rimuovi dalla scena, c’è poco da fare ed apple non ha fatto altro che seguire il trend, anche perchè tra freescale e ibm non si trova uno straccio di roadmap decente

    imho l’unico modo per ridimensionare gli x86 sarà migrare il software verso framework basati su bytecode….forse a quel punto si riuscirà a proporre qualcosa di alternativo

  • # 29
    Marco
     scrive: 

    @D
    ““AmigaOS su ARM…”
    Sarebbe il miglior os che ARM potrebbe permettersi in questo momento”

    Con sommo dispiacere da vecchio amighista devo dire che non concordo. Stiamo parlando di un SO di oltre 20 anni fa e praticamente non piu’ aggiornato (almeno a livello di architettura), con limiti pesantissimi e difficilmente accettabili anche a livello embedded.
    BTW credo che sia previsto un porting di MorphOS su ARM, dato che Genesi per la prossima efika (che dovrebbe anche avere una incarnazione tipo “smartbook”) cambiera’ architettura.

    “Linux francamente è una barzelletta”
    Il supporto per ARM e’ maturo, ci sono diverse distro che lo supportano da lustri, e sul carrozzone recentemente si e’ aggiunta anche Ubuntu, se mai ce ne fosse stato bisogno.

    “x86-32 neanche 64 bit, mentre la stragrande maggioranza dei port su altre cpu sono più esperimenti che progetti seri”

    Linux e’ stato il primo SO in assoluto a supportare AMD64, ed e’ assolutamente stabile e maturo il supporto per numerose altre architetture quali IA64, SPARC, S390, PPC (e Cell), MIPS. Non capisco cosa ci sia di cosi’ sperimentale, e insieme a me non lo capiscono Red Hat, IBM, Oracle, HP, centinaia di altri vendor e migliaia di grossi clienti.

    Per ARM embedded cmq ci sono i vari Windows Mobile, Apple iPhone/iPod OS, Symbian, Android che hanno gia’ una buona presenza anche se probabilmente non scaleranno verso l’alto partendo dagli smartphone. Per i MID, sempre su ARM, ci sara’ anche Nokia/Maemo linux e Chrome OS. Se mai ARM dovesse infiltrarsi nel mercato notebook/desktop mainstream vedrai che non tardera’ una versione di Windows 7 nativa.

    Ultime note, il volume di vendite di ARM:
    – 1.6 miliardi di CPU nel 2005 (si, miliardi)
    – 10 miliardi di CPU vendute fino a gennaio 2008
    – previsione di venderne 5 miliardi in un anno per il 2011

    e il fatto che siano anche estremamente economici da produrre (sempre per il fatto di avere un transistor count enormemente inferiore): 9 mmq il die di un Cortex A8, 25 per un Atom diamondville.
    Sul fronte delle prestazioni esistono SOC (tipo il Tegra di nvidia e altri prodotti tipo Qualcomm Snapdragon o TI OMAP) che sbaragliano allegramente Atom+qualsivoglia IGP Intel (il paragone lo si dovra’ fare con Pineview).
    Apple, con l’acquisto di PASemi, ora sviluppa chip ARM direttamente in house per iPhone, e da un bel po’ si vocifera del famoso tablet: vedremo se useranno lo stesso os di iPhone o meglio una versione stripped di MacOS.

    @Cesare
    Dell’ottimo materiale si trova qui:
    http://www.bitsavers.org/pdf/dec/vax/

    Fa conto che sono riusciti a metterci dentro cose tipo “POLYD” e “POLYF” (Polynomial Evaluation rispettivamente in double e float) XD

  • # 30
    simone
     scrive: 

    è qui che entra in gioco Google!!!!!!!
    il fatto di fare nascere Chorme OS sarà una rivoluzione x linux—->quindi x ARM!ogni software fino ad ora creato in ambiente linux con google verà sviluppato e diffuso esponenzialmente x il solo nome google(daltronde come accadde allo stesso modo x il mondo windows)!secondo me tempo 20 anni e il mondo infomratico si svilupperà in 2 parti…smartphone/netbook che confluiranno sui 32bit con processore muilti-ARM(con mondo linux-google),e dall’altra il mondo windows con processi a 64bit(x lavoro/ricerca)implementanto su portatili/fissi/server!

  • # 31
    Alessio Di Domizio
     scrive: 

    Da parte mia mi sono fatto l’idea che x86 sia ormai per Intel una scelta “culturale” più che una motivazione tecnica. Ogni volta che sottoponi ad Intel una domanda tipo “non siete preoccupati delle inefficienze dell’architettura x86?” ti rispondono con una sorta di mantra: “internet gira su x86, il 99,9% del software mai prodotto gira su x86″.

    Il problema è che le cose stanno cambiando e che, nella grande battaglia su dispositivi mobili di convergenza, Intel è ancora legata al concetto di notebook in miniatura mentre ARM è in netto vantaggio nel mondo degli smartphone di nuova generazione. Questa situazione influenza inevitabilmente anche il fronte software e credo, come argomenterò in un pezzo che uscirà a breve, che la scelta di Intel di supportare Chrome OS sia in questo senso una scelta politica più che tecnica.

    Fra il serio e il faceto, ho personalmente supplicato uno specialista di Intel di disseppellire le proprietà intellettuali dell’architettura RISC Alpha per farne un competitor nell’ambito dell’ultramobile!

    Ciò che non si può risolvere attraverso un efficientamento dell’ISA – per esclusione dev’essere questa la loro idea – si può risolvere con innovazioni nei processi produttivi. Lo scopriremo solo vivendo ma, per quanto Intel possa essere all’avanguardia su questo fronte, i passaggi di tecnologia prima o poi riguardano anche le architetture rivali: Samsung ha recentemente portato un’architettura ARM11 a 45nm.

    A quel punto i vantaggi architetturali si ripristinano e siamo punto e a capo…

  • # 32
    Marco
     scrive: 

    “Samsung ha recentemente portato un’architettura ARM11 a 45nm.”

    Esatto, tutti gli ultimi SOC basati su ARM sono gia’ a 45nm, e visti i numeri in gioco saranno sempre in prima linea presso le grandi foundries indipendenti tipo TSMC.
    Alcune implementazioni sono realmente impressionanti, tipo il Qualcomm QSD8672: due core Cortex A9 a 1.5GHz, WSXGA, 1080p e una sezione 3D da fare invidia al Nintendo Wii, tutto in un package 15x15mm e quindi verosimilmente un die di dimensioni inferiori ad un Atom single core.

  • # 33
    Alessio Di Domizio
     scrive: 

    A questo punto scatta la domanda per gli esperti di ISA: come la vedete l’architettura Alpha, opportunamente evoluta, in prospettiva SOC? Credete che il gap sia recuperabile? È un asso che Intel e HP potrebbero avere nella manica…

    Per inciso, nello scenario dell’ultramobilità, l’acquisizione di PA-Semi da parte di Apple mostra tutto il suo potenziale, anche nell’ottica (in un futuro non prossimo) di una progressiva (e parziale) emancipazione da Intel/x86… Un esempio: non credo che nel prossimo venturo netbook/tablet di Apple vedremo un Atom.

  • # 34
    Marco
     scrive: 

    Lungi dal considerarmi un esperto in materia, ecco le mie considerazioni.
    Tenendo conto che probabilmente stiamo parlando della miglior architettura mai progettata, il focus di Alpha e’ sempre stato il mercato server (dove andava a rimpiazzare VAX) e il supercalcolo, grazie rispettivamente ai 64 bit e alle prestazioni nel calcolo in virgola mobile. Purtroppo sono caratteristiche che non si addicono particolarmente all’embedded, dove ARM (gia’ nato con requisiti di estrema semplicita’) negli anni si e’ specializzato con Thumb, Jazelle, Neon, ecc., insomma ci sarebbe un bel po’ di lavoro da fare.
    Nel desktop invece ci avevano gia’ provato con le varie Multia e Alphastation. Ricordo anche di schede madri Alpha vendute singolarmente per gli assemblatori, con tanto di versione dedicata di Windows NT4, e purtroppo anche qui per vari motivi gli sforzi sono stati vani. 64 bit in quell’epoca sul desktop voleva solo dire spendere il doppio per la RAM.
    Cio’ non toglie che probabilmente clock-per-clock un 21264 e’ ancora piu’ veloce di un Core i7 gia’ nel calcolo intero e in Intel-HP secondo me a piu’ riprese avranno pensato di cestinare Itanium in favore di Alpha.

  • # 35
    mithrandirxxx
     scrive: 

    mi ricordo di un film con la Jolie(hackers) in cui uno dei protagonisti tirava fuori dalla borsa un portatile a suo dire rivoluzionario dato che aveva un processori RISC all’interno,che secondo lui avrebbe rappresentato il futuro…che ridere!!!

  • # 36
    j
     scrive: 

    A questo punto scatta la domanda per gli esperti di ISA: come la vedete l’architettura Alpha, opportunamente evoluta, in prospettiva SOC? Credete che il gap sia recuperabile? È un asso che Intel e HP potrebbero avere nella manica…

    nè meglio nè peggio di altre ISA risc, visto che Alpha era un risc puro con un set di istruzioni pulito ed essenziale, ma anche privo di particolarità distintive (un po’ come il mips a cui in effetti era ispirato)

    una caratteristica interessante dell’ ARM, invece, è l’ esecuzione condizionale ortogonale, nel senso che sebbene il formato delle istruzioni vari a seconda della modalità operativa, in ognuna è previsto un campo il cui valore denota la condizione a cui l’ istruzione può sottostare
    quindi su arm ogni istruzione può essere eseguita o meno a seconda dell’ esito della verifica fatta direttamente sulle flag di stato (se non ricordo male proprio da un comparatore in serie alla alu)
    il che, se non elimina la necessità di usare salti condioznati nel codice, quantomeno la riduce considerevolmente, riducendo di conseguenza l’ importanza di una logica di branch prediction ampia () e complessa (d’ altra parte necessaria per mantenere l’ efficienza della cpu sui code path con molti salti, magari nested, laddove questi siano il principale costrutto di controllo di flusso)
    ed è un’ altra cosa in meno ad assorbire corrente…

  • # 37
    Cesare Di Mauro
     scrive: 

    @pabloski: è difficile trovare estimatori degli x86. ;)

    @Marco: grazie per il link; appena avrò un po’ di tempo me li studierò (tra l’altro ho visto che il sito è un’autentica miniera :). Comunque “promette bene” da quel che hai scritto. :D

    Per quanto riguarda s.o. & co., come dicevo anche prima io vedrei bene AmigaOS, se opportunamente aggiornato (coi cambiamenti che suggerivo). Ti sembrerà strano, ma lo trovo un s.o. ancora moderno e godibilissimo (ovviamente servono le applicazioni: senza software non si va da nessuna parte).
    Prova a dare un’occhiata alla “riscrittura” open source, AROS: http://aros.sourceforge.net/ Ci trovi anche una versione con immagine VMWare, così eviti l’installazione (e la lentezza della versione live su CD-Rom, che purtroppo è realizzata decisamente male da questo punto di vista).
    Tra l’altro la versione ufficiale e commerciale (AmigaOS 4.0 che gira su PowerPC), implementa i meccanismi di protezione di cui parlavo, ed è anche aggiornata a livello di interfaccia grafica.

    Su Linux & ARM dico soltanto una cosa: sono anni che aspetto una distro che sia in grado di rimpiazzare in tutto e per tutto quella nativa del mio Zaurus SL-5500. -_-

    Riguardo a Windows, non penso che arriverà una versione per ARM fino a quando non ci saranno consistenti vendite di netbook con questa CPU.

    Infine sul confronto Cortex vs Atom, preferirei non mettere in mezzo variabili addizionali, come chipset e memoria. Da programmatore e studioso di architetture m’interessa intanto cercare di capire le potenzialità della sola CPU, e poi quelle del complesso (tra l’altro per Atom c’è pure lo ION di nVidia a disposizione, che non è paragonabile al chipset IGP di Intel).

    @simone: Chrome OS è sostanzialmente web-based (parlo dal punto di vista dell’utente). Per cui penso che non ci sarà differenza apprezzabile fra una soluzione basata su ARM e un’altra su x86, a parte costi, consumi, e dotazione.

    @Alessio Di Domizio: l’Alpha è stato sviluppato in ottica server, come giustamente hanno riportato, per cui non lo vedrei bene nel settore mobile (nemmeno nei netbook, onestamente).

    Quanto a Intel, è già sui 32nm, quando i suoi principali concorrenti sono ancora fermi ai 45nm, per cui parte sempre in posizione di vantaggio.

    Inoltre, riprendendo il discorso che avevo fatto nell’articolo e sottolineato poi da un altro utente, c’è da dire che più si riduce il processo produttivo, più le differenze dal punto di vista della dimensione dei chip e dei consumi si riduce. Il legacy, insomma, incide sicuramente su fattori di scala piccoli (i pochi milioni di transistor di Atom, ad esempio), ma poco su quelli più grandi (i quasi due miliardi di transistor di Nehalem in versione octopus).

    @Marco: impressionante la soluzione Qualcomm basata su Cortex-A9. Sono numeri da far spavento, e Intel ha sicuramente di che preoccuparsi.

    Per quanto riguarda Itanium, Intel e HP hanno investito troppo, e non credo che torneranno mai su Alpha (e PA-RISC per HP).

    @j: l’esecuzione condizionale è presente anche sui PowerPC se non ricordo male.

    Comunque anche se teoricamente rappresenta un’eccellente soluzione per cercare di rimuovere i salti condizionati, praticamente mi sembra un grande spreco (di spazio negli opcode, in particolare), perché in genere nel “codice di tutti i giorni” sarebbe sufficiente una move condizionale (MOVEcc) per risolvere problemi di stallo della pipeline causati da questo tipo di codice.

    Tra l’altro viene utilizzato anche un bit per specificare se un’istruzione possa o no modificare i flag di stato. Anche questo mi sembra un altro spreco. Visto che è molto raro dover preservare il registro di stato, preferisco nettamente la soluzione di 6800, 6502 e 68000: quasi tutte le istruzioni (anche quelle di “MOVE / LOAD”) alterano i flag. Codice più compatto e spesso più efficiente.

    Però devo ammettere che questa soluzione di ARM e PPC la trovo molto pulita ed elegante. :)

  • # 38
    Marco
     scrive: 

    “Prova a dare un’occhiata alla riscrittura open source, AROS”
    Eh, da affezionato ex utente lo seguo da anni, e in particolare recentemente la “distro” Icaros (ex VMWAros): http://icarosdesktop.org
    La protezione della memoria in OS4 invece mi sembra che sia limitata a dei canary sugli stack trappati che killano il processo in caso di scrittura su aree proibite, alla stregua di -fstack-protector o SSP che dir si voglia. Fare di piu’ significherebbe probabilmente la rottura della retrocompatibilita’, anche se a questo punto, visto il parco software esistente, relegherei all’emulazione i vecchi programmi (come alla fine ha fatto anche Apple col MacOS classic) e porterei definitivamente al passo con i tempi il kernel. Mi spiace (per me che avevo cominciato a programmare in C proprio su Amiga con l’Aztec) che, come in altre piattaforme, il grosso delle applicazioni siano meri porting di software dal mondo GNU/FOSS che si appoggiano a layer di compatibilita’ posix (ixemul.library) che poco hanno da spartire con la filosofia originaria.

    “tra l’altro per Atom c’è pure lo ION di nVidia”
    Hai ragione, cmq poi dato che si parlava di SOC infatti ho detto che il confronto si dovra’ fare con Pineview, che incorporera’ anche il northbridge e la gpu.

    “non credo che torneranno mai su Alpha”
    Eh, nemmeno io purtroppo.

  • # 39
    zazabusula
     scrive: 

    Ma quanto sono potenti questi arm?
    Con un paio di watt gli atom fanno girare xp o seven, arm non penso ci riuscirebbe, quanto andrebbe a consumare un processore così potente con questa architettura???

  • # 40
    arkanoid
     scrive: 

    Perchè le archittture tipo dragonball, che mi risulta derivassero dal più volte lodato 68000, sono sparite? Non potrebbero essere una via di mezzo congruente con lo scopo?

  • # 41
    Cesare Di Mauro
     scrive: 

    @Marco: AmigaOS 4 la compatibilità col passato l’ha comunque rotta (è per PPC), per cui il software per 680×0 potrebbe benissimo girare tramite UAE o, meglio ancora, con un sistema di tunnelling tipo il WoW (rimappando le chiamate alle API delle librerie standard del 68000 su quelle native della piattaforma su cui gira).

    Da amighista m’interessa un AmigaOS aggiornato con almeno la protezione della memoria e il resource tracking. Cosa non facile, ma che non richiede nemmeno grossi sforzi.

    E poi, come te, preferisco software nativo a banali port, che della struttura e delle capacità di AmigaOS non sfruttano una mazza, aggiungendo, anzi, un layer in più su quello già pesante dell’emulazione POSIX.

    @zazabusula: dai benchmark che ho visto competono con Atom. Ma senza una vasta e variegata batteria di test non siamo autorizzati a trarre delle conclusioni definitive.

    @arkanoid: purtroppo sono state soppiantate da ARM, che è una soluzione più economica.

  • # 42
    D
     scrive: 

    “Con sommo dispiacere da vecchio amighista devo dire che non concordo. Stiamo parlando di un SO di oltre 20 anni fa e praticamente non piu’ aggiornato”

    Esiste una cosa che si chiama Amiga OS 4 e non ha 20 anni…

    “Il supporto per ARM e’ maturo, ci sono diverse distro che lo supportano da lustri, e sul carrozzone recentemente si e’ aggiunta anche Ubuntu, se mai ce ne fosse stato bisogno.”

    “Linux e’ stato il primo SO in assoluto a supportare AMD64, ed e’ assolutamente stabile e maturo il supporto per numerose altre architetture quali IA64, SPARC, S390, PPC (e Cell), MIPS. Non capisco cosa ci sia di cosi’ sperimentale, e insieme a me non lo capiscono Red Hat, IBM, Oracle, HP, centinaia di altri vendor e migliaia di grossi clienti.”

    Io voglio supporto software, supporto hardware, applicativi e driver a profusione. Compro oggi una schifosa chiavetta umts e devo ancora leggere sulla scatola cose oscene come “disponibili driver per vista a 32 bit”.
    Per l’OS maggiormente diffuso al mondo, basato sull’architettura commercialmente dominante c’è ancora chi nel 2009 si guarda bene dall’offrire un supporto completo e degno di questo nome e te mi vieni a parlare di cose che si sognano pure quel poco ?
    Voglio installare ubuntu a 64bit e mi ritrovo con i repository grossi la metà della controparte a 32bit (in ambito x86, non CoccoBelloCPU altrimenti potrei scrivermeli), senza contare la cronica mancanza di librerie e pacchetti imprescindibili per un uso soddisfacente del sistema (vedi codec per video, audio o anche solo flash).

    Ma dove si vuole andare… E’ facile vantare il supporto di linux verso ogni hardware ma le cose vanno dette per intero: supporto hw/sw ciccia così tutto cambia sulla carta quanto rimane immobile nei fatti.

  • # 43
    Marco
     scrive: 

    @Cesare
    “AmigaOS 4 la compatibilità col passato l’ha comunque rotta”

    Beh non proprio, in realta’ viene usato un emulatore JIT del 68000 (come a suo tempo Apple fece passando da 68K a PPC), quindi non una vera e propria sandbox. Cqm AROS usa proprio UAE e i risultati sono apprezzabili secondo me.
    Concordo sul fatto che si potrebbero aggiungere finalmente almeno queste due caratteristiche fondamentali, peccato che lo sviluppo sia stagnante e Amiga preferisca investire nei giochini per PDA.

    @D
    “Esiste una cosa che si chiama Amiga OS 4 e non ha 20 anni…”

    Architetturalmente si. E non e’ da biasimare nessuno, dato che e’ sviluppato da una societa’ che si occupa di porting di videogiochi impiegando 4 sviluppatori nel tempo in cui non hanno altro da fare e con l’ostracismo della casa madre. E per questo ci hanno messo… boh? 5 o 6 anni per giungere ad una release “stabile”.

    “Compro oggi una schifosa chiavetta umts”
    Ma siamo seri per favore, si parlava di architetture, non di chiavette USB. Le ditte che ti ho citato ti danno un pieno supporto enterprise 24/7, non certo i bollini “designed for z/OS” da appiccicare alle scatole dei mouse. Se vuoi parlare dei problemi di Linux sul tuo PC comprato al supermercato non e’ questo il thread adatto e se ne e’ gia’ discusso altrove.

  • # 44
    D
     scrive: 

    “E per questo ci hanno messo… boh? 5 o 6 anni per giungere ad una release “stabile”.”

    Beh sicuramente sarebbe più facile creare un supporto hardware verso amiga che non verso linux visto che ci sarebbe la certezza che le carte non finiscono per cambiare da un giorno all’altro a causa del solito gruppo di bastian contrari.

    “Se vuoi parlare dei problemi di Linux sul tuo PC comprato al supermercato non e’ questo il thread adatto e se ne e’ gia’ discusso altrove.”

    Qui si sta parlando di ARM in un ambito di concorrenza rispetto ad intel per i pc del supermercato quindi ha molto più senso parlare di bollini e chiavette usb che non di z/OS e sistemi enterprise.

  • # 45
    Marco
     scrive: 

    “sicuramente sarebbe più facile creare un supporto hardware verso amiga”

    Eh si, come no. Infatti il mercato pullula di vendor che supportano AmigaOS. Che non e’ supportato nemmeno dalla sua stessa casa madre.

    “Qui si sta parlando di ARM in un ambito di concorrenza rispetto ad intel”

    Difatti sei stato a uscirtene con “Linux francamente è una barzelletta” e “stragrande maggioranza dei port su altre cpu sono più esperimenti”. Uno che fa affermazioni di questo tipo onestamente non saprei se definirlo un troll o semplicemente uno che non sa di cosa sta parlando.

  • # 46
    Cesare Di Mauro
     scrive: 

    Quando parlavo di compatibilità rotta col passato mi riferivo al fatto che AmigaOS 4 non fa girare nativamente le vecchie applicazioni. Deve, quindi, ricorrere a un emulatore.

    AROS, invece, si prefigge proprio l’obiettivo della totale retrocompatibilità.

  • # 47
    Marco
     scrive: 

    @Cesare
    “AmigaOS 4 non fa girare nativamente le vecchie applicazioni. Deve, quindi, ricorrere a un emulatore.
    AROS, invece, si prefigge proprio l’obiettivo della totale retrocompatibilità.”

    Secondo me e’ vero il contrario: AROS si prefigge una compatibilita’ a livello di API/ABI e necessita della ricompilazione dei sorgenti per l’architettura target qualora fosse differente dal 68K (lasciando perdere UAE che e’ un “mero” emulatore e funziona su qualsiasi piattaforma), mentre AmigaOS 4.x fa funzionare il vecchio software 68K direttamente nel nuovo SO emulando esclusivamente la CPU. Ad esempio se volessi usare DOpus su AROS viene lanciato UAE, caricato un AmigaOS 68K ed eseguito in una sandbox (piuttosto inutile in questo caso dato che accederesti esclusivamente al filesystem del SO emulato), su OS4 viene eseguito in maniera trasparente accedendo a tutte le risorse dell’host.

  • # 48
    Cesare Di Mauro
     scrive: 

    Esattamente. Mi riferivo esclusivamente alla piattaforma 680×0 quando parlavo di retrocompatibilità per AROS (d’altra parte AmigaOS era disponibile solo per questa famiglia di microprocessori).

  • # 49
    » Canonical, Xandros, Novell adottano Moblin _ Ultime su ARM e LINUX
     scrive: 

    […] libera. Nessuno può negare che ARM è un’alternativa verde, economica ed etica, in breve: tecnologicamente superiore.Per ora ARM è supportata solo da Microsfot Windows CE su Nvidia Tegra (oltre ai sistemi embedded), […]

  • # 50
    Riflessioni sull’architettura ARM - Appunti Digitali
     scrive: 

    […] In questa rubrica abbiamo parlato estensivamente dell’architettura ARM, uno dei microprocessori RISC più diffusi e indiscutibilmente destinato ad avere un ruolo sempre più di primo piano grazie a un ottimo compromesso fra prestazioni, costi e consumi. […]

  • # 51
    ChromeOS, cattive notizie per Atom e x86 - Appunti Digitali
     scrive: 

    […] mobile, un’efficienza energetica che l’overhead dell’architettura x86 rende difficilmente raggiungibile, a parità di tecnologie produttive e […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.