slacky.eu

Ciao a tutti

Mi è sorta ultimamente una perplessita: quando compilo programmi e kernel da sorgenti, sono io ha decidere se fornirgli istruzioni a 64 o 32 bit? Nel senso i sorgenti sono già a 32 bit/64bit o sono "vergini" e sono io a dirgli in che modo devono lavorare?
Perdonate l'ignoranza e la niubbagine della domanda ma non sono riuscito a trovare nulla di preciso in merito

Buoni sorgenti non dipendono dall'architettura, li ottimizza il compilatore attraverso i parametri che gli passi.

PS: per maggiori dettagli aspetta che ti rispondano gli esperti informatici.

Di solito il programmatore definisce il tipo e poi sta al compilatore stabilire quanti con quanti bit rappresentare quel tipo, ma dipende sempre dai sorgenti.

Quindi dovranno esistere sorgenti per la compilazione a 32 bit e quelli per la compilazione a 64, il compilatore serve solo a ottimizzarli ma non decide l'istruzione, giusto?

Non è solo questione di tipi: per esempio, un intero su macchine a 32 bit è costituito da 32 bit e su macchine a 64 bit da 64, ma un intero in un sorgente C/C++/Java/... è sempre dichiarato come 'int'. In genere la portabilità sui tipi è semplice da realizzare. I problemi sorgono con set di istruzioni caratteristici di una certa architettura.

elettronicha ha scritto:Non è solo questione di tipi: per esempio, un intero su macchine a 32 bit è costituito da 32 bit e su macchine a 64 bit da 64, ma un intero in un sorgente C/C++/Java/... è sempre dichiarato come 'int'. In genere la portabilità sui tipi è semplice da realizzare. I problemi sorgono con set di istruzioni caratteristici di una certa architettura.

già

prometeo79 ha scritto:Quindi dovranno esistere sorgenti per la compilazione a 32 bit e quelli per la compilazione a 64, il compilatore serve solo a ottimizzarli ma non decide l'istruzione, giusto?

No, è il contrario! Hai mai visto su sourceforge una serie interminabile di sorgenti? no, al massimo avrai visto binari (ossia file compilati) per architetture diverse 386, 486, 586, 686, 64bit, sparc, powerpc, etc.

elettronicha ha scritto:

prometeo79 ha scritto:Quindi dovranno esistere sorgenti per la compilazione a 32 bit e quelli per la compilazione a 64, il compilatore serve solo a ottimizzarli ma non decide l'istruzione, giusto?

No, è il contrario! Hai mai visto su sourceforge una serie interminabile di sorgenti? no, al massimo avrai visto binari (ossia file compilati) per architetture diverse 386, 486, 586, 686, 64bit, sparc, powerpc, etc.

Ok, credo di seguirti

elettronicha ha scritto:I problemi sorgono con set di istruzioni caratteristici di una certa architettura.

Questa invece mi sfugge, cioè?

Cioé, anche se di solito sono casi rari, i problemi sorgono quando usi delle istruzioni che funzionano solo su certi tipi di cpu...
Ad esempio la modalità protetta non è disponibile su un 8086...
Il compilatore è sostanzialmente un traduttore da un linguaggio di programmazione al linguaggio macchina: di solito il codice non fa specifici riferimenti ad una particolare architettura e ci pensa il compilatore a sfruttare al massimo le possibilità offerte dalla tua architettura, ad esempio se per i calcoli in virgola mobile c'è un'unità apposita che li può fare più velocemente sfrutterà quella e non le procedure più complesse per le cpu che non ce l'hanno...
Eventuali problemi ci potrebbero essere con codice scritto male, ad esempio, in c, quando non viene usato sizeof per sapere con quanti bit viene rappresentato un tipo di dati e non si prendono le relative precauzioni, ma di solito quasi nessuno commette leggerezze di questo tipo...
Programmi scritti in c/c++ sono di solito dunque molto portabili, di norma li puoi ricompilare a 64bit specificandolo al compilatore e linkandoli a librerie a 64 bit ed eseguendoli poi con un kernel a 64 bit (puoi eseguire anche programmi a 32 bit nelle architetture intel/amd athlon purché linkati a librerie a 32 bit anche se il sistema è a 64 bit con os a 64 bit).
L'assembly, per sua natura, è invece ritagliato su misura per una certa famiglia di cpu e lì, sì, è proprio il codice ad essere scritto per 32 o 64 bit.
Potresti avere problemi con programmi in c/c++ se richiedono tassativamente librerie che sfruttano dispositivi che la tua macchina non ha, ad esempio le istruzioni sse2 su un 486 o altri tipi di istruzione, ad esempio, per sistemi multiprocessore...

Scusa se sono stato molto approssimativo, spero di aver reso l'idea...

P.S.
Dato che non sono un programmatore esperto, ma ho scritto solo qualcosina a uso personale in c standard, chiedo venia ai programmatori più esperti se sono stato poco rigoroso e forse inesatto sui metodi avanzati di programmazione per architetture specifiche.

Per set di istruzioni si intende un insieme di istruzioni che la cpu è in grado di gestire nativamente.

Con l'esempio spero di farti capire meglio la questione. Alcuni anni fa l'intel inserirì nei sui processori il set di istruzioni sse, necessarie per gestire formati multimediali. In questo modo, la macchina, è in grado di processare con maggiore facilità le informazioni. Nel caso in cui mancano queste istruzioni specifiche, si può sempre svolgere un'operazione particolare, ma si impiega più tempo perchè bisogna fare uso di altre istruzioni.

Alcune volte usare il set di istruzioni specifico di un'architettura migliora la velocità di un programma, ma come risvolto della medaglia si ha una minore portabilità del codice, dovuto al fatto che non tutte le architetture supportano lo stesso set di istruzioni.

Che dire!
Risposte veloci e precise come al solito. Ora ho le idee molto più chiare pur da profano della programmazione.
Grazie a tutti