[jcxz 184]

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

Не верю! B)

[juvf 10]

Не верю! B)

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

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

[jcxz 184]

Bера в церкви. Вы как гуру должны не верить, а знать, что for-loop будет работать не быстрее, чем любые практические реализации memcpy()[/url].

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

А в общем случае быстрее будет for loop. Особенно если вспомнить, что компиляторы умеют оптимизировать.

 

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

Не знаю, что Вы имеете в виду под "безопасностью", но даже Вы в своём совете с memcpy() допустили пару неточностей. :laughing:

[adnega 10]

C memcpy не нужны манимуляции с j.

Увидеть бы весь код. Есть мнение, что j легким движением превратиться в (i * 2 + 0) и (i * 2 + 1).

[juvf 10]

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

какую?

 

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

в каких? поделитесь?

[scifi 1]

и БЫСТРЕЕ

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

Интересно, куда все торопятся? Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046:

[VladislavS 29]

Интересно, куда все торопятся?

Если я знаю несколько способов решить одну и ту же задачу, то естественно выберу тот который работает быстрее и/или занимает меньше ресурсов. Иначе будет как с "640K ought to be enough for anybody".

 

Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046:

Именно потому что опыт это и есть набор эффективных реализаций, которые не тормозят там где не надо.

 

[jcxz 184]

какую?

Причём вообще в данном примере memcpy()? ...если ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник?

С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит?

Причём там вообще memcpy()??? Научитесь читать исходники!

 

Интересно, куда все торопятся? Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046:

И экономить электроэнергию - тоже редко? :wacko:

[adnega 10]

С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит?

Это очевидно из строчки

DataBuffer = (data_out[j++]<<8) | data_out[j++];

Если data_out будет больше 8 бит, то операция | будет перемешивать биты из двух соседних значений.

(data_out[j++]<<8) | data_out[j++] имеет в этом случае не более 16 значащих бит.

Соответственно DataBuffer не менее 16 бит. Какой смысл делать больше?

[Obam 30]

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

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

[jcxz 184]

Это очевидно из строчки

DataBuffer = (data_out[j++]<<8) | data_out[j++];

Уважаемый, из этой строчки очевидно только, что к некоему объекту DataBuffer применяются операции индексирования и присвоения значения, а к объекту data_out - операции индексирования и операции приведения к другому типу (возможно целочисленному).

Всё остальное - Ваши фантазии, не более. :laughing:

 

Если data_out будет больше 8 бит, то операция | будет перемешивать биты из двух соседних значений.

И что? Может это и есть цель ТСа? :laughing:

 

Соответственно DataBuffer не менее 16 бит. Какой смысл делать больше?

Я видимо ошибся форумом... Думал - тут форум программистов и электронщиков, а оказывается - гадалок и экстрасенсов. :laughing:

Я, как можете заметить, не пытаюсь домысливать тайные намерения автора. И я понятия не имею - чего же он пытается изобразить.

Я просто основываюсь на том, что вижу в вопросе.

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

Опять спросите "зачем"? Ну хотя бы например:

1. Многие МК имеют SPI-контроллеры, у которых передаваемое данное записывается в регистр, младшие 16 бит которого - собственно передаваемые биты, а старшие биты - различные биты управления (управление сигналами CS, управление межсловным интервалом и т.п.). Знаю несколько таких МК. Вот если нужно скажем передавать байты в SPI в том порядке, в котором они лежат в памяти, но передавать 16-битными словами (для уменьшения блока пересылки DMA) и при этом к словам добавить управляющую информацию, то может и потребоваться перевёртывание 16-битных слов с расширением их до 32 бит.

2. Или например - он готовит фрейм для передачи в видеопамять LCD-контроллера (опять-же по 16-битному SPI), который (контроллер) принимает пиксели с глубиной цвета 32 бита, а в памяти автора отрисовка идёт 16-битными пикселями. Соответственно - при передаче необходимо расширение каждого пикселя до 32 бит.

3. Или: у автора в устройстве на SPI висит пара слэйвов, соединённых в daisy-chain. Каждый из них имеет размер слова ==16 бит. И он хочет записывать в дальний в цепочке слэйв слова из data_out, а в ближний - нули. Ну скажем эти два слэйва - два 16-разрядных ЦАП, соединённых в daisy-chain. И его DMA должен по неким запросам выдавать по 32 бита на запрос (по слову в каждый ЦАП). Вот он и формирует буфер для DMA таким образом.

И это - всего три из тысяч возможных вариантов!

[adnega 10]

И что? Может это и есть цель ТСа? :laughing:

Ага. Причем это объекты классов, а операторы [] и | перегружены.

Бритва Оккама. Нет, не слышал.

Если бы было нужно что-то из описанного вами, то код бы выглядел иначе.

[juvf 10]

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 бит? Я писал ЕСЛИ, вы знаете значение слова "если"?

[adnega 10]

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

Среди профессионалов принято так: если есть наиболее вероятное и простое объяснение, то нужно пользоваться именно им.

В противном случае один мой знакомый говорил: "а если инопланетяне прилетели и сделали {подставить нужное}".

Если ТС-инопланетянин, пишет, вроде, по нашему, но по ихнему это совсем другой смысл, то jcxz должен посыпать голову пеплом раз не

предположил, что такое возможно. Дальше смысл беседы в этом направлении теряется.

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

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

если ТС начнет добавлять противоречащие новые обстоятельства.

 

В соседней ветке про таймеры ТС на третей станице пошел по второму кругу, хотя у меня была полная уверенность, что точка в вопросе поставлена.

В этой связи, jcxz поддерживаю, т.к. без телепатии, а на одной только логике, не понять, что нужно ТС.

[Сергей Борщ 119]

"а если инопланетяне прилетели и сделали {подставить нужное}".

К сожалению, аборигены запомнили только, что нужно хлопать при приземлении.