É possível usar o compilador Intel C / C ++ no Linux para criar arquivos de objetos a serem vinculados no Windows?

Por quê?

Dependendo da sua fonte, o compilador Intel é provável ou definitivamente o compilador que gera os executáveis ​​mais rápidos para a arquitetura x86 (melhoria de 5 a 100% no tempo de execução).

A Intel oferece seus compiladores para Linux sob uma licença não comercial de graça (acho que li em algum lugar da página: Intel - Desenvolvimento de software não comercial ). Também existe uma licença não comercial gratuita para estudantes, mas essa licença não é aplicável, embora sejam oferecidas ferramentas para os três principais sistemas operacionais (o link caiu devido à restrição de reputação).

Objetivo

Eu (como não estudante) gostaria de poder usar os compiladores Intel para possíveis melhorias na velocidade de execução sob a licença não comercial para compilar arquivos de objetos que podem ser vinculados para criar bibliotecas executáveis ​​e de vínculo dinâmico para Windows (e possivelmente SO X)

Mais detalhes:

O que deduzi deste documento é que os compiladores da Intel criam arquivos de objetos que são compatíveis com os compiladores dominantes da plataforma.

Sub-perguntas:

1. Quais são os formatos de arquivo objeto de gcc, g ++, cl, mingw32, icc, icpc e icl no Windows e Linux (versões atuais)?
2. Partes da cadeia de ferramentas do compilador cruzado mingw32 poderiam ser usadas para atingir o objetivo?
3. Estou certo de que os metadados nos arquivos de objetos gerados são o principal problema?

anúncio 2: o
mingw32-objcopy parece capaz de converter a saída do compilador Intel no Linux (provavelmente ELF) em COFF compatível com a Microsoft (com a possível exceção de arquivos de objetos realocáveis). Alguém poderia confirmar que isso realmente funciona (para aplicativos não triviais), por favor?

É possível criar executáveis ​​do Windows em uma máquina de compilação Linux usando um compilador cruzado. Mas, a Intel não fornece esses compiladores cruzados.

Para responder às sub-perguntas:

Quais são os formatos de arquivo objeto de gcc, g ++, cl, mingw32, icc, icpc e icl no Windows e Linux (versões atuais)?

O formato dos arquivos de objeto é determinado com eficácia pelo sistema operacional (ou melhor, pelo compilador usado para compilá-lo). Para Windows, esse é o formato Portable Executable (PE) e, para Linux, o formato ELF .

Partes da cadeia de ferramentas do compilador cruzado mingw32 poderiam ser usadas para atingir o objetivo?

Não. A parte relevante é o gerador de código, que é responsável por gerar o formato de objeto correto e a parte dos compiladores Intel que fornece ao código gerado a vantagem da velocidade.

Estou certo de que os metadados nos arquivos de objetos gerados são o principal problema?

Não. É uma questão, mas há mais. Um problema mais fundamental é a diferença potencial de como os parâmetros são passados ​​para o kernel e / ou biblioteca padrão. IIRC, essas convenções são diferentes entre Windows e Linux.

A resposta é quase certamente sim. Eu sei que a compilação cruzada de binários do Windows (via mingw32 ) em uma caixa Linux é facilmente possível usando o gcc - obviamente você não poderá executar o programa no Linux (a menos que funcione no Wine), mas conheço vários programas que obtêm Binários do Windows dessa maneira.

No entanto, não sei se o compilador Intel tem as opções para isso, acho que sim.

O formato do objeto para Windows é PE , enquanto para Linux é ELF .

Com o código C vinculado a nada (diretamente) que usa as convenções de chamada personalizadas da Microsoft, você pode ter a chance de usar o MinGW objcopy. Eu o usei para converter um arquivo de objeto montado, mas não precisei me preocupar em chamar convenções.

Eu passaria o tempo que você tentaria fazer isso, fazendo com que o GCC ou o clang fizessem exatamente o que você deseja. Se essa velocidade é realmente tão importante, compile um binário Linux com o compilador Intel e tente ver exatamente o que, se é que existe alguma coisa, isso acelera seu código. Você pode corrigir a montagem se tudo mais falhar.

Proponho a seguinte resposta:

Um talvez definitivo (inclinado a sim) com um mas em relação ao contexto.

Explicação: Em relação à parte "inclinado": parece não ser uma perda total de tempo para tentar isso, mas (a parte "colocada") levando em consideração esta resposta, você provavelmente não obterá melhorias no tempo de execução em comparação com uma Intel apenas uma cadeia de ferramentas. A parte relevante é o feedback do vinculador e do tempo de execução para o compilador (otimização de todo o programa, otimização guiada por perfil, geração de código em tempo de link).

Detalhes adicionais:
De acordo com as Perguntas frequentes do MinGW, existem possíveis problemas com o uso de bibliotecas e DLLs:
"Embora as DLLs devam ser razoavelmente portáteis em diferentes compiladores do Windows, o acesso a DLL através de um arquivo de biblioteca (.lib ou .a) não é. A biblioteca os formatos de arquivo são específicos para determinados compiladores e não podem ser usados ​​de maneira portável com diferentes compiladores, a menos que o compilador forneça suporte para ele ".

Para completar a resposta:
subquestão 1:

Quais são os formatos de arquivo objeto de gcc, g ++, cl, mingw32, icc, icpc e icl no Windows e Linux (versões atuais)?

O formato de arquivo de objeto padrão para qualquer compilador no Windows é COFF (provavelmente a variante PE ). O formato de arquivo de objeto padrão para qualquer compilador no Linux é ELF

subquestão 2:

Partes da cadeia de ferramentas do compilador cruzado mingw32 poderiam ser usadas para atingir o objetivo?

Provavelmente sim (para a parte de vinculação), mas provavelmente você não terá muita melhoria no tempo de execução.

subquestão 3:

Estou certo de que os metadados nos arquivos de objetos gerados são o principal problema?

Em relação à vinculação: sim.