Вопрос

Рассмотрим следующий фрагмент кода C:

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

Это включает в себя -

  1. Преобразуйте второй параметр в расширение знака.
  2. Поместите подписанный параметр расширения в стек как b.
  3. Преобразуйте первый параметр в расширение знака.
  4. Поместите подписанный параметр расширения в стек как a.
  5. Добавьте a и b, приведите результат к char и сохраните его в c.
  6. C снова является расширенным знаком.
  7. Расширенный знак c копируется в регистр возвращаемого значения и функция возвращается вызывающему абоненту.
  8. Чтобы сохранить функцию вызова результата, снова преобразуйте int в char.

Мои вопросы -

  1. Кто это делает?
  2. Какая необходимость делать так много преобразований?
  3. Уменьшит/увеличит ли это производительность машины/компилятора?
  4. Если это снижает производительность, что нам следует сделать, чтобы ее повысить?
Это было полезно?

Решение

  1. Кто это делает? - В конечном счете, это делает процессор;компилятор генерирует все соответствующие инструкции для ЦП для выполнения преобразований
  2. Какая необходимость делать так много преобразований? - Преобразования необходимы для обеспечения согласованности результатов на нескольких платформах, поддерживаемых несколькими компиляторами C.
  3. Уменьшит/увеличит ли это производительность машины/компилятора? — Это снизит производительность по сравнению с «ничего не делать», но разницы никто не заметит.
  4. Если это снижает производительность, что нам следует сделать, чтобы ее повысить? - Ничего:если вам необходимо выполнить арифметические действия над chars, то вы выполняете арифметические операции над charс.Позвольте оптимизатору позаботиться об удалении всех ненужных инструкций для вашей платформы.В большинстве случаев процессор имеет инструкции, совместимые с семантикой языка C, поэтому сгенерированный код будет очень коротким.

Конечно, если вам не нужно выполнять операции со знаковыми символами, вы можете выполнять операции с беззнаковыми символами.Это устранило значительное расширение знаков.

Другие советы

Преобразования, которые вы описываете, выполняются только на абстрактной машине.Компилятор может сократить все это, если это приведет к такому же наблюдаемому поведению.

При включении оптимизации мой компилятор транслирует это в следующий ассемблер

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

это всего лишь одно дополнение (скрытое в leal инструкцию) и ret Прыгать.

  1. Код при запуске.Компилятор генерирует необходимый код для реализации указанной семантики языка программирования.
  2. Я не уверен, что вы говорите о «складке», насколько мне известно, в C такого требования нет.
  3. Это не имеет смысла;по сравнению с чем?
  4. Вы можете попробовать удалить бессмысленное c переменная и просто иметь return (char) (a + b);.Тем не менее, я не думаю, что в этой функции есть что-то «оптимизируемое».Он должен скомпилироваться с очень небольшим количеством кода.Если вы сможете встроить его, вероятно, это будет порядка 1 инструкции.

Я не уверен в деталях вашего вопроса.Вы неоднократно ссылаетесь на расширение знака, не ссылаясь на какой-либо источник;Я думаю, вы предполагаете, что char тип данных будет расширен, чтобы соответствовать разрядности процессора, но я не думаю, что есть какая-либо гарантия, что это уже не так.

Однако, в качестве попытки ответить на ваши расплывчатые вопросы:

  1. Компилятор делает это в ответ на то, что вы пишете код.Кто пишет код?Я думаю, разработчик. Ты сделал это, когда ты писал вопрос.
  2. Если есть необходимость (поскольку вы не указываете свой источник), я полагаю, что это необходимо для того, чтобы ЦП мог самостоятельно обрабатывать арифметику.
  3. Технически это уменьшило бы его, но только по сравнению с теоретической машиной, имеющей произвольную разрядность.На самом деле, это не имеет заметной разницы.
  4. Если вы используете типы данных, соответствующие собственной разрядности вашей архитектуры, прирост производительности будет очень небольшим.Однако это очень незначительный и обычно не стоит неудобств.
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top