Domanda niubba su compilazione sorgenti
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- prometeo79
- Linux 4.x

- Messaggi: 1278
- Iscritto il: gio 17 mar 2005, 0:00
- Slackware: 12
- Località: Torino
Domanda niubba su compilazione sorgenti
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
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
- elettronicha
- Master

- Messaggi: 1712
- Iscritto il: mer 13 apr 2005, 0:00
- Località: Torino
- Contatta:
- prometeo79
- Linux 4.x

- Messaggi: 1278
- Iscritto il: gio 17 mar 2005, 0:00
- Slackware: 12
- Località: Torino
- elettronicha
- Master

- Messaggi: 1712
- Iscritto il: mer 13 apr 2005, 0:00
- Località: Torino
- Contatta:
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.
- Paoletta
- Staff

- Messaggi: 3975
- Iscritto il: lun 25 apr 2005, 0:00
- Slackware: 14.2 - 64 bit
- Desktop: fluxbox
- Località: Varese
già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.
- elettronicha
- Master

- Messaggi: 1712
- Iscritto il: mer 13 apr 2005, 0:00
- Località: Torino
- Contatta:
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.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?
- prometeo79
- Linux 4.x

- Messaggi: 1278
- Iscritto il: gio 17 mar 2005, 0:00
- Slackware: 12
- Località: Torino
Ok, credo di seguirtielettronicha ha scritto: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.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?
Questa invece mi sfugge, cioè?elettronicha ha scritto:I problemi sorgono con set di istruzioni caratteristici di una certa architettura.
- albatros
- Iper Master

- Messaggi: 2098
- Iscritto il: sab 4 feb 2006, 13:59
- Kernel: 6.18.0
- Desktop: gnome and lxqt
- Distribuzione: Ubuntu 24.04 & FC 41
- Località: Darmstadt - Germania
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.
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.
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.
- prometeo79
- Linux 4.x

- Messaggi: 1278
- Iscritto il: gio 17 mar 2005, 0:00
- Slackware: 12
- Località: Torino
