jcxz 242 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба безопаснее, и БЫСТРЕЕ.. Не верю! B) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба Не верю! B) Bера в церкви. Вы как гуру должны не верить, а знать, что for-loop будет работать не быстрее, чем любые практические реализации memcpy(). а про безопастность - так ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся. C memcpy не нужны манимуляции с j. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба Bера в церкви. Вы как гуру должны не верить, а знать, что for-loop будет работать не быстрее, чем любые практические реализации memcpy()[/url]. Я и знаю, что это не так. И знаю почему. И я знаю как внутри работает memcpy(). Поэтому он будет быстрее только в определённых случаях. А в общем случае быстрее будет for loop. Особенно если вспомнить, что компиляторы умеют оптимизировать. а про безопастность - так ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся. C memcpy не нужны манимуляции с j. Не знаю, что Вы имеете в виду под "безопасностью", но даже Вы в своём совете с memcpy() допустили пару неточностей. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба C memcpy не нужны манимуляции с j. Увидеть бы весь код. Есть мнение, что j легким движением превратиться в (i * 2 + 0) и (i * 2 + 1). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба но даже Вы в своём совете с memcpy() допустили пару неточностей. :laughing:какую? Поэтому он будет быстрее только в определённых случаях.в каких? поделитесь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба и БЫСТРЕЕ Поэтому он будет быстрее только в определённых случаях. Интересно, куда все торопятся? Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladislavS 39 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба Интересно, куда все торопятся? Если я знаю несколько способов решить одну и ту же задачу, то естественно выберу тот который работает быстрее и/или занимает меньше ресурсов. Иначе будет как с "640K ought to be enough for anybody". Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046: Именно потому что опыт это и есть набор эффективных реализаций, которые не тормозят там где не надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба какую? Причём вообще в данном примере memcpy()? ...если ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник? С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит? Причём там вообще memcpy()??? Научитесь читать исходники! Интересно, куда все торопятся? Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко :smile3046: И экономить электроэнергию - тоже редко? :wacko: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба С чего Вы вообще взяли, что 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 38 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба ...ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся... GCC не ругнётся нигде и никогда: у ТСа IAR ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба Это очевидно из строчки 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 11 20 июня, 2018 Опубликовано 20 июня, 2018 · Жалоба И что? Может это и есть цель ТСа? :laughing: Ага. Причем это объекты классов, а операторы [] и | перегружены. Бритва Оккама. Нет, не слышал. Если бы было нужно что-то из описанного вами, то код бы выглядел иначе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 21 июня, 2018 Опубликовано 21 июня, 2018 · Жалоба 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 11 21 июня, 2018 Опубликовано 21 июня, 2018 · Жалоба С чего вы решили, что я утверждаю, что DataBuffer 16 бит, а data_out - 8 бит? Я писал ЕСЛИ, вы знаете значение слова "если"? Среди профессионалов принято так: если есть наиболее вероятное и простое объяснение, то нужно пользоваться именно им. В противном случае один мой знакомый говорил: "а если инопланетяне прилетели и сделали {подставить нужное}". Если ТС-инопланетянин, пишет, вроде, по нашему, но по ихнему это совсем другой смысл, то jcxz должен посыпать голову пеплом раз не предположил, что такое возможно. Дальше смысл беседы в этом направлении теряется. Если по исходнику понятно, что источник шире 8 байт приведет к перемешиванию бит, а в приемнике в итоге получается только 16 значащих бит, то с уверенностью можно принять за факт их размеры 8 и 16 бит соответственно, и при необходимости заявлять "сам дурак", если ТС начнет добавлять противоречащие новые обстоятельства. В соседней ветке про таймеры ТС на третей станице пошел по второму кругу, хотя у меня была полная уверенность, что точка в вопросе поставлена. В этой связи, jcxz поддерживаю, т.к. без телепатии, а на одной только логике, не понять, что нужно ТС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 143 21 июня, 2018 Опубликовано 21 июня, 2018 · Жалоба "а если инопланетяне прилетели и сделали {подставить нужное}".К сожалению, аборигены запомнили только, что нужно хлопать при приземлении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться