[C] Compilatore gratis per win XP

[71104]

Originariamente inviato da ilsensine

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

[AnonimoVeneziano]

Originariamente inviato da 71104

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

[71104]

problemi tipo?

[k0nt3]

Originariamente inviato da 71104

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

Originariamente inviato da 71104

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

[AnonimoVeneziano]

Originariamente inviato da 71104

problemi tipo?

Problemi di linking o di eseguibili che non partivano

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]

Originariamente inviato da k0nt3

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

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]

Originariamente inviato da AnonimoVeneziano

Problemi di linking o di eseguibili che non partivano

più specificamente...?

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]

Originariamente inviato da 71104

più specificamente...?

C++ ABI Mismatch . Più di così non posso dirti 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 )

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]

Originariamente inviato da 71104

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.

Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio.

[ilsensine]

Originariamente inviato da 71104

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!

[k0nt3]

Originariamente inviato da cdimauro

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.

Comunque, dato il titolo del thread, l'ambiente migliore che può usare è Visual Studio.

si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela"
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

[AnonimoVeneziano]

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

[Murphy]

Originariamente inviato da AnonimoVeneziano

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 )!

Mi bastano le chiamate di base, non devo fare niente di eccezionale!

cmq grazie a tutti mi sono fatto una cultura!!!!!!

ciao

[71104]

Originariamente inviato da AnonimoVeneziano

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 )

è 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 )

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.

Originariamente inviato da ilsensine

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...
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ò?

Originariamente inviato da k0nt3

si ma anche lui va incontro a guai legali se non paga i diritti a PGI-bis per il "Giovanni mangia una mela"

azz, questo si chiama sgammone

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

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*

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
un programmatore italiano del team ha sviluppato una libreria PSEH che gestisce appositamente le eccezioni SEH.

[71104]

Originariamente inviato da AnonimoVeneziano

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]

Originariamente inviato da 71104

grazie al cavolo, se il MinGW supportasse il formato PE a 64 bit sarebbe stato possibile...
c'è una mancanza di impegno da entrambe le parti, chi dei due ha la colpa?

La Apple, ovvio

capirai -.-
e quanti decimi di secondo si guadagnano in fase di compilazione perciò?

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]

Originariamente inviato da ilsensine

La Apple, ovvio


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

[AnonimoVeneziano]

Originariamente inviato da 71104

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)

Originariamente inviato da 71104

[...]
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"

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 )

Originariamente inviato da 71104

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?

Ciao

[71104]

Originariamente inviato da AnonimoVeneziano

Si, ma se sto assembly serve a così poco allora perchè l'hai tirato in ballo?

era la ciliegina sulla torta

[cdimauro]

Originariamente inviato da k0nt3

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

Usata da chi? Ancora oggi si lavora spesso con l'ANSI C (89?).