Arquiteturas de processador para testar a portabilidade de C / C ++

5

Atualmente estou trabalhando em uma base de código C / C ++ que é razoavelmente portátil, ele pode compilar na maioria dos sistemas Unix, assim como MS-Windows (MSVC), usando vários compiladores populares.

Anteriormente, eu encontrei testes em diferentes sistemas operacionais e arquiteturas para ajudar a encontrar bugs obscuros ou suposições ruins.

Eu me preocupo com o domínio do x86 / amd64 que nossa base de código pode, sem saber, se tornar menos portável.

Além de testar em um sistema big-endian (para encontrar erros óbvios com big / little endian), existem algumas arquiteturas que têm características que os tornam melhores para a portabilidade de software de teste de estresse?

Exemplos de possíveis diferenças.

  • endian diferente.
  • comportamento diferente ao segmentar.
  • comportamento da memória da pilha.
  • tamanho dos tipos primitivos (char, short, int, long, float ... etc).
  • alinhamento / preenchimento de estruturas (o que pode ocultar erros).
  • diferença nas otimizações feitas pelo compilador.

Existem algumas arquiteturas que têm diferenças mais significativas para x86 / amd64, tornando-as melhores candidatas para expor problemas de portabilidade de código? (e tem compiladores C / C ++ e bibliotecas - libc, libstdc ++).

Perguntar porque é um investimento de tempo considerável para configurar um novo sistema, mesmo que seja emulado.

caso não esteja claro o que quero dizer com arquiteturas de processador, por exemplo, (x86, amd64, ia64, mips, risc, armar, m68k, ppc, itanium)

Note que não estou propondo isso como uma maneira primária de descobrir bugs, nós rodamos várias ferramentas de análise estática e testes, mas no passado encontramos erros no código por causa das diferenças em plataformas menos comuns (SGI , SPARC, Solaris, BSD etc. No entanto, alguns desses sistemas estão desaparecendo de uso)

    
por ideasman42 03.08.2014 / 09:33
fonte

2 respostas

6

Você está certo de que o uso de diferentes configurações para seus testes pode aumentar a chance de tropeçar acidentalmente em alguns bugs. No entanto, você deve considerar se a criação de outra plataforma de testes faz sentido a partir de uma perspectiva comercial - suspeito que você queira vender ou distribuir código útil, em vez de criar o Código Perfeito em sua torre de marfim.

I worry with the dominance of X86/AMD64 our code-base may unknowingly become less portable.

Se o seu código só roda em arquiteturas x86 ou AMD64, então há pouco uso para testar em outras arquiteturas - YAGNI se aplica aqui. Você ficaria melhor expandindo sua suíte de testes para garantir todo o comportamento documentado e eliminando a base de código de construções duvidosas com a ajuda de linters. Usar vários compiladores diferentes em configurações diferentes também é uma estratégia de baixo impacto e alto impacto para descobrir bugs (por exemplo, GCC e Clang).

Se, no entanto, você suportar explicitamente determinadas combinações de arquiteturas e sistemas operacionais, também deverá testar essas combinações.

Se, no entanto, você quiser testar mais algumas configurações de alienígenas que ainda são usadas com bastante frequência, recomendo:

  • Arquitetura: SPARC. Sistemas Operacionais: Família Solaris, Linux, família BSD. Endianness: grande, possivelmente bi. Comentários: paralelismo maciço.

  • Arquitetura: ARM. SOs: Linux, família BSD, OpenSolaris. Endianness: pouco, possivelmente bi. Comentários: usados em dispositivos incorporados, telefones celulares.

Os recursos listados podem ser testados variando os seguintes componentes na configuração:

  • Endianess: arquitetura.
  • Threading: SO, configurações do kernel, bibliotecas de threading, número de processadores.
  • Pilha:?
  • Tamanhos primitivos: diretivas de pré-processador, configurações do compilador.
  • Alinhamento de estruturas: compiladores.
  • Otimizações: configurações do compilador.
  • Outros: compile usando diferentes implementações de libc.

Minha principal exposição à programação entre plataformas é a leitura da fonte do interpretador Perl. Aqui, os problemas de portabilidade são abordados por:

  • … detectando recursos fornecidos pela implementação da libc usada, possivelmente substituindo funções customizadas. Esta informação é então registrada como um conjunto de definições pré-processador antes da compilação.
  • … de forma invasiva usando macros para tipos numéricos. Os tamanhos podem ser definidos durante a compilação.
  • … tornando o encadeamento opcional, pois a versão não encadeada tem melhor desempenho. No código, algumas seções são executadas somente quando compiladas com suporte a threads.
  • … principalmente ignorando endianess, como isso tende a resolver-se. Endianness só se torna relevante ao fazer algo como interpretar um dado padrão de bits como um número BE de 16 bits em um sistema LE.
  • … listando explicitamente as plataformas suportadas e também documentando problemas de portabilidade ou comportamentos diferentes nessas plataformas.
  • ... executando uma enorme suíte de testes incl. uma tonelada de testes de regressão que são executados em uma rede de caixas CI.
por 03.08.2014 / 11:40
fonte
4

Eu acho que você provavelmente já cobriu grande parte disso, mas eu daria mais algumas considerações:

  • Ambiente com pouca memória, por ex. móvel com pouca RAM ou dispositivos incorporados. Embora seus clientes atuais possam não precisar disso, quem sabe se sua biblioteca está subitamente em grande demanda por sistemas de gerenciamento de motor ou roteadores domésticos.
  • Ambiente altamente concorrente, por ex. mais threads e núcleos do que você já considerou possível. Embora você possa ter caminhos de código de encadeamento único e multiencadeado como uma opção de compilação, é possível que um grande número de encadeamentos exponha a contenção que você não sabia que tinha.
  • Posso fornecer meus próprios alocadores? Se não, o que acontece se eu redefinir malloc ou operador new () para usar um alocador slab ou mecanismo de memória não-padrão - o seu código ainda pode lidar com isso?
  • Você está confiando na ordem de inicialização em qualquer lugar? Quaisquer variáveis alocadas estaticamente?
por 03.08.2014 / 21:42
fonte