Tecnologia PPC Lenta? Ma Quando Mai?

[cdimauro]

Ma infatti non il motivo di tanta esitazione, da che mondo e mondo la stragrande maggioranza dei software (sopratutto tempo fa.. oggi oramai serve a poco) in tutti gli ambienti sono disponibili in versione 32 e versione 64 bit, per il semplice fatto che è sufficiente ricompilare.

Comunque secondo me tlosm sa qualcosa che non vuole o non può dire

Per quanto mi riguarda, poco importa, perché gli scenari sono quelli che ho già descritto. Se vogliono realizzare s.o. REALMENTE a 64 bit, il prezzo da pagare è la retrocompatibilità, e da quel che ho visto finora ci sono legati mani e piedi e se la vogliono tenere ben stretta.

Non posso nemmeno dire "aspettiamo a vedere", perché coi tipici tempi biblici c'è il rischio che certe cose non le vedrà mai nessuno.

[marmotta]

Ma infatti non il motivo di tanta esitazione, da che mondo e mondo la stragrande maggioranza dei software (sopratutto tempo fa.. oggi oramai serve a poco) in tutti gli ambienti sono disponibili in versione 32 e versione 64 bit, per il semplice fatto che è sufficiente ricompilare.

Comunque secondo me tlosm sa qualcosa che non vuole o non può dire

Per quanto mi riguarda, poco importa, perché gli scenari sono quelli che ho già descritto. Se vogliono realizzare s.o. REALMENTE a 64 bit, il prezzo da pagare è la retrocompatibilità, e da quel che ho visto finora ci sono legati mani e piedi e se la vogliono tenere ben stretta.

Non posso nemmeno dire "aspettiamo a vedere", perché coi tipici tempi biblici c'è il rischio che certe cose non le vedrà mai nessuno.

Di quale retrocompatibilita parli? I software ppc32 verrebbero velocemente ricompilati e l'emulazione 68k seguirebbe la stessa strada, o no?

Inviato dal mio GT-P3110 utilizzando Tapatalk

[tlosm]

tutto il software 32 bit è facilmente ricompilabile visto che è open source al 99% o di cui si hanno i sorgenti quindi retro compatibilità risolta .. il software a pagamento è ricompilabile poichè le software house che l'hanno fatto esistono ancora.

[cdimauro]

Per quanto mi riguarda, poco importa, perché gli scenari sono quelli che ho già descritto. Se vogliono realizzare s.o. REALMENTE a 64 bit, il prezzo da pagare è la retrocompatibilità, e da quel che ho visto finora ci sono legati mani e piedi e se la vogliono tenere ben stretta.

Non posso nemmeno dire "aspettiamo a vedere", perché coi tipici tempi biblici c'è il rischio che certe cose non le vedrà mai nessuno.

Di quale retrocompatibilita parli? I software ppc32 verrebbero velocemente ricompilati e l'emulazione 68k seguirebbe la stessa strada, o no?

SE è vero quello che sento ripetere, come ho già detto prima, allora sì, è così per il software PowerPC a 32 bit. Per cui, e lo ripeto, non ha senso perdere tempo in pezze per usare la memoria oltre i 2GB, ma sarebbe molto meglio fornire un s.o. realmente a 64-bit.

Ma di molto software 68K non sono disponibili i sorgenti o non è stato portato su PowerPC, per cui rimangono soltanto i binari. Un esempio su tutti: AREXX...

Inoltre l'attuale emulazione 68K non funzionerebbe, ma si dovrebbe ricorrere a un emulatore che gira in una sandbox, un po' come fa AROS. Questo perché l'ambiente a 32-bit dei 68K (come pure delle applicazioni PowerPC a 32-bit) è incompatibile con quello a 64-bit (ma non è vero in generale: vale solo per i s.o. Amiga-like. In altri s.o. possono girare assieme, perché il s.o. e le applicazioni NON convidono strutture dati importanti fra di loro, se non tramite meccanismi "opachi").

[marmotta]

Per quanto mi riguarda, poco importa, perché gli scenari sono quelli che ho già descritto. Se vogliono realizzare s.o. REALMENTE a 64 bit, il prezzo da pagare è la retrocompatibilità, e da quel che ho visto finora ci sono legati mani e piedi e se la vogliono tenere ben stretta.

Non posso nemmeno dire "aspettiamo a vedere", perché coi tipici tempi biblici c'è il rischio che certe cose non le vedrà mai nessuno.

Di quale retrocompatibilita parli? I software ppc32 verrebbero velocemente ricompilati e l'emulazione 68k seguirebbe la stessa strada, o no?

SE è vero quello che sento ripetere, come ho già detto prima, allora sì, è così per il software PowerPC a 32 bit. Per cui, e lo ripeto, non ha senso perdere tempo in pezze per usare la memoria oltre i 2GB, ma sarebbe molto meglio fornire un s.o. realmente a 64-bit.

Ma di molto software 68K non sono disponibili i sorgenti o non è stato portato su PowerPC, per cui rimangono soltanto i binari. Un esempio su tutti: AREXX...

Inoltre l'attuale emulazione 68K non funzionerebbe, ma si dovrebbe ricorrere a un emulatore che gira in una sandbox, un po' come fa AROS. Questo perché l'ambiente a 32-bit dei 68K (come pure delle applicazioni PowerPC a 32-bit) è incompatibile con quello a 64-bit (ma non è vero in generale: vale solo per i s.o. Amiga-like. In altri s.o. possono girare assieme, perché il s.o. e le applicazioni NON convidono strutture dati importanti fra di loro, se non tramite meccanismi "opachi").

Quindi si perderebbe Petunia? (E AREXX che non penso sia difficile da riscrivere)

Quando parli di altri Os ti riferisci ad esempio a Osx e Rosetta? Infatti se non ricordo male osx era gia a 64bit mentre si poteva eseguire software ppc32 (quindi si emulava una cpu diversa con ambiente misto 32/64bit). Anche se bisogna dire che osx non era a totalmente a 64bit ma i due ambienti 64/32bit convivevano, quando osx è diventato totalmente a 64 bit (Lion?) hanno abbandonato Rosetta.

[cdimauro]

SE è vero quello che sento ripetere, come ho già detto prima, allora sì, è così per il software PowerPC a 32 bit. Per cui, e lo ripeto, non ha senso perdere tempo in pezze per usare la memoria oltre i 2GB, ma sarebbe molto meglio fornire un s.o. realmente a 64-bit.

Ma di molto software 68K non sono disponibili i sorgenti o non è stato portato su PowerPC, per cui rimangono soltanto i binari. Un esempio su tutti: AREXX...

Inoltre l'attuale emulazione 68K non funzionerebbe, ma si dovrebbe ricorrere a un emulatore che gira in una sandbox, un po' come fa AROS. Questo perché l'ambiente a 32-bit dei 68K (come pure delle applicazioni PowerPC a 32-bit) è incompatibile con quello a 64-bit (ma non è vero in generale: vale solo per i s.o. Amiga-like. In altri s.o. possono girare assieme, perché il s.o. e le applicazioni NON convidono strutture dati importanti fra di loro, se non tramite meccanismi "opachi").

Quindi si perderebbe Petunia?

Sì.

(E AREXX che non penso sia difficile da riscrivere)

Richiederebbe un po' di tempo.

Quando parli di altri Os ti riferisci ad esempio a Osx e Rosetta?

No, in generale. Quindi anche Windows, Linux, ecc. col passaggio da 16 a 32-bit, e da 32 a 64 bit.

Comunque Rosetta faceva girare codice PowerPC a 32-bit su architettura Intel a 32-bit. Non si poneva, dunque, il problema della diversa dimensione dei dati (e registri).

Infatti se non ricordo male osx era gia a 64bit

No, era a 32-bit, ma con (molto) parziale supporto ai 64-bit. Ecco qui un mio articolo in proposito.

mentre si poteva eseguire software ppc32 (quindi si emulava una cpu diversa con ambiente misto 32/64bit).

No, soltanto 32-bit su 32-bit, come detto prima.

Anche se bisogna dire che osx non era a totalmente a 64bit ma i due ambienti 64/32bit convivevano,

Certamente, come tutti i s.o. fatti bene i due ambienti possono tranquillamente coesistere e scambiarsi pure informazioni. La chiave di tutto è nel NON consentire il libero accesso alle strutture del s.o. o delle applicazioni, ma provvedere meccanismi appositi.

quando osx è diventato totalmente a 64 bit (Lion?) hanno abbandonato Rosetta.

L'hanno fatto quando ormai il software PowerPC era stato praticamente tutto portato su Intel.

[marmotta]

@cdimauro
Windows e linux non hanno mai avuto la necessita di emulare un'altra cpu, per questo pensavo ad osx.

Snow Leopard poteva eseguire software a 64 bit ed emulava il ppc32 con rosetta. Non potrebbe anche AmigaOs avere un ambiente misto 32/64? Magari stanno lavorando proprio a questo ;-)

[cdimauro]

@cdimauro
Windows e linux non hanno mai avuto la necessita di emulare un'altra cpu, per questo pensavo ad osx.

OK, chiaro, e da questo punto di vista hai sicuramente ragione.

Snow Leopard poteva eseguire software a 64 bit ed emulava il ppc32 con rosetta. Non potrebbe anche AmigaOs avere un ambiente misto 32/64? Magari stanno lavorando proprio a questo ;-)

No, non è possibile perché i s.o. Amiga/-like rendono pubbliche le loro strutture dati, e le applicazioni fanno lo stesso. Per cui non è possibile far girare assieme applicazioni a 32 e 64-bit.

Una soluzione potrebbe essere quella di avere due versioni, a 32 e 64 bit, del s.o. che girano assieme, e ognuna delle due che fa girare le proprie applicazioni, ma senza condividere tutto come avviene adesso. Condividere qualcosa sarebbe decisamente incasinato e richiederebbe non poco tempo per modificare le due versioni del s.o. apposta.

[tlosm]

voglio fare una domanda... come mai lubuntu e debian hanno il kernel a 64bit sul g5 mentre tutto il software compreso l'os e' a 32?

[cdimauro]

Questo non avviene soltanto sul G5, ma anche su x64, ad esempio. Il nocciolo è che questi s.o. non rendono pubbliche le loro strutture interne, ma bisogna ricorrere a delle API per ottenere informazioni e in generale servizi.

A livello applicativo, tu applicazione a 32 o 64 bit invochi un'API se ti serve qualcosa dal s.o. (aprire un file, allocare memoria, aprire uno schermo/finestra, ecc. ecc.), e ci pensa il s.o. a fare tutto, ma tu NON hai alcun accesso diretto alle strutture che lui usa per fornirti i suoi servizi.
Per cui, per fare un esempio, se un'applicazione a 64-bit aprire una finestra sul desktop, non ha alcun riferimento diretto a essa, ma soltanto un cosiddetto "handle" che il s.o. gli ha passato per gestire le operazioni su di essa. L'handle è soltanto un numeretto: non ti dice assolutamente nulla su tutte le risorse che il s.o. ha messo in piedi per aprirti quella finestra, ma è utile al s.o. perché tramite quello sa ciò che deve fare.
E la finestra che hai aperto è visibile anche alle applicazioni a 32-bit, perché anche queste non hanno alcun accesso alle strutture interne del s.o., ma possono soltanto interrogarlo con le API per sapere quante e quali finestre ci sono aperte, ottenere l'handle di una particolare finestra, e mandargli dei comandi (ma sempre tramite delle apposite API del s.o.: niente accesso diretto alla finestra!).

Un s.o. Amiga/-like è, invece, totalmente diverso: tutti hanno accesso a tutto, e spesso non si fa uso di handle, ma hai proprio il puntatore alla risorsa, e puoi modificarla come vuoi. Quindi di uno schermo o finestra non hai un handle, ma un puntatore. E puoi accedere direttamente a tutti i suoi campi senza chiedere nulla al s.o.. E siccome un puntatore ha pure una dimensione ben precisa (32-bit o 64-bit), è chiaro che tutte le strutture del s.o. (ma anche delle applicazioni) che ne fanno uso saranno ben diverse a seconda se compili a 32 o 64 bit. Da cui l'incompatibilità di cui parlavo prima.
Per fare un esempio, se un s.o. Amiga-/like a 64-bit creasse uno schermo, il puntatore ai dati dello schermo sarebbe a 64-bit, per cui NON potrebbe essere passato a un'applicazione a 32-bit (tranne se l'indirizzo fosse entro i primi 4GB di spazio, ma questo limiterebbe la memoria ai primi 4GB, e non si sfrutterebbe alcun vantaggio degli indirizzi a 64-bit). Inoltre eventuali puntatori interni allo schermo sarebbero a loro volta a 64-bit, e ci sarebbe lo stesso problema.

Per cui con questi s.o. (tutti, nessuno escluso) si potrebbero far girare soltanto s.o. E applicazioni o a 32-bit oppure soltanto a 64-bit. Niente mix.

[rebraist]

Rimane il fatto che con un parco istallato al 99% di sam e tra le 10 e le 50 x1000 su tutto il pianeta, bank switching o 64bit full saranno fruibili solo l, nel caso migliore, da 100 utenti (mettendoci altri 50 paperoni che compreranno altro costoso hw aeon). A mio avviso il salto verso i 64 bit, allo stato attuale, è una perdita di tempo. E forse il bank switching ha un suo perché se l'os continua a funzionare sulle macchine acube (4x0 tutte) ed è anche la soluzione più intelligente: No martini no party per le piccole e qualche "optional" in più per le 20 x1000 in giro per il pianeta.

[cdimauro]

Il bank switching è già una gran perdita di tempo, in particolare per gli sviluppatori che dovranno scrivere codice apposito per supportarlo direttamente. E se l'utenza che ne può fruire è così piccola, mi domando che senso abbia averci lavorato, viste le poche forze in campo in ambito coder.

[tlosm]

Il bankswitching è una pezza per il 4.1.7 e per quelli che hanno le X1000 con più di 2 gb di ram o le X5000 che partiranno con 4gb DDR3 .
Quindi sarà una perdita di tempo ma visto che il 4.1.7 deve uscire per i Beta tester e per le altre macchine e racchiuderà 4.1.6 più tutte gli upgrade meglio averlo che non avere nulla ... tanto non si paga.

[Kyle]

Ora si critica anche ciò che è gratis

[cdimauro]

Il bankswitching è una pezza per il 4.1.7 e per quelli che hanno le X1000 con più di 2 gb di ram o le X5000 che partiranno con 4gb DDR3 .
Quindi sarà una perdita di tempo ma visto che il 4.1.7 deve uscire per i Beta tester e per le altre macchine e racchiuderà 4.1.6 più tutte gli upgrade meglio averlo che non avere nulla ... tanto non si paga.

Ma servono gli sviluppatori che scrivano il codice apposito: è questo il punto.