È possibile utilizzare il compilatore Intel C / C ++ su Linux per creare file oggetto da collegare su Windows?

Perché?

A seconda della fonte, il compilatore Intel è probabilmente o sicuramente il compilatore che genera gli eseguibili più veloci per l'architettura x86 (miglioramento del tempo di esecuzione dal 5 al 100%).

Intel offre gratuitamente i suoi compilatori per Linux con una licenza non commerciale (penso di averlo letto gratuitamente da qualche parte sulla loro pagina: Intel - Sviluppo di software non commerciale ). Esiste anche una licenza non commerciale gratuita per gli studenti, ma questa licenza non è applicabile sebbene vengano offerti strumenti per tutti e tre i principali sistemi operativi (link rilasciato a causa di una limitazione della reputazione).

Obbiettivo

Io (come non studente) vorrei essere in grado di utilizzare i compilatori Intel per possibili miglioramenti della velocità di esecuzione in base alla licenza non commerciale per compilare file oggetto che possono essere collegati per creare file eseguibili e librerie di collegamento dinamico per Windows (e possibilmente OS X)

Più dettagli:

Ciò che ho dedotto da questo documento è che i compilatori Intel creano file oggetto compatibili con i compilatori dominanti della piattaforma.

Sub-domande:

1. Quali sono i formati di file oggetto di gcc, g ++, cl, mingw32, icc, icpc e icl su Windows e Linux (versioni correnti)?
2. Parti della toolchain cross-compilatore mingw32 potrebbero essere utilizzate per raggiungere l'obiettivo?
3. Ho ragione sul fatto che i metadati nei file oggetto generati sono il problema principale?

annuncio 2:
mingw32-objcopy sembra essere in grado di convertire l'output del compilatore Intel su Linux (presumibilmente ELF) in COFF compatibile con Microsoft (con la possibile eccezione dei file oggetto trasferibili). Qualcuno potrebbe confermare che questo funziona davvero (per applicazioni non banali), per favore?

È possibile creare eseguibili di Windows su una macchina di compilazione Linux utilizzando un cross-compilatore. Ma Intel non fornisce tali compilatori incrociati.

Per rispondere alle domande secondarie:

Quali sono i formati di file oggetto di gcc, g ++, cl, mingw32, icc, icpc e icl su Windows e Linux (versioni correnti)?

Il formato per i file oggetto è effettivamente determinato dal sistema operativo (o meglio, il compilatore utilizzato per costruirlo). Per Windows, questo è il formato Portable Executable (PE) e per Linux il formato ELF .

Parti della toolchain cross-compilatore mingw32 potrebbero essere utilizzate per raggiungere l'obiettivo?

No. La parte rilevante è il generatore di codice, che è sia la parte responsabile della generazione del giusto formato di oggetto sia la parte sui compilatori Intel che conferisce al loro codice generato il vantaggio di velocità.

Ho ragione sul fatto che i metadati nei file oggetto generati sono il problema principale?

No. È un problema, ma ce ne sono altri. Un problema più fondamentale è la potenziale differenza nel modo in cui i parametri vengono passati al kernel e / o alla libreria standard. IIRC, queste convenzioni sono diverse tra Windows e Linux.

La risposta è quasi certamente sì. So che i binari di Windows di compilazione incrociata (tramite mingw32 ) su una scatola Linux sono facilmente possibili usando gcc - ovviamente non sarai in grado di eseguire il programma su Linux (a meno che non funzioni sotto Wine), ma conosco diversi programmi che ottengono File binari di Windows in questo modo.

Tuttavia, non so se il compilatore Intel abbia le opzioni per questo, dovrei pensare che lo sia.

Il formato oggetto per Windows è PE , mentre per Linux è ELF .

Con il codice C collegato a nulla (direttamente) che utilizza le convenzioni di chiamata personalizzate di Microsoft, potresti avere una possibilità utilizzando MinGW objcopy. L'ho usato per convertire un file oggetto assemblato, ma poi non ho dovuto preoccuparmi di chiamare convenzioni.

Trascorrerei solo il tempo che avresti provato a fare questo invece di convincere GCC o Clang a fare esattamente quello che volevi. Se una tale accelerazione è davvero così importante compila un binario Linux con il compilatore Intel e prova a vedere esattamente cosa, se non altro, accelera il tuo codice. È possibile applicare patch all'assembly se tutto il resto non riesce.

Propongo la seguente risposta:

Un definito forse (incline al sì) con un ma rispetto al contesto.

Spiegazione: Per quanto riguarda la parte "pendente": sembra non essere una perdita totale di tempo per provare questo, ma (la parte "put") tenendo conto di questa risposta probabilmente non otterrai miglioramenti del tempo di esecuzione rispetto a un Intel -solo toolchain. La parte pertinente è il linker e il feedback di runtime al compilatore (ottimizzazione dell'intero programma, ottimizzazione guidata dal profilo, generazione del codice del tempo di collegamento).

Ulteriori dettagli:
Secondo le FAQ di MinGW ci sono possibili problemi con l'uso di librerie e DLL:
"Sebbene le dll debbano essere abbastanza portatili su diversi compilatori di Windows, l'accesso alle dll attraverso un file di libreria (.lib o .a) non lo è. i formati di file sono specifici di compilatori particolari e non possono essere utilizzati in modo portabile con compilatori diversi a meno che il compilatore non fornisca supporto per esso. "

Per completare la risposta:
sottointerrogazione 1:

Quali sono i formati di file oggetto di gcc, g ++, cl, mingw32, icc, icpc e icl su Windows e Linux (versioni correnti)?

Il formato di file oggetto predefinito per qualsiasi compilatore su Windows è COFF (probabilmente la variante PE ). Il formato file oggetto predefinito per qualsiasi compilatore su Linux è ELF

sottointerrogazione 2:

Parti della toolchain cross-compilatore mingw32 potrebbero essere utilizzate per raggiungere l'obiettivo?

Molto probabilmente sì (per la parte di collegamento), ma molto probabilmente non otterrai molti miglioramenti nei tempi di esecuzione.

sottointerrogazione 3:

Ho ragione sul fatto che i metadati nei file oggetto generati sono il problema principale?

Per quanto riguarda il collegamento: sì.