di  -  mercoledì 9 febbraio 2011

Di Steve Jobs si può dire che sia sfacciato e cinico, ma certamente non che viva nel mondo dei sogni. E’ grazie al suo freddo, a volte spietato, pragmatismo che Apple è tornata a essere grande, a imporsi come status symbol, e i suoi prodotti a essere oggetto di venerazione nonché ispirazione o copia, nel bene o nel male che sia.

Soltanto grazie al suo enorme carisma e alla capacità di imporre le sue idee, la sua volontà, in maniera così convincente, Apple è riuscita in un’impresa che sembrava ridicola o, nella meno colorita delle ipotesi, disperata: il traghettamento di quella massa di fanatici integralisti dai PowerPC agli x86 di Intel.

In pochi minuti Jobs è riuscito a trasformare la delusione serpeggiante dei fedelissimi in uno smisurato tripudio per il nuovo, meraviglioso, corso che OS X aveva intrapreso, con una frase che rimarrà nella storia: “Il cuore del Mac è il sistema operativo più che l’hardware“.

D’altra parte non aveva scelta: i PowerPC avevano da tempo perso la leadership prestazionale, e nonostante i benchmark artefatti con cui Apple ne sbandierava ai quattro venti la superiorità, la verità non poteva più essere nascosta grazie anche alla rapida diffusione del web che in poco tempo metteva alla berlina questi tentativi.

Tanto che il passaggio al nuovo venne immediatamente suggellato con grafici che mostravano prestazioni fino a 4 volte superiori rispetto ai “vecchi” Mac, i quali, fino a quel momento, avevano potuto vantare velocità anche doppie rispetto ai PC. Misteri della matematica di casa Cupertino…

L’arrivo dell’architettura Pentium-M/Banias di Intel, che permetteva di ottenere anche consumi decisamente ridotti, è stato il colpo di grazia che ha indotto Jobs a una presa di coscienza sfociata poi alla dolorosa, ma necessaria, decisione.

Che il cuore del Mac fosse ormai OS X era piuttosto evidente da tempo, considerato che dal 1984 al 2005 (anno della svolta) gli elementi hardware distintivi dai PC si erano ridotti sostanzialmente al solo processore con annesso chipset dedicato: tutto il resto era stato man mano “importato” da un mondo odiato, ma che sicuramente faceva comodo.

Ciò che Jobs capì 6 anni fa, cioè l’inopportunità di proseguire con una famiglia di processori ormai non competitiva su tutti gli aspetti (anche quello economico), continua a non voler essere preso in considerazione o, meglio ancora, ignorato da una comunità ancora visceralmente legata al concetto di biodiversità, a trovare quindi un elemento (hardware) distintivo da tutto il resto.

Col fallimento della Commodore e l’arrivo delle nuove schede acceleratrici basate su PowerPC, l’Amiga (o, meglio, ciò che viene inteso con questa etichetta) sembra essersi legato indissolubilmente con questa famiglia di processori, in un connubio che non ha nulla di razionale, ma esclusivamente per fattori empatici e/o nostalgici (ma i nostalgici di lunga data ricordano ancora i 68000).

Aggrapparsi a un microprocessore non ha alcun senso, e questo già da parecchi anni. Fino alla prima metà degli anni ’90 programmare in assembly era una pratica abbastanza diffusa, con gli anni ’80 che hanno rappresentato un periodo d’oro, ma l’interesse è andato via via scemando a causa della sproporzione esistente fra i risultati e il tempo impiegato per ottenerli.

Oggi, infatti, l’uso di questo linguaggio è relegato in ambiti di nicchia dove, ad esempio, le risorse a disposizione sono troppo poche (ad esempio su microcontrollori di fascia bassa), in piccole parti del kernel e/o dei driver di un sistema operativo, o ancora per parti critiche di un’applicazione o gioco.

Perso il forte interesse verso questo linguaggio, automaticamente si perde anche quello per le caratteristiche intrinseche di un’architettura, e ci si concentra su fattori più pragmatici per la valutazione di una CPU: prestazioni, costo, consumi, dissipazione di calore, ed eventuali caratteristiche accessorie (presenza di un’unità SIMD o di una GPU integrata, ad esempio).

Preso atto della situazione non troppo felice discussa nel precedente articolo, ci si dovrebbero rimboccare le maniche e cercare una valida alternativa che consenta di spostare la comunità Amiga su una piattaforma hardware più conveniente sulla quale far girare AmigaOS & derivati per quello che, contrariamente ai pensieri e ai sogni di alcuni, non può avere velleità alcuna, se non quella di rappresentare un hobby.

Le risorse a disposizione purtroppo sono ben poche anche per le società che operano in questo settore, per cui bisognerebbe sfruttarle meglio e valorizzarle il più possibile.

Il team di MorphOS già da tempo non punta sull’hardware, ma preferisce attingere al mercato dell’usato, cioè le vecchie macchine Apple dotate di PowerPC che si trovano a buon mercato e offrono buone prestazioni allo scopo, specialmente in rapporto al costo d’acquisto. Al momento vengono supportati modelli dotati di G4, in attesa degli agognati G5 che dovrebbero riceverlo a breve. Dopo si troverà sostanzialmente in un vicolo cieco, non avendo altro hardware da sfruttare.

Hyperion col suo AmigaOS 4 punta, invece, su macchine nuove, come l’AmigaOne X1000 e la Sam 460 di cui abbiamo già parlato, ma per accaparrarsele bisogna spendere cifre in assoluto molto elevate a fronte di una dotazione hardware che può lasciare delle perplessità (com’è emerso anche dai commenti ai rispettivi articoli).

Inoltre l’X1000 non è ancora stato commercializzato, per cui bisognerà attende ancora qualche mese. Hyperion può continuare a supportare nuove macchine ovviamente, ma tutto dipenderà dai volumi, e il costo elevato rappresenta un forte deterrente nonché una restrizione del potenziale mercato.

L’unica realtà che si è smarcata dal legame con uno specifico hardware, ma che alle spalle non ha alcuna azienda affidandosi esclusivamente al tempo libero di alcuni sviluppatori, è AROS, che già da anni ha preferito puntare sugli x86, da tempo ne supporta anche l’evoluzione a 64 bit (AMD64) che rappresenta il futuro per quest’architettura, coprendo anche i PowerPC, con un bounty aperto per il supporto agli ARM, e con recente supporto ai 68000 che di giorno in giorno si fa sempre più concreto.

Passare da un’architettura a un’altra non è cosa semplice, ma non rappresenta nemmeno un’opera titanica. Fortunatamente i s.o. moderni sono scritti con un linguaggio ad alto livello (usualmente il C), e soltanto poche e piccolissime parti richiedono la scrittura di codice assembly, come già detto.

La documentazione a disposizione non manca di sicuro, e tra l’altro esistono molti progetti di s.o. (portati avanti anche da singole persone!) che girano su variegate architetture da cui si può prendere spunto o eventualmente anche pezzi di codice che possono facilitare la migrazione, driver e supporto alle periferiche inclusi.

MorphOS, ad esempio, adotta il medesimo stack USB di AROS, Poseidon, e non per questo il s.o. perde di valore. Reinventare la ruota, specialmente con le poche risorse su cui si può continuare, non è un demerito, ma al contrario una scelta ampiamente apprezzabile. Sarebbe, anzi, auspicabile una maggior collaborazione nella comunità Amiga, per ridurre la frammentazione e ottimizzare le risorse.

Portare il s.o. non è, comunque, l’unico dei problemi. Dopo il s.o. è ovvio che si dovrà pensare anche alle applicazioni già scritte, ma quante sono? Avrebbe senso sviluppare un emulatore (magari dotato di compilatore JIT) PowerPC per farle girare sul nuovo hardware? A mio avviso quest’ultima strada è troppo costosa in rapporto ai benefici ottenibili.

Parliamo, infatti, di applicazioni abbastanza recenti, per cui è più facile che siano a disposizione i sorgenti, o che comunque la società o il programmatore titolari siano in grado di ricompilarle fornendo degli eseguibili nativi. Il codice scritto bene generalmente non richiede altro che una ricompilazione, specialmente se la toolchain utilizzata è la stessa (quella GNU rappresenta praticamente lo standard di fatto per questi s.o.).

Un grosso scoglio è rappresentato, invece, dalla retrocompatibilità con le vecchie applicazioni 68000 per AmigaOS, sulla quale hanno puntato molto AmigaOS 4 e MorphOS, sfruttando ciascuno delle soluzioni proprietarie (Petunia e Trance) per integrarle in maniera trasparente a quelle native e, soprattutto, con ottime prestazioni che, sembra, si avvicinino molto a quelle PowerPC.

Petunia è scritto in assembly, per cui lo sforzo sarebbe notevole (a parte il fatto che l’autore non sembra interessato), e per Trance penso valga lo stesso, visto il tipo di “applicazione”. Ma anche pensando di non effettuarne il port, affidandosi quindi al solo strato di emulazione 68000, rimarrebbero due grossi problemi, uno immediato e un altro che è soltanto posticipato.

Il primo riguarda la cosiddetta endianess, cioè in che modo la CPU memorizza valori interi che richiedono più di un byte. I 68000 sono stati da sempre big-endian mentre gli x86 sono little-endian. Per le applicazioni native scritte secondo i canoni della buona programmazione, questo non è mai stato un problema, ma per il layer di emulazione adottato da AmigaOS 4 e MorphOS, invece lo è, ed è pure pesante.

Preciso che non si tratta di cattiva programmazione, come si potrebbe pensare da una superficiale lettura della frase, ma di una questione puramente contingente dovuta all’architettura adottata e al meccanismo messo in piedi per garantire la retrocompatibilità, unita a buona velocità d’esecuzione e integrazione con l’esistente (nativo).

Ciò avviene grazie a quelle che in gergo vengono chiamate trap (trappole). Un’applicazione 68000, infatti, gira all’interno di un ambiente che ricalca quello del vecchio AmigaOS, ma nel momento in cui effettua delle chiamate al s.o., queste vengono intercettate e smistate alle API native, quindi con codice PowerPC e beneficiando del nuovo ambiente.

Prendiamo per esempio l’API OpenScreen della libreria intuition.library:

il cui unico parametro è un puntatore a una struttura NewScreen:

Quando un’applicazione 68000 deve invocarla, alloca e riempie opportunamente una struttura di tipo NewScreen, e ne passa il puntatore all’API OpenLibrary.

MorphOS e AmigaOS 4 hanno inserito una trap all’indirizzo in cui si trova l’API OpenLibrary (lato 68000), che provvede a reindirizzare la chiamata alla versione nativa di OpenLibrary, che prende la struttura NewScreen e si occupa di portare effettivamente a termine l’operazione, ritornando poi il risultato all’applicazione 68000 (un puntatore alla struttura Screen, allocata e riempita opportunamente lato PowerPC / nuovo s.o.).

Questo meccanismo funziona benissimo fintanto che l’endianess dei due processori rimane la stessa, ma smette di funzionare in caso contrario. Infatti se il nuovo s.o. girasse su una macchina little-endian, tutti i campi di tipo WORD (e LONG) nonché i puntatori risulterebbero completamente errati, in quanto il codice 68000 li avrebbe riempiti memorizzando prima i byte più significativi fino a quelli meno significativi, mentre il processore “nativo” li leggerebbe esattamente al contrario (dal meno significativo al più significativo).

Come si può intuire, si tratta di un problema di difficile soluzione, e infatti al momento AROS non offre un layer di emulazione 68000 simile a quello di AmigaOS 4 e MorphOS.

Da questo punto di vista l’adozione di ARM quale architettura sulla quale far girare le nuove versioni di questi s.o. rappresenta la scelta migliore, in quanto è in grado di lavorare indifferentemente in modalità big-endian o little-endian.

Al momento non ci sarebbero consistenti vantaggi prestazionali rispetto ai PowerPC, ma sicuramente sul piano economico si tratta di soluzioni di gran lunga più abbordabili (basti pensare, ad esempio, ai tablet che arriveranno in massa a invadere il mercato).

In ogni caso anche l’adozione di ARM rimanderebbe di qualche anno la soluzione a questo problema, perché verrebbe riaperto col passaggio ai famigerati 64 bit (previsti nel 2015 per i nuovi ARM).

Infatti se l’endianess non porrebbe più grattacapi, i puntatori di dimensione doppia (8 byte anziché 4) ne presenterebbero altri non risolvibili (se non castrando lo spazio d’indirizzamento a 4GB totali, perdendo il beneficio principale del passaggio ai 64 bit).

Questo perché i puntatori lato 68000 rimarrebbero sempre a 32 bit, mentre quelli dell’architettura nativa sarebbero a 64 bit, che… non possono essere “compressi” o “ridotti” a 32 bit per essere utilizzabili nell’ambiente 68000. Discorso, questo, che si applica anche alle architetture PowerPC a 64 bit, ovviamente.

Si capisce bene, e concludo, come l’adozione di ARM o x86 come nuova architettura al momento (cioè finché non verrà tirata fuori il classico uovo di Colombo) pone davanti a una drastica scelta: barattare l’ottimo livello di retrocompatibilità raggiunto finora, con le migliori prestazioni (nonché quantitativi di memoria utilizzabili) di s.o. e applicazioni native.

Sarebbe interessante, a questo punto, conoscere l’opinione di chi ci lavora in merito agli argomenti trattati, e cosa ne pensano del futuro dei loro sistemi.

38 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
    Z80Fan
     scrive: 

    Mi ha sorpreso un po’ la lettura di questo articolo, perchè i problemi che tu citi come “di difficile soluzione” mi sembrano abbastanza semplici:

    – Endianess: prendendo a esempio proprio la struttura che hai indicato: il 68000 la riempie con dati big-endian, il gestore delle trap sa che quella è un’applicazione legacy, quindi semplicemente leggerà i dati e li invertirà per poi elaborarseli secondo i suoi metodi little-endian. Allo stesso modo, prima si scrivere i risultati per la nuova struttura, converte da little a big e ritorna al codice 68000 che si trova i dati corretti. Certo, è più lento di una soluzione nativa, ma non è impossibile come soluzione.

    – 64 bit: Ovviamente non possiamo pretendere che le applicazioni 68000 possano usare più dei 4 GB di memoria, ma questo non vuol dire che i 64 bit sono inutili o dannosi: tramite la memoria virtuale si mappano solo al massimo i 4Gb per un’applicazione a 32 bit, e il sistema operativo si prende cura di allocare dati solo in quella zona “bassa”. Le applicazioni native invece possono usare tutti i 64 bit. Se eventualmente il processore non ha modo di gestire puntatori di dimensione diversa dai 64 bit, semplicemente si legge i 32 bit inferiori azzerando i superiori.

    Come soluzioni mi sembrano molto semplici, evidentemente c’è qualche dato che mi sfugge…

  • # 2
    Massimo M
     scrive: 

    Anche io (sono un firmwarista) non vedo tutti questi grandi problemi.
    E’ vero, la storia di little endian-big endian è una rottura di scatole ma nel “porting” non è la cosa più complessa. E’ un problema che si può risolvere (ed almeno si conosce!).
    Anche io non programmo quasi più in Assembler, ma per ragioni di costi … e di sudore!
    Condivido pi ilproblema degli indirizzi. Anche qui il passare da 32 a 64 non è un semplice problema, ma risolvibile egregiamente tramite MMU o ricompilazione …
    Resto molto vago, lo sno e non voletemene. MA aspetto critiche costruttive.
    Grazie

  • # 3
    Alex
     scrive: 

    Mi sembra interessante il tono con cui affronti il discorso che l’hardware oggi come oggi non è più fondamentale rispetto ad un tempo. Ma anche dal punto di vista dei S.O. oggi non vedo grosse differenze e AmigaOS o qualunque altra cosa non mi emoziona per nulla. Oggi tutti i sistemi operativi utilizzano sempre la metafora del desktop magari chi meglio e chi peggio, ma dal punto di vista dell’esperienza siamo li. Insomma o si supera una volta e per sempre la metafora della scrivania, del desktop 2D o continueremo a parlare del nulla. Tanto alla fine quale sistema operativo non ci permette di leggere la posta, vedere un divx, ascoltare un mp3, etc…? Sono decenni che si promettono novità ma stiamo sempre li, invece l’attenzione si sta spostando verso S.O. per dispositivi variegati (cell, touch pad, etc..). Io vedo nel futuro un S.O. per ogni esigenza e magari l’uso di nuove periferiche come il touch, il kinect e varie varianti per farci lavorare meglio ed in modo più piacevole.

  • # 4
    Marco
     scrive: 

    Ma Rosetta che trasforma codice PowerPC in x86 per i binari non FAT sul Mac OS X? Sarebbe così difficile da implementare? Anche li c’è il problema di endianess e 64 bit (su MAC OS a 64 bit e applicazione power PC a 32 bit)… E il problema sembra sia stato risolto… Ci vorrebbe un JIT Rosetta-like, che supporti 68000, Power PC e x86 come input e almeno x86 32 e 64 e ARM come output… Con il solito schema Codice Legacy -> Codice Intermedio -> Codice Nativo, così se e quando arriverà una nuova architettura (ARM a 64 bit o un’altra architettura), basterà cambiare separatamente i 2 pezzi…

  • # 5
    makrov
     scrive: 

    non sembrano affatto problemi insormontabili, del resto come gia detto è inutile reinventare la ruota, e trattandosi di applicazioni tutto sommato “vecchie” e poco impegnative dal punto di vista computazionale per dei processori moderni (che siano x86_64 o ARM) si potrebbe usare parte del codice di Qemu per ricreare un clone virtuale dell’hardware (68000 in primis) e usarlo per eliminare i problemi di passaggio di architettura, tanto anche se su virtual machine saranno comunque piu veloci che su hardware originale, mentre per il porting di programmi nuovi il problema non si pone.
    capisco l’effetto nostalgia, ma non si puo sperare che powerPC o 68k tornino alla ribalta quando ormai sono relegati alla “nicchia” dei microcontroller (o delle console :P )

  • # 6
    sergio
     scrive: 

    Per mè la soluzione è quella alla Hyper-V di windows, cioè utilizzare delle sandbox di emulazione per le vecchie applicazioni 68000, basterebbe utilizzare UAE in maniera trasparente agli utenti, delegare a uae il passaggio dei dati in Clipboard, la possibilità di condividere il Filesystem e basta, le vecchie applicazioni non si avvarranno mai del nuovo HW (a parte i GHZ che comunque si sentirebbero) e delle nuove funzionalità del SO quindi è inutile cercare di integrarle all’interno del SO.

  • # 7
    Alessio Di Domizio
     scrive: 

    Anche a me pare che questo attaccamento “affettivo” per un’architettura CPU sia anacronistico e irrazionale, e porti a risultati molto meno che ottimali. Non sono certo un ammiratore di un’architettura evolutasi in maniera evolutiva da 30 anni a questa parte, e sono felice che l’alternativa ARM stia prendendo piede dove x86 non può arrivare. D’altronde PPC oggi è su un binario morto e anche ai tempi del G5 il gap che separava PPC da x86 era mi pare più che chiuso. Eppure molti “cultori” del marchio erano ancora fedeli alla linea “PPC o morte”; io stesso, nel 2005, decisi di comprare l’ultimo iBook G4 per verificare, dopo tre lustri di Intel/AMD, se ci fosse vita fuori da x86.
    Come ho già avuto modo di segnalare c’è tanta gente oggi che, senza sapere quel che dice, rimpiange i “veri Mac” castrati dal crescente rallentamento di PPC rispetto a x86 (oltre che da un OS sempre meno all’altezza). In questo senso il realismo di Jobs (che mentre siglava l’accordo con IBM per il G5 continuava a sviluppare OS X per Intel) è stato una salvezza.
    Un “reality check” ad Hyperion male non farebbe. Magari con la scelta di puntare tutto su ARM in un form factor compatto, pronto a migrare su formati mobile.

  • # 8
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’esempio che ho riportato nel pezzo è molto semplice e serviva soltanto a introdurre il problema.

    Riguardo al problema provocato dal diverso endianess, provate a immaginare una lista doppiamente linkata di strutture complesse (contenenti puntatori ad altre strutture, come tra l’altro appare nell’esempio), e capite bene che eseguire una copia cambiando l’ordine può diventare molto pesante (e a magari rischioso, se si incontra un ciclo).

    Inoltre c’è da considerare che AmigaOS come s.o. non offre alcuna protezione, per cui permette di poter accedere a qualunque zona di memoria. Ed è quello che fanno tante applicazioni.

    La copia da un’endianess a un’altra funzionerebbe esclusivamente se l’ambiente emulato e quello nativo avessero strutture completamente isolate, a compartimenti stagni.

    Riguardo ai 32 vs 64 bit, riservare soltanto la memoria bassa alle applicazioni 68000 implicherebbe che queste non possano accedere ai dati allocati da e per le applicazioni a 64 bit (o anche a strutture del s.o.), quindi sancendo di fatto una separazione dei due ambienti.

    Cosa succederebbe se un’applicazione a 64 bit allocasse una risorsa nella sua zona di memoria? Non potrebbe condividerla con quelle a 32 bit, per cui l’attuale e assoluta trasparenza fra applicazioni native e 68000 si perderebbe.

    Spero di aver chiarito la questione. Se ci sono dubbi, posso pensare a qualche altro esempio.

  • # 9
    MatteoC
     scrive: 

    Rispondo a Marco, commento 4:
    che io sappia l’unica ditta con una certa credibilità in fatto di traduttori dinamici in tempo reale di binari e con specifica attinenza alle piattaforme 68K/PPC/X86 era la Transitive Corp., ora acquisita da IBM e blindati i suoi prodotti all’interno dell’offerta di BigBlue.
    Sono quelli che fecero Rosetta per Apple se non vado errato.

    Per il resto, il sandboxing selvaggio mi pare una strada percorribile, ma non LA risposta, non LA soluzione.
    Devi comunque avere un’architettura all’orizzonte, devi poter parlare di “nativo” ed avere un certa presa, offrire qualcosa di preciso e non fumoso. Te la puoi cavare “nel frattempo” con sandboxing, con acceleratori SIMD per i bytecode e binari “veri” più svariati, roba tipo il Jazelle di ARM et similia… ma serve anche qualcosa di più concreto secondo me alla lunga.
    La prospettiva 64-bit per ARM c’è ed è concreta, ma non è nemmeno dietro l’angolo.

  • # 10
    [D]
     scrive: 

    Non riesco a capire tutti questi problemi riguardo la retrocompatibilità.
    Si tratta di far rinascere amiga su sistemi pc dotati di cpu e gpu infinitamente più potenti e veloci, il codice amiga per contro è nato per operare su cpu veramente misere, per cui che ci frega dell’emulazione jit dal momento che anche non utilizzandola si otterrebbero le stesse prestazioni o quanto meno roba fin troppo degna ?

    Prendo winuae e lo faccio girare dove voglio senza preoccuparmi un accidente dei 32 bit dei 64 bit, big endian, little endian: troppo difficile replicare questo altrove ?
    Tra l’altro se si considera che è possibile gestire i dischi amiga come directory qualunque e che su j-uae esistono già funzionalità di coerenza, risulta praticamente immediato avere la compatibilità che si cerca senza farsi tutto sto male.

    Ma poi, quand’è che la si smette di guardare indietro e si comincia a guardare nel senso giusto ?

    In ogni caso, quello che c’era da dire è stato detto, il risultato, il destino che spetta amiga al fondo del tunnel, è fin troppo chiaro. Chi vuole capire si darà una sonora svegliata e cercherà di cambiare le cose, gli altri che affoghino nel loro mare di stupidità e capricci. Com’è stato per linux e la comunità free, una lunga dose di sconfitte è servita a smussare almeno in parte fanatismi e balle varie e adesso finalmente qualcosa s’ingrana, anche ad amiga serve la stessa cura, ammesso che la chemio non l’accoppi definitivamente prima…

  • # 11
    Cesare Di Mauro (Autore del post)
     scrive: 

    UAE viene già utilizzato per garantire la totale retrocompatibilità, ma questi s.o. offrono molto di più che lanciare il vecchio AmigaOS e le vecchie applicazioni.

    Il loro valore aggiunto è rappresentato dalla totale integrazione delle vecchie applicazioni 68000 con le nuove, facendo girare tutto nel nuovo s.o. in maniera completamente trasparente.

    Giusto per essere chiari, le applicazioni 68000 hanno “pari dignità” di quelle PowerPC, ne condividono l’ambiente, possono interagire tutte fra di loro.

    Il rovescio della medaglia è che questo “ben di dio” crea i problemi di cui ho parlato e che sono di difficile soluzione.

  • # 12
    Dax
     scrive: 

    L’articolo pone buoni quesiti ed è ben redatto.

    Ingenerale vorrei solo far notare come ogni volta che si pone la question “x86″ port, sorgono (nei forum) 1000 facili soluzioni alle quali personaggi come Ralph Schmidt, Andreas Wolf, Hans.J.Frieden e Thomas Frieden (poveri pivelli sprovveduti) non sarebbero mai arrivati (sarcasmo ;-))
    Io dico che una lunga chiacchierata tecnica con tali individui potrebbe illuminare non poco chi di questi sistemi operativi, non ne puo per forza di cose capire altrettanto

  • # 13
    TheKaneB
     scrive: 

    @Dax: AROS gira su 4 architetture, il MOS team ha più volte detto che con l’architettura del loro OS il passaggio sarebbe relativamente veloce da farsi. Linux che in origine era pesantemente vincolato al 386 è stato portato in pochi anni su altre architetture e oggi ne supporta una ventina.

    Quindi o l’OS di Hyperion è scarso, oppure sono loro ad essere scarsi, o una combinazione lineare delle due cose. Oppure ancora, più probabile, non lo fanno per dei contorsionismi logici basati sul non voler “tradire” la fiducia dei clienti così visceralmente e psicologicamente vincolati al PowerPC (non si sa per quale motivo, visto che Amiga quando è morta nel 93 ancora aveva il 68k…)

  • # 14
    Wilfrick
     scrive: 

    Non sono tecnico e non posso capire tutte queste cose di codici, ecc. C’è però una questione più pratica che mi sembra assurda.
    Cosa può interessare fare coesistere ed interagire applicazioni x86 o x64 con applicazioni 68xxx p PPC? C’è qualcuno che su PC moderno tiene in esecuzione un software nuovo insieme ad uno di 20 anni fa? Cioè il problema, se capisco giusto, è che posso avere “problemi” se mentre il comp. mi sta facendo un rendering unbiased sfruttando quasi tutta la CPU e GPU, o convertendo un video in HD (tanto per dire due cose che vengono fatte recentemente), io non posso giocare a S.of the beast perchè si può incriccare tutto? E sono troppo fighetto per rifiutarmi di volerlo (il gioco) lanciare in uae perchè lo pretendo in esecuzione nativa? Oppure voglio che SCALA MM mi elabori delle immagini che contemporaneamente sta sistemando un batch di photoshop? (ammesso per assurdo che scala riesca ad aprire e gestire file con le caratteristiche richieste oggigiorno) Non so… mi sembra come volere usare una BMW nuova con un carburatore anni 80: o si fa uno o l’altro: tutti i giorni, per lavoro, la bmw e la domenica, per sfizio, ci si prende la ritmo cabrio per fare un giro tamarro (e sudare come bestie perchè manca l’aria condizionata, il sedile è scomodo, ecc ecc ecc… perchè poi si notano tutte le differenze).
    forse sbaglio e non ho capito di cosa si stia parlando…

  • # 15
    alex del viero
     scrive: 

    Articolo interessante.
    Io sarei per “zero compatibilità”!
    Ma se mettiamo questo nuovo OS su un quadcore da 3 ghz veramente
    vogliamo farci girare i giochini a 64 colori o deluxe paint in ham?
    Si deve pensare a una nuova serie di applicativi adatti all’HW
    su cui girano.
    Iniziamo dai classici dell’opensource tipo gimp,libreoffice, firefox ecc…
    Per i nostalgici ci sara’ sempre uae.

  • # 16
    Dax
     scrive: 

    @TheKaneB
    Non credo che sia quello il problema, ed è interesse massimo degli sviluppatori MOS vendere meglio su x86 se potessero (ma non vi è in corso nessun facilissimo port).
    Aros è un concetto che piace ad alcuni e ad altri no, è gratis e gira su X86, eppure c’è chi spende 100 euro per comprare sistemi operativi Amiga che gratis non sono, probabilmente, non tutti amano lo stesso paradigma.

  • # 17
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sì, questo è scontato, ma TheKaneB si riferiva agli eventuali problemi di port su altre architetture, e da questo punto di vista ha perfettamente ragione.

    Tra l’altro questi AmigaOS hanno una struttura di gran lunga più semplice rispetto a un s.o. moderno, per cui l’operazione è sicuramente facilitata.

    @Wilfrick: giochi come Shadow of the Beast, che usano direttamente l’hardware, vengono fatti girare dentro una versione di UAE, per forza di cose perché non si possono “sposare” col s.o. nativo.

    L’idea di far convivere applicazioni vecchie e nuove non è una forzatura, ma una cosa molto positiva.

    Immagina di essere affezionato a un’applicazione di cui non esiste il port per uno di questi s.o.: la puoi usare tranquillamente come se girasse sul vecchio AmigaOS, col vantaggio di poter sfruttare ciò che di buono c’è in quello nuovo (ad esempio hard disk SATA e porte USB) e, inoltre, può comunicare con le altre applicazioni native come se fosse una di loro.

    Non è che un’applicazione, per quanto vecchia, sia da buttare. Ne esistono di molto interessanti, ed è per questo che ancora oggi le si usa.

    @alex del viero: UAE c’è già e funziona bene (specialmente WinUAE), ma non è questo il punto. Vedi la mia risposta a Wilfrick. ;)

  • # 18
    Z80Fan
     scrive: 

    @Cesare #8

    “Inoltre c’è da considerare che AmigaOS come s.o. non offre alcuna protezione, per cui permette di poter accedere a qualunque zona di memoria. Ed è quello che fanno tante applicazioni.

    La copia da un’endianess a un’altra funzionerebbe esclusivamente se l’ambiente emulato e quello nativo avessero strutture completamente isolate, a compartimenti stagni.”

    Nell’AmigaOS di un tempo ok, ma vuoi dirmi che gli AmigaOS “moderni” non hanno una banale memoria virtuale? Si permette anche alle applicazioni native di accedere alla memoria delle altre?

    “Cosa succederebbe se un’applicazione a 64 bit allocasse una risorsa nella sua zona di memoria? Non potrebbe condividerla con quelle a 32 bit, per cui l’attuale e assoluta trasparenza fra applicazioni native e 68000 si perderebbe.”
    Si mappa la pagina di memoria comune dallo spazio alto dell’applicazione natica nello spazio basso dell’applicazione 68k.

  • # 19
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sì, ma rimandi il problema a quando si esaurirà lo spazio d’indirizzamento a 32 bit. Il nocciolo della questione è che, a un certo punto, una zona di memoria allocata da un’applicazione a 64 bit sarà impossibile da mappare nello spazio d’indirizzamento a 32 bit accessibile dalle sole applicazioni 68000.

    Visto che lo spazio d’indirizzamento è comune (ne parlo meglio sotto), si potrebbe risparmiare qualcosa evitando di mappare le pagine di codice a 64 bit (e forse anche lo stack), ma in ogni caso i dati dovrebbero essere mappati sempre nello spazio a 32 bit.

    Riguardo alle domande precedenti, la risposta è sì: le applicazioni 68000 possono accedere alla memoria delle altre. Anzi, in generale, qualunque applicazione può accedere a qualunque zona di memoria, inclusa quella del s.o..

    AmigaOS4 adotta qualche misura addizionale (protegge in sola lettura le zone di memoria caricate come codice, se non ricordo male), ma sostanzialmente la situazione è quella: unico spazio d’indirizzamento per s.o. e applicazioni, con piena libertà di accesso. E tutto che viene eseguito in usermode (tranne, ovviamente, il codice degli handler per eccezioni, interrupt, trap).

    Ecco perché si presentano i problemi di cui parlavo prima riguardo a un cambio di endianess: la memoria è condivisa da tutti e per tutto.

  • # 20
    [D]
     scrive: 

    “Il rovescio della medaglia è che questo “ben di dio” crea i problemi di cui ho parlato e che sono di difficile soluzione.”

    Sono programmi vecchi, molto vecchi e basta.
    Limitano in modo esasperante qualsiasi evoluzione futura: la memoria protetta non c’è grazie a loro, il supporto multiprocessore (oramai comune con i processori multicore) idem con patate, qualsiasi implementazione di sicurezza non parliamone neppure.

    Tutta sta roba dev’essere forzata a girare attraverso uae e SOLO attraverso UAE.

    “Giusto per essere chiari, le applicazioni 68000 hanno “pari dignità” di quelle PowerPC, ne condividono l’ambiente, possono interagire tutte fra di loro.”

    Siamo veramente chiari: il prezzo di questa pari dignità sono dei sistemi semplicemente indegni di potersi presentare a testa alta al di fuori del loro piccolo mondo perfetto, quanto morente.

    Anche Windows era tanto orgoglioso della propria retrocompatibilità ed il prezzo che ha dovuto pagare, anzi che abbiamo noi utenti dovuto pagare è stata una storia infinita di bug, a volte pure storici, che aprivano falle nei meandri più assurdi del sistema. Mi immagino un hacker davanti un sistema amiga (originale o like), letteralmente godere della possibilità di mandare tutto a gambe all’aria riciclando metodologie più antiche di winnuke.

  • # 21
    Cesare Di Mauro (Autore del post)
     scrive: 

    Il problema non è rappresentato dai programmi, ma dal s.o..

    Che un’applicazione richiami un’API del s.o., non fa alcuna differenza che sia 68000 o PowerPC.

    Il s.o. è lì messo apposta per astrarre dall’hardware e fornire un ambiente di più alto livello con esposti dei “servizi”.

    I problemi sorgono principalmente quando, a causa dell’estrema apertura di AmigaOS, alcune applicazioni non proprio pulite ne approfittano per accedere alle strutture del s.o. o, in generale, a informazioni che non dovrebbero toccare.

    Questo vale sia per le applicazioni 68000 che PowerPC, visto che qualunque di esse potrebbe potenzialmente far danni.

    Bisognerebbe vedere un po’ quali di esse sono “pericolose”. A mio avviso non dovrebbero essere molte, perché l’avvento di AmigaOS 2.0 prima, e del 3.0 poi, ha “messo in riga” tanti sviluppatori che avevano fatto delle porcate, e che per veder girare i loro programmi su qualunque macchina sono stati costretti a scrivere codice più pulito.

  • # 22
    [D]
     scrive: 

    “A mio avviso non dovrebbero essere molte, perché l’avvento di AmigaOS 2.0 prima, e del 3.0 poi, ha “messo in riga” tanti sviluppatori che avevano fatto delle porcate, e che per veder girare i loro programmi su qualunque macchina sono stati costretti a scrivere codice più pulito.”

    Eppure, più di qualcosa continua a non tornare. Per quanto si vogliano tirare in ballo certi spiriti di protezionismo da parte di Hyperion nei confronti dei capricci di certi nostalgici, non credo proprio che la mancanza della memoria protetta sia determinata da questo.
    Per me bisogna avere il coraggio di darci un taglio, relegando alla peggio il tutto ad un emulatore. La “pari dignità” al prezzo attuale non ha senso di esistere perchè, lo vediamo con winuae, è già possibile garantire una “comunicazione” da parte di questi programmi verso l’esterno.
    Winuae può connettere i programmi amiga alla rete attraverso la bsdsocket.library, monta tutte le unità esterne che si vogliono (dischi rigidi ide e scsi, cd, dvd, chiavette usb), permette ai programmi di stampare, usare porte parallele, seriali, midi e tutto questo senza compromettere la stabilità di windows quando misterprogramminodeininety crashava eventualmente abbattendo l’amiga os emulato.
    Proprio non capisco cosa manchi per far felici tutti quanti.
    Una eventuale porta arexx ? Sono sicuro che basta farlo notare allo sviluppatore dell’emulatore ed entro un paio di release comincerà a spuntare fuori anche qualcosa di quel tipo.

    Qui è solo una questione di capriccio, di sbattere il testone contro il muro e continuare a spingere nella vana speranza che crolli o si smuova anche solo di un millimetro in modo da giustificare la sensatezza dell’idea invece della sua follia.

    Apple nella sua vita ha cambiato ben tre architetture ed ogni volte le ha affrontate inserendo un emulatore giusto il tempo necessario a garantire un passaggio indolore e poi via, basta con i rimpianti.

    Qua invece le cose paiono addirittura che se amiga fosse un’evoluzione del c64, dovremmo fare i conti anche con un emulatore jit del 6502 ed ovviamente tutte le sue problematiche, tutti i suoi limiti e tutti i freni che porrebbe al resto del mondo.

    Dai, una cosa del genere non può andare avanti…

  • # 23
    Z80Fan
     scrive: 

    Sono d’accordo con [D].

    “Sì, ma rimandi il problema a quando si esaurirà lo spazio d’indirizzamento a 32 bit”
    Quanta memoria al massimo ha un Amiga “classic” completamente caricato? 8 Mega? 16 Mega? Addirittura 32 Mega? Non pensi che per un’applicazione legacy sia un po’ difficile arrivare a saturare tutto lo spazio di indirizzamento?
    Probabilmente la suddetta applicazione andrà in crash prima perchè il programmatore aveva pensato bene di usare il quarto byte di un indirizzo come dati, tanto il bus è solo a 24bit…

    “AmigaOS4 adotta qualche misura addizionale (protegge in sola lettura le zone di memoria caricate come codice, se non ricordo male), ma sostanzialmente la situazione è quella: unico spazio d’indirizzamento per s.o. e applicazioni, con piena libertà di accesso.”

    Anche nell’85 penso che questa non fosse una feature, ma un limite del 68000 che non poteva proteggere la memoria. Pensi che abbiano programmato AmigaOS apposta in modo che le applicazioni andassero a trafficare con le strutture di sistema?
    Ora che abbiamo a disposizione la protezione della memoria, dobbiamo scrivere TUTTO il sistema operativo per rifarci a quella limitazione, anche con i programmi nuovi?

    “I problemi sorgono principalmente quando, a causa dell’estrema apertura di AmigaOS, alcune applicazioni non proprio pulite ne approfittano per accedere alle strutture del s.o. o, in generale, a informazioni che non dovrebbero toccare.”
    Appunto non devono toccare, e se ci provano, le si blocca.
    Visto che della retrocompatibilità nativa non si può fare a meno, si fa così: la zona di memoria dove un tempo c’erano le strutture di sistema, la si imposta come non scrivibile. Quando un’app legacy tenta di scrivere, il gestore della trap riconosce che è un’app legacy, gli lascia scrivere i dati e si memorizza da qualche parte che l’app ha modificato la pagina. Al successivo task-switch, il s.o. legge le modifiche fatte, aggiorna le vere tabelle interne, e risetta la pagina come non scrivibile. Ovviamente solo per le app 68000, quelle native vengono bloccate senza pietà.

  • # 24
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Z80Fan:

    Quanta memoria al massimo ha un Amiga “classic” completamente caricato? 8 Mega? 16 Mega? Addirittura 32 Mega? Non pensi che per un’applicazione legacy sia un po’ difficile arrivare a saturare tutto lo spazio di indirizzamento?

    Non se manipola immagini o video, ad esempio.

    Ma il punto non riguarda tanto le applicazioni 68000, che sono già da sé limitate a 2GB di spazio d’indirizzamento, quanto quelle a 64 bit: sono le loro pagine di dati a dover essere mappate in quello a 32 bit, ma se si usa un’architettura a 64 bit generalmente è perché si vuole sfondare la barriera dei 4GB. Questo sempre per i dati (ho difficoltà a pensare a più di 4GB occupati soltanto dal codice :D).

    Probabilmente la suddetta applicazione andrà in crash prima perchè il programmatore aveva pensato bene di usare il quarto byte di un indirizzo come dati, tanto il bus è solo a 24bit…

    Sono poche e rare quelle che lo facevano. In particolare, erano le prime applicazioni, come AmigaBASIC, ad esempio.

    E alcuni giochi, ma quelli non fanno testo perché di integrarli col s.o. non se ne parla assolutamente, e in ogni caso non ce ne sarebbe bisogno.

    Anche nell’85 penso che questa non fosse una feature, ma un limite del 68000 che non poteva proteggere la memoria.

    Certamente, ma il 68000 poteva pur sempre lavorare in modalità supervisore o utente, quindi almeno il kernel avrebbe potuto girare in supervisor mode. Invece AmigaOS gira sempre in usermode (tranne per i casi che ho citato).

    Tra l’altro il 68000 comunica sempre all’esterno in che modalità sta girando, e se sta eseguendo fetch di codice o di dati, per cui sarebbe stato possibile separare fisicamente gli spazi d’indirizzamento di kernel e applicazioni (al prezzo di qualche complicazione gestibile con logica esterna). Ma non fu fatto, appunto.

    Certo, la soluzione migliore sarebbe stata quella di adottare il 68010, ma era più costoso, e comunque lo sviluppo del s.o. avrebbe richiesto molto più tempo (per arrivare a presentare Amiga non hai idea delle “corse” che si fece il team).

    Pensi che abbiano programmato AmigaOS apposta in modo che le applicazioni andassero a trafficare con le strutture di sistema?

    Purtroppo sì: le strutture di sistema sono liberamente accessibili, e anche ben documentate.

    Inoltre per disabilitare il multitasking Commodore mise a disposizione, oltre a un’API del s.o., una macro che accedeva direttamente al campo che ne teneva traccia.

    Questa scelta infausta è alla base dei problemi che si hanno per introdurre l’SMP.

    Ora che abbiamo a disposizione la protezione della memoria, dobbiamo scrivere TUTTO il sistema operativo per rifarci a quella limitazione, anche con i programmi nuovi?

    Direi proprio di no. D’altra parte un’applicazione nuova dovrà seguire delle nuove linee guida.

    Appunto non devono toccare, e se ci provano, le si blocca.
    Visto che della retrocompatibilità nativa non si può fare a meno, si fa così: la zona di memoria dove un tempo c’erano le strutture di sistema, la si imposta come non scrivibile. Quando un’app legacy tenta di scrivere, il gestore della trap riconosce che è un’app legacy, gli lascia scrivere i dati e si memorizza da qualche parte che l’app ha modificato la pagina. Al successivo task-switch, il s.o. legge le modifiche fatte, aggiorna le vere tabelle interne, e risetta la pagina come non scrivibile. Ovviamente solo per le app 68000, quelle native vengono bloccate senza pietà.

    E’ quel che penso anch’io, ma sono più drastico: quelle strutture non gliele farei modificare del tutto.

    Per me della retrocompatibilità a tutti i costi se ne può fare a meno, e qui mi riallaccio al commento di [D]. Se serve utilizzare qualche applicazione “sporca”, la si fa girare con (Win)UAE.

    Quelle “pulite” per me hanno pari dignità di quelle native, perché se fanno ricorso esclusivamente alle API del s.o., e al più leggono soltanto alcune strutture del s.o., per me possono girare senza problemi.

    In ogni caso il problema rimane la differenza di endianess in primis, e poi i 64 bit.

  • # 25
    alex del viero
     scrive: 

    Rimango dell’opinione che se si vuol fare qualcosa di realemnte interessante si deve fare tavola rasa.
    Ripartiamo mantenendo i concetti di base Amiga.
    Partirei sviluppando direttamente a 64bit… tanto per quando sarà pronta la prima beta i 64bit saranno la norma anche sui cellulari! :D

  • # 26
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non serve far tabula rasa. E’ sufficiente mettere dei paletti.

    AROS, ad esempio, garantisce soltanto la compatibilità con le vecchie applicazioni a livello di sorgente, non a livello binario (tranne per le versioni 68000).

    Si potrebbero aggiungere altri vincoli, come quelli esposti prima: niente accesso alle strutture private del s.o., o al limite a sola lettura (per alcune).

    Altra cosa, bisognerebbe “opacizzare” alcune strutture, cioè non rendere disponibili le informazioni (tutte o alcune) su come sono costituite internamente.

    L’information hiding è molto importante per garantire più sicurezza ma, soprattutto, la possibilità di poter effettuare delle modifiche anche radicali all’implementazione di un s.o. senza che ciò comporti problemi alle applicazioni esistenti.

  • # 27
    Mabo
     scrive: 

    **** COMMENTO OFFENSIVO MODERATO ****

  • # 28
    divina
     scrive: 

    @Dax scrive: //Non credo che sia quello il problema, ed è interesse massimo degli sviluppatori MOS vendere meglio su x86 se potessero (ma non vi è in corso nessun facilissimo port).

    Più volte è stato fatto intendere dal MoprhOS team un futuro eventuale supporto della architettura x86/x64, tuttavia loro non hanno alcuna premura in tal senso, anzi hanno in mano un parco hardware PowerPC G4 e G5 immenso, infinito per le loro esigenze, e come hai visto mano mano aggiungono nuove postazioni come supporto al loro OS :-)
    Se nel tempo vi sarà (per qualche “miracolo”) un prodotto PowerPc valido, moderno, competitivo, lo valuteranno in caso contrario, la strata da seguire è scontata (leggi qualche riga sopra)

  • # 29
    Z80Fan
     scrive: 

    @Cesare:

    ” Ma il punto non riguarda tanto le applicazioni 68000, che sono già da sé limitate a 2GB di spazio d’indirizzamento, quanto quelle a 64 bit: sono le loro pagine di dati a dover essere mappate in quello a 32 bit, ma se si usa un’architettura a 64 bit generalmente è perché si vuole sfondare la barriera dei 4GB. Questo sempre per i dati (ho difficoltà a pensare a più di 4GB occupati soltanto dal codice :D). ”

    Ma anche se una pagina di dati è mappata ad un indirizzo superiore in un’app 64 bit, si può sempre mappare in un indirizzo basso per un’app 68000, è questo il vantaggio della memoria virtuale.
    Il problema al massimo è quando un’app 64 bit vuole condividere più di 2 Gb con un’app 68000… ma, realisticamente, è probabile questa situazione? Come è probabile che qualcuno voglia editare un’immagine da 1Gb con un’applicazione legacy…

    “Certamente, ma il 68000 poteva pur sempre lavorare in modalità supervisore o utente, quindi almeno il kernel avrebbe potuto girare in supervisor mode. Invece AmigaOS gira sempre in usermode (tranne per i casi che ho citato).”

    Wikipedia indica che AmigaOS è un tipo di microkernel (picokernel ma l’idea è la stessa), quindi è normale che faccia così. Il problema in questo caso è che anche un’app usermode può modificare la memoria del sistema, quindi è come se la suddivisine non ci fosse.

    ” Tra l’altro il 68000 comunica sempre all’esterno in che modalità sta girando, e se sta eseguendo fetch di codice o di dati, per cui sarebbe stato possibile separare fisicamente gli spazi d’indirizzamento di kernel e applicazioni (al prezzo di qualche complicazione gestibile con logica esterna). Ma non fu fatto, appunto. ”

    Sicuramente non per volontà dei progettisti.

    “Certo, la soluzione migliore sarebbe stata quella di adottare il 68010, ma era più costoso, e comunque lo sviluppo del s.o. avrebbe richiesto molto più tempo (per arrivare a presentare Amiga non hai idea delle “corse” che si fece il team).”

    Appunto.

    “Purtroppo sì: le strutture di sistema sono liberamente accessibili, e anche ben documentate.

    Inoltre per disabilitare il multitasking Commodore mise a disposizione, oltre a un’API del s.o., una macro che accedeva direttamente al campo che ne teneva traccia.

    Questa scelta infausta è alla base dei problemi che si hanno per introdurre l’SMP.”

    Già, è una scelta triste, ma per ottenere le massime prestazioni era necessario (almeno prima di provare a prendere il controllo dell’intero sistema, presumo)

    ” E’ quel che penso anch’io, ma sono più drastico: quelle strutture non gliele farei modificare del tutto.

    Per me della retrocompatibilità a tutti i costi se ne può fare a meno, e qui mi riallaccio al commento di [D]. Se serve utilizzare qualche applicazione “sporca”, la si fa girare con (Win)UAE.

    Quelle “pulite” per me hanno pari dignità di quelle native, perché se fanno ricorso esclusivamente alle API del s.o., e al più leggono soltanto alcune strutture del s.o., per me possono girare senza problemi.

    In ogni caso il problema rimane la differenza di endianess in primis, e poi i 64 bit. ”

    Secondo me si riescono a usare tutte allo stesso modo. Le strutture di sistema accessibili alle app 68000 ovviamente saranno fittizie, generate dal sistema ogni volta che l’applicazione cerca di leggere i dati. E poichè sono generate appositamente, non c’è un problema di endianess.

    Il sistema potrebbe anche avere 2 livelli di simulazione: un’app viene avviata con emulazione “debole”, che sarebbe quello per le applicazioni “pulite”. Finchè un’app legge e basta le strutture, ok. Appena un’app prova a scrivere le strutture o nella zona di I/O, si passa all’emulazione “forte”, equivalente ad un emulatore apposito. Il sistema può tenersi una blacklist delle applicazioni “sporche” in modo da avviarle sempre in emulazione “forte”.

    Oppure ancora si può provedere ad una specie di paravirtualizzazione, con un AmigaOS legacy che interagisce con AmigaOS4 tramite appositi driver. In questo caso l’emulazione è sempre forte, e un’apposito manager gestisce la condivisione di dati tra più istanze delle macchine. Se un’istanza trova un’applicazione sporca, il manager la separa dalle altre.

    Ovviamente non so di preciso quali api sono esposte dall’amigaos e quali strutture vanno emulate, quindi questi ragionamenti potrebbero essere del tutto inutili :)

  • # 30
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Z80Fan:

    Ma anche se una pagina di dati è mappata ad un indirizzo superiore in un’app 64 bit, si può sempre mappare in un indirizzo basso per un’app 68000, è questo il vantaggio della memoria virtuale.

    Questo lo so, e infatti non ho nulla da dire su questo.

    Il problema al massimo è quando un’app 64 bit vuole condividere più di 2 Gb con un’app 68000… ma, realisticamente, è probabile questa situazione?

    Considera che non si tratta dei dati di una sola applicazione, ma di tutti i dati di tutte le applicazioni che dovrebbero essere visibili tanto nello spazio d’indirizzamento a 64 bit che in quello a 32 bit.

    Come è probabile che qualcuno voglia editare un’immagine da 1Gb con un’applicazione legacy…

    Non vedo perché no. Già ai tempi dell’Amiga 4000 si vedevano macchine dotate di ben 128MB di ram (all’epoca!!!).

    Ricorda che su Amiga sono nati programmi di modellazione e rendering 3D, nonché di disegno, fotoritocco, e animazioni. ;)

    Già, è una scelta triste, ma per ottenere le massime prestazioni era necessario (almeno prima di provare a prendere il controllo dell’intero sistema, presumo)

    Per le mie applicazioni ho sempre chiamato l’API Forbid prima di prendere il controllo della macchina. D’altra parte la chiamata era secca: lo facevo una sola volta e basta.

    Non so se ci sono stati casi in cui la chiamata all’API era frequente, ma in ogni caso il costo della chiamata a Forbid non era elevato, e si poteva benissimo evitare di far ricorso alla macro o, peggio ancora, di andare a scrivere direttamente quel campo.

    Secondo me si riescono a usare tutte allo stesso modo. Le strutture di sistema accessibili alle app 68000 ovviamente saranno fittizie, generate dal sistema ogni volta che l’applicazione cerca di leggere i dati. E poichè sono generate appositamente, non c’è un problema di endianess.

    Non è fattibile perché non si tratta di banali strutture, ma, al contrario, possono essere anche molto complicate, facendo uso di liste doppiamente concatenate, e col rischio di trovarsi di fronte a dei cicli. Come dicevo prima.

    Il sistema potrebbe anche avere 2 livelli di simulazione: un’app viene avviata con emulazione “debole”, che sarebbe quello per le applicazioni “pulite”. Finchè un’app legge e basta le strutture, ok. Appena un’app prova a scrivere le strutture o nella zona di I/O, si passa all’emulazione “forte”, equivalente ad un emulatore apposito. Il sistema può tenersi una blacklist delle applicazioni “sporche” in modo da avviarle sempre in emulazione “forte”.

    Oppure ancora si può provedere ad una specie di paravirtualizzazione, con un AmigaOS legacy che interagisce con AmigaOS4 tramite appositi driver. In questo caso l’emulazione è sempre forte, e un’apposito manager gestisce la condivisione di dati tra più istanze delle macchine. Se un’istanza trova un’applicazione sporca, il manager la separa dalle altre.

    Sì, è una cosa che fanno già in parte gli emulatori dotati di JIT di AmigaOS 4 e MorphOS.

    Ovviamente non so di preciso quali api sono esposte dall’amigaos e quali strutture vanno emulate, quindi questi ragionamenti potrebbero essere del tutto inutili :)

    Se consideri che raramente c’erano delle API di “Get” per recuperare i valori, ma si faceva diretto accesso alle strutture, puoi renderti conto del livello di coesione esistente fra le applicazioni e il s.o..

    Comunque pensare a un s.o. moderno, ispirato ad AmigaOS, è possibile, ma non so se ne valga la pena.

  • # 31
    Wilfrick
     scrive: 

    Scusa Cesare, sono sempre daccordo con te, ma qui ti devo fare un appunto perchè mi sembra che stai forzando la mano in sostegno di una tesi che non è “sostenibile” a livello pratico (siamo realisti…).
    Nel 1994 avevo (ed ho tuttora) uno studio grafico, facevano uso esclusivamente di Amiga 4000, per grafica 3D. Avevo iniziato anni prima su amiga 500… ed i primi lavori erano prorpio con il 500… a pensarci adesso è roba da matti, ma era così. Eravamo fra i pochissimi nel ’93 a fare uso di lightwave 3d su amiga, quando esisteva solo in ntsc, negli stati uniti, legato al videotoaster. Questo per dirti che è vero che potenzialmente potrebbe esserci un’applicazione che edita un’immagine da 1 giga, ma realisticamente nessuno mai lo farebbe, semplicemente perchè tutti i sw si sono evoluti e nessuno, ma davvero nessuno, andrebbe ad ediotare una qualsiasi cosa con una versione di software di 20 anni fa….. Cioè, anche potendolo fare non lo si farebbe: perchè usare artdepartment quando hai photoshop5? Un conto è voler giocare ad un game del ’90 (dove lo scopo è il game stesso), un conto è usare un sw di editing, di 3d o di qualsiasi altra cosa si voglia per giungere ad un risultato finalizzato ad ottenere un prodotto: il fine ultimo non è l’utilizzo del software, ma il prodotto finale (foto, video, grafica…), pertanto chiunque andrebbe ad usare il sw più “moderno” e che offre le maggiori potenzialità.
    Pertanto Z80 ha ragione quando dice che nessuno userebbe un sw legacy per editare un’immagine da 1 giga. Tu dici “non vedo il perchè”… te l’ho spiegato io sopra e ti aggiungo che se uno volesse farlo per la gloria di rivivere quelle emozioni allora non edita un’immagine da un giga semplicemente perchè con il 4000, pompato come vuoi, non lo si poteva fare, quindi o usa sw moderni oppure si va ad editare un’immaginina da 1024×768 in ham8 (ora non ricordo nemmeno se il 4000 reggeva quella risoluzione in ham8).
    E’ vero che “potenzialmente” si potrebbe fare (su una macchina con 3 giga, hd veloci, processore nuovo, ecc ecc.) e quindi tu vorresti tutto perfetto a puntino, ma è la stessa cosa di “potenzialmente” una 500 degli anni ’60 può fare il giro del mondo: in realtà non arrivi nemmeno a roma perchè cola il motore, almeno che di andare a 50kmh fermandoti ogni 30 minuti, ma passate due ore di guida torni indietro e ti prendi l’aereo. Quindi, in sostanza, nessuno consumerebbe 2 giga con applicazioni di 20 anni fa perchè è un suicidio celebrale… pertanto non ci sarebbero problemi a mettere tutti i paletti che si vuole (che avete perfettamente elencato e spiegato voi).
    Ciao

  • # 32
    Wilfrick
     scrive: 

    p.s. scusa per gli errori grammaticali ma sono fuso…

  • # 33
    Cesare Di Mauro (Autore del post)
     scrive: 

    Figurati: io ne commetto a valanga. Siamo esseri umani. :D

    OK, siamo seri: difficilmente qualcuno lo farà, anche se ti assicuro che c’è gente che continua a utilizzare le applicazioni 68000 anche sui nuovi s.o., perché non c’è un port per il sistema nativo o semplicemente sono abituati a quell’interfaccia pur esistendo delle applicazioni native per fare le stesse cose.

    Ma mettiamo che tutto ciò sia irrilevante / trascurabile.

    Rimane il problema tecnico di dover mappare tutta la memoria allocata per i dati tanto nello spazio d’indirizzamento a 64 bit che in quello a 32 bit. Questo perché non puoi sapere a priori se quei dati saranno visibili / utilizzati in quest’ultimo, causa politica di “totale condivisione”.

    Questo significa che se apro un’immagine “cicciosa” :D con un’applicazione nativa a 64 bit, potrei anche saturare lo spazio d’indirizzamento a 32 bit, e di fatto impedire all’ecosistema 68000 di funzionare. Tutto ciò senza che sia in programma di passare quell’immagine a un’applicazione a 32 bit.

    Quindi non è semplicemente una questione di “condivisione” dei dati fra i mondo a 64 e quello a 32 bit, ma è a rischio il funzionamento stesso di quell’ambiente vecchio all’interno del nuovo.

    Non so se sono stato chiaro.

  • # 34
    [D]
     scrive: 

    “Se serve utilizzare qualche applicazione “sporca”, la si fa girare con (Win)UAE.

    Quelle “pulite” per me hanno pari dignità di quelle native, perché se fanno ricorso esclusivamente alle API del s.o., e al più leggono soltanto alcune strutture del s.o., per me possono girare senza problemi.”

    Per me non c’è applicazione “sporca” o “pulita”, ma applicazione “vecchia” ovvero scritta secondo i canoni infausti del passato e applicazione “nuova”, dove finalmente si mandano in soffitta tutta quella serie di procedure e brutte abitudini che mettono un freno alla crescita del sistema. La dignità è già più che garantita da winuae il quale necessita al massimo di minime aggiunte per acconsentire la completa integrazione “sicura” tra vecchio e nuovo.

    Winuae può utilizzare comuni cartelle del sistema come dischi amiga quindi può praticamente contenere un workbench dentro l’altro come se il vecchio fosse un “programma” del nuovo, già adesso insieme al pacchetto esiste una cartella “amiga programs” dove troviamo patch per determinate librerie ma soprattutto software che permettono di controllare windows da amiga os emulato. Non credo sarebbe così difficile realizzare un software che si faccia carico di far partire un programma emulato direttamente dall’interfaccia host, saltando la scomoda interazione con il sistema operativo emulato stesso.

  • # 35
    Wilfrick
     scrive: 

    Grazie, si, è chiaro.
    Resto dell’idea comunque che sarebbe meglio (meno doloroso) un nuovo Amiga incompatibile con applicazioni vecchie, ma che sia vero Amiga moderno con prospettive per il futuro (con emulazione 68000 se si vuole), piuttosto che un Amiga zoppo e vetusto ma compatibile e senza futuro se non per quei pochissimi appassionati.
    D’altra parte, se vogliamo ben vedere, mica è così scontato poter far girare applicazioni del 1990 per pc su computer moderni con il 7…
    Ciao

  • # 36
    [D]
     scrive: 

    “D’altra parte, se vogliamo ben vedere, mica è così scontato poter far girare applicazioni del 1990 per pc su computer moderni con il 7…”

    Oltretutto dal punto di vista di uno sviluppatore, chi glielo fa fare di realizzare un programma nuovo se i suoi potenziali utenti pestano i piedi perchè vogliono continuare ad ogni costo con roba fatta 20 anni prima ?
    Un so senza un ricambio di programmi nuovi non ha futuro. La retrocompatibilità dovrebbe essere considerata solo come una pezza per ovviare a delle mancanze momentanee non come la soluzione a tutti i problemi.

  • # 37
    Cesare Di Mauro (Autore del post)
     scrive: 

    Il problema principale è il s.o. in sé, perché i problemi delle vecchie applicazioni le hanno anche le nuove, che girano su AmigaOS4, AROS e MorphOS.

    Bisognerebbe ripensare alla base il s.o., ma non so se potremmo poi parlare di AmigaOS. Forse è meglio che resti così, e amen.

  • # 38
    Bruno
     scrive: 

    Personalmente sarei a favore di una rimozione completa del passato – e ancor di più di tutte le società che stanno pasteggiando sui rimasugli della comunità Amiga proponendo soluzioni e prodotti francamente fuori dal mondo.

    L’unica strada percorribile secondo me è quella iniziata da AROS, ma bisognerebbe fare un passo in più e spingere l’integrazione con l’hardware.

    Mi spiego meglio: AmigaOS era un OS fantastico anche perché era strettamente legato all’hardware custom su cui girava – AROS dovrebbe fare lo stesso: scegliere una piattaforma hardware di riferimento e iper-ottimizzarsi su quella.

    Il punto dei vecchi Amiga era proprio che con una macchina relativamente economica ci si poteva fare tutto quello che si faceva su dispositivi molto più costosi – proprio grazie alla stretta integrazione tra software e hardware.

    La ricerca disperata della retrocompatibilità deriva, secondo me, da un equivoco di fondo: gli Amiga classici erano spremuti così a fondo che bastava aggiungere mezzo mega di RAM per ritrovarsi con software inutilizzabili. Questa ferita dev’essere stata così profonda che ancora oggi l’obiettivo principale sembra essere la compatibilità con programmi scritti 20 anni fa.

    In realtà ciò che serve è un OS scritto con criteri moderni, che sia ottimizzato quanto basta per stracciare Windows, MacOS e Linux su un determinato hardware di riferimento, e che sia al tempo stesso astratto a sufficienza da garantire che un programma scritto oggi continui a funzionare tra un anno.

    Un OS del genere avrebbe QUALCHE chance nel mercato odierno. Per tutto il resto, c’è l’UAE.

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.