<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Layerscape中的主题 Inefficient code in nadk_memcpy.h</title>
    <link>https://community.nxp.com/t5/Layerscape/Inefficient-code-in-nadk-memcpy-h/m-p/467349#M637</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I just had a look at nadk_memcpy.h delivered as part of ls2085a-sdk-ear5 and to me the code seems to be rather inefficient.&lt;BR /&gt;It seems to be based on a hand-optimized memcpy routine for Intel SSE capable CPUs and defines macros to perform block-wise SIMD moves which for the freescale-version have been replaced with calls to memcpy:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;[code]&lt;/P&gt;&lt;P&gt;static inline void nadk_mov64(uint8_t *dst, const uint8_t *src) { memcpy(dst, src, 64); }&lt;/P&gt;&lt;P&gt;static inline void nadk_mov128(uint8_t *dst, const uint8_t *src) { memcpy(dst, src, 128); }&lt;/P&gt;&lt;P&gt;[/code]&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Later those macros are called from within nadk_memcpy_func(), which handles all the alignment issues one would have to care about when those macros would actually be *real* assembler. While most likely the generated code isn't as horrible as the C-code suggests, I still don't understand why nadk_memcpy isn't simply redirecting to memcpy?&lt;BR /&gt;Memcpy most likely is already SIMD optimized, and for small memcpys the compiler can use fast inline-versions. At least it would remove a lot of code which most likely doesn't do what it has been designed for (to provide a fast and efficient version of memcpy I presume)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 17 Feb 2016 17:40:46 GMT</pubDate>
    <dc:creator>clemenseisserer</dc:creator>
    <dc:date>2016-02-17T17:40:46Z</dc:date>
    <item>
      <title>Inefficient code in nadk_memcpy.h</title>
      <link>https://community.nxp.com/t5/Layerscape/Inefficient-code-in-nadk-memcpy-h/m-p/467349#M637</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I just had a look at nadk_memcpy.h delivered as part of ls2085a-sdk-ear5 and to me the code seems to be rather inefficient.&lt;BR /&gt;It seems to be based on a hand-optimized memcpy routine for Intel SSE capable CPUs and defines macros to perform block-wise SIMD moves which for the freescale-version have been replaced with calls to memcpy:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;[code]&lt;/P&gt;&lt;P&gt;static inline void nadk_mov64(uint8_t *dst, const uint8_t *src) { memcpy(dst, src, 64); }&lt;/P&gt;&lt;P&gt;static inline void nadk_mov128(uint8_t *dst, const uint8_t *src) { memcpy(dst, src, 128); }&lt;/P&gt;&lt;P&gt;[/code]&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Later those macros are called from within nadk_memcpy_func(), which handles all the alignment issues one would have to care about when those macros would actually be *real* assembler. While most likely the generated code isn't as horrible as the C-code suggests, I still don't understand why nadk_memcpy isn't simply redirecting to memcpy?&lt;BR /&gt;Memcpy most likely is already SIMD optimized, and for small memcpys the compiler can use fast inline-versions. At least it would remove a lot of code which most likely doesn't do what it has been designed for (to provide a fast and efficient version of memcpy I presume)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 17 Feb 2016 17:40:46 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Inefficient-code-in-nadk-memcpy-h/m-p/467349#M637</guid>
      <dc:creator>clemenseisserer</dc:creator>
      <dc:date>2016-02-17T17:40:46Z</dc:date>
    </item>
    <item>
      <title>Re: Inefficient code in nadk_memcpy.h</title>
      <link>https://community.nxp.com/t5/Layerscape/Inefficient-code-in-nadk-memcpy-h/m-p/467350#M638</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;(When) will this be fixed?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 16 Mar 2016 15:37:02 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Layerscape/Inefficient-code-in-nadk-memcpy-h/m-p/467350#M638</guid>
      <dc:creator>clemenseisserer</dc:creator>
      <dc:date>2016-03-16T15:37:02Z</dc:date>
    </item>
  </channel>
</rss>

