Due cose Amiga ha portato alle masse, facendone al contempo i propri cavalli di battaglia: il multitasking e i coprocessori dedicati. Molti ricorderanno ancora la mascella a terra (per non dire altro) guardando le finestre e gli schermi (Copper docet) sul Workbench che facevano girare applicazioni diverse simultaneamente, sfoggiando anche grafica elaborata in tempo reale (e qui… Blitter docet!).
Infatti l’Amiga, non mi stancherò mai di ripeterlo, è stato un eccellente connubio fra sistema operativo (AmigaOS) e hardware dedicato, nato da menti geniali che hanno saputo pensare tanto ai programmatori quanto all’utenza finale.
La presenza di coprocessori dedicati per svolgere alcuni compiti, sgravando di conseguenza la CPU, permette, a mio avviso, di parlare già di ASMP (multiprocessing asimmetrico), sebbene generalmente il termine sia utilizzato in sistemi in cui i processori appartengono alla stessa famiglia o sono molto simili.
Se per “processore” intendiamo, come in letteratura, un “elemento che processa”, cioè che elabora delle informazioni, esegue delle operazioni o delle azioni, ecc., non dovrebbero esservi dubbi sul fatto che l’uso dell’etichetta ASMP sia perfettamente legittimo.
Nel precedente articolo riguardo agli scenari futuri dell’Amiga non ho mai parlato esplicitamente né di SMP né di ASMP per non appesantirlo troppo, e per affrontare l’argomento (che si trascina da tempo, e se ne parla infatti sia per il progetto Natami, che per AROS e altri s.o. AmigaOS-like o derivati) dedicandogli ben più di qualche riga.
Soprattutto non voglio separarlo nettamente fra SMP e ASMP, ma suddividere ulteriormente quest’ultimo in appositi scenari più “specializzati” e non mutuamente esclusivi, quanto piuttosto sovrapponibili (quindi alcuni, o anche tutti, possono coesistere).
Partendo proprio dai coprocessori presenti nel chipset, abbiamo già visto che l’intenzione era quella di migliorarli, aggiungendone anche altri dedicati a precisi scopi, come ad esempio il 3D, il cui supporto nativo (visto che comunque grazie a Blitter e/o CPU era possibile simularlo) era assente.
Quando parlo di coprocessori in quest’ambito, mi riferisco sempre a processori dedicati dotati di funzionalità “fisse” (fixed function, in gergo), pertanto con scarsa o nulla programmabilità. Per rendere meglio l’idea, potremmo considerare tale un chip che si occupa esclusivamente di fungere da modem, oppure un altro che miscela più canali sonori per generare l’output finale (magari con effetti predefiniti selezionabili), un’unità di de/compressione di suoni compressi, ecc.
Un’altra forma di ASMP, ma più sofisticata e appetibile per uno sviluppatore, riguarda l’aggiunta di processori programmabili, come il DSP 3210 di AT&T che Dave Haynie aveva integrato nel prototipo Amiga 3000+ di cui abbiamo parlato in un altro articolo.
Si tratta di una soluzione sicuramente molto più costosa rispetto a un processore dedicato a un ben preciso scopo, ma che mette a disposizione una flessibilità e potenza di calcolo enorme. Il 3210 permetteva, tra l’altro, di essere collegato ad altri DSP della stessa famiglia, e di eseguire in parallelo un s.o. dedicato con task / processi annessi.
Trattandosi di caratteristiche del tutto nuove, eventuali incompatibilità sono completamente assenti: non si può, infatti, programmare male un processore che prima era assolutamente inesistente, giusto per fare un confronto coi problemi causati dall’aggiornamento della sezione video del chipset AGA.
L’adozione di DSP altamente programmabili apre, però, altre questioni. Prima di tutto sceglierne uno o una famiglia (supponendo che i vari membri della medesima siano fra loro compatibili, o almeno retrocompatibili per i modelli più nuovi rispetto ai predecessori) significa anche legarvisi mani e piedi, come si suol dire, in quanto lo sviluppo di applicazioni che ne faranno uso aggiungerà un (pesante) vincolo alle future evoluzioni delle macchine.
Per essere chiari, non si potrebbe poi passare a un nuovo DSP della Texas Instruments, per quanto “mostruoso” potesse essere, se venisse a mancare la retrocompabilità con l’esistente (cosa ovvia in questi casi, andando a pescare da vendor diversi).
Altra cosa molto importante, l’adozione di coprocessori con architetture diverse da quella della CPU principale giocoforza introduce l’obbligo di doverne studiare un’altra, appunto. E se non si tratta di smazzarsi i manuali di riferimento della casa madre per programmarvi in assembly, in ogni caso serve conoscerne le caratteristiche di targa, e come compilare e far eseguire le applicazioni realizzate ad hoc.
Una soluzione scontata è quella di dotare un sistema di ASMP di processori della stessa famiglia, o addirittura esattamente gli stessi, della CPU. L’architettura unica ha indubbi vantaggi, perché consente di riciclare le stesse, o almeno una buona parte, delle conoscenze acquisite col microprocessore “dominante”.
Si tratta di un approccio che è stato scelto di recente per Natami, che inizialmente prevedeva di affiancare all’N050 (CPU di derivazione Motorola 68000 ovviamente) un coprocessore basato su un RISC (molto semplice) appositamente progettato per prendersi carico di massicci calcoli in virgola mobile o interi.
Un processore basato sullo stesso, identico, N050, a cui verranno aggiunte delle capacità di calcolo vettoriale per valori interi e in virgola mobile (approccio SIMD), è una soluzione a mio avviso (e per il lavoro che faccio) di gran lunga preferibile rispetto a un nuovo RISC che avrebbe costretto i coder a ripartire da zero per sfruttarlo.
Ciò non toglie che le due soluzioni abbiano dei costi decisamente diversi, in quanto il core N050 richiede molta più logica / transistor rispetto a quello RISC, trattandosi di un processore nettamente più complesso (e che tra l’altro raggiunge velocità di clock più ridotte). Ma evidentemente i progettisti hanno ritenuto complessivamente “migliore” il progetto basato su N050.
La naturale conseguenza è chiedersi come mai gli stessi processori si dovrebbero utilizzare come coprocessori, e non affiancarli invece a quello principale, dividendosi quindi equamente (se possibile) tutti i compiti (modello SMP, appunto).
D’altra parte, e come abbiamo citato all’inizio, Amiga nasce come sistema multitasking, per cui riuscire ad assegnare i vari task a più processori potrebbe portare a notevoli vantaggi prestazionali in situazioni di forte carico.
Purtroppo per AmigaOS quello che potrebbe sembrare l’uovo di Colombo in realtà pone problemi di difficile soluzione, a causa dell’enorme macigno che fa capo alla retrocompabilità con le applicazioni già scritte (male).
Sulla carta questo s.o. espone l’API Forbid() per disabilitare il multitasking (e Permit() per riabilitarlo), oltre a decine di altre API per gestire semafori et similia, da usare nei casi più critici in cui si vuol esser sicuri di essere gli unici a manipolare certe strutture delicate (come anche quelle dello stesso s.o.).
Queste API vanno a modificare un preciso parametro di ExecBase (la struttura base del kernel, Exec), TDNestCnt (task disable nesting count), che serve a tenere il conto delle varie chiamate effettuate a quest’API (o alla duale), fino all’azzeramento che comporta la riabilitazione del multitasking.
Quest’API si sarebbe potuta patchare opportunamente, in modo da utilizzare delle istruzioni atomiche verso la memoria per garantirsi l’acquisizione o meno della risorsa senza incorrere nei famigerati casi di race condition che si potrebbero verificare.
Purtroppo tanti programmatori hanno pensato bene di risparmiare qualche ciclo di clock, evitando di richiamare l’API, e manipolando direttamente questo campo con tutte le implicazioni che possiamo immaginare dovute dall’infausta operazione.
Il risultato è che per Natami molto probabilmente la soluzione arriverà da un meccanismo di locking & sequenzializzazione di questa specifica locazione di memoria, in modo da regolarne rigorosamente l’accesso. Questo sarà possibile grazie al fatto che Natami è sostanzialmente un SoC, per cui avendo tutto integrato (anche il chipset) può permettersi il lusso di tenere sotto controllo tutto.
Lo stesso ragionamento non si può fare con un sistema SMP classico, cioè dotato di CPU che risiedono in socket diversi (o comunque isolate, se sono contenute nello stesso package), poiché senza un robusto meccanismo di arbitraggio di TDNestCnt i problemi rimangono dietro l’angolo.
Oltretutto l’SMP pone anche quello del bilanciamento del carico sui processori esistenti, in modo da massimizzarne lo sfruttamento. Aggiungiamo, infine, che serve pure stabilire se una CPU debba fare da master, in modo da prendersi carico soltanto lei della gestione del multitasking e/o degli interrupt di sistema, e dell’accesso all’hardware.
Tutti problemi di non banale soluzione di cui un’evoluzione dell’Amiga, sia essa intesa come hardware e/o come AmigaOS, deve tenere assolutamente conto. Da questo punto di vista l’ASMP è certamente più comodo, in quanto o non si pone il problema (gli interrupt li gestisce il core principale, ad esempio), oppure è la CPU che mette i coprocessori in condizione di lavorare in maniera “sicura”, assegnando loro specifici compiti con precise risorse a disposizione.
Fortunatamente non tutte le soluzioni sono mutuamente esclusive e, anzi, persino modelli ibridi SMP / ASMP potrebbero benissimo esistere e convivere senza “pestarsi i piedi”, migliorando le prestazioni del sistema.
Lato mio aggiungo soltanto un paio di cose. Personalmente trovo l’ASMP una soluzione migliore dati i problemi che sussistono con le attuali versioni di AmigaOS. ASMP implementato sfruttando la stessa CPU (o “affine”) della macchina, chiaramente.
La seconda, e chiudo, è che immagino un sistema ASMP dotato di un arbitro che si occupa, oltre alla gestione del bus di connessione coi vari core ASMP, anche di schedulare opportunamente i lavori (job) che gli arrivano, sfruttando una coda per depositarli in ordine di priorità e/o di arrivo, e facendo uso di una funzione di callback per avvisare eventualmente il task “mandante” della fine del job.
In questo modo i programmatori non devono nemmeno sbattere la testa contro i muri per cercare di suddividere preventivamente il lavoro da fare sulla base del numero di processori esistenti, ma è l’arbitro / schedulatore a occuparsi di ricevere dei job più piccoli, da passare ai processori man mano che si liberano, ottimizzando il tutto (sempre nei limiti del possibile).
Non nascondo il fatto che sono rimasto particolarmente affascinato dall’architettura di Larrabee, grazie alla commistione fra un’ISA ben nota (x86) e una potente nonché elegante unità SIMD di nuova generazione.
In ogni caso la scelta fra SMP e ASMP, o magari di soluzioni ibride, per Amiga e/o AmigaOS (e derivati) sarebbe stata soltanto rimandata, perché è fuor di dubbio che il futuro sarà dominato da soluzioni multicore, poiché scalare in frequenza s’è rivelata un’impresa alquanto ardua e difficile da attuare.
Forse non sarebbe male prendere in seria considerazione l’idea di dare un taglio alla retrocompatibilità, mettendoci l’anima in pace se un’applicazione scritta male non funzionerà più (o, peggio, creerà problemi) in un sistema SMP…
“Forse non sarebbe male prendere in seria considerazione l’idea di dare un taglio alla retrocompatibilità, mettendoci l’anima in pace se un’applicazione scritta male non funzionerà più (o, peggio, creerà problemi) in un sistema SMP…”
Quand’è che si comincerà ad applicare questa cosa ad aros ? Così la si smette di cercare soluzioni assurde che a fine 2010 ci hanno portato solo un coso che sbanda non appena un programma fa i capricci ? Chi vuole la retrocompatibilità si tiene un emulatore, non cerca di minare lo sviluppo e la crescita di un intero ecosistema.
Secondo me la soluzione potrebbe essere quella di implementare delle macchine virtuali come fà Microsoft con Hyper-V/MED-V, in questo modo il sistema operativo nuovo sarebbe libero da dover gestire le retrocompatibilità.
potrebbero farlo anche con l’architettura x86,ma intel non ne vuole sapere!
al recente Amiwest americano Hyperion ha spiegato qualcosa su come stanno implementando il supporto multicore in AmigaOS: su AW.net qualche post riportava qualche informazione…
A proposito di nuove macchine Amiga, che ne pensate dell’X1000 di A-EON?
http://www.a-eon.com/
Ciao!
Ma non è ancora uscito ?
Già è discutibile per potenza, prezzo e supporto lato sistema. Se aspettano ancora un po’ fa la fine del primo amigaone (G3 in un mondo di dual core)
Preferirei non parlarne qui, visto che l’argomento è un altro.
Riguardo invece ad AROS, ti ho già risposto nell’altro articolo a riguardo.
Qui il topic verte su SMP e ASMP per Amiga/AmigaOS, non sui problemi generati da software scritto male (come avevo specificato alla fine dell’articolo; unica parte in grassetto del pezzo).
@Sergio: si utilizza già UAE per far girare le vecchie applicazioni, comprese quelle bacate.
L’idea è quella di isolarle in una sandbox, appunto.
@supertigrotto: considera che in modalità AMD64 non puoi più far girare codice a 16 bit (sia in modalità reale che protetta / 80286) né utilizzare la segmentazione, e inoltre un bel po’ di vecchie istruzioni legacy sono state rimosse.
Il vecchio software gira soltanto in ambiente virtualizzato, e mi sembra un’ottima cosa (d’altra parte siamo alle porte del 2011 :D).
@andres: non ne so niente. Se trovi qualche link potresti passarlo, cortesemente? Così gli butto un occhio. Grazie. :)
Hai voluto tirare in ballo te la retrocompatibilità ed io mi sono limitato a far notare dove sarebbe ora di ridimensionarla. Poi per carità, non sta bene perchè in qualche modo snatura amiga os ?
Benissimo tieniti nel 2011 “ms dos con la freccetta rossa” tanto come stabilità siamo lì
@Cesare
l’ho letto in qualche commento nelle discussioni su AW.net, ora purtroppo non ho il tempo di ritrovarlo… cmq sono solo accenni, mi sembra parlassero supervisor e hypervisor, e da lì sono state fatte delle deduzioni…
Il problema della retrocompatibilità non mi sembra tale, basterebbe che il nuovo SO si appoggiasse a un sistema simile all’XP mode di Seven, totalmente trasparente all’utente.
Fatto questo è giusto che il SO si avvalga di tutti i ritrovati delle tecniche (multicore, protezione della memoria, virtualizzazione hardware e così via).
La questione ASMP vs SMP è interessante.
Fino ad poco tempo fa tutti i sistemi erano pensati per essere SMP, tranne negli ormai classici casi di divisione dei compiti tra elaborazione computazionale e quella grafica. Le nuove CPU hanno tutti multi core (2, 4, 6, 12…) pensati per funzionare in SMP.
Con l’arrivo del Cell di IBM e con il GPGPU è diventato chiaro che l’ASMP abbia vantaggi non indifferenti.
In primis la semplificazione della gestione delle risorse e il fatto che moduli specializzati in determinate operazioni e che non sono affetti dalla ridondanza di dover gestire un OS insieme ad altri “partecipanti” incrementi l’efficienza.
Un sistema come il Cell mette ancora più in evidenza la cosa: un chip relativamente piccolo ma con capacità di calcolo enormi e consumi ridotti (e non ha il problema della comunicazione tra CPU e GPU come con il GPGPU).
La possibilità di estendere le capacità elaborative in maniera indipendente da come si sviluppa la tecnologia del componente master e a seconda degli specifici usi è decisamente interessante.
Ovviamente il problema rimane l’omogeneità delle configurazioni, ma dato un minimo, le capacità di elaborazione possono essere espanse a dismisura.
Ovviamente tutti i problemi relative alla disomogeneità delle architetture potrebbe essere risolta a livello di librerie con funzioni messe a disposizione dall’OS (come lo era con AmigaOS verso il Blitter). In questo caso che dall’altra parte ci siano 8 o 32 SPU con o senza capacità di calcolo in double precision o una GPU o una semplice acceleratore 2D con diversa architettura non farebbe alcuna differenza.
L’idea di usare un sistema come l’RTG non solo per le operazioni grafiche ma anche per elaborazioni più complesse non sarebbe da scartare (vedesi quello che oggi offrono le OpenGL e DirectX).
Oggi tutte le modifiche e le espansioni alle architetture delle normali CPU x86 sono gestite direttamente in HW dalla CPU stessa, con relativo aumento della complessità di decodifica delle istruzioni e una generale diminuzione dell’efficienza delle aggiunte che richiedono espressamente la ricompilazione del codice. Con un sistema a librerie “indipendenti” la cosa porterebbe vantaggi in termini di possibilità di espansione decisamente migliori (e volendo a nessuno sarebbe comunque vietato di scrivere codice altamente specializzato per una determinata architettura con tutti i pro e i contro della cosa).
Solo che io preferisco un sistema ASMP “omogeneo”, con tutti i processori uguali o al limite della stessa famiglia.
Soprattutto mi piacciono le architetture semplici da programmare (non semplici di per sé).
Questo se devo lavorarci in assembly. In C o altri linguaggi ad alto livello non fa differenza.
@[D]: La retrocompatibilità l’ho citata perché è basata sul concetto “far girare le vecchie applicazioni”. Anche se scritte male, quindi.
Poi per me si può fare come col passaggio a Vista, ad esempio. Per cui se le vecchie applicazioni non funzionano semplicemente perché non sanno lavorare senza i privilegi di amministrazione (ad esempio), ce ne facciamo una ragione.
Per il resto AmigaOS è un s.o. fatto in un certo modo. Si può discutere su come aggiungere funzionalità moderne, ma riferendomi ad AROS, e come ho già detto, prima dev’essere completato perché non siamo ancora alla 1.0 final.
@andres: grazie lo stesso. :)
@Giacomo: questo già avviene tramite l’uso di WinUAE per far girare le vecchie applicazioni 68K.
@Cesare Di Mauro: Infatti, il mio discorso era precisamente legato a UAE e a Natami; eliminando il carico legato all’emulazione dell’HW (non più necessaria su Natami) si può creare una Sandbox che giri al massimo delle prestazioni, completamente integrata nel SO e quindi assolutamente invisibile all’utente. Con possibilità di implementare funzioni come il Copia&Incolla, condivisione del Filesystem etc. etc.
Così facendo si sgrava il lavoro degli sviluppatori del SO che possono più liberamente implementare nuove funzionalità relegando le gestione della retrocompatibilità nella Sandbox.
L’uso della virtualizzazione poi facilita anche la gestione del Multi Processing.
Però ne limiti le potenzialità. L’Amiga stesso era un insieme di coprocessori tutti con caratteristiche diverse (Blitter, Copper, Paula). Con l’aggiunta delle schede grafiche esterne si è aggiunto un nuovo “coprocessore”.
E non c’è motivo per cui aggiungere un altro componente con caratteristiche particolari (come un DSP della Texas) porti a particolari problemi.
E’ l’idea che sta poi alla base dei microcontrollori, dove esiste un core “standard” più o meno evoluto e una serie indefinita di periferiche con capacità diverse a seconda dell’esigenza.
Ovviamente un approccio alla Cell con una batteria di SPE omogenei non è un male. Ma come è si è visto potrebbero non bastare ed è stato necessario aggiungere una “normale” GPU per fare in maniera efficiente i calcoli di rasterizzazione sulla PS3.
Solo con un sistema così composto abbiamo 3 tipi di architetture differenti da programmare.
I vantaggi in termini di efficienza sono però indiscutibili.
Salve,
il discorso ASMP relativamente a coprocessori dedicati mi sembra “un po’ tirato” anche dal punto di vista teorico.
Comunque Amiga disponeva di coprocessori dalle buone prestazioni per il tempo in cui è stato presentato sul mercato e sicuramente con un rapporto qualità/prezzo molto conveniente… ma sicuramente non erano il top assoluto, ma semplicemente il top per la gamma home/personal.
Inoltre Amiga ha sicuramente portato il multitasking alle masse, ma non di certo i coprocessori, vorrei ricordare che già nel glorioso C64 (perciò in fascia home/personal della generazione precedente) c’erano il VICII e il SID che affiancavano il 6510 per grafica e musica rispettivamente… insomma “nulla di nuovo in casa Commodore!”.
La via dei coprocessori dedicati, perciò, era già stata intrapresa da molto tempo prima in ambito personal. E, nel modo in cui poni inizialmente la questione, si potrebbe addirittura comprendere le famose schede di espansione già abbondantemente presenti in Apple-II alla fine degli anni ’70.
Casi diversi sono le architetture multi-core ed, eventualmente, i transputer, che seppure già sviluppate in ambito mini e workstation (Apollo, HP e altri minori montavano più cpu e disponevano di coprocessori o intera circuiteria dedicata soprattutto alla grafica) anche negli anni di Amiga. Queste soluzioni sono state “presentate alle masse” anni più tardi (metà Novanta, a parte alle schede grafiche che erano diffuse già da prima). Una eccezione è il tentativo Atari con Abaq (e il OS Helios) basato sui transputers INMOS-T800… ma questi sono sicuramente argomenti da retroinformatica!
il problema di programmare architetture multicore (magari concorrenti) è di natura completamente diversa da quelle che sono le problematiche di programmazione per sistemi con più architetture (anche non omogenee). Perciò il discorso non si può affrontare in maniera univoca… dunque il problema è mal posto!
Ciao ciao
PS: come annotato la volta precedente, ringrazio per l’indicazione di A-EON.
Bello, interessante, stimolante… ma rappresenta sempre un timido avanzamento rispetto allo stadio precedente (A-ONE, PEGASOS) e sempre un passo indietro rispetto alla tecnologia oggi disponibile a basso costo… anzi, non voglio nemmeno sapere il prezzo per non deprimermi!
Ciao