Newsgroup: it.comp.macintosh
Titolo: Passaggio a intel confermato?

Spymac.com lo da per confermato..
morte di apple?
-- 
dimix

 Spymac.com lo da per confermato..
tutti e ripeto TUTTI si stanno basando sulla news che ho postato di
CNET, l'unica fonte attendibile (purtroppo).
-- 
.zen spera per una volta che abbiano preso un granchio..

 CNET, l'unica fonte attendibile (purtroppo).
 si perň loro sono cosě convinti =(
ma scusa se passano ad intel no, facciamo conto che lo fanno, ok.. tutti
contenti..
perň da qui in avanti, non appena esce il primo modello tutti i software
nuovi li fanno per quello no? Insomma non faranno una doppia versione di
tutto.. 
bah.. mi sto preoccupando..
-- 
dimix

 non è stata pubblicata una smentita?
no. 
-- 
.zen domani è il giorno x

 bah.. mi sto preoccupando..
aspettiamo Jobs, č inutile fare ipotesi campate in aria.
-- 
.zen in attesa

 Ma lunedě che c'č? Un keynote?
yes, quello per gli sviluppatori.
-- 
.zen non commenta :P

 E non credo siano gli unici.
Nel mio piccolo stavo per prendere la production box ma visto che, per
fortuna, domani e' domani... aspettero' dopodomani :-)
-- 
"25 maggio: "you'll never walk alone" - Tessera #69
http://snipurl.com/f5e7

  (Zio Biggo©)
dicendo "Intel? WTF HAVE YOU SMOKE GUYS?" ;)
..give me some...
-- 
.zen vuole crederci ;( 

 morte di apple?
Anche supponendo esatta la "spiata" di Spymac.com "Passaggio a Intel" 
non significa che MacOSX possa essere installato su tutti i PC in 
circolazione: può anche essere che Apple sviluppi un Mac con processore 
Intel, una macchina comunque "proprietaria" la cui unica differenza 
dalle macchine attuali sia il processore, ma in cui sia sempre valido il 
vincolo hw-os.
Io continuo a non crederci: 4 anni di ottimizzazione per Altivec (e ora 
per i 64 bit del G5) non si buttano nel cesso in questo modo... a meno 
che parallelamente non abbiano portato avanti la stessa cosa anche per 
una piattaforma alternativa. In questo caso credo comuqnue che ci 
troverenno davanti ad un Mac con x86, e non a MacOSX per x86
(che sono due cose completamente distinte)
ciao

 I diritti sulla CPU sono di Apple, non di IBM o Motorola...
Tutto iniziò nel lontano 1992 (faccio il dotto, in realtà
sto leggendo un vecchio libro sull'assembler PowerPC :-)
quando Apple, IBM e Motorola si allearono e, congiuntamente,
silupparono l'architettura PowerPC.
Ora non so le questioni legali, ma, se non è cambiato qualche cosa,
Apple non dovrebbe (essendo un proprietario al pari di IBM e Motorola)
avere problemi a decidere di commissionare la costruzione
del suo nuovo processore ad Intel.
In tal caso Intel costruirebbe il processore su licenza Apple,
bisogna poi vedere se ci sono dei vincoli con gli
altri partner per impedire questo, ma, comunque, essendo
in un libero mercato, una licenza si può sempre affittare
o vendere.
Ciao


| |._/|_|\__/\__/\__/ | *Non e' bello cio' che e' bello,
|        /_/ /_/      |  figurarsi cio' che e' brutto.

 Vedremo
Anche se hanno preso un granchio non lo ammetteranno.
Stanno diventando peggio di Brighthand.
-- 
I'm praying for rain
to see desert flowers again

 emula il set x86.
non erano gli AMD questi?
-- 
.zen chiede eh

 Da quand'e' che i programmi vengono sviluppati sul processore? 
I programmi vengono SEMPRE sviluppati per un processore specifico (anche
Java, che viene sviluppato per una "macchina virtuale" aka un
"processore" che non esiste e che viene emulato dalla JVM di ogni
singolo sistema).
Quando il compilatore compila, scrive linguaggio macchina specifico di
quel dato processore. Ergo un programma compilato per 68k non girera' su
PPC ne' un programma PPC su x86 (se non ci sono "strati" di codice extra
che emulano il processore giusto).
 - ∞
-- 
I miei post non sbagliano. E' la realta' ad essere inesatta.

 yes, quello per gli sviluppatori.
Be', tutta la conferenza e' per gli sviluppatori... :D


 di niente
La professionalita' di CNet mi e' sempre parsa un po' cosi' cosi'. Se
non fosse che non scommetto per principio, io scommetterei sul "fanno
finta di nulla".


 che in mezzo ci stesse un sistema operativo.
vero, però per dire, magari ilife 06 andrà solo su osx x86 e non su osx
per ppc.. no? intendevo in questo modo..
-- 
dimix

 smazza tutte il compilatore.
Boh, con tutto il sciu' sciu' che mettono giu' per il sistema trovo
ridicolo che si debbano scrivere applicazioni che poggiano sul
processore. Se il processore ha una caratteristica importante, e' il
sistema che la deve mettere a disposizione. Cosi' come sta alle
applicazioni mettermi a disposizione le funzioni del sistema: mica mi
devo scrivere il software per usare Textedit o le librerie di quicktime.


 Be', tutta la conferenza e' per gli sviluppatori... :D
è quello che ho scritto, ma "i keynote" non sono sempre e solo per
sviluppatori ;D
-- 
.zen lo specifico

 processore.
se fai reverse engineering nel ragionamento arrivi a capire che tutto (o
quasi) dipende dalla cpu :D
-- 
.zen al contrario

 quel dato processore
Ma c'e' ancora gente che scrive in assembly?
No, perche' che io sappia, da quando esistono i sistemi operativi una
finestra si apre dicendo al sistema "apri una finestra", non mandando
microcodice a un processore. Ma forse *anche* la programmazione e'
tornata agli anni '70 .-D


 finestra si apre dicendo al sistema "apri una finestra"
Eggrazie. Te come glielo dici "apri una finestra"?
Semplice: scrivi una riga di codice simile a:
[unaFinestra makeKeyAndOrderFront:nil]; // cocoa
Il compilatore la legge e (qui viene il bello) _trasforma quella linea
nelle ISTRUZIONI MACCHINA CORRISPONDENTI alla chiamata al sistema
operativo di cui sopra_, che vengono scritte nel file eseguibile vero e
proprio (quello che sta in Mostra contenuto pacchetto > Contents > MacOS
di una .app qualsiasi).
Se io faccio una app per x86, devo ricompilare il codice in modo che il
compilatore, incontrando quella linea, scriva le istruzioni macchina x86
corrispondenti. Per PowerPC, stessa cosa, ma il risultato nei due casi
e' ovviamente differente.
Il sistema operativo non fa magie, si limita a darmi la possibilita' di
fare la chiamata (ovvero: ha il codice che realizza effettivamente una
finestra sullo schermo). Ma un computer, in realta', non sa eseguire
alcun comando che non sia scritto come una sequenza di istruzioni di
codice macchina del proprio processore. E per dare un'istruzione del
tipo "chiedi al sistema operativo di mostrare una finestra", gliela devo
dare al processore nel suo codice macchina.
Spero di essermi spiegato decentemente.


 sviluppatori ;D
Ops, a leggere di fretta... :p


 dare al processore nel suo codice macchina.
No, la devi dare al sistema nel suo linguaggio. E' il sistema che prende
le tue istruzioni e le manda al processore, non viceversa. A meno che tu
abbia deciso di parlare direttamente al processore, e allora auguri per
i tuoi programmi. Io un word processor fatto da te non lo comprerei .-)


 
Il sistema mette a disposizione delle librerie e delle IPC. Il tutto 
permette di sfruttare codice gia' scritto e messo in librerie, le quali 
sono compilate secondo il processore, e vari sistemi per far dialogare 
le applicazioni tra di loro.
Le librerie, sono compilate sul "tal" processore e le applicazioni che 
ne fanno uso devono essere compilate per "tal" processore.
Morale della favola: un'applicazione compilata per x86 non girera' anche 
su PPC. E infatti guarda un po', le versioni di LinuxPPC, hanno tutte 
applicazioni appositamente compilate per processori PPC, altrimenti le 
applicazioni proprio non funzionerebbero.
Non mi sto ad innoltrare oltre, di info e' piena la rete....ma tu 
toglimi una curiosita'....su quali basi dici cio' in maniera' cosi' 
convinta ? ;)
Ciao
	MaX

 non erano gli AMD questi?
Quelli sono cosě da anni: gli ultimi, i penultimi, i terzultimi...

 convinta ? ;)
Mi fido del sistema fin dal CP/M. C'era una bellissima tabella di
indirizzi, una manciata di chiamate al sistema, usavi quelle e il tuo
programma andava su qualunque macchina che girasse in CP/M.
Nell'eventualita' (improbabile, eh) che capitasse una macchina in CP/M
col 6502 al posto dello Z80, al massimo avrei dovuto cambiare le
istruzioni di jump. Oh, certo, avrei potuto usare la page zero del 6502
e rendere il mio programma, pardon, la mia serie di chiamate al sistema,
incompatibile col resto del mondo. Indovina un po': non l'avrei fatto.
(Ho perso brevemente questa fiducia nell'OS con il DOS che non era
compatibile con se' stesso e la roba andava sul 50% delle macchine. Ma
in questo caso parlare col processore sarebbe stato anche peggio. Alla
fine l'unica cosa sicura era compilare sulla macchina dove il programma
doveva girare: fare il binario su un IBM e cercare di eseguirlo su un
Olivetti gia' dava problemi).
Comunque qui si parlava di *riscrivere le applicazioni* o addirittura di
"non sviluppare piu' per PPC", non di ricompilare. Se e' questione di
ricompilare, basta un drag and drop su un traduttore. Se non basta un
traduttore significa che l'applicazione e' scritta da un superfigo che
*sa parlare col computer*.
E si', lo so che oggi i programmi sono *tutti* scritti da vasti gruppi
di hobbysti con poco tempo da perdere e tanta voglia di sentirsi fighi.


> Ma c'e' ancora gente che scrive in assembly?
Tutti quelli (migiaia, non certo milioni) che sviluppano software
(non a livello amatoriale) dove il fattore velocità è ancora il più
importante, tipo l'elaborazione delle immagini, dei suoni,
compressione, reti neurali, sistemi di riconoscimento e roba del genere.
In ogni caso, in queste applicazioni cpu-intensive la parte in assembler
riguarda solo quelle poche centinaia se non migliaia di istruzioni
che compongono il "core" dell'applicazione, il restante 95%
del programma continuerà ad essere scritto in un linguaggio a più
alto livello.
Nell'ipotesi di cambio di processore la parte in assembler deve
essere completamente riscritta, mentre il restante codice và ritoccato
poco o niente (a meno che non si cambi anche il sistema operativo
sottostante).
Ciao

 per i 64 bit del G5) non si buttano nel cesso in questo modo...
Anch' io resto dubbioso.
Del resto penso che in caso di passaggio, il supporto
al ppc resterebbe per 4-5 anni (massimo?) 

 compressione, reti neurali, sistemi di riconoscimento e roba del genere.
Secondo me nemmeno questi. Se hai hardware proprietario scrivi un driver
e lo attacchi al sistema, o lo piazzi in OF direttamente sulla scheda, o
ambedue le cose. Per tutto il resto mi sa che si usino linguaggi vari a
livello piu' o meno alto, ma che l'assembly non lo usi davvero nessuno
se non gli sviluppatori del sistema. Sviluppare per un processore
specifico equivale a tagliarsi le p*lle da soli.
In ogni caso, tra il riscrivere un pezzetto di poche applicazioni
specialistiche e il "non sviluppare piu' software per PPC" mi pare che
ce ne passi .-)
In realta' il passaggio da 9 a X e' stato molto piu' un casino di quello
da 68x00 a PPC, per dire: cambiare il sistema e' stato un trauma,
cambiare il processore, boh, io mica me ne sono accorto. Se domani
mettono un pentium nel mio G5 e ricompilano il sistema che differenza
vuoi che faccia? I programmi scritti bene non se ne accorgerebbero
nemmeno. Al limite, appunto, non funzionerebbero alcune app mirate, ma
si tratterebbe di utility molto specializzate o di qualche programma
della Digidesign .-D


 *sa parlare col computer*.
Calma, calma.
Oggigiorno sul Mac siamo fortunati ad avere gcc come compilatore, che e'
ragionevolmente cross-platform. Io posso dare un listato Objective-C
(Cocoa) a gcc sul Mac e lo compila; poi posso passarlo a Linux + GNUStep
e nel 99% dei casi lo compila lo stesso. Comodo, eh?
I problemi sono:
 - le estensioni vettoriali, che sono diverse tra i processori in
questione _E_ non del tutto compatibili tra loro. AltiVec si accede
scrivendo assembler o utilizzando estensioni di sintassi al C, capita da
gcc. SSE del Pentium e dell'Athlon non li conosco molto bene, ma e'
probabile che non supportino tutti i concetti e le operazioni allo
stesso modo di AltiVec e che la sintassi del gcc (se c'e') sia
differente; il che vuol dire che con somma probabilita' se usi AltiVec
dovrai riscrivere dei pezzi di codice da capo.
 - idem se per qualche motivo scrivi dei pezzi del programma
direttamente in assembly per ottenere qualche effetto particolare o la
massima performance (leggi: giochi...).
Quindi la risposta e': dal sorgente PUOI generare applicazioni per piu'
piattaforme senza troppi problemi (andando di #ifdef se e' il caso per
mascherare porzioni di codice per un sistema e porzioni per un altro).
Ma: o distribuisci i sorgenti, oppure compili la tua applicazione piu'
volte (per come e' fatto Mac OS X puoi avere entrambi gli eseguibili
nello stesso pacchetto .app, come ai tempi dei pacchetti sia OS X che OS
9, ma sempre due volte devi compilarlo il programma).


 massima performance (leggi: giochi...).
Giusto per prevenire... non solo giochi. Anche molte applicazioni di
calcolo (scientifico e non), algoritmi (che so io, codec), eventualmente
filtri audio e video... insomma, di cose candidate per essere scritte in
codice macchina ce ne sono tante.
E no, non e` il mio mestiere. Io piu` sto lontano dall'ASM e piu` sono
in pace con il mondo.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto
pretenderanno che tu torni indietro/e ti costringeranno a partorire per
poi chiamarlo figlio della colpa / e tu una Maddalena da pentire

 non erano gli AMD questi?
Che io sappia si.


 in pace con il mondo.
Quanto ti capisco, ho l'esame di ASM del 68k tra tre settimane e
purtroppo e' il piu' facile degli esami che devo dare... :'(


 
Allora forse non ci eravamo solamente capiti...io intendevo 
*ricompilazione*.
Avevo capitp che tu intendessi che un programma Y potesse girare su 
architetture differenti senza neppure doverlo ricompilare.
Ok :)
Ciao
	MaX

 basati su x86 non erano pc (
argh, volevo dire PC-98
Comunque l' idea di Arruba di chip intelloidi che sebbene spacciati per x-86
siano risc  che ottengano la compatibilità x-86  tramite uno strato di 
microcodice programmabile,
e l' eventuale avanzata possibilità che cambiando tale codice si ottengano 
PPC
compatibili, vera o no, é qualcosa di ganzo :)
CPU general purpose. 

 purtroppo e' il piu' facile degli esami che devo dare... :'(
Esame di ASM 68k? Ma a che pro?
Io un po' di ASM 68k lo maneggiavo da ragazzino (tipo non dico 10 anni
fa, ma quasi) e al momento ho rimosso tutto... ma serve a qualcosa fare
un esame su tale soggetto *ora*?
Comunque se puo` consolarti ho un'esame di Logica fra 5 giorni (e adesso
filo a studiare), uno di Fisica (e quello vabbe, non e` difficile) fra
un tre settimane, contestualmente un progetto di Analisi e Verifica
Software da fare (tutta roba nuova, prodotta da 0, non ci sono testi che
trattano le stesse cose che stiamo facendo). Poi in giro ho un esame di
Teoria analitica dei numeri... vabbe`.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 architetture differenti senza neppure doverlo ricompilare.
No ma perche' no, direi. Se il programma si basa esclusivamente sul
sistema e il sistema e' stato adattato o riscritto per un nuovo
processore non dovrebbero esserci problemi. Sto parlando di programmi,
non di driver o codec o comunque pezzi di sistema operativo, che
dovrebbero essere di competenza degli sviluppatori veri.
Per dire, Word o Safari o Photoshop non dovrebbero contemplare
chiacchierate col processore.


 Teoria analitica dei numeri... vabbe`.
In bocca al lupo ;)


 In bocca al lupo ;)
Crepi, ed in bocca al lupo anche a te :)


 la mia obiezione era su un corso di Assembly.
Non e' il solo argomento dell'esame; si parlera' anche di struttura del
calcolatore.
Essendo pero' l'argomento che sto studiando adesso, ogni volta che ne
parlo, per me, e' l'esame di Assembly ^_^;


 adesso domani č oggi, quindi..
Quindi aspetto 'sta sera :-D
Comunque alcune migliaia di euro in hw le ho gia' spese: se mai dovesse
esserci "la rivoluzione", per un bel po' di anni, IO non me ne
preoccupero'.
-- 
"25 maggio: "you'll never walk alone" - Tessera #69
http://snipurl.com/f5e7

 elaboratori l'ho fatto usando l'assembler del MIPS.
Speriamo in bene... l'anno scorso usavano un fintoassembler per la JVM,
questo e' il primo con il 68k... speriamo in bene...


 calcolatore.
Ah, ok :))
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto
