我在一家主要从事汽车网络设计的软件公司部门工作。我们主要用C写网络协议(protocol)栈。最近，我被分配了一个项目，需要使用飞思卡尔的 HC12 Controller 。最初编写的协议(protocol)栈支持使用 unbanked RAM 以及 banked 和 unbanked 闪存。在分配给我的项目中，客户要求使用banked RAM而不是unbanked RAM(我不知道原因)。在我开发这个项目时，我意识到我可以使用远指针来访问(读/写)存储的 RAM。
我的问题是:当我使用远指针访问存储区 RAM 时，我的库代码大小增加了 10kbytes。这是正常的吗？在我使用的编译器 (codewarrior) 的引用手册中，远指针的大小被提到为 3 个字节，而普通指针的大小为 2 个字节。这 1 个额外的字节真的会导致代码大小有如此大的差异吗？有没有其他方法不包括使用远指针，我仍然可以访问存储的 RAM？
如能对我的问题提供任何有用的答案，我们将不胜感激。
最佳答案
最初，HCS12 上的分区内存仅用于闪存中的程序代码，在这种情况下，您不会注意到程序大小有很大差异。唯一的区别是子程序调用需要使用存储内存指令(CALL、RTC 而不是 JMP、RTS)，每个函数调用需要多几个字节的程序内存。
后来他们发布了同时具有存储区闪存和存储区 RAM 的设备(一些 HCS12X 等)。 RAM 显然用于数据，而不是程序存储器。
问题是 HCS12 是一个 16 位 CPU，所以它不能轻易处理 24 位数据指针。这意味着所有此类处理存储区内存中数据的代码将变得相当低效:对于每次访问(通过“远”指针等)，它将必须设置页面寄存器，该页面寄存器代表 24 位地址的高 8 位。完成后，它可以使用正常指令将数据读/写到地址的 16 位部分，硬件会将其映射到正确的页面。一旦完成，程序还必须恢复页面寄存器。
编译器很可能无法很好地优化对分页数据的访问 - 理论上，您可以设置页面寄存器，然后在需要恢复之前访问该页面中的所有数据。但是在编译时，编译器可能无法知道变量的确切分配位置。
您可以很容易地看到使用 Codewarrior 的反汇编程序实际生成的代码。另请注意，Codewarrior 在优化方面一直功能失调:永远不清楚哪些优化必须明确启用，哪些是“内置”的。确保您确实启用了所有相关优化。
总的来说，尽可能避免存储内存。您可以使用高达 64k 内存的非分区内存模型。只有当您超出该限制时才需要分页内存。也许这就是您的客户需要它的原因，他们可能用完了 RAM。
关于在 C 中使用远指针时更改代码大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35998194/