djyos的可移植性(二)
本帖最后由 djyos 于 2012-8-10 11:50 编辑1. 数据位宽与对齐 嵌入式开发中,对于移植性来说,数据类型的长度和对齐,是一个很容易出错的问题。1.1. 对齐 关于什么是对齐,有很多资料,不明白的,可以google,这里不占用篇幅。 先谈谈对齐的问题,不同的系统,有不同的对齐方式,处理不好的话,会给移植带来很大的问题。遗憾的是,许多有经验的程序员都会犯对齐的错误,而且,许多情况下,对齐错误是一个隐含的错误,再详细的测试都测不出来。下面以arm为例谈谈这个问题,arm要求栈8字节对齐,是因为LDRD/STRD指令要求8字节对齐的操作地址。加入没有遵守8字节对齐,如果编译时没有使用这两条指令,那么程序执行就是正确的。修改一下编译选项(一般是优化选项),编译器可能就选择了使用这两条指令,程序执行就错了。所幸的是,这两条指令被使用的机会,大约只有万分之一~万分之五,因此一般不容易表现出来;不幸的是,这种测试时不容易暴露的问题,是很容易到达用户手中的。如果数据结构中有64位的成员,比如u64,该结构的起始地址,也要求8字节对齐的。 这种错误,即使是国际知名大公司出的例程,都免不了,略举两例: TI公司为他的TMS320C470编写的固件库的启动代码,只做了4字节对齐。我在为帮助用户把djyos移植到OMAPL138的过程中发现了这个问题,并反馈给了TI,得到了TI官方的确认的。你现在看到的、新下载的example,估计就没这个问题了。 在ST官方固件库中,开发工具商RAISONANCE公司为RIDE7提供的工具链,也没有做8字节对齐。大家打开ST官方提供的固件库中,ride目录下的stm32f10x_flash_extsram.ld文件,一看就知。Djyos为了避免用户写应用程序时犯对齐的错误,做了如下措施:1、无论是从堆中分配内存,还是从内存池中分配内存,都做了8字节对齐。只要是使用djyos的内存管理函数分配的内存,可以放心地做各种操作。否则,把动态分配的内存指针强制转换成结构变量访问时,就可能出问题。略举一例:struct abc{u32 a;u63 b;}u8 buf;struct abc *ppp;struct mem_cell_pool *my_pool;my_pool = mb_create_pool(…);ppp = (struct abc *)mb_malloc(my_pool); 这段代码,如果内存管理不做对齐,ppp就是一个定时炸弹,运行时会出现不可预知的问题,取决于cpu是否支持不对齐操作,以及编译器给buf分配什么地址。即使cpu支持非对齐操作,运行效率也是大打折扣的。遗憾的是,像ucosii这样著名的操作系统,都没有注意到这个问题,它要求用户自己提供的内存块首址是对齐的,(参见ucosii的OSMemCreate函数)。如果用户提供了非对齐的地址,你可以认为是用户的错,但是,OS作为“主管部门”,就没有监管责任吗?这样,岂不成了“相关部门”了。而djyos着重于预防应用程序出错的理念,在此展现无遗。2、定义了一个按最严格对齐的数据类型:typedef u64 align_type; //arm中,u64能满足所有对齐要求3、定义了一些跟对齐相关的常数:#define mem_align 1 //如果目标系统没有对齐要求,改为0#define align_size 8 //arm(含cm3)要求8字节对齐4、定义了一些跟对齐相关的宏操作:#define align_down_sys(x) align_down(8,x) //arm要求8字节对齐#define align_up_sys(x) align_up(8,x) //arm要求8字节对齐#define define_align_buf(name,size)align_type name宏define_align_buf用于定义一个首址符合系统对齐要求的缓冲区。示例:u8 buf;struct abc *ppp;ppp = (struct abc *)buf; 这段代码能否正确运行,同样取决于cpu是否支持不对齐操作,以及编译器给buf分配什么地址。但如果把“u8 buf”改为“define_align_buf(buf,1000)”则没有任何问题。 align_down_sys用于把一个地址向下调整到系统要求的对齐值,align_up_sys则把一个地址向上调整到系统要求的对齐值,define_align_buf用于定义一个数组,其起始地址满足系统对齐要求。 严格使用上述定义设计的应用程序,在不同对齐要求的系统中移植时,只需要修改上述定义即可,源代码完全不用修改。 支持一下。 第一次抢到沙发哦{:biggrin:} 现在还看不懂,还得努力学习 顶起,刚看到讲的好
页:
[1]