Costo cpu sam dual core

[Mck]

Speriamo e presto.

[orson]

Non è un caso se ormai tutti si buttano sugli ARM. Bisognerebbe seriamente prenderli in considerazione questi processori.

Tra l'altro hanno pure il vantaggio di operare in modalità big-endian, come i Motorola 68000 e i PowerPC, per cui la retrocompatibilità col vecchio codice (si potrebbe introdurre un "emulatore" come Petunia o Trance, ma per il codice PowerPC già esistente) sarebbe garantita.

Unica cosa, i 64 bit: questi, che si tratti di PowerPC, ARM, o qualunque altra architettura, non si possono usare senza dare un taglio netto alla retrocompatibilità.

Credo anch'io che la via d'uscita si Arm, sia per i motivi tecnici suddetti che per motivi di mercato.
AmigaOS su macchine High End come X86 è troppo lontano dagli altri OS, mentre su macchine Low End come gli Arm può mettere a frutto la propria leggerezza.
Magari riuscendo ad inserirsi nel mercato embedded.

Certo che il limite della memoria non è drammatico, ma il multiprocessing ormai è una necessità su tutte le piattaforme

[AMIGATV]

@Cdimauro

Una domanda, lasciando perdere x86, secondo te tra tutte le cpu powerpc embedded quale potrebbe avere il miglior rapporto prezzo/prestazioni per il piccolo mercato amiga?

[Tuxedo]

@cidmauro

Grazie a te della prof :)
Non sapevo 'sta cosa di ARM...certo sarebbe di sicuro un apssaggio più "indolore" allora...

Per quanto riguarda SMP/AMP, ma effettivametne che differenze ci sono? Se puntano su SMP(problemi di compatibilità a aprte) sarà percghè prestazionalmente è decisamente più performante o cosa? Sennò non avrebbe senso no?

[cdimauro]

Credo anch'io che la via d'uscita si Arm, sia per i motivi tecnici suddetti che per motivi di mercato.
AmigaOS su macchine High End come X86 è troppo lontano dagli altri OS, mentre su macchine Low End come gli Arm può mettere a frutto la propria leggerezza.
Magari riuscendo ad inserirsi nel mercato embedded.

Il mercato ormai è saturo, e la vedo molto difficile.

Comunque anche su x86 non vedo problemi a farlo girare, anche perché esistono architetture come Atom di Intel, Fusion (soprattutto) di AMD e Nano di Via che sono molto popolari nella fascia bassa e/o di bassissimo consumo.

Certo che il limite della memoria non è drammatico,

Dipende da quello che ci fai. Oggi 2GB stanno decisamente stretti anche senza andare a manipolare foto da 100Mpixel.

ma il multiprocessing ormai è una necessità su tutte le piattaforme

Senza dubbio.

@Cdimauro

Una domanda, lasciando perdere x86, secondo te tra tutte le cpu powerpc embedded quale potrebbe avere il miglior rapporto prezzo/prestazioni per il piccolo mercato amiga?

Purtroppo non conosco i prezzi.

@cidmauro

Grazie a te della prof :)
Non sapevo 'sta cosa di ARM...certo sarebbe di sicuro un apssaggio più "indolore" allora...

Assolutamente. Le difficoltà stanno nello riscrivere il boot loader, la parte del kernel che si occupa di gestire interrupt e processi, e in generale i pezzi di codice assembly.

Oltre ovviamente a Petunia / Trance per il layer di emulazione / compilazione JIT delle applicazioni 68000 (e, come dicevo, se ne potrebbe aggiungere un altro "in parallelo" anche per il codice PowerPC).

Diciamo che a parte quest'ultimo aspetto, quelli elencati sopra sono problematiche generali, che riguardano qualunque architettura verso la quale si volesse portare un s.o..

E diciamo pure che fino a quando non entra in gioco la retrocompatibilità coi 68000, l'endianess non sarebbe affatto un problema e il porting si potrebbe realizzare senza problemi per qualunque architettura (quindi anche x86, e pure AMD64 "castrando" i puntatori a 32 bit se vogliamo mantenere il s.o. a 32 bit, sfruttando però il doppio dei registri che sono a disposizione in questa nuova modalità a 64 bit).

Per quanto riguarda SMP/AMP, ma effettivametne che differenze ci sono? Se puntano su SMP(problemi di compatibilità a aprte) sarà percghè prestazionalmente è decisamente più performante o cosa? Sennò non avrebbe senso no?

Sinteticamente, con l'SMP puoi far girare una qualunque applicazione su qualunque core a disposizione.

Con l'AMP, invece, il "primo" core è quello principale che gestisce il tutto, mentre gli altri core sono utilizzabili o per fungere da coprocessore (in maniera veramente banale. Basterebbe replicare quanto già fatto in AmigaOS per gestire il Blitter) oppure, meglio ancora, per farci girare delle speciali applicazioni che non possono utilizzare tutte le funzionalità del s.o..

Sono speciali e limitate nel senso che il s.o. non le gestisce come tutte le altre (che girano sul primo core), ma esclusivamente per eseguire calcoli o comunque senza che possano toccare parti critiche del s.o. o relative all'interazione con altre applicazioni.

[Tuxedo]

mmm...
- quindi alla fine è sempe l'Os che gestisce la seconda CPU a seconda dei casi..oppure no e bisogna scrivere codice apposta? O melgio...sarebbe più semplice scrivere codice che scfrutta il secondo core in SMP o AMP?

- per quanto riguarda il fatto della retrocomptaibilità 68k...scusate l'ignoranza ma...se io scrivo un emulatore della CPU che me ne frega dell'architettura su cui gira? Se scrivo un emulaotre deve emulare per evitarmi problemi mica crearmene...ma di sicuro mi manca qualcosa... :P

[cdimauro]

mmm...
- quindi alla fine è sempe l'Os che gestisce la seconda CPU a seconda dei casi..

E' sempre il s.o. che la gestisce. Al più le applicazioni potrebbero facilitarle il compito; mi spiego dopo.

oppure no e bisogna scrivere codice apposta? O melgio...sarebbe più semplice scrivere codice che scfrutta il secondo core in SMP o AMP?

Con l'SMP il vantaggio è che non serve scrivere codice apposito, se non per lanciare genericamente n processi/thread (uno per ogni core), in modo da distribuire il carico.

Dal punto di vista applicativo l'SMP richiede meno sforzi ai programmatori. Con l'AMP invece lo sforzo maggiore è delegato all'applicazione, che deve provvedere non soltanto a distribuire il carico nei vari core, ma assicurarsi che ogni processo/thread "worker" non utilizzi funzioni "critiche" del s.o. (anche lo stesso accesso alla GUI, ad esempio) che sono delegate e possono essere utilizzate esclusivamente al processo/thread "main".

E' il processo/thread principale che si occupa di sincronizzare tutti i worker, e di prendersi carico di eventuali richieste "critiche" al s.o., mentre con l'SMP tutti i processi/thread sono equipotenti e possono fare le stesse cose.

- per quanto riguarda il fatto della retrocomptaibilità 68k...scusate l'ignoranza ma...se io scrivo un emulatore della CPU che me ne frega dell'architettura su cui gira? Se scrivo un emulaotre deve emulare per evitarmi problemi mica crearmene...ma di sicuro mi manca qualcosa... :P

Finché rimaniamo al mero ambito dell'emulazione, in cui vediamo il sistema emulato come una "scatoletta" (sandbox) che gira in un mondo tutto suo (con una limitatissima capacità di comunicazione col s.o. ospite; generalmente solo per inviare l'output video e audio, ricevere input da tastiera mouse, o ancora sfruttare un file come fosse il disco rigido o il floppy visto dal sistema emulato, ecc.), è corretto quello che dici.

Il problema nasce quando si va oltre l'emulazione, e il sistema emulato diventa parte o condivide risorse critiche del sistema ospite, come avviene con Petunia e Trance.

In questi casi l'emulazione (e compilatore JIT online) è un "accessorio" che serve soltanto a convertire le istruzioni "aliene" (68000) in quelle dell'architettura ospite (PowerPC), ma per il resto i dati dei due sistemi risultano (totalmente) condivisi.

Pensiamo a un'applicazione 68000 che chieda di aprire uno schermo su OS4 o MorphOS, ad esempio. La chiamata a OpenScreen del codice 68000 sarà intercettata da Petunia/Trance, che la girerà così com'è (a parte copiare i registri 68000 sui corrispondenti registri PowerPC) alla relativa OpenScreen di OS4/MorphOS, che preleverà i dati ed elaborerà la richiesta esattamente allo stesso modo di una richiesta proveniente da un'applicazione "nativa" PowerPC. Il risultato sarà poi preso e passato ai relativi registri 68000 da Petunia/Trance.

In tutto ciò non c'è nessuna conversione di dati (la copia da registro 68000 a PowerPC e viceversa non è una conversione; è una copia, appunto, perché i dati non vengono alterati in alcun modo, e in ogni caso riguarda esclusivamente i registri della CPU emulata), perché tutti i dati vengono condivisi così come sono. Sostanzialmente per OS4/MorphOS non c'è alcuna differenza fra un'applicazione 68000 e una PowerPC, perché vengono trattate (e servite) allo stesso modo.

La stessa cosa non si può fare con un'architettura little endian, perché in questo caso i dati devono necessariamente essere convertiti da big-endian (68000, PowerPC) a little-endian (x86, AMD64) per essere elaborati dal s.o. ospite (ad esempio AROS), e viceversa. Se la cosa è fattibile per semplici dati, non lo è certo per le strutture complesse che normalmente sono utilizzate dal s.o..

Esempio banale: l'elenco dei task, che racchiude sia dati semplici, sia puntatori ad altre strutture dati che a loro volta possono contenere sia dati semplici che puntatori ad altre strutture dati. Pensare di convertire tutto ogni volta non è soltanto un enorme spreco risorse (anche per operazioni semplici), ma pura follia (perché si potrebbe facilmente incappare in strutture che formano un ciclo, dal quale ovviamente è molto difficile uscirsene).

[Tuxedo]

ri-ummmm...

Allora, se ho capito bene:

- SMP o AMP poco contetrebbe per noi(visto i lcomunque pco software in circolazione) e anzi AMP sarebbe di più veoce e semplice implementazione...

- per effettuare un'emulazione 68k funzionale su sistemi little-endian(vorrei capire che vantaggi ha rispetto al big...) o si fa girare le vecchie applicazioni su una sandbox tipo AmiCygniX oppure, mi domando, no si potrebbe "semplicemente" creare un kernel big-endian(cioè che in pratica pensa lui a intercettare le chiamata alle vecchie aplicazioni e passare solo l'output grafico al OS vero e proprio) da affiancare a Petunia/trance? una specie di sandbox meno "distaccata" dall'OS...

forse vaneggio :)

Buon pomeriggio!

[cdimauro]

ri-ummmm...

Allora, se ho capito bene:

- SMP o AMP poco contetrebbe per noi(visto i lcomunque pco software in circolazione) e anzi AMP sarebbe di più veoce e semplice implementazione...

Esatto. Ancora più veloce sarebbe sfruttare i core come coprocessori, (quasi) come si faceva ieri col Blitter.

- per effettuare un'emulazione 68k funzionale su sistemi little-endian(vorrei capire che vantaggi ha rispetto al big...)

Little-endian e big-endian sono due modi diversi di rappresentare la stessa informazione (interi che occupano più di 1 byte).

Ogni rappresentazione porta con sé pregi e difetti, ma un s.o. non deve dipendere da questa informazione.

o si fa girare le vecchie applicazioni su una sandbox tipo AmiCygniX

Non la conosco. Io pensavo più che altro a (Win)UAE quale sandbox 68000.

oppure, mi domando, no si potrebbe "semplicemente" creare un kernel big-endian(cioè che in pratica pensa lui a intercettare le chiamata alle vecchie aplicazioni e passare solo l'output grafico al OS vero e proprio) da affiancare a Petunia/trance? una specie di sandbox meno "distaccata" dall'OS...

forse vaneggio :)

Buon pomeriggio!

Purtroppo non si può fare per quanto scritto alla fine del precedente messaggio: ci sarebbe troppo lavoro dietro e le prestazioni (oltre che l'uso di memoria) crollerebbero.

Tra l'altro qualcosa del genere c'è già: (Win)UAE appunto. Perché lì dentro c'è AmigaOS che gira interamente in modalità big-endian. Ma le prestazioni non sono equiparabili a quelle di un kernel nativo little-endian (come quello di AROS, ad esempio).

[ShInKurO]

AmiCygnix è X per AmigaOS4, non è proprio una sandbox... Classic di OSX era una sandbox...

[cdimauro]

Capito. La solita brodaglia Unix, che con AmigaOS non ha nulla a che spartire.

[Tuxedo]

ora è tutto molto più chiaro grazie :)

PS AmiCygniX è si una brodaglia, ma risulta cmq abb comodo in caso di becessità(vedi usare AbiWord, gnumeric o gimp...) :)

[MacGyverPPC]

ora è tutto molto più chiaro grazie :)

PS AmiCygniX è si una brodaglia, ma risulta cmq abb comodo in caso di becessità(vedi usare AbiWord, gnumeric o gimp...) :)

L'unica cosa che trovo lenta in Amicygnix, spostare finestre e caricare foto da 12 MPixel che ci mette un po' sulla 440, ma quando lavori con gymp nella finestra del disegno ha il pregio di filare bene.
Non capisco perchè questa lentezza del desktop rispetto alla funzionalità dei programmi... comunque si, un buon compromesso quando voglio usare alcuni programmi rispetto a quelli pur sempre ottimi su AOS, tra ImageFX, photogenics che mi lascia ancora sbalordito per come gira grazie a petunia e altre vecchie e nuove glorie.
Ieri hanno rilasciato un programma nativo di grafica per OS4 (SketchBlock Version 1.1 (prototype release)) beh, gimp a confronto gli da le fave... ok che è un prototipo e credo migliorerà, ma tanto per intenderci...

[Tuxedo]

il problema di AmiCygniX è che il driver 2D no ha l'accelerazione hw per cui tutte le azioni che fanno uso di grafica(come lo spostare/ridisegnare finestre ne risentono no npoco....), come se installi una nuova scheda grafica su windows senza mettere divers appositi...lentezza assoulta nel refresh/ridimensionamento delle finestre! :P
Purtroppo l'autore mi ha detto che non sa bene come risolvere la cosa(come pure che non si può andare se non in 16bit...)...
Certo è un vero peccato, se ci fosse l'accelerazione hw sarebbe tutta un'altra muscisa usare AmiCigniX...

[Alblino]

@Cdimauro

Una domanda, lasciando perdere x86, secondo te tra tutte le cpu powerpc embedded quale potrebbe avere il miglior rapporto prezzo/prestazioni per il piccolo mercato amiga?

Io sono convinto che anche se la cpu costasse pochissimo la Sam o l'x1000 costerebbero
sempre tanto proprio per via della poca produzione.
Alla fine produrre 1000 Sam all'anno o 10000 il prezzo cambia all'utente finale.
Esistono dei costi fissi in produzione che puoi abbassare solo con l'aumento della
produzione sopratutto in italia.