La macchina più chiacchierata del mondo Amiga “NG” (New Generation) è senza dubbio l’AmigaOne X1000, realizzata da A-EON col supporto finanziario di un facoltoso utente amighista, Trevor Dickinson, e l’appoggio di Hyperion per quanto riguarda il sistema operativo (ovviamente AmigaOS 4).
Quella che doveva essere la macchina del rilancio, abbiamo visto rivelatasi, invece, sostanzialmente un flop, a causa di diverse problematiche che sono state analizzate in un apposito articolo.
Dopo il passo falso rappresentato dal recente supporto alle seriali e al PATA, arriva una buona notizia che riguarda il componente che è stato oggetto di numerose speculazioni nonché fantasie legate all’immaginario amighista: il coprocessore XMOS XCore XS1-L2 124, ribattezzato nel frattempo Xena in ricordo dei vecchi tempi (ma che di custom non ha proprio nulla, essendo un componente discreto acquistabile da chiunque e a poco prezzo), è finalmente supportato dal s.o..
Lo sviluppatore che se n’è occupato ha annunciato di aver realizzato una demo che accende un paio di LED presenti nella scheda madre dell’X1000, mettendo a disposizione un file di risorsa AmigaOS (si tratta di una speciale libreria AmigaOS che espone delle API per accedere e manipolare una particolare risorsa, appunto) per gli sviluppatori, oltre ad alcuni strumenti per caricare applicazioni per l’XCore e monitorarne lo stato.
Si tratta quasi sicuramente del contributo di un appassionato che s’è offerto volontariamente e gratuitamente di lavorare su questa parte della piattaforma, che ha poi rilasciato. Infatti in una pagina del suo sito personale riporta l’elenco dei donatori e l’ammontare del contributo, fra i quali figurano Steven Solie (lead developer di Hyperion) e il già citato Trevor Dickinson.
In particolare quest’ultimo ha reso pubblica, in un messaggio, l’intenzione di effettuarla, dopo l’annuncio del supporto a XCore. Poiché si tratta del “patron” del progetto, dovrebbe essere chiaro, a questo punto, la natura genuinamente volontaria dell’opera dello sviluppatore, che ha deciso motu proprio di dare una mano.
Ognuno, ed è sacrosanto, impiega il proprio tempo libero come vuole; lo stesso Solie ha dichiarato, in una fresca intervista, che in Hyperion lavorano soltanto due sviluppatori (oltre lui, che ormai programma poco), affidandosi per alcuni lavori a programmatori esterni e non nascondendo di cullare l’idea di un modello di sviluppo parzialmente open source (sebbene ci siano delle problematiche).
D’altra parte la manodopera gratuita fa sicuramente comodo, e anche molte multinazionali ne traggono vantaggio. Lo sa bene Apple, che su progetti già esistenti ha letteralmente fondato il suo MacOS X. Ma OS X si paga, e AmigaOS 4 pure…
Chiusa questa parentesi e tornando all’XCore, è lecito domandarsi a questo punto come verrà impiegato questo coprocessore, ed è quello che hanno fatto e continuano a fare diversi amighisti “NG” che gravitano attorno a OS4.
Per fornire qualche risposta è necessario comprendere meglio il funzionamento di questo componente, di cui si trova una parziale analisi nella parte finale dell’articolo sull’X1000. A ciò va aggiunta un’apposita sezione della FAQ di questo computer, oltre a un recente messaggio di Solie, e ovviamente la documentazione disponibile sul sito di XMOS.
Il dubbio più grosso riguarda la capacità del chip di interfacciarsi con la memoria, ma si tratta di un’incertezza destinata a sparire velocemente. Infatti all’inizio della FAQ viene posta questa domanda, a cui però non segue alcuna risposta; inoltre Solie parla di un “local bus” che connette XCore e PA6T (la CPU).
Non poteva essere altrimenti, poiché questo coprocessore non è dotato di sufficienti linee per poter accedere direttamente alla memoria (sarebbe comunque servito un chipset allo scopo), e al più avrebbe potuto farlo come un’altra periferica collegata al southbridge, ma, essendo stata esplicitata la connessione diretta con la CPU, cade anche quest’ipotesi.
Dunque la CPU deve farsi carico di inviare all’XCore i dati che a questi servono, e di prelevarne eventualmente i risultati. Qui notiamo già una differenza fondamentale coi coprocessori dell’Amiga, che si occupavano autonomamente, una volta programmati, di lavorare recuperando direttamente dalla memoria i dati e scaricando completamente la CPU, che poteva dedicarsi ad altro.
Di questo local bus non si sa nulla della sua natura e non ci sono altre informazioni. Non si conosce la banda a disposizione né tanto mento quanto incidono sulla CPU le richieste di scambio dati con l’XCore. Solie parla della possibilità di scambiare velocemente grosse quantità di dati, ma il dubbio che sia realmente così è più che lecito.
Infatti dalla FAQ si apprende che circa un quarto delle linee dati del coprocessore sono state dedicate proprio all’implementazione del local bus. Leggendo la documentazione di XMOS sul modello XS1-L2 124, si apprende che si tratta di un dual core, che mette a disposizione 84 linee dati (44 il primo core, e 40 il secondo).
Un quarto ammonta rozzamente a 21 linee, presumibilmente di un solo core (in modo da lasciare libero l’altro per pilotare le linee dati, ma non è escluso che possa essere anch’esso interfacciato alla CPU).
Sempre dalla documentazione presente sul sito di XMOS, salta fuori che un core può comunicare con un altro tramite dei link, fruttando 2 oppure 5 linee dati. Nella sua incarnazione più veloce, l’XCore mette a disposizione un protocollo di comunicazione basato su 5 linee che arriva a toccare 250Mbit al secondo, pari dunque a 31,25MB/s.
Si tratta di valori teorici, di picco, poiché il protocollo di comunicazione ha un suo costo (ad esempio c’è almeno un byte nell’intestazione dei pacchetti di dati scambiati), e inoltre si assume che avvenga uno scambio di una certa quantità di dati (32 byte negli esempi presenti nella documentazione).
Con 21 linee dati si può, quindi, ipotizzare che vengano implementati fino a 4 link di questo tipo, per una banda aggregata teorica di 125MB/s. Anche questi rigorosamente di picco, anche perché si tratterebbe di 4 canali di comunicazione diversi, che trasportano ciascuno pacchetti di dati diversi.
Infatti per ottimizzare al massimo le prestazioni, sfruttando la banda totale a disposizione, la CPU dovrebbe garantire l’invio di 4 stream di dati in parallelo, il che non è sempre possibile; tutt’altro. Oltre a diventare un’operazione complicata e che impegnerebbe la CPU, dovendo badare a 4 link da “sfamare” (negli stessi cicli di clock).
Un’altra soluzione potrebbe essere quella di impiegare in maniera diversa quelle linee. Ad esempio se ne potrebbero riservare 16 (8 per ogni “porta”; le linee dati sono raggruppate in “porte”, che possono gestirne al massimo 8 alla volta) per i dati, e le altre per controllarne le operazioni (ad esempio per inviare comandi che implementano il protocollo di trasferimento).
Questo significa che nell’XCore un thread sarebbe riservato all’ascolto dei comandi e un altro adibito al solo trasferimento dei dati. Si tratta di uno scenario ipotizzato per massimizzare le prestazioni; l’implementazione potrebbe essere molto diversa.
Trasferendo 16 bit alla volta, e ignorando completamente il costo del protocollo da implementare, in linea teorica si potrebbero trasferire 2 byte (16 bit) ogni 5 cicli di clock, supponendo astrattamente che il secondo thread debba eseguire soltanto 4 istruzioni per il trasferimento (lettura prima porta, scrittura primo byte in memoria; lettura seconda porta, scrittura secondo byte in memoria) e una per mettersi nuovamente in attesa del prossimo dato.
Con questa soluzione il picco teorico risulterebbe pari a 500M * 2 / 5 = 200MB/s. Un valore più elevato rispetto al precedente, ma soprattutto senza il vincolo di dover spedire 4 diversi pacchetti.
Rimane il forte dubbio che si possa fare meglio dei 125MB/s dei 4 link, sfruttando l’implementazione fornita già nativamente da XMOS per i suoi chip, ma senza alcun dato concreto sull’implementazione del local bus non ci si può che affidare a delle ipotesi di massima.
In ogni caso 200MB/s non sono male, ma non è nemmeno un valore elevato in assoluto, considerata la banda che mettono a disposizione le memorie DDR-2 a 800Mhz montate nella macchina, pari a 12,8GB/s teorici (avendo a disposizione due canali).
Considerato che per accedere a un dato nella memoria principale bisogna passare comunque dalla CPU, con tutta la latenza che deriva da quest’operazione (basti ricordare che le CPU hanno introdotto le cache, sempre più corpose, proprio per evitarlo il più possibile) che ormai porta via centinaia di cicli di clock, lo scenario è tutt’altro che idilliaco.
Infatti, sempre nella FAQ, è scritto a chiare lettere che non è loro intenzione usare questo coprocessore per l’emulazione del chipset AGA, ma più realisticamente, e alla luce di tutte le considerazioni fatte, appare poco plausibile che il chip di XMOS possa essere in grado assolvere a questo compito, come pure per il ben più semplice chipset ECS.
Chi pensava a possibili impieghi per accelerare l’esecuzione di programmi come Blender, MPlayer, LAME, ecc., non può che rimanere deluso, poiché siamo decisamente lontani. D’altra parte è bene notare che questo coprocessore presenta esclusivamente istruzioni intere: manca del tutto una FPU, e men che meno un’unità SIMD.
Si potrebbe utilizzare per operazioni di filtraggio di canali audio, o decompressione di immagini JPEG, come riporta la documentazione del sito di XMOS, ma fra il trasferimento dei dati da e per la memoria, e il tempo d’elaborazione, la CPU completerebbe l’operazione in molto meno tempo.
Quali, quindi, i possibili impieghi? Il controllo di linee di I/O, che rimane poi il dominio d’elezione per questo chip, la cui architettura è stata pensata appositamente (presenta, infatti, molte istruzioni per manipolare bit e campi di bit).
Per natale c’è tempo, e qualche passo è già stato fatto: un paio di LED si sono accesi. Con un altro po’ di lavoro babbo natale potrebbe assistere a un grazioso spettacolo. Only Amiga makes it possible…
