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

[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 - это как личная гигиена.

[Jenya7]

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

We saw in Section 5.2.1 that converting local variables from types char or short to type int increases performance and reduces code size.

обратите внимание на reduces code size.

[CrimsonPig]

обратите внимание на reduces code size.

Книжки надо не только читать, но еще и понимать.
Например, замена uint_8 на uint_32 в этом примере вполне себе сможет уменьшить размер кода и сделать мир лучше:
for(uint8_t i=0; i<100, ++i)
{ [do something] }

Что будем делать тут?

uint32_t CalcCRC(void* apData, uint32_t aNumBytes);

uint8_t buffer[100];
uint32_t crc = CalcCRC(buffer, 64); //-- очень хорошо, правда ?
crc = CalcCRC(buffer+17, 13); //-- а тут ? Весело? как насчет оптимизации CalcCRC для работы с uint32_t* ?

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