Murphy
29-01-2008, 11:52
Mi servirebbe un compilatore possibilmente gratis che gira sotto win xp!
Ciao e gRazie
Ciao e gRazie
View Full Version : [C] Compilatore gratis per win XP
VICIUS
29-01-2008, 11:54
C'è mingw che contiene l'ottimo gcc. Altrimenti se scarichi Visual C++ Express dal sito della Microsoft dentro c'è anche il compilatore.
Murphy
29-01-2008, 11:56
C'è mingw che contiene l'ottimo gcc. Altrimenti se scarichi Visual C++ Express dal sito della Microsoft dentro c'è anche il compilatore.
gentilissimo, tu quale consigli?
gentilissimo, tu quale consigli?
k0nt3
29-01-2008, 11:58
usa MinGW
immagino che vuoi anche un ambiente di sviluppo.. quindi ti consiglio codeblocks che si installa così: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Windows
immagino che vuoi anche un ambiente di sviluppo.. quindi ti consiglio codeblocks che si installa così: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Windows
VICIUS
29-01-2008, 12:02
Se non hai paura di sporcarti le mani con la console e qualche editor di testo minimale io userei gcc. Altrimenti vai per quello di mamma ms. :)
71104
29-01-2008, 12:27
usa il compilatore Microsoft: implementa costrutti che il gcc non implementa (SEH) ed inoltre dovessi mai utilizzare blocchi di assembly la sintassi Intel (usata da Microsoft) è N volte migliore della sintassi GNU (N grande a piacere).
il consiglio di scaricare Visual C++ solo per la comodità dell'IDE è valido ma non più di tanto perché per MinGW esiste l'IDE Code::Blocks, incompleto ma promettente.
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale, che col MinGW non credo compili correttamente a causa dei #pragma e di qualche sintassi non standard usata da Microsoft (struct anonime).
il consiglio di scaricare Visual C++ solo per la comodità dell'IDE è valido ma non più di tanto perché per MinGW esiste l'IDE Code::Blocks, incompleto ma promettente.
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale, che col MinGW non credo compili correttamente a causa dei #pragma e di qualche sintassi non standard usata da Microsoft (struct anonime).
ilsensine
29-01-2008, 12:34
usa il compilatore Microsoft
compilatore noto per la sua aderenza allo standard C99
ed inoltre dovessi mai utilizzare blocchi di assembly la sintassi Intel (usata da Microsoft) è N volte migliore della sintassi GNU (N grande a piacere).
utilizzabile anche dal gcc
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale
Questo finalmente può essere un valido motivo. Mingw fornisce delle msvcrt vecchie come il cucco.
compilatore noto per la sua aderenza allo standard C99
ed inoltre dovessi mai utilizzare blocchi di assembly la sintassi Intel (usata da Microsoft) è N volte migliore della sintassi GNU (N grande a piacere).
utilizzabile anche dal gcc
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale
Questo finalmente può essere un valido motivo. Mingw fornisce delle msvcrt vecchie come il cucco.
k0nt3
29-01-2008, 12:36
usa il compilatore Microsoft: implementa costrutti che il gcc non implementa (SEH)
non vedo perchè dovrebbe implementarli visto che non fanno parte del linguaggio C
ed inoltre dovessi mai utilizzare blocchi di assembly la sintassi Intel (usata da Microsoft) è N volte migliore della sintassi GNU (N grande a piacere).
in ogni caso ha chiesto un compilatore C
il consiglio di scaricare Visual C++ solo per la comodità dell'IDE è valido ma non più di tanto perché per MinGW esiste l'IDE Code::Blocks, incompleto ma promettente.
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale, che col MinGW non credo compili correttamente a causa dei #pragma e di qualche sintassi non standard usata da Microsoft (struct anonime).
puoi usare MSVC anche con codeblocks. ho consigliato MinGW perchè, senza specificare particolari opzioni che non userà mai nessuno, aderisce meglio allo standard
non vedo perchè dovrebbe implementarli visto che non fanno parte del linguaggio C
ed inoltre dovessi mai utilizzare blocchi di assembly la sintassi Intel (usata da Microsoft) è N volte migliore della sintassi GNU (N grande a piacere).
in ogni caso ha chiesto un compilatore C
il consiglio di scaricare Visual C++ solo per la comodità dell'IDE è valido ma non più di tanto perché per MinGW esiste l'IDE Code::Blocks, incompleto ma promettente.
edit - altra ragione per preferire il compilatore Microsoft: puoi utilizzare il Platform SDK originale, che col MinGW non credo compili correttamente a causa dei #pragma e di qualche sintassi non standard usata da Microsoft (struct anonime).
puoi usare MSVC anche con codeblocks. ho consigliato MinGW perchè, senza specificare particolari opzioni che non userà mai nessuno, aderisce meglio allo standard
71104
29-01-2008, 12:51
non vedo perchè dovrebbe implementarli visto che non fanno parte del linguaggio C perché altrimenti non può catturare le eccezioni
puoi usare MSVC anche con codeblocks. ho consigliato MinGW perchè, senza specificare particolari opzioni che non userà mai nessuno, aderisce meglio allo standard se deve programmare su Windows davo per scontato che gli servisse un compilatore C che aderisse a Windows. metti che deve usare un'API che in certi casi lancia un'eccezione? metti che deve usare funzioni non importate dal windows.h di MinGW? metti che deve scrivere codice assembly :asd:?
puoi usare MSVC anche con codeblocks. ho consigliato MinGW perchè, senza specificare particolari opzioni che non userà mai nessuno, aderisce meglio allo standard se deve programmare su Windows davo per scontato che gli servisse un compilatore C che aderisse a Windows. metti che deve usare un'API che in certi casi lancia un'eccezione? metti che deve usare funzioni non importate dal windows.h di MinGW? metti che deve scrivere codice assembly :asd:?
71104
29-01-2008, 12:53
puoi usare MSVC anche con codeblocks. giusto, ma tra un IDE incompleto e promettente e un IDE completo e di qualità gli ho consigliato il secondo
71104
29-01-2008, 12:55
compilatore noto per la sua aderenza allo standard C99 alcune estensioni Microsoft al C assomigliano a quelle introdotte dal C99 (per esempio è possibile usare CONST); tuttavia di questa mancanza non s'è mai lamentato nessuno, o forse non si sono lamentati abbastanza; insomma, prevedo che non sarà un grosso problema.
utilizzabile anche dal gcc se n'era discusso poco tempo fa, ma mi pare che tu stesso avevi detto che la sintassi Intel si può usare solo limitatamente
utilizzabile anche dal gcc se n'era discusso poco tempo fa, ma mi pare che tu stesso avevi detto che la sintassi Intel si può usare solo limitatamente
k0nt3
29-01-2008, 13:00
perché altrimenti non può catturare le eccezioni
se deve programmare su Windows davo per scontato che gli servisse un compilatore C che aderisse a Windows. metti che deve usare un'API che in certi casi lancia un'eccezione? metti che deve usare funzioni non importate dal windows.h di MinGW? metti che deve scrivere codice assembly :asd:?
io davo per scontato che gli servisse un compilatore C che aderisse al C :doh:
ovviamente se avesse specificato che gli serviva usare le le win32 non avrei consigliato MinGW, ma non è il caso e quindi consiglio ancora MinGW + codeblocks (che non trovo per nulla incompleto).
Visual C++ è più di quello che gli serve nel 100% dei casi :asd:
se deve programmare su Windows davo per scontato che gli servisse un compilatore C che aderisse a Windows. metti che deve usare un'API che in certi casi lancia un'eccezione? metti che deve usare funzioni non importate dal windows.h di MinGW? metti che deve scrivere codice assembly :asd:?
io davo per scontato che gli servisse un compilatore C che aderisse al C :doh:
ovviamente se avesse specificato che gli serviva usare le le win32 non avrei consigliato MinGW, ma non è il caso e quindi consiglio ancora MinGW + codeblocks (che non trovo per nulla incompleto).
Visual C++ è più di quello che gli serve nel 100% dei casi :asd:
Murphy
29-01-2008, 13:08
Grazie a tutti per i consigli, ma non volevo niente di potente, mi bastano le cose elementari per adesso!
sto usando questo:
MinGW Developer Studio
che ha anche l'editor, per quello che ci devo fare in questo periodo mi basta ed avanza!
Invece dovrei usare linux, distro ubuntu, il compilatore mi sembra che già c'è , è il gcc, serve altro?
Illuminatemi!:D
Grazie
ciao
sto usando questo:
MinGW Developer Studio
che ha anche l'editor, per quello che ci devo fare in questo periodo mi basta ed avanza!
Invece dovrei usare linux, distro ubuntu, il compilatore mi sembra che già c'è , è il gcc, serve altro?
Illuminatemi!:D
Grazie
ciao
k0nt3
29-01-2008, 13:18
Grazie a tutti per i consigli, ma non volevo niente di potente, mi bastano le cose elementari per adesso!
sto usando questo:
MinGW Developer Studio
che ha anche l'editor, per quello che ci devo fare in questo periodo mi basta ed avanza!
Invece dovrei usare linux, distro ubuntu, il compilatore mi sembra che già c'è , è il gcc, serve altro?
Illuminatemi!:D
Grazie
ciao
se usi ubuntu puoi benissimo accontentarti di gcc + un qualsiasi editor di testo (es. gedit). installa il pacchetto build-essential per avere tutto quello che ti serve per compilare.
se vuoi qualcosa di un pò più complesso puoi dare un'occhiata a anjuta, ma non credo sia necessario ai tuoi scopi
sto usando questo:
MinGW Developer Studio
che ha anche l'editor, per quello che ci devo fare in questo periodo mi basta ed avanza!
Invece dovrei usare linux, distro ubuntu, il compilatore mi sembra che già c'è , è il gcc, serve altro?
Illuminatemi!:D
Grazie
ciao
se usi ubuntu puoi benissimo accontentarti di gcc + un qualsiasi editor di testo (es. gedit). installa il pacchetto build-essential per avere tutto quello che ti serve per compilare.
se vuoi qualcosa di un pò più complesso puoi dare un'occhiata a anjuta, ma non credo sia necessario ai tuoi scopi
Murphy
29-01-2008, 13:22
se usi ubuntu puoi benissimo accontentarti di gcc + un qualsiasi editor di testo (es. gedit). installa il pacchetto build-essential per avere tutto quello che ti serve per compilare.
se vuoi qualcosa di un pò più complesso puoi dare un'occhiata a anjuta, ma non credo sia necessario ai tuoi scopi
devo compilare da riga di comando o con l'editor riesco a compilare?
scusa ma di linux ne so poco!
Grazie
se vuoi qualcosa di un pò più complesso puoi dare un'occhiata a anjuta, ma non credo sia necessario ai tuoi scopi
devo compilare da riga di comando o con l'editor riesco a compilare?
scusa ma di linux ne so poco!
Grazie
k0nt3
29-01-2008, 13:27
devo compilare da riga di comando o con l'editor riesco a compilare?
scusa ma di linux ne so poco!
Grazie
se usi l'editor di testo devi usare poi il terminale per compilare. ma non è per nulla difficile per programmi banali:
gcc nome_file.c -o nome_eseguibile
da digitare nella directory dove hai salvato il sorgente.
altrimenti puoi usare anjuta come ti dicevo oppure MinGW Developer Studio anche su linux (a quanto ho capito)
scusa ma di linux ne so poco!
Grazie
se usi l'editor di testo devi usare poi il terminale per compilare. ma non è per nulla difficile per programmi banali:
gcc nome_file.c -o nome_eseguibile
da digitare nella directory dove hai salvato il sorgente.
altrimenti puoi usare anjuta come ti dicevo oppure MinGW Developer Studio anche su linux (a quanto ho capito)
Murphy
29-01-2008, 13:53
se usi l'editor di testo devi usare poi il terminale per compilare. ma non è per nulla difficile per programmi banali:
gcc nome_file.c -o nome_eseguibile
da digitare nella directory dove hai salvato il sorgente.
altrimenti puoi usare anjuta come ti dicevo oppure MinGW Developer Studio anche su linux (a quanto ho capito)
Grazie gentilissimo:)
gcc nome_file.c -o nome_eseguibile
da digitare nella directory dove hai salvato il sorgente.
altrimenti puoi usare anjuta come ti dicevo oppure MinGW Developer Studio anche su linux (a quanto ho capito)
Grazie gentilissimo:)
ilsensine
29-01-2008, 14:50
tuttavia di questa mancanza non s'è mai lamentato nessuno, o forse non si sono lamentati abbastanza; insomma, prevedo che non sarà un grosso problema.
Almeno gli utilizzatori di ffmpeg per windows si sono lamentati eccome...
Volendo usare il VC, sono costretti per forza ad usare le librerie di ffmpeg compilate con mingw. Una bella polpetta...
se n'era discusso poco tempo fa, ma mi pare che tu stesso avevi detto che la sintassi Intel si può usare solo limitatamente
Cambia il modo in cui il codice asm si integra con il "contorno" (variabili, passaggio/restituzione parametri ecc.). Il gcc qui ha una sintassi un pò sua e leggermente più complicata, ma - te lo dico perché mi è capitato di sbatterci il grugno anni fa - estremamente flessibile e potente.
Almeno gli utilizzatori di ffmpeg per windows si sono lamentati eccome...
Volendo usare il VC, sono costretti per forza ad usare le librerie di ffmpeg compilate con mingw. Una bella polpetta...
se n'era discusso poco tempo fa, ma mi pare che tu stesso avevi detto che la sintassi Intel si può usare solo limitatamente
Cambia il modo in cui il codice asm si integra con il "contorno" (variabili, passaggio/restituzione parametri ecc.). Il gcc qui ha una sintassi un pò sua e leggermente più complicata, ma - te lo dico perché mi è capitato di sbatterci il grugno anni fa - estremamente flessibile e potente.
71104
29-01-2008, 16:59
io davo per scontato che gli servisse un compilatore C che aderisse al C :doh: se il suo scopo fosse stato solo quello di scrivere codice C puro non avrebbe chiesto un compilatore C specificamente per Windows visto che ha detto di avere un'installazione di Ubuntu.
e quindi consiglio ancora MinGW + codeblocks (che non trovo per nulla incompleto). lo è per ammissione degli autori stessi :rolleyes:
e quindi consiglio ancora MinGW + codeblocks (che non trovo per nulla incompleto). lo è per ammissione degli autori stessi :rolleyes:
71104
29-01-2008, 17:01
Visual C++ è più di quello che gli serve nel 100% dei casi :asd: così gli stai dando del programmatore mediocre
71104
29-01-2008, 17:04
Almeno gli utilizzatori di ffmpeg per windows si sono lamentati eccome...
Volendo usare il VC, sono costretti per forza ad usare le librerie di ffmpeg compilate con mingw. Una bella polpetta... embe' che c'è di male?
Cambia il modo in cui il codice asm si integra con il "contorno" (variabili, passaggio/restituzione parametri ecc.). Il gcc qui ha una sintassi un pò sua e leggermente più complicata, ma - te lo dico perché mi è capitato di sbatterci il grugno anni fa - estremamente flessibile e potente. più potente di quella Intel? in un blocco asm scritto per gcc è possibile fare cose che in un blocco asm scritto per CL (compilatore Microsoft) non è possibile fare? se la risposta è no allora il gcc ha perso :)
non c'è alcun motivo di complicare le cose
Volendo usare il VC, sono costretti per forza ad usare le librerie di ffmpeg compilate con mingw. Una bella polpetta... embe' che c'è di male?
Cambia il modo in cui il codice asm si integra con il "contorno" (variabili, passaggio/restituzione parametri ecc.). Il gcc qui ha una sintassi un pò sua e leggermente più complicata, ma - te lo dico perché mi è capitato di sbatterci il grugno anni fa - estremamente flessibile e potente. più potente di quella Intel? in un blocco asm scritto per gcc è possibile fare cose che in un blocco asm scritto per CL (compilatore Microsoft) non è possibile fare? se la risposta è no allora il gcc ha perso :)
non c'è alcun motivo di complicare le cose
AnonimoVeneziano
29-01-2008, 17:09
embe' che c'è di male?
Beh, in effetti è un po' brutto. Ci sono stati per anni problemi di linking anche tra eseguibili con librerie compilate con versioni diverse di G++, figuriamoci tra compilatori diversi. Anche con ICC è la stessa cosa .
Ciao
Beh, in effetti è un po' brutto. Ci sono stati per anni problemi di linking anche tra eseguibili con librerie compilate con versioni diverse di G++, figuriamoci tra compilatori diversi. Anche con ICC è la stessa cosa .
Ciao
71104
29-01-2008, 17:19
problemi tipo? :mbe:
k0nt3
29-01-2008, 17:32
se il suo scopo fosse stato solo quello di scrivere codice C puro non avrebbe chiesto un compilatore C specificamente per Windows visto che ha detto di avere un'installazione di Ubuntu.
mi sfugge il collegamento. il C è tale e quale sia su windows che su linux e io non ho visto nessun riferimento a librerie legate alla piattaforma nei suoi post
così gli stai dando del programmatore mediocre
al contrario, la prima cosa che distingue un buon programmatore da un programmatore mediocre è la scelta degli strumenti più idonei per raggiungere i propri obiettivi :fagiano:
mi sfugge il collegamento. il C è tale e quale sia su windows che su linux e io non ho visto nessun riferimento a librerie legate alla piattaforma nei suoi post
così gli stai dando del programmatore mediocre
al contrario, la prima cosa che distingue un buon programmatore da un programmatore mediocre è la scelta degli strumenti più idonei per raggiungere i propri obiettivi :fagiano:
AnonimoVeneziano
29-01-2008, 17:55
problemi tipo? :mbe:
Problemi di linking o di eseguibili che non partivano :asd:
PS= Comunque leggo ora che il thread parla di C , non so perchè ma ero convinto che si parlasse di C++. Questi problemi c'erano soprattutto col C++.
Problemi di linking o di eseguibili che non partivano :asd:
PS= Comunque leggo ora che il thread parla di C , non so perchè ma ero convinto che si parlasse di C++. Questi problemi c'erano soprattutto col C++.
71104
29-01-2008, 18:23
mi sfugge il collegamento. il C è tale e quale sia su windows che su linux e io non ho visto nessun riferimento a librerie legate alla piattaforma nei suoi post c'è un riferimento a tutta la piattaforma nel titolo
al contrario, la prima cosa che distingue un buon programmatore da un programmatore mediocre è la scelta degli strumenti più idonei per raggiungere i propri obiettivi :fagiano: e Giovanni mangia una mela.
ho capito perfettamente le tue frasi fatte, quello che intendevo dire è che nella frase precedente sembrava che lui non era in grado di utilizzare tutto il surplus di cui parlavi, che sarebbe rimasto in eterno a scrivere programmi in C & librerie standard del C, di quelli che girano in console e ti calcolano la serie di Fibonacci.
al contrario, la prima cosa che distingue un buon programmatore da un programmatore mediocre è la scelta degli strumenti più idonei per raggiungere i propri obiettivi :fagiano: e Giovanni mangia una mela.
ho capito perfettamente le tue frasi fatte, quello che intendevo dire è che nella frase precedente sembrava che lui non era in grado di utilizzare tutto il surplus di cui parlavi, che sarebbe rimasto in eterno a scrivere programmi in C & librerie standard del C, di quelli che girano in console e ti calcolano la serie di Fibonacci.
71104
29-01-2008, 18:24
Problemi di linking o di eseguibili che non partivano :asd: più specificamente...? :mbe:
PS= Comunque leggo ora che il thread parla di C , non so perchè ma ero convinto che si parlasse di C++. Questi problemi c'erano soprattutto col C++. quelli li conosco: ogni tanto la gente si scorda #ifdef __cplsuplus/extern "C" {, si sa. colpa loro comunque, la soluzione al problema c'è, sono loro che se la dimenticano (o non la sanno).
PS= Comunque leggo ora che il thread parla di C , non so perchè ma ero convinto che si parlasse di C++. Questi problemi c'erano soprattutto col C++. quelli li conosco: ogni tanto la gente si scorda #ifdef __cplsuplus/extern "C" {, si sa. colpa loro comunque, la soluzione al problema c'è, sono loro che se la dimenticano (o non la sanno).
AnonimoVeneziano
29-01-2008, 18:35
più specificamente...? :mbe:
C++ ABI Mismatch . Più di così non posso dirti :D Prova a compilare una libreria con G++ 3.0 e poi a compilare un programma linkandolo a quella libreria con G++ 3.4 (ad esempio) e dovrebbe scattare questo problema. (Ma penso basti anche la 3.3 con la 3.4 :D )
quelli li conosco: ogni tanto la gente si scorda #ifdef __cplsuplus/extern "C" {, si sa. colpa loro comunque, la soluzione al problema c'è, sono loro che se la dimenticano (o non la sanno).
Non c'entra con la convivenza tra C e C++ . Sto parlando di solo C++.
Ciao
C++ ABI Mismatch . Più di così non posso dirti :D Prova a compilare una libreria con G++ 3.0 e poi a compilare un programma linkandolo a quella libreria con G++ 3.4 (ad esempio) e dovrebbe scattare questo problema. (Ma penso basti anche la 3.3 con la 3.4 :D )
quelli li conosco: ogni tanto la gente si scorda #ifdef __cplsuplus/extern "C" {, si sa. colpa loro comunque, la soluzione al problema c'è, sono loro che se la dimenticano (o non la sanno).
Non c'entra con la convivenza tra C e C++ . Sto parlando di solo C++.
Ciao
cdimauro
29-01-2008, 19:27
e Giovanni mangia una mela.
ho capito perfettamente le tue frasi fatte
Veramente la sua era un citazione a una mia frase fatta di un paio di giorni fa.
Solo che non mi ha pagato i diritti e adesso gli mando a casa la SIAE a pignorargli tutto quello che ha. :asd:
Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio. ;)
ho capito perfettamente le tue frasi fatte
Veramente la sua era un citazione a una mia frase fatta di un paio di giorni fa.
Solo che non mi ha pagato i diritti e adesso gli mando a casa la SIAE a pignorargli tutto quello che ha. :asd:
Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio. ;)
ilsensine
29-01-2008, 19:44
embe' che c'è di male?
Visto che il gcc per pe64 ancora non c'è, a causa della differente calling convention scelta da Microsoft (o dal gcc, scegli tu), non è possibile utilizzare ffmpeg a 64 bit su Windows ad esempio.
Se il VC fosse stato C99, sarebbe stato possibile...
più potente di quella Intel? in un blocco asm scritto per gcc è possibile fare cose che in un blocco asm scritto per CL (compilatore Microsoft) non è possibile fare? se la risposta è no allora il gcc ha perso :)
non c'è alcun motivo di complicare le cose
Il modo di indicare le condizioni al contorno, sì. Rende più agevole il lavoro al compilatore C, che deve integrare una parte "aliena" in assembler.
Un paio di esempi chiariscono; il primo è veramente banale:
int a=3, b;
asm("" : "=g"(b) : "0"(a) );
Effettua "b = a". Con il constraint "g", il compilatore è libero di mettere a e/o b in memoria o in registri.
In questo esempio imposto tutto buf con il carattere 'A'. Qui i constraint mi sono utili per preparare i registri da utilizzare: sizeof(buf) in ecx, 'A' in eax, buf (puntatore) in edx:
char buf[64];
asm(
"rep stosb"
: : "c"(sizeof(buf)), "a"('A'), "D"(buf)
);
Lo stesso si può fare con i constraint in uscita (ad es. posso informare il compilatore c che il risultato che verrà assegnato ad una certa variabile si trova nel registro xyz), oppure informando il compilatore che un certo registro è stato "sporcato" (in quanto usato per elaborazioni intermedie) e il suo valore potrebbe essere stato invalidato dal blocco assembler. L'ottimizzatore tiene conto di tutti questi vincoli nella fase di ottimizzazione del codice c. Nell'esempio precedente il compilatore è autorizzato a concludere che il registro ebx non è modificato, quindi il suo valore viene mantenuto sia prima che dopo il blocco asm!
La "fatica" quindi non è tanto per lo sviluppatore, ma per aiutare il compilatore!
Visto che il gcc per pe64 ancora non c'è, a causa della differente calling convention scelta da Microsoft (o dal gcc, scegli tu), non è possibile utilizzare ffmpeg a 64 bit su Windows ad esempio.
Se il VC fosse stato C99, sarebbe stato possibile...
più potente di quella Intel? in un blocco asm scritto per gcc è possibile fare cose che in un blocco asm scritto per CL (compilatore Microsoft) non è possibile fare? se la risposta è no allora il gcc ha perso :)
non c'è alcun motivo di complicare le cose
Il modo di indicare le condizioni al contorno, sì. Rende più agevole il lavoro al compilatore C, che deve integrare una parte "aliena" in assembler.
Un paio di esempi chiariscono; il primo è veramente banale:
int a=3, b;
asm("" : "=g"(b) : "0"(a) );
Effettua "b = a". Con il constraint "g", il compilatore è libero di mettere a e/o b in memoria o in registri.
In questo esempio imposto tutto buf con il carattere 'A'. Qui i constraint mi sono utili per preparare i registri da utilizzare: sizeof(buf) in ecx, 'A' in eax, buf (puntatore) in edx:
char buf[64];
asm(
"rep stosb"
: : "c"(sizeof(buf)), "a"('A'), "D"(buf)
);
Lo stesso si può fare con i constraint in uscita (ad es. posso informare il compilatore c che il risultato che verrà assegnato ad una certa variabile si trova nel registro xyz), oppure informando il compilatore che un certo registro è stato "sporcato" (in quanto usato per elaborazioni intermedie) e il suo valore potrebbe essere stato invalidato dal blocco assembler. L'ottimizzatore tiene conto di tutti questi vincoli nella fase di ottimizzazione del codice c. Nell'esempio precedente il compilatore è autorizzato a concludere che il registro ebx non è modificato, quindi il suo valore viene mantenuto sia prima che dopo il blocco asm!
La "fatica" quindi non è tanto per lo sviluppatore, ma per aiutare il compilatore!
k0nt3
29-01-2008, 20:10
Veramente la sua era un citazione a una mia frase fatta di un paio di giorni fa.
Solo che non mi ha pagato i diritti e adesso gli mando a casa la SIAE a pignorargli tutto quello che ha. :asd:
Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio. ;)
:asd: si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela" :asd:
comunque ti avrei potuto anche darti ragione se si trattava di C++, ma per quanto riguarda il C non vedo come un compilatore che non implementa nemmeno l'ultima versione dello standard possa essere considerato la scelta ideale :fagiano:
Solo che non mi ha pagato i diritti e adesso gli mando a casa la SIAE a pignorargli tutto quello che ha. :asd:
Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio. ;)
:asd: si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela" :asd:
comunque ti avrei potuto anche darti ragione se si trattava di C++, ma per quanto riguarda il C non vedo come un compilatore che non implementa nemmeno l'ultima versione dello standard possa essere considerato la scelta ideale :fagiano:
AnonimoVeneziano
29-01-2008, 20:15
Comunque dipende da quello che deve fare.
Visto che vuole programmare in C mi viene da pensare sia per qualche corso universitario o scolastico. Se gli serve solo per passare tale corso e non gli interessa approfondire ulteriormente la programmazione dopo un Visual Studio è eccessivo (E' grosso da scaricare, ci vuole tanto ad installarlo e ad aggiornarlo, occupa parecchio spazio su HD e può essere anche dispersivo o poco intuitivo per uno alle prime armi) . Magari in questo caso un MinGW + Code::blocks è meglio.
Se vuole mettersi a programmare su Win32 in maniera seria allora VS è d'obbligo .
Ciao
Visto che vuole programmare in C mi viene da pensare sia per qualche corso universitario o scolastico. Se gli serve solo per passare tale corso e non gli interessa approfondire ulteriormente la programmazione dopo un Visual Studio è eccessivo (E' grosso da scaricare, ci vuole tanto ad installarlo e ad aggiornarlo, occupa parecchio spazio su HD e può essere anche dispersivo o poco intuitivo per uno alle prime armi) . Magari in questo caso un MinGW + Code::blocks è meglio.
Se vuole mettersi a programmare su Win32 in maniera seria allora VS è d'obbligo .
Ciao
Murphy
29-01-2008, 22:47
Comunque dipende da quello che deve fare.
Visto che vuole programmare in C mi viene da pensare sia per qualche corso universitario o scolastico. Se gli serve solo per passare tale corso e non gli interessa approfondire ulteriormente la programmazione dopo un Visual Studio è eccessivo (E' grosso da scaricare, ci vuole tanto ad installarlo e ad aggiornarlo, occupa parecchio spazio su HD e può essere anche dispersivo o poco intuitivo per uno alle prime armi) . Magari in questo caso un MinGW + Code::blocks è meglio.
Se vuole mettersi a programmare su Win32 in maniera seria allora VS è d'obbligo .
Ciao
Hai centrato il punto, devo fare del codice veloce in C, e mi seccava installare tutto il visual studio che ho(ho poco spazio e il pc pulito:D )!
Mi bastano le chiamate di base, non devo fare niente di eccezionale!
cmq grazie a tutti mi sono fatto una cultura!!!!!!:D
ciao;)
Visto che vuole programmare in C mi viene da pensare sia per qualche corso universitario o scolastico. Se gli serve solo per passare tale corso e non gli interessa approfondire ulteriormente la programmazione dopo un Visual Studio è eccessivo (E' grosso da scaricare, ci vuole tanto ad installarlo e ad aggiornarlo, occupa parecchio spazio su HD e può essere anche dispersivo o poco intuitivo per uno alle prime armi) . Magari in questo caso un MinGW + Code::blocks è meglio.
Se vuole mettersi a programmare su Win32 in maniera seria allora VS è d'obbligo .
Ciao
Hai centrato il punto, devo fare del codice veloce in C, e mi seccava installare tutto il visual studio che ho(ho poco spazio e il pc pulito:D )!
Mi bastano le chiamate di base, non devo fare niente di eccezionale!
cmq grazie a tutti mi sono fatto una cultura!!!!!!:D
ciao;)
71104
29-01-2008, 23:25
C++ ABI Mismatch. per esempio il fatto di non potersi scambiare oggetti di classi STL (vector, map, string, stack...) con una libreria compilata con un altro runtime? ti dirò, quello non solo è un problema stranoto, ma le cause sono addirittura segno di pessimo design da parte dell'autore della libreria. ad ogni modo la soluzione su Windows è compilare i vari pezzi del programma (programma principale, librerie, DLL, ecc.) linkandole alla versione DLL esterna del runtime di Visual C++; quindi basta dare un'occhiata al manifest file.
Prova a compilare una libreria con G++ 3.0 e poi a compilare un programma linkandolo a quella libreria con G++ 3.4 (ad esempio) e dovrebbe scattare questo problema. (Ma penso basti anche la 3.3 con la 3.4 :D ) è come dire che A e B devono andare d'accordo passandosi pezzi di C1 e C2, che entrambi credono essere un unico C; cioè il problema mi sembra palese, se gli autori delle STL di un certo compilatore fossero costretti a mantenere invariato il layout delle loro classi le STL di quel compilatore resterebbero sempre identiche, non migliorerebbero mai... (c'è di buono che non peggiorerebbero :asd: )
Non c'entra con la convivenza tra C e C++ . Sto parlando di solo C++. i principali problemi di linking che riuscivo a concepire erano nel far andare d'accordo i nomi dei simboli decorati e non decorati; quello che hai esposto tu non è un problema di linking; potremmo dire di versioning.
Se il VC fosse stato C99, sarebbe stato possibile... grazie al cavolo, se il MinGW supportasse il formato PE a 64 bit sarebbe stato possibile... :D
c'è una mancanza di impegno da entrambe le parti, chi dei due ha la colpa?
Il modo di indicare le condizioni al contorno, sì. [...] fai conto che io non conosco nulla di sintassi GNU per l'assembly... :|
so solo che gli operandi sono invertiti (non so neanche cosa succeda nelle istruzioni che prendono tre operandi...)
La "fatica" quindi non è tanto per lo sviluppatore, ma per aiutare il compilatore! capirai -.-
e quanti decimi di secondo si guadagnano in fase di compilazione perciò? :mbe:
:asd: si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela" :asd: azz, questo si chiama sgammone :D
comunque ti avrei potuto anche darti ragione se si trattava di C++, ma per quanto riguarda il C non vedo come un compilatore che non implementa nemmeno l'ultima versione dello standard possa essere considerato la scelta ideale :fagiano: leggi i miei post precedenti. ma anzi, faccio anche un esempio pratico: quando si sviluppano drivers per Windows il costrutto __try e il meccanismo di SEH non costituiscono un'opzione, ma sono necessari praticamente sempre perché un driver spesso necessita di accedere a buffers trasmessi da un applicativo user-mode che per questioni di performance non vengono ricopiati in kernel-space; di conseguenza ogni accesso a questi buffers collocati in zona "insicura" deve essere circondato da un __try/__except perché intanto che quel thread accede nel frattempo un altro thread potrebbe deallocare quel buffer di memoria (cosa che solitamente si spera non accada con buffers allocati in kernel space: in quel caso tanto vale lasciare che il BugCheck faccia il suo corso). di conseguenza il SEH non è un'optional quando si programma in questo ambiente, e il gcc non può essere utilizzato per programmare drivers*. ne consegue che la versione GNU del DDK è un lavoro completamente *inutile* :asd:
lo stesso concetto vale in user-mode: se una funzione decide che deve lanciare un'eccezione spera solo che non stai programmando col gcc. oppure se non è una funzione potrebbe essere un errore tuo o di una libreria, come l'accesso ad aree di memoria non allocate o la scrittura su aree di memoria a sola lettura; oppure anche solo l'accesso in lettura o scrittura ad aree di memoria con accesso PAGE_EXECUTE su processori con hardware enforced DEP (NX-bit).
* devi vedere che hanno dovuto fare in ReactOS :asd:
un programmatore italiano del team ha sviluppato una libreria PSEH che gestisce appositamente le eccezioni SEH.
Prova a compilare una libreria con G++ 3.0 e poi a compilare un programma linkandolo a quella libreria con G++ 3.4 (ad esempio) e dovrebbe scattare questo problema. (Ma penso basti anche la 3.3 con la 3.4 :D ) è come dire che A e B devono andare d'accordo passandosi pezzi di C1 e C2, che entrambi credono essere un unico C; cioè il problema mi sembra palese, se gli autori delle STL di un certo compilatore fossero costretti a mantenere invariato il layout delle loro classi le STL di quel compilatore resterebbero sempre identiche, non migliorerebbero mai... (c'è di buono che non peggiorerebbero :asd: )
Non c'entra con la convivenza tra C e C++ . Sto parlando di solo C++. i principali problemi di linking che riuscivo a concepire erano nel far andare d'accordo i nomi dei simboli decorati e non decorati; quello che hai esposto tu non è un problema di linking; potremmo dire di versioning.
Se il VC fosse stato C99, sarebbe stato possibile... grazie al cavolo, se il MinGW supportasse il formato PE a 64 bit sarebbe stato possibile... :D
c'è una mancanza di impegno da entrambe le parti, chi dei due ha la colpa?
Il modo di indicare le condizioni al contorno, sì. [...] fai conto che io non conosco nulla di sintassi GNU per l'assembly... :|
so solo che gli operandi sono invertiti (non so neanche cosa succeda nelle istruzioni che prendono tre operandi...)
La "fatica" quindi non è tanto per lo sviluppatore, ma per aiutare il compilatore! capirai -.-
e quanti decimi di secondo si guadagnano in fase di compilazione perciò? :mbe:
:asd: si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela" :asd: azz, questo si chiama sgammone :D
comunque ti avrei potuto anche darti ragione se si trattava di C++, ma per quanto riguarda il C non vedo come un compilatore che non implementa nemmeno l'ultima versione dello standard possa essere considerato la scelta ideale :fagiano: leggi i miei post precedenti. ma anzi, faccio anche un esempio pratico: quando si sviluppano drivers per Windows il costrutto __try e il meccanismo di SEH non costituiscono un'opzione, ma sono necessari praticamente sempre perché un driver spesso necessita di accedere a buffers trasmessi da un applicativo user-mode che per questioni di performance non vengono ricopiati in kernel-space; di conseguenza ogni accesso a questi buffers collocati in zona "insicura" deve essere circondato da un __try/__except perché intanto che quel thread accede nel frattempo un altro thread potrebbe deallocare quel buffer di memoria (cosa che solitamente si spera non accada con buffers allocati in kernel space: in quel caso tanto vale lasciare che il BugCheck faccia il suo corso). di conseguenza il SEH non è un'optional quando si programma in questo ambiente, e il gcc non può essere utilizzato per programmare drivers*. ne consegue che la versione GNU del DDK è un lavoro completamente *inutile* :asd:
lo stesso concetto vale in user-mode: se una funzione decide che deve lanciare un'eccezione spera solo che non stai programmando col gcc. oppure se non è una funzione potrebbe essere un errore tuo o di una libreria, come l'accesso ad aree di memoria non allocate o la scrittura su aree di memoria a sola lettura; oppure anche solo l'accesso in lettura o scrittura ad aree di memoria con accesso PAGE_EXECUTE su processori con hardware enforced DEP (NX-bit).
* devi vedere che hanno dovuto fare in ReactOS :asd:
un programmatore italiano del team ha sviluppato una libreria PSEH che gestisce appositamente le eccezioni SEH.
71104
29-01-2008, 23:32
Se gli serve solo per passare tale corso e non gli interessa approfondire ulteriormente la programmazione dopo un Visual Studio è eccessivo (E' grosso da scaricare, ci vuole tanto ad installarlo e ad aggiornarlo, occupa parecchio spazio su HD e può essere anche dispersivo o poco intuitivo per uno alle prime armi). può scaricare anche il compilatore da solo credo
ilsensine
29-01-2008, 23:42
grazie al cavolo, se il MinGW supportasse il formato PE a 64 bit sarebbe stato possibile... :D
c'è una mancanza di impegno da entrambe le parti, chi dei due ha la colpa?
La Apple, ovvio :asd:
capirai -.-
e quanti decimi di secondo si guadagnano in fase di compilazione perciò? :mbe:
Non è questo il punto; la scrittura di inline assembler è un grattacapo per il compilatore c. Quali registri ha a disposizione? Quali vengono preservati dall'asm? Come "connettere" al meglio il codice asm con il resto? La memoria viene modificata o meno? I flag di stato sono alterati? Il controllo fine sulle condizioni al contorno da la possibilità al compilatore di non penalizzare l'ottimizzazione del codice c solo perché in mezzo c'è del codice asm.
c'è una mancanza di impegno da entrambe le parti, chi dei due ha la colpa?
La Apple, ovvio :asd:
capirai -.-
e quanti decimi di secondo si guadagnano in fase di compilazione perciò? :mbe:
Non è questo il punto; la scrittura di inline assembler è un grattacapo per il compilatore c. Quali registri ha a disposizione? Quali vengono preservati dall'asm? Come "connettere" al meglio il codice asm con il resto? La memoria viene modificata o meno? I flag di stato sono alterati? Il controllo fine sulle condizioni al contorno da la possibilità al compilatore di non penalizzare l'ottimizzazione del codice c solo perché in mezzo c'è del codice asm.
71104
30-01-2008, 00:47
La Apple, ovvio :asd:
Non è questo il punto; la scrittura di inline assembler è un grattacapo per il compilatore c. Quali registri ha a disposizione? Quali vengono preservati dall'asm? Come "connettere" al meglio il codice asm con il resto? La memoria viene modificata o meno? I flag di stato sono alterati? Il controllo fine sulle condizioni al contorno da la possibilità al compilatore di non penalizzare l'ottimizzazione del codice c solo perché in mezzo c'è del codice asm. hai presente di cosa stiamo parlando? :)
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
in pratica vengono usati solo da chi programma sistemi operativi e chi vuole usare istruzioni specifiche del processore inaccessibili tramite linguaggio e API.
sono una cosa che già di per se' viene usata una volta ogni morte di papa, poi mettici anche che nel 50% dei casi le routines che ne contengono contengono solo quello (e quindi non resta un bel niente da "connettere" col codice C circostante) e nel rimanente 50% sono dei blocchi talmente piccoli che la mancata ottimizzazione loro e delle due istruzioni circostanti a parer mio non è un grave problema.
tutti quelli scervellamenti, imho, sono una soluzione eccessiva: una sintassi incomprensibile per un problema inesistente :stordita:
Non è questo il punto; la scrittura di inline assembler è un grattacapo per il compilatore c. Quali registri ha a disposizione? Quali vengono preservati dall'asm? Come "connettere" al meglio il codice asm con il resto? La memoria viene modificata o meno? I flag di stato sono alterati? Il controllo fine sulle condizioni al contorno da la possibilità al compilatore di non penalizzare l'ottimizzazione del codice c solo perché in mezzo c'è del codice asm. hai presente di cosa stiamo parlando? :)
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
in pratica vengono usati solo da chi programma sistemi operativi e chi vuole usare istruzioni specifiche del processore inaccessibili tramite linguaggio e API.
sono una cosa che già di per se' viene usata una volta ogni morte di papa, poi mettici anche che nel 50% dei casi le routines che ne contengono contengono solo quello (e quindi non resta un bel niente da "connettere" col codice C circostante) e nel rimanente 50% sono dei blocchi talmente piccoli che la mancata ottimizzazione loro e delle due istruzioni circostanti a parer mio non è un grave problema.
tutti quelli scervellamenti, imho, sono una soluzione eccessiva: una sintassi incomprensibile per un problema inesistente :stordita:
AnonimoVeneziano
30-01-2008, 01:24
può scaricare anche il compilatore da solo credo
Beh, in questo caso è allora indifferente quale scegliere :) (Sempre che sia facile interfacciare il MSVC con Code::Blocks)
[...]
Risposta all'ABI Mismatch ....
[...]
L'esempio l'avevo fatto per dire : "Se tra due versioni dello stesso compilatore ci sono problemi di linking/esecuzione allora figuriamoci tra due compilatori diversi" :D
Comunque questo è un problema in cui ero cascato personalmente tempo fa, quando su Gentoo si usava ancora GCC 3.x . In particolare avevo il GCC 3.2 e avevo compilato tutto KDE con quello. A un certo punto esce l'aggiornamento di GCC alla versione 3.3. Tempo dopo escono anche gli aggiornamenti di alcune applicazioni KDE . Dopo la ricompilazione il risultato era il sopraccitato errore.
Adesso fortunatamente però con la serie 4 del GCC non succede più (la ABI si è stabilizzata :) )
hai presente di cosa stiamo parlando?
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
Si, ma se sto assembly serve a così poco allora perchè l'hai tirato in ballo? :asd:
Ciao :)
Beh, in questo caso è allora indifferente quale scegliere :) (Sempre che sia facile interfacciare il MSVC con Code::Blocks)
[...]
Risposta all'ABI Mismatch ....
[...]
L'esempio l'avevo fatto per dire : "Se tra due versioni dello stesso compilatore ci sono problemi di linking/esecuzione allora figuriamoci tra due compilatori diversi" :D
Comunque questo è un problema in cui ero cascato personalmente tempo fa, quando su Gentoo si usava ancora GCC 3.x . In particolare avevo il GCC 3.2 e avevo compilato tutto KDE con quello. A un certo punto esce l'aggiornamento di GCC alla versione 3.3. Tempo dopo escono anche gli aggiornamenti di alcune applicazioni KDE . Dopo la ricompilazione il risultato era il sopraccitato errore.
Adesso fortunatamente però con la serie 4 del GCC non succede più (la ABI si è stabilizzata :) )
hai presente di cosa stiamo parlando?
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
Si, ma se sto assembly serve a così poco allora perchè l'hai tirato in ballo? :asd:
Ciao :)
71104
30-01-2008, 01:38
Si, ma se sto assembly serve a così poco allora perchè l'hai tirato in ballo? :asd: era la ciliegina sulla torta :asd:
cdimauro
30-01-2008, 08:51
comunque ti avrei potuto anche darti ragione se si trattava di C++, ma per quanto riguarda il C non vedo come un compilatore che non implementa nemmeno l'ultima versione dello standard possa essere considerato la scelta ideale :fagiano:
Usata da chi? Ancora oggi si lavora spesso con l'ANSI C (89?). ;)
Usata da chi? Ancora oggi si lavora spesso con l'ANSI C (89?). ;)
ilsensine
30-01-2008, 08:56
hai presente di cosa stiamo parlando? :)
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
E come fai nei driver per Windows a effettuare una semplice memory barrier ad esempio? Chiami una funzione esterna?
Per fortuna, sì, poi mettici anche che nel 50% dei casi le routines che ne contengono contengono solo quello (e quindi non resta un bel niente da "connettere" col codice C circostante)
mmm no. Un incremento atomico può essere ottenuto efficacemente solo tramite codice asm (a meno di funzioni esterne dedicate o costosi lock)
e nel rimanente 50% sono dei blocchi talmente piccoli che la mancata ottimizzazione loro e delle due istruzioni circostanti a parer mio non è un grave problema.
Appunto perché sono in genere piccoli è importante dire al compilatore quali danni fanno e soprattutto quali non fanno. E possibilmente dire all'ottimizzatore quali gradi di libertà rimangono.
E proprio perché sono casi particolari non ci vedo niente di male a fare un pò di fatica in più per aiutare il compilatore.
Solo questo sto dicendo, non mi sembrava una affermazione stratosferica da metterci su una discussione...
tutti quelli scervellamenti, imho, sono una soluzione eccessiva: una sintassi incomprensibile per un problema inesistente :stordita:
Le soluzioni alternative quali sono? Il compilatore deve assumere che tutti i registri sono ormai invalidati? Il codice asm deve occuparsi di salvare e ripristinare tutti i registri che intende usare? Oppure si devono considerare invalidati tutti i registri che compaiono nel codice (come fa più o meno il Delphi)? Non so dimmi tu...
i blocchi di assembly in mezzo al codice C sono cose che ormai non vengono più scritte nemmeno nei drivers!! (almeno per quanto riguarda Windows)
E come fai nei driver per Windows a effettuare una semplice memory barrier ad esempio? Chiami una funzione esterna?
Per fortuna, sì, poi mettici anche che nel 50% dei casi le routines che ne contengono contengono solo quello (e quindi non resta un bel niente da "connettere" col codice C circostante)
mmm no. Un incremento atomico può essere ottenuto efficacemente solo tramite codice asm (a meno di funzioni esterne dedicate o costosi lock)
e nel rimanente 50% sono dei blocchi talmente piccoli che la mancata ottimizzazione loro e delle due istruzioni circostanti a parer mio non è un grave problema.
Appunto perché sono in genere piccoli è importante dire al compilatore quali danni fanno e soprattutto quali non fanno. E possibilmente dire all'ottimizzatore quali gradi di libertà rimangono.
E proprio perché sono casi particolari non ci vedo niente di male a fare un pò di fatica in più per aiutare il compilatore.
Solo questo sto dicendo, non mi sembrava una affermazione stratosferica da metterci su una discussione...
tutti quelli scervellamenti, imho, sono una soluzione eccessiva: una sintassi incomprensibile per un problema inesistente :stordita:
Le soluzioni alternative quali sono? Il compilatore deve assumere che tutti i registri sono ormai invalidati? Il codice asm deve occuparsi di salvare e ripristinare tutti i registri che intende usare? Oppure si devono considerare invalidati tutti i registri che compaiono nel codice (come fa più o meno il Delphi)? Non so dimmi tu...
71104
30-01-2008, 14:12
E come fai nei driver per Windows a effettuare una semplice memory barrier ad esempio? Chiami una funzione esterna? http://msdn2.microsoft.com/en-us/library/ms801931.aspx
mmm no. Un incremento atomico può essere ottenuto efficacemente solo tramite codice asm (a meno di funzioni esterne dedicate o costosi lock) anima candida :asd:
ricordo ancora di quest'estate, trascorsa a programmare in C portabile per Windows e Linux (esame di Sistemi Operativi 2): a un certo punto ho avuto la necessità di utilizzare su Win32 le funzioni InterlockedXxx; ho sofferto per il fatto che non c'erano soluzioni analoghe su Linux (alla fine, col consenso del professore, ho dovuto rinunciare alla portabilità tra hardware diversi e scrivere codice assembly per implementare le InterlockedXxx su Linux).
http://msdn2.microsoft.com/en-us/library/aa489850.aspx
http://msdn2.microsoft.com/en-us/library/aa490017.aspx
http://msdn2.microsoft.com/en-us/library/aa489885.aspx
http://msdn2.microsoft.com/en-us/library/aa490138.aspx
http://msdn2.microsoft.com/en-us/library/aa490035.aspx
http://msdn2.microsoft.com/en-us/library/aa490152.aspx
(eccetera eccetera)
Le soluzioni alternative quali sono? Il compilatore deve assumere che tutti i registri sono ormai invalidati? Il codice asm deve occuparsi di salvare e ripristinare tutti i registri che intende usare? Oppure si devono considerare invalidati tutti i registri che compaiono nel codice (come fa più o meno il Delphi)? Non so dimmi tu... posto che nessuno lo sa dal momento che sia il compilatore Microsoft sia il compilatore Intel non sono opensource, l'ultima idea non mi sembra male, e la si può anche ottimizzare: vengono invalidati tutti i registri che compaiono come operandi che le istruzioni modificano (per esempio una mov modifica solamente il registro di destinazione, non quello sorgente).
mmm no. Un incremento atomico può essere ottenuto efficacemente solo tramite codice asm (a meno di funzioni esterne dedicate o costosi lock) anima candida :asd:
ricordo ancora di quest'estate, trascorsa a programmare in C portabile per Windows e Linux (esame di Sistemi Operativi 2): a un certo punto ho avuto la necessità di utilizzare su Win32 le funzioni InterlockedXxx; ho sofferto per il fatto che non c'erano soluzioni analoghe su Linux (alla fine, col consenso del professore, ho dovuto rinunciare alla portabilità tra hardware diversi e scrivere codice assembly per implementare le InterlockedXxx su Linux).
http://msdn2.microsoft.com/en-us/library/aa489850.aspx
http://msdn2.microsoft.com/en-us/library/aa490017.aspx
http://msdn2.microsoft.com/en-us/library/aa489885.aspx
http://msdn2.microsoft.com/en-us/library/aa490138.aspx
http://msdn2.microsoft.com/en-us/library/aa490035.aspx
http://msdn2.microsoft.com/en-us/library/aa490152.aspx
(eccetera eccetera)
Le soluzioni alternative quali sono? Il compilatore deve assumere che tutti i registri sono ormai invalidati? Il codice asm deve occuparsi di salvare e ripristinare tutti i registri che intende usare? Oppure si devono considerare invalidati tutti i registri che compaiono nel codice (come fa più o meno il Delphi)? Non so dimmi tu... posto che nessuno lo sa dal momento che sia il compilatore Microsoft sia il compilatore Intel non sono opensource, l'ultima idea non mi sembra male, e la si può anche ottimizzare: vengono invalidati tutti i registri che compaiono come operandi che le istruzioni modificano (per esempio una mov modifica solamente il registro di destinazione, non quello sorgente).
ilsensine
30-01-2008, 14:46
http://msdn2.microsoft.com/en-us/library/ms801931.aspx
Ok chiami una funzione esterna. Sic.
(a meno che quella è una funzione inline definita nell'header, come spero).
ricordo ancora di quest'estate, trascorsa a programmare in C portabile per Windows e Linux (esame di Sistemi Operativi 2): a un certo punto ho avuto la necessità di utilizzare su Win32 le funzioni InterlockedXxx; ho sofferto per il fatto che non c'erano soluzioni analoghe su Linux (alla fine, col consenso del professore, ho dovuto rinunciare alla portabilità tra hardware diversi e scrivere codice assembly per implementare le InterlockedXxx su Linux).
http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
Ci sono tutte le funzioni che ti servono, espresse come inline, disponibili per parecchi processori.
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre.
...link a mezza msdn...
Non saranno anche quelle tutte funzioni esterne?
Cosa ha la Microsoft nel mettere open code quelle mezze istruzioni assembler che sono necessarie?
Ok chiami una funzione esterna. Sic.
(a meno che quella è una funzione inline definita nell'header, come spero).
ricordo ancora di quest'estate, trascorsa a programmare in C portabile per Windows e Linux (esame di Sistemi Operativi 2): a un certo punto ho avuto la necessità di utilizzare su Win32 le funzioni InterlockedXxx; ho sofferto per il fatto che non c'erano soluzioni analoghe su Linux (alla fine, col consenso del professore, ho dovuto rinunciare alla portabilità tra hardware diversi e scrivere codice assembly per implementare le InterlockedXxx su Linux).
http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
Ci sono tutte le funzioni che ti servono, espresse come inline, disponibili per parecchi processori.
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre.
...link a mezza msdn...
Non saranno anche quelle tutte funzioni esterne?
Cosa ha la Microsoft nel mettere open code quelle mezze istruzioni assembler che sono necessarie?
ilsensine
30-01-2008, 14:59
posto che nessuno lo sa dal momento che sia il compilatore Microsoft sia il compilatore Intel non sono opensource
Hanno un manuale spero!
l'ultima idea non mi sembra male
Bè a suo tempo il Delphi era all'avanguardia infatti. La soluzione del gcc consente di generare un codice (contorno compilato + asm alieno) globalmente un pò migliore.
Hanno un manuale spero!
l'ultima idea non mi sembra male
Bè a suo tempo il Delphi era all'avanguardia infatti. La soluzione del gcc consente di generare un codice (contorno compilato + asm alieno) globalmente un pò migliore.
ilsensine
30-01-2008, 15:07
Ci sono tutte le funzioni che ti servono, espresse come inline, disponibili per parecchi processori.
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre.
Ovviamente le cose le trovi quando ormai non ti servono...e scopri di averle avute sempre sotto al naso...
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Atomic-Builtins.html#Atomic-Builtins
Ho fatto una veloce prova su x86-64, sembrano ok...
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre.
Ovviamente le cose le trovi quando ormai non ti servono...e scopri di averle avute sempre sotto al naso...
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Atomic-Builtins.html#Atomic-Builtins
Ho fatto una veloce prova su x86-64, sembrano ok...
71104
30-01-2008, 15:08
Ok chiami una funzione esterna. Sic.
(a meno che quella è una funzione inline definita nell'header, come spero). può anche darsi: certe "funzioni" che Microsoft documenta come tali in realtà le chiama funzioni in tono un po' generico, poi con un po' di studio sul PSDK e sul DDK si va a scoprire che sono macro oppure funzioni inline; oppure possono anche avere implementazioni multiple, per es. inline e funzione esterna.
alcune Interlocked basilari mi pare abbiano un'implementazione sia come funzioni intrinseche del compilatore sia come funzioni esterne in kernel32.dll, ntoskrnl.exe, ecc.; altre invece mi pare fossero macro o inline che chiamano le prime. talvolta la doppia implementazione è dovuta a motivi di retrocompatibilità: prima c'era la funzione da importare, poi hanno aggiunto quella intrinseca nel compilatore.
http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
Ci sono tutte le funzioni che ti servono, espresse come inline, disponibili per parecchi processori.
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre. :muro:
ma il bello è che manco il professore me le ha sapute indicare... io mica mi sono affidato esclusivamente al forum per risolvere quel problema.
Non saranno anche quelle tutte funzioni esterne?
Cosa ha la Microsoft nel mettere open code quelle mezze istruzioni assembler che sono necessarie? vedi sopra il discorso della doppia implementazione.
comunque il fatto di rendere aperto il codice di quelle mezze istruzioni assembly non è un problema, infatti di alcune Interlocked (originali) il codice l'ho visto.
(a meno che quella è una funzione inline definita nell'header, come spero). può anche darsi: certe "funzioni" che Microsoft documenta come tali in realtà le chiama funzioni in tono un po' generico, poi con un po' di studio sul PSDK e sul DDK si va a scoprire che sono macro oppure funzioni inline; oppure possono anche avere implementazioni multiple, per es. inline e funzione esterna.
alcune Interlocked basilari mi pare abbiano un'implementazione sia come funzioni intrinseche del compilatore sia come funzioni esterne in kernel32.dll, ntoskrnl.exe, ecc.; altre invece mi pare fossero macro o inline che chiamano le prime. talvolta la doppia implementazione è dovuta a motivi di retrocompatibilità: prima c'era la funzione da importare, poi hanno aggiunto quella intrinseca nel compilatore.
http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
Ci sono tutte le funzioni che ti servono, espresse come inline, disponibili per parecchi processori.
Non te le indicai a suo tempo perché...non le avevo neanche cercate :stordita:
Le ho trovate ora con una ricerca di pochi istanti, probabilmente ne esistono anche altre. :muro:
ma il bello è che manco il professore me le ha sapute indicare... io mica mi sono affidato esclusivamente al forum per risolvere quel problema.
Non saranno anche quelle tutte funzioni esterne?
Cosa ha la Microsoft nel mettere open code quelle mezze istruzioni assembler che sono necessarie? vedi sopra il discorso della doppia implementazione.
comunque il fatto di rendere aperto il codice di quelle mezze istruzioni assembly non è un problema, infatti di alcune Interlocked (originali) il codice l'ho visto.
71104
30-01-2008, 15:09
Ovviamente le cose le trovi quando ormai non ti servono...e scopri di averle avute sempre sotto al naso...
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Atomic-Builtins.html#Atomic-Builtins
:cry: :cry:
edit - ma vabbè chissenefrega, ormai è andata e c'ho preso pure 29 :asd:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Atomic-Builtins.html#Atomic-Builtins
:cry: :cry:
edit - ma vabbè chissenefrega, ormai è andata e c'ho preso pure 29 :asd:
71104
30-01-2008, 15:13
Hanno un manuale spero! be', non so se questi aspetti possono essere documentati pubblicamente... per esempio io l'unica documentazione che ho visto su MSDN relativamente al compilatore è quella della command line (ma non ho cercato bene).
ilsensine
30-01-2008, 15:21
:cry: :cry:
edit - ma vabbè chissenefrega, ormai è andata e c'ho preso pure 29 :asd:
Peccato, ti sei perso la faccia del tuo professore davanti a quella soluzione :D (certe cose valgono più di un 30L...l'esame che mi ha dato più soddisfazioni paradossalmente è quello a cui ho preso meno!)
edit - ma vabbè chissenefrega, ormai è andata e c'ho preso pure 29 :asd:
Peccato, ti sei perso la faccia del tuo professore davanti a quella soluzione :D (certe cose valgono più di un 30L...l'esame che mi ha dato più soddisfazioni paradossalmente è quello a cui ho preso meno!)
ilsensine
30-01-2008, 15:23
be', non so se questi aspetti possono essere documentati pubblicamente... per esempio io l'unica documentazione che ho visto su MSDN relativamente al compilatore è quella della command line (ma non ho cercato bene).
No sicuramente documentano da qualche parte a cosa prestare attenzione quando inserisci del codice asm. Se non è in bella vista è anzi un bene!
No sicuramente documentano da qualche parte a cosa prestare attenzione quando inserisci del codice asm. Se non è in bella vista è anzi un bene!
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.