Pergunta

Considere o seguinte pedaço de código em C -

char sum_char(char a,char b)
{
   char c = a+b;
   return c;
}

Envolve -

  1. Converter segundo parâmetro para a extensão do sinal.
  2. Empurre assinado parâmetro de extensão na pilha de b.
  3. Converter primeiro parâmetro para a extensão do sinal.
  4. Empurre assinado parâmetro de extensão na pilha como um.
  5. Adicionar a & b, resultado elenco para char e guarde-a em c.
  6. C é novamente estendido por sinal.
  7. Sinal estendido c é copiado para o valor de retorno registrar e função de retorno para o chamador.
  8. Para armazenar o resultado do chamador função novamente converter int para char.

Minhas perguntas são: -

  1. Quem faz isso ?
  2. O que é a necessidade de se fazer tantas conversões ?
  3. Será que vai reduzir/aumentar o desempenho da máquina/compilador ?
  4. Se está reduzindo o desempenho o que devemos fazer para aumentá-lo ?
Foi útil?

Solução

  1. Quem faz isso? - Em última análise, é a CPU que faz isso;o compilador gera todas as instruções para a CPU para realizar as conversões
  2. O que é a necessidade de se fazer tantas conversões? - As conversões são necessárias para garantir a consistência dos resultados através de múltiplas plataformas suportadas por vários compiladores C.
  3. Será que vai reduzir/aumentar o desempenho da máquina/compilador? - Isso vai reduzir o desempenho em relação ao "não fazer nada", mas ninguém vai notar a diferença.
  4. Se está reduzindo o desempenho o que devemos fazer para aumentá-lo? - Nada:se tem de efectuar operações aritméticas em chars e, em seguida, efectuar operações aritméticas em chars.Deixe o otimizador de cuidar da remoção de todos os desnecessários instruções para a sua plataforma.Na maioria dos casos, a CPU tem instruções que são compatíveis com a semântica necessária pela linguagem C, de modo que o código gerado será muito curto.

É claro que se você não precisa executar operações sobre assinado caracteres, você pode realizar operações em caracteres não assinados.Isso eliminou uma boa parte do sinal de extensão.

Outras dicas

As conversões que você descreve são executadas somente na máquina abstracta.Um compilador pode atalho de tudo isto, se leva para o mesmo comportamento observável.

Ao ligar otimizações meu compilador traduz isso para o seguinte assembler

sum_char:
.LFB0:
    .cfi_startproc
    leal    (%rsi,%rdi), %eax
    ret
    .cfi_endproc
.LFE0:
    .size   sum_char, .-sum_char

que é apenas uma adição (escondido no leal instrução) e um ret pular.

  1. O código, quando executado.O compilador gera o código necessário para implementar a semântica especificado para a linguagem de programação.
  2. Eu não tenho certeza do empurrando a "pilha" que você está falando, não há nenhuma exigência em C tanto quanto eu sei.
  3. Que não faz sentido;comparado com o quê?
  4. Você pode tentar remover o inútil c variável, e só tem return (char) (a + b);.O que disse, eu não acho que há muito para ser "otimizado" com essa função.Ele deve compilar a muito pouco código.Se você pode obtê-lo antes, ele provavelmente será na ordem de 1 instrução.

Eu não tenho certeza quanto ao detalhe de sua pergunta.Você se refere repetidamente a extensão do sinal, sem citar qualquer fonte;Eu acho que você está supondo que o char tipo de dados será estendido para corresponder ao bit-ness do CPU, mas eu não acho que há qualquer garantia de que este não é o caso do já.

No entanto, como uma facada respondendo a sua vaga perguntas:

  1. O compilador faz isso a resposta para você escrever o código.Quem escreve o código?Um desenvolvedor, eu poderia imaginar. Você fiz isso, quando você escreveu a pergunta.
  2. Se há uma necessidade (para não citar a sua fonte), eu imagino que é assim que a CPU pode processar a aritmética de forma nativa.
  3. Tecnicamente seria reduzi-lo, mas apenas em comparação teórica máquina que tem arbitrário de bits ness.Realisticamente, não faz nenhuma diferença notável.
  4. Há um muito ligeiro ganho de desempenho se você usar tipos de dados que correspondem ao bit nativo-dade de sua arquitetura.No entanto, este é muito ligeira, e geralmente isso não merece o inconveniente.
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top