如果它没有破坏不修复它 . 它没有破产 .

主要问题是未对齐的访问 . 根据您运行的架构，它们会从糟糕变为非常糟糕 . 很多都与程序员有关，有些与编译器有关 .

修复memcpy的最便宜的方法是不使用它，保持数据在良好的边界上对齐，并使用或替换memcpy，只支持良好对齐的块副本 . 更好的方法是让编译器为了速度而牺牲程序空间和ram . 使用大量结构的人或语言，以便编译器在内部生成对memcpy的调用，或者等效语言的任何内容都会使其结构增长，以便在内部填充或填充内部 . 59字节结构可能变为64字节 . malloc或只提供指向指定对齐的地址的指针的替代方法 . 等等

自己完成所有这些操作要容易得多 . 对齐的malloc，结构是对齐大小的倍数 . 你自己的memcpy是一致的，等等，这很容易为什么硬件人会搞乱他们的设计，编译器和用户？它没有商业案例 .

另一个原因是缓存改变了画面 . 您的dram只能以固定大小访问，32位64位，类似于此，任何小于此的直接访问都会带来巨大的性能损失 . 将缓存放在前面，性能命中率会下降，任何读取 - 修改 - 写入都会在缓存中发生，修改允许对单个读取和写入dram进行多次修改 . 您仍然希望减少缓存的内存周期数，是的，您仍然可以通过使用换档功能(8位一档，16位二档，32位三档，64位)来平滑性能增益位巡航速度，32位下移，16位下移，8位下移)

我不能说英特尔，但确实知道像ARM这样的人已经完成了你所要求的

ldmia r0!,{r2,r3,r4,r5}

例如，如果内核使用32位接口，则仍然是四个32位传输 . 但对于64位接口，如果在64位边界上对齐，则变为长度为2的64位传输，双方之间的一组协商和两个64位字移动 . 如果没有在64位边界上对齐，那么它将变成三个传输，一个32位，一个64位，然后是一个32位 . 您必须要小心，如果这些硬件寄存器根据寄存器逻辑的设计可能不起作用，如果它只支持单个32位传输，则您无法对该地址空间使用该指令 . 不知道为什么你会尝试这样的东西 .

最后的评论是......当我这样做时会很痛......好吧不要这样做 . 不要单步进入内存副本 . 这样做的必然结果是，任何人都无法修改硬件的设计，使用户更容易单步执行内存复制，用例非常小，不存在 . 使用该处理器的所有计算机日夜全速运行，测量所有计算机单步执行mem副本和其他性能优化代码 . 这就像比较一粒沙子和地球的宽度 . 如果您是单步执行，那么无论新解决方案是什么，您仍然必须单步执行 . 为了避免巨大的中断延迟，手动调整的memcpy仍将以if-then-else开头(如果太小的副本只是进入一小组展开的代码或字节拷贝循环)然后以一些最佳速度进入一系列块拷贝，而没有可怕的延迟大小 . 你仍然需要单步执行 .

做单步执行调试你必须编译搞砸，慢，代码无论如何，通过memcpy问题解决单步的最简单方法，是告诉编译器和链接器 Build 调试，构建和链接非 - 优化的memcpy或一般的备用非优化库 . gnu / gcc和llvm是开源的，你可以让它们做你想做的任何事情 .