Локальные переменные. Опции

[Jenya7]

Прочитал следующее в ARM System Developer's Guide.

ARMv4-based processors can efficiently load and store 8-, 16-, and 32-bit data. However,
most ARM data processing operations are 32-bit only. For this reason, you should use
a 32-bit datatype, int or long, for local variables wherever possible. Avoid using char and
short as local variable types, even if you are manipulating an 8- or 16-bit value. The one
exception is when you want wrap-around to occur.

И переделал все локальные переменные на uint32_t.
Вопрос - как я понимаю это касается и аргументов передаваемых в функцию?

[ViKo]

Прочитал следующее в ARM System Developer's Guide.

И переделал все локальные переменные на uint32_t.
Вопрос - как я понимаю это касается и аргументов передаваемых в функцию?

Да. И возвращаемых значений тоже.
Не касается это лишь управляющих структур, массивов, которые используются в программе. Чтобы место экономить.

[Jenya7]

Да. И возвращаемых значений тоже.
Не касается это лишь управляющих структур, массивов, которые используются в программе. Чтобы место экономить.

Ну а вот например

Код

uint32_t MessageChecksum(unsigned char *p, uint32_t len)
{
    uint32_t csum = 0;
    while (len)
    {
      csum+=(*p)&0xFF;
      p++;
      len--;
    }
    return csum;
}

тут у меня unsigned char потому что это касается UART я передаю данные 8 бит. или все равно привести к uint32_t?

uint_fastXX_t это если я захочу перенести код на AVR

[CrimsonPig]

Ну а вот например

Код

uint32_t MessageChecksum(unsigned char *p, uint32_t len)
{
    uint32_t csum = 0;
    while (len)
    {
      csum+=(*p)&0xFF;
      p++;
      len--;
    }
    return csum;
}

тут у меня unsigned char потому что это касается UART я передаю данные 8 бит. или все равно привести к uint32_t?

Если есть ну очень сильное желание, то этот код можно соптимизировать, чтобы он работал с 32-битными значениями. А оно сильно надо ? Этот код критичен к скорости выполнения ?
Да, тогда еще возникнет ряд проблем, если размер массива не будет кратен 4 байтам, придется вводить пляски с бубном. Кроме того, могут возникнуть проблемы с выравниванием всего массива входных данных по границе слова. Если char* автоматически выравнен по границе байта, то uint32* будет выравнен по границе 4-х байтов. Если попытаться вычислить сумму начиная с невыравненного адреса, будут проблемы, в т.ч и с производительностью

Общие замечания:
1. в качестве первого параметра надо использовать const unsigned char*, облегчается жизнь себе и компилятору
2. эта контрольная сумма - дерьмо. Она не обнаруживает перестановку байтов, например. Есть гораздо более надежные методы и довольно простые - adler, fletcher checksum, ну и классические CRC

Сообщение отредактировал CrimsonPig - Jan 20 2015, 12:09

[Jenya7]

Если есть ну очень сильное желание, то этот код можно соптимизировать, чтобы он работал с 32-битными значениями. А оно сильно надо ? Этот код критичен к скорости выполнения ?
Да, тогда еще возникнет ряд проблем, если размер массива не будет кратен 4 байтам, придется вводить пляски с бубном. Кроме того, могут возникнуть проблемы с выравниванием всего массива входных данных по границе слова. Если char* автоматически выравнен по границе байта, то uint32* будет выравнен по границе 4-х байтов. Если попытаться вычислить сумму начиная с невыравненного адреса, будут проблемы, в т.ч и с производительностью

Общие замечания:
1. в качестве первого параметра надо использовать const unsigned char*, облегчается жизнь себе и компилятору
2. эта контрольная сумма - дерьмо. Она не обнаруживает перестановку байтов, например. Есть гораздо более надежные методы и довольно простые - adler, fletcher checksum, ну и классические CRC

это poor man CRC - быстро и просто без заморочек.
а вообще прибор работает от батарейки поэтому скорость любой функции для меня важна - быстро отработал и пошел спать.
а чем const упрощает жизнь кроме того что не дает модифицировать строку?

Сообщение отредактировал Jenya7 - Jan 20 2015, 12:17

[CrimsonPig]

это poor man CRC - быстро и просто без заморочек.
а вообще прибор работает от батарейки поэтому скорость любой функции для меня важна - быстро отработал и пошел спать.
а чем const упрощает жизнь кроме того что не дает модифицировать строку?

1. "Просто и без заморочек" - это очень хорошо... только вот с обнаружением ошибок будет весьма плохо.
2. про батарейку - вопрос спорный "быстро отработал" - не значит "мало съел". "Скорость любой функции" соптимизировать невозможно. Например, после долгого вырывания волос из попы автор таки соптимизирует свой алгоритм для работы с 32-битными числами. При этом размер кода вырастет в 2 раза, скорость выполнения увеличится на 0.1%, в то время как эта функция как вызывалась раз в секунду, так и вызывается. Оно того стоило ? Все равно потребление электричества надо будет мерять. Не факт что оптимизация по скорости уменьшит потребление энергии.
3. если гениальный автор с бодуна в своей функции напишет не val=*p++, а *p++ = val, и не протестирует (а некоторые вещи почти невозможно протестировать), то впоследствии может быть горько и обидно. Для меня использование const - это как личная гигиена.