我在一家主要从事汽车网络设计的软件公司的部门工作。我们主要用C语言编写网络协议栈。最近,我被分配了一个项目,需要使用飞思卡尔的HC12控制器。最初编写的协议栈支持使用无银行存储的RAM以及有银行存储和无银行存储的flash。在分配给我的项目中,客户要求使用银行内存而不是非银行内存(原因我不知道)。在开发这个项目时,我意识到可以使用远指针来访问(读/写)banked RAM。
我的问题是:当我使用远指针访问banked RAM时,我的库代码大小增加了10字节。这正常吗?在我正在使用的编译器的参考手册(codewarrio)中,远指针的大小是3字节,而普通指针的大小是2字节。这1个额外的字节真的会导致代码大小的如此大的差异吗?有没有其他方法不包括在我仍然可以访问banked RAM的地方使用远指针?
如对我的问题有任何有用的回答,将不胜感激。

最佳答案

最初,HCS12上的存储空间仅用于flash中的程序代码,在这种情况下,您不会注意到程序大小的巨大差异。唯一的区别是子例程调用将需要使用存储指令(CALL,RTC而不是JMP,RTS),这些指令在每个函数调用时需要多几个字节的程序内存。
后来,他们发布了既有存储闪存又有存储RAM的设备(一些HCS12X等)。RAM显然是用来存储数据的,不是用来存储程序的。
问题是HCS12是一个16位的CPU,所以它不能很容易地处理24位的数据指针。这意味着,所有这些代码处理存储在银行内存中的数据将变得相当低效:对于每次访问(通过“远”指针等),它将必须设置代表24位地址的上8位的页寄存器。一旦完成,它就可以用正常的指令将数据读/写到地址的16位部分,并且硬件会将其映射到正确的页面。一旦完成,程序还必须恢复页面寄存器。
编译器很可能无法优化对分页数据的访问—理论上,您可以在需要还原页面之前设置页面寄存器,然后访问该页面中的所有数据。但在编译时,编译器可能无法知道变量的确切分配位置。
您可以很容易地看到使用codewarrio的反汇编程序实际生成的代码。还要注意的是,在优化方面,codewarrio总是很不正常:从来都不清楚哪些优化必须显式启用,哪些是“内置”的。确保实际启用了所有相关的优化。
总的来说,尽可能避免储存内存。您可以使用高达64k内存的无存储模块。只有当你超过这个限制时,你才需要分页内存。也许这就是您的客户需要它的原因,他们可能已经用完了RAM。

07-24 09:46
查看更多