请问创建者2.2是否对数据的结构打包有任何控制？

男孩网页搅乱了我的结构示例。让我再试一次，如果它仍然不起作用，我想你可以弄明白我的意思。
TyBuffsStutt{Unt8LoADDFLAG；UTIT16版本；UTI16OUTRF；}配置数据；也许这会更好地工作…罗斯



     以下为原文
  Boy the web page scrambled my structure example.  Let me try again, if it still does not work I guess you can figure out what I mean.
    typedef struct {     uint8  LoadedFlag;     uint16 Version;     uint16 OutRef; } ConfigData;  Maybe that will work better...  Russ

对此我很好奇，我没有意识到编译器是这样做的。
我找到了KEIL，但不适用于GSOC作为GCC。
用于ARM，PSoC 4/5。
www. kel.com /Sputp/Ma/DOCS/ARMCC/ARMCCJCJADHEDH.HTM
我确实发现了这一点——Axelo.WordPress .COM/NI7/07/24/BE-BURE -打包结构/
在创建者，GCC DOC的第309/310页，有一个对齐和包装的讨论。
问候，Dana。



     以下为原文
   Very curious about this, I did not realize compilers did this.
     I found this for Keil, but does not apply to PSOC as GCC
     used for ARM, PSOC 4/5.
      
          www.keil.com/support/man/docs/armcc/armcc_CJADHEDH.htm
      
     I did find this - axelio.wordpress.com/2007/07/24/be-careful-with-packed-structures/
      
     On page 309/310 in Creator, GCC doc, there is a discussion of alignment and packling.
      
     Regards, Dana.

标准的GCC：Y-Apple（Apple）将做这件事，但是…
需要小心。填充结构将减慢内存获取或可能导致某些处理器上的对齐异常。标准的做法是只用于处理器间通信或可能的外部存储。在内存中执行通常是最好的，如果左解包。
-ED



     以下为原文
   standard GCC: __attribute__ (__packed__) will do it BUT ...
     
    care needs to be taken. packed structure will slow down memory fetches or possibly cause alignment exceptions on some processors. standard practice is to only use it for interprocessor communication or possible external storage. in memory execution is usually best if left unpacked.
     
    -Ed

当值存储在偶数地址相同的字节值规则时，ARM内核工作得最好。可能一些优化设置阻碍了RAM空间的优化。问题是：你能花这个字节吗？
鲍勃



     以下为原文
  The ARM core works best when values are stored on even addresses same rules for byte-values. Probably some optimization settings are hindering a ram-space optimization. The question is: can you spend that byte..?
     
    Bob

是的，这次我可以花这个字节。它是通过串行接口发送的数据包，它与接收程序所期望的不匹配。这次我可以修改接收程序，但是如果我不能呢？那么就有必要包装这个结构。
拆装结构被组织，使得每个项在与处理器的本机整数大小相匹配的偶数地址边界上开始。这使得数据获取和存储效率更高，从而提高了速度。但是，随着今天的快速处理器，我不认为它会有那么大的差别。我想在一个实时的过程中它可能是有用的…
现在我有了答案，如果将来我需要打包一个结构。
谢谢，Russ



     以下为原文
  Yes, I can spend the byte, this time.  It is a packet of data being sent over the serial interface, and it did not match what the receiving program was expecting.  THIS TIME I was able to modify the receiving program, but what if I could not?  Then it would be necessary to pack the structure.
    Unpacked structures are organized so that each item starts on an even address boundary that matches the native integer size of the processor.  This makes data fetches and stores much more efficient, thus increasing speed.  But with the fast processors of today I do not think it makes all that much difference.  I guess in a real time process maybe it could be useful...
    Well I now have the answer in case I need to pack a struct in the future.
    Thanks, Russ

当需要将项目从一个CPU传送到另一个CPU时，这是需要检查的问题之一。例如从PSoC3到PSOC5。



     以下为原文
   that's one of the issue when needs check when needs to port project from one cpu to another. such as from PSoC3 to/from PSoC5.

内存访问时间不关心CPU速度，而是内存访问时间。而后一种情况在过去的20年里没有多大改善。
本质上，问题是当大于1字节的数据元素围绕一个单词（或取决于体系结构）的两个或四个字的边界时。然后，元素上的每个操作都需要2个内存访问，这将极大地减缓它的速度。当操作被认为是原子时，它会变得更麻烦。
也见维基百科：HTTP://E.WiKiTo.Org/WiKi/DATAXStultStudio对齐方式



     以下为原文
  Memory access times don't care about the CPU speed, but about memory access times. And the latter ones haven't improved that much in the last 20 years...
    Essentially the problem is when a data element larger than 1 byte is places around a word (or double- or quad-word, depending on the architecture) boundary. Then every operation on the element requires now 2 memory accesses, which will slow it down tremendously. It gets even more problematic when the operation is supposed to be atomic.
    See also Wikipedia: http://en.wikipedia.org/wiki/Data_structure_alignment