Странное предупреждение Опции

[Jenya7]

Есть такая строчка в коде

Код

for (i=0; i < size_to_take; i++)
{
      DataBuffer[i] = (data_out[j++]<<8) | data_out[j++];
}

Выскакивает предупреждение

Warning[Pa079]: undefined behavior: variable "j" (declared at line 176) (or a value reached by some form of indirection through it) is modified more than once without an intervening

В GCC компайлере такого предупреждения нет.Что надо переделать чтоб предупреждение исчезло?

[juvf]

Есть такая строчка в коде

Код

for (i=0; i < size_to_take; i++)
{
      DataBuffer[i] = (data_out[j++]<<8) | data_out[j++];
}

если нет перевёртывания с эндианами и DataBuffer - это 16-ти разрядное, то

Код

memcpy((void*)DataBuffer, (void*)&data_out[j], 2*size_to_take);
j += 2*size_to_take; //если j дальше не нужно, удалить эту строку

без ворнингов, безопаснее, и БЫСТРЕЕ. (явное преобразование к воид не обязательно).

[jcxz]

безопаснее, и БЫСТРЕЕ..

Не верю!

[juvf]

Не верю!

Bера в церкви. Вы как гуру должны не верить, а знать, что for-loop будет работать не быстрее, чем любые практические реализации memcpy().
а про безопастность - так ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся. C memcpy не нужны манимуляции с j.

[Obam]

...ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся...

GCC не ругнётся нигде и никогда: у ТСа IAR

[juvf]

GCC не ругнётся нигде и никогда: у ТСа IAR

2Obam, читаем ещё раз первый пост ТС до конца

В GCC компайлере такого предупреждения нет.

Причём вообще в данном примере memcpy()? ...если ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник?
С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит?
Причём там вообще memcpy()??? Научитесь читать исходники!

adnega - ППКС,
2jcxz - из кода видно, что с вероятностью близкой к 100, данные из какого-то байтового тх/рх буфера перекидываются в нужный массив DataBuffer. Научитесь читать исходники!.
Но не факт что это так, поэтому я сразу написал

если нет перевёртывания с эндианами и DataBuffer - это 16-ти разрядное, то

2jcxz - Научитесь читать посты участников.

мало ли чего человек хочет? Может ему требуется читать из источника пары байт и записывать их по адресу назначения с расширением до 32-бит. Не задумывались?

Может быть! Согласен. Может data_out - это класс, а операторы << и | перегруженны. Может даже оператор "++" перегружен в "--". Может где то false переопределён в true. Но из кода видно, что с большей вероятностью просто перекачка из 8 бит массива в 16 битный, поэтому я и сделал оговорку.

Что касается memcpy() и остального....

И я знаю как внутри работает memcpy()

Как вы можете знать, как работает memcpy() у ТС, если memcpy реализуется разработчиками каждого компилятора под каждую архитектуру? Вы знаете как каждый memcpy() реализован? У каждого своя реализация. Как правило, memcpy() реализован так, что из всех возможных реализаций код memcpy будет самый оптимальный, вплоть до ухода в асм. Если пользователь компилятора/библиотеки и решит написать свой копипаст, то он будет менее эффективный, в лучшем случае будет такойже, поэтому при копировании памяти не нужно замарачиваться и изобретать скоростной велосипед, а просто использовать memcpy(). Наверно бывают случаю, что memcpy сырой, написан индусами и можно свой написать оптимальней, но это на столько редко.... и нужно хорошо знать архитектуру. Потратите много времени, выиграете 1-2 такта на копировании 1 байта.

более того, если ЕСЛИ всё же нет перевертывания и это 8 и 16 бит, то даже плохой memcpy будет быстрее кода ТС. Посмотрите сколько лишних операций в for у ТС! какие-то приведения типов, операторы, << и |, дополнительный j, операции j++!!! УЖАС!!!(кстати.... j++ достаточно медленный, по сравнению с ++j). Более того, если ЕСЛИ data_out - это signed char или int8_t, то в коде ТС ошибка, которая обнаружиться только при выполнении, и хорошо если на столе ТС, а может и через год-два у пользователя.

jcxz я сюда не батлится с вами захожу, я тут черпаю чужой опыт, делюсь своим и чужим опытом. Поделитесь вы.....

Поэтому он будет быстрее только в определённых случаях.

В каких случаях?

Вы в своём совете с memcpy() допустили пару неточностей.

какие неточности? Опять же, mне на батл пофиг, просто я не хочу ошибаться и других вводить в заблуждение в отличие от некоторых
Или вы пустослов? Тогда можно нужно отфильтровать ваши посты, ибо это всё равно что "на заборе написано".

ps
вы сами себе противоречите, причем сразу в одном посте.....

ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник...
С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит?

так всё таки "ТС ... пытается поменять байты" или "С чего Вы вообще взяли, что ... data_out - 8 бит?"

С чего вы решили, что я утверждаю, что DataBuffer 16 бит, а data_out - 8 бит? Я писал ЕСЛИ, вы знаете значение слова "если"?

[jcxz]

Как вы можете знать, как работает memcpy() у ТС, если memcpy реализуется разработчиками каждого компилятора под каждую архитектуру? Вы знаете как каждый memcpy() реализован? У каждого своя реализация.

"из кода видно, что с вероятностью близкой к 100..." где-то я это уже слышал недавно?
Так вот - у ТС-а IAR, и я им пользуюсь; у ТС-а (согласно строки выше) Cortex-M - и я под него сейчас отлаживаю. Аргументов достаточно?

Как правило, memcpy() реализован так, что из всех возможных реализаций код memcpy будет самый оптимальный, вплоть до ухода в асм. Если пользователь компилятора/библиотеки и решит написать свой копипаст, то он будет менее эффективный, в лучшем случае будет такойже, поэтому при копировании памяти не нужно замарачиваться и изобретать скоростной велосипед, а просто использовать memcpy().

С этим категорически не согласен! Попробуйте когда-нить не теоретизировать внустую, а скомпилировать и посмотреть разные варианты с копированием в цикле на разных компиляторах с включённой полной оптимизацией по скорости и с разными условиями цикла (короткий цикл/длинный, условия окончания и указатели - переменные или известны на этапе компиляции). И будете удивлены.
Вариант с memcpy() на коротких циклах, где кол-во проходов и/или указатели заданы переменными, проиграет варианту с простым for, так как ему не надо: a) сохранять содержимое из scratch регистров; б) делать вызов memcpy() и возврат; в) внутри memcpy() выполнять ветвление выбирая нужный вариант цикла копирования по условию длины цикла, выравниваний первого и второго аргумента и т.п.
На циклах с заранее (на этапе компиляции) известными условиями выполнения, for-вариант опять же будет как минимум не хуже, просто хотя-бы потому что компилятор зная условия выполнения цикла может подставить нужную последовательность команд (подобную оптимальному копированию внутри memcpy()), но с другими более удобными регистрами и их количеством - удобными для данной точки кода.
А некоторые компиляторы, так и вообще цикл for так оптимизируют (при определённых условиях) что готовому memcpy() и не снилось - в разы быстрее по скорости. Смотрим на компиляторы для DSP-ядер.

Посмотрите сколько лишних операций в for у ТС! какие-то приведения типов, операторы, << и |, дополнительный j, операции j++!!! УЖАС!!!

И что? Современные оптимизаторы творят чудеса. И им по-барабану Ваши жалкие потуги заменить операции индексирования на указатели и подобное - они это и сами хорошо делают, даже ещё и лучше. Так что если бы код автора не был такой кривой, результат работы оптимизирующего компилятора мог быть лучше memcpy().
Я в своё время, разрабатывая для DSP, немало заменил копирований через memcpy() на циклы for - это давало внушительный прирост скорости.

(кстати.... j++ достаточно медленный, по сравнению с ++j).

Опять чушь! Если предположить, что автор использует ARM, то что пре- что пост-инкремент - без разницы, и то и другое на ARM можно сделать в пределах одной команды выборки из памяти. Откройте мануал по системе команд и найдите разницу между: LDRB Rx, [Ry], #1 и LDRB Rx, [Ry, #1]!

В каких случаях? какие неточности?

Во-первых: memcpy там не к месту как я писал выше;
во-вторых: ничего не известно о значении size_to_take, а если она перед началом цикла может быть отрицательной (и i - тоже знаковое), что будет с вашим вариантом на memcpy()?
в-3-х: с чего Вы приводите входные аргументы к типу void *? А если у ТС-а DataBuffer и data_out объявлены к примеру с модификатором volatile, т.е. указывают на strong ordered memory? Например DataBuffer или data_out - это FIFO-буфера в некоей периферии, чувствительные к размерности и последовательности операций записи/чтения.
Я уж не говорю о том, что эта память может позволять только доступы определённой разрядности...

вы сами себе противоречите, причем сразу в одном посте.....

В чём именно противоречие?

Если по исходнику понятно, что источник шире 8 байт приведет к перемешиванию бит, а в приемнике в итоге получается только 16 значащих бит,
то с уверенностью можно принять за факт их размеры 8 и 16 бит соответственно, и при необходимости заявлять "сам дурак",

Из "исходника" даже не ясно, что именно нужно этому горе-программисту (если data_out указывает на unsigned char) - поменять местами байты при копировании или может он хочет продублировать байты. Т.е. сделать так:
1. *(u16 *)&DataBuffer[i] = __REVSH(*(u16 __packed *)&data_out[j]); j += 2;
или так:
2. *(u16 *)&DataBuffer[i] = (uint)*(u8 *)&data_out[j++] * 0x101u;
а может и что другое.....

[juvf]

Посмотрите сколько лишних операций в for у ТС! какие-то приведения типов, операторы, << и |, дополнительный j, операции j++!!! УЖАС!!!

И что? Современные оптимизаторы творят чудеса. И им по-барабану Ваши жалкие потуги заменить операции индексирования на указатели и подобное - они это и сами хорошо делают, даже ещё и лучше. Так что если бы код автора не был такой кривой, результат работы оптимизирующего компилятора мог быть лучше memcpy().

Попробуйте когда-нить

попробую обязательно.

Добрый день фантазёры, эльфы, а также программисты. Совсем недавно (2017-2018 год) занимался оптимизацией кода в STM8. Ручные потуги оптимизации давали очень хороший результат. Оптимизатор конечно оптимизировал код, но некоторый несложный рефакторинг давал значительно лучший результат. Может стм8 сырой? может арм действительно рулит? Проверил на арме.... собрал код ТС, улучшенный код ТС, а также просто memcpy(). В трёх случаях заполнял массив uin16_t [16] из массива uin8_t[32]. Измерял осциллографом.
улучшенный код ТС выглядит так:

Код

#define SIZ    32
uint8_t dataOut[SIZ+2];
uint16_t buffer[SIZ/2];
uint8_t *p1 = (uint8_t*)buffer;
uint8_t *p2 = (uint8_t*)&dataOut[0];
...
GPIO_SetBits(GPIOA, GPIO_Pin_5); //ТР2 = 1
//оптимизированный варинат ТС
for(int i = 0; i < SIZ; i++)
    p1[i] = p2[i];
GPIO_ResetBits(GPIOA, GPIO_Pin_5);

Результат - (код TC с "<<", "|", "++", "j") / (улучшенный код ТС) / (говноmemcpy() )
Не оптимизированный код дал результат 8/5/1.3 мкс
с оптимизацией по скорости -Ohs результат 3/0.5/0.5 мкс

кагбэ в примере всё выровнено к 4. Но серийные данные не всегда выровнены, поэтому усложнил задачу МК и приблизил к реальности, uint8_t *p2 = (uint8_t*)&dataOut[1];
получил без оптимизациии 8/5/2мкс, с оптимизацией -Ohs 3/2/1.7 мск

Результат на лицо. Априори. Вот вам и наряд в не очереди современные оптимизаторы!!!

ps проверял на стм32ф103, компилятор иар.

[jcxz]

ps проверял на стм32ф103, компилятор иар.

1.Не держите всех тут за дураков: эта ваша "проверка" - это для домохозяек аргумент.
В первом случае что именно проверили? Что в случае цикла и в случае memcpy() компилятор очевидно заменил и то и другое циклом типа:

Код

   MOVS Rn, #32/4
p: LDR Rx, [Ry], #4
   STR Rx, [Rz], #4
   SUBS Rn, Rn, #1
   BNE p

или вообще развернул цикл в линейный код?
Так я об этом ещё много постов назад говорил, что Ваш memcpy() в бОльшей части случаев не даст выигрыша.
И далее - нашли какой-то случай, когда определённый компилятор, при определённых ключах компиляции даст небольшой выигрыш?
Так я опять же уже давно говорил, что при определённых условиях и memcpy может быть быстрее.
А теперь попробуйте задать размер переменным и указатели переменными, так чтобы они не могли быть вычислены на этапе компиляции.
Измерить всю функцию а не какой-то непонятно как выбранный участок.
Вывод из этих "проверок" можно сделать только один: компилятор оказался умнее вас.

2.Измерять миллиметровые расстояния линейкой с метровыми делениями - это типичный ардуино-подход.
Позвольте узнать - сколько времени заняли ваши конструкции с установками/сбросами GPIO? Как они оптимизировались в случаях разных тестов?
У вас они дали больше погрешности чем весь "измеряемый" код.
Нормальное измерение длительностей (тем более таких малых) делают по таймеру, но никак не по GPIO.

Вся ваша проверка яйца выеденного не стоит. Этими проверками Вы как раз и показали всем тут свой "уровень" программирования и понимания сего процесса.
И проверять там нечего, достаточно взглянуть на листинг как Вам тут уже неоднократно говорили.
Впрочем похоже для вас это пустой звук. Так же как и о самом предмете оптимального программирования Вы не имеете никакого понятия.

[juvf]

ваш ответ - тоже априори. много слюней, воды, телепатии и всё мимо. Так ведут себя диванные эксперты.

компилятор очевидно заменил и то и другое циклом типа:

Код

   MOVS Rn, #32/4
p: LDR Rx, [Ry], #4
   STR Rx, [Rz], #4
   SUBS Rn, Rn, #1
   BNE p

даже близко не угадали. ни одной строчки кода ))))

или вообще развернул цикл в линейный код?

- опять мимо

что Ваш memcpy() в бОльшей части случаев не даст выигрыша.

ещё раз мимо.

Позвольте узнать - сколько времени заняли ваши конструкции с установками/сбросами GPIO?

Сначала проверил, сколько времени будет установка и сброс GPIO - с -Ohs составило 300 нс в каждом тесте. Результат показанный ранее, был с учетом погрешности GPIO.

Нормальное измерение длительностей (тем более таких малых) делают по таймеру, но никак не по GPIO.

Нормальные измерения длительностей делают осциллографом, анализаторам, а не внутренними таймерами. Осциллограф даст более точное измерение (тем более он поверенный), нежели внутренний таймер МК, когда частота МК на порядок меньше полосы осциллографа. И генератор МК ±вагонИтележка, по сравнению с поверенными средствами измерения. Что ваш внутренний таймер, когда система должна среагировать на внешние прерывание/событие, обработать данные и выдать признак готовности, например дернуть регистр GPIO/DMA/UART? Это реальное время и реальный мир, а не ваша Нарния ваши фантазии с таймерами. Как раз таки осциллограф даст точность в мкм, а таймер в метрах.
Вы предлагаете Измерять миллиметровые расстояния линейкой с метровыми делениями - это типичный эльфо-подход.

И проверять там нечего, достаточно взглянуть на листинг

Дак посмотрите, оторвитесь от дивана и посмотрите, вместо того чтобы тут сочинения писать. Я то посмотрел.... исходный код ТС с << | j более грамоздкий в асме, нежели чем без этих лишних операторов или memcpy(). Впрочем похоже для вас это пустой звук. Так же как и о самом предмете оптимального программирования Вы не имеете никакого понятия.

Оставайтесь прибывать в своих фантазиях.

[jcxz]

Нормальные измерения длительностей делают осциллографом, анализаторам, а не внутренними таймерами. Осциллограф даст более точное измерение (тем более он поверенный),

Да уж... цена вам как специалисту теперь уже достаточно ясна. Понятно почему все вокруг виноваты: и компиляторы и Тексас и другие виноваты в ваших проблемах - то CRC не считается, то SPI не работает, то процессор не отлаживается. Больше говорить с вами не о чем....
Из-за генератора МК видите ли неточность таймера возникает. А то что и работа GPIO и выполнение этой кучи кода (которая ещё и по-разному может скомпилиться) зависят от этого же самого генератора об этом конечно не подумали? А то что вместо прямого измерения, делается какое-то косвенное на которое кроме кучи разных факторов и режимы работы пинов влияют тоже не подумали? И поверенность осциллографа ещё сюда приплели.

[juvf]

Ну, даешь, ядрена вошь!
И олень тебе не гож?
А вчерась мытарил душу:
Вынь оленя да положь!..

То дай код, в нём ошибка! то новый вымыслы про стек... то внезапно код мой безразличен... то предложение проверить да проверь... то проверять там нечего... виртуоз-переобувальщик. а когда все таки проверил - вдруг проверка неугодная стала!!!
аргументы кончились, понеслось что-то абстрактное, типа "кучи разных факторов" и оскорбление негативная оценка оппонента, типичное поведения.... ну вы поняли кого...

Попробуйте когда-нить не теоретизировать внустую, а скомпилировать и посмотреть разные варианты с копированием в цикле на разных компиляторах с включённой полной оптимизацией по скорости и с разными условиями цикла (короткий цикл/длинный, условия окончания и указатели - переменные или известны на этапе компиляции). И будете удивлены.

вот тут вы правы, соглашусь!!! Очень удивился. memcpy() на порядок быстрее for-loop. Перепробывал с разными вариантами, с переменными размерами массива и указателями, неизвестными на этапе компиляции. в тактах процессора примерно 90 к 700(без gpio, таймеров и прочей "кучи разных факторов"). Причем оптимизация практически не влияет на memcpy(). Он всегда быстрый. Вашим for даже и не снилась такая скорость.

устали вы меня.