优化TC3xx系统运行效率的策略

描述

目录

1.Tricore寻址模式

2.lsl链接文件Section分析

3.限定符对于代码的影响

4.小结

1.Tricore寻址模式

今天聊个好玩的事情。 之前ARM培训的时候,他们对于函数形参的先后顺序、数据类型、对齐方式等等做了介绍,详细分析了上述操作不同写法对于CPU的通用寄存器使用效率上的影响,这给我留下了一点印象,但不多。 而最近我在用ADS验英飞凌LMU、DSPR、PSRP等等访问效率时,发现了这样一行代码:

 

#pragma section farbss lmubss
#pragma ,section,咱们都非常熟悉了,这个farbss是什么意思呢?以前做BSW还真没多大关注这个。 查看Tasking的手册,得到了一些答案,如下:

TriCore

可以看到,上述farbss这类属于lsl里的section类型,而对于其memory 限定符则为__far,它表示远程数据;再看其他的限定符,分别出现了__a0,__a1等等,很明显讲的是Tricore内核的寻址模式,那么顺着这个思路来捋捋线索,为代码能力和系统优化打基础。 Tricore 1.6.2的编程模型长这样:

TriCore

总共32个通用寄存器,其中16个作为数据寄存器D[0]-D[15],16个作为地址寄存器A[0]-A[15], 特别的,A[0]、A[1]、A[8]、A[9]还可以作为系统Global寄存器进行使用,我们再回过头来看看Tasking文件里给的memory限定符,似乎有某种联系,因此接下来我们了解Tricore的寻址模式。 Tricore是32位机,很明显可以访问4GBytes(2^32)的memory空间,这4GB空间分成了16个Segment[0H-FH],用地址高四位来索引,每个Segment为256MBytes,其用法如下:

TriCore

所谓寻址模式,就是LoadStore这类指令访问数据元素的机制,这些数据元素长度可以为8163264bits。Tricore提供了7种寻址模式,如下图:

TriCore

绝对寻址:主要用于I/O 外设寄存器和全局数据的访问,值得一提的是,这种方式只能访问每个segment的前16K,原因如下:

TriCore

利用高四位定位segment,利用低14位定位目标,而2^14刚好为16KB,这与Tasking memory限定符__near关联。 基地址+偏移:主要用于局部变量、静态数据等访问,根据偏移的不同寻址方式可以分为short offset寻址(10 bits)和long offset寻址(16bits)。long offset寻址刚好就对应__a0a1a8a9访问。 故对于寻址方式与限定符关联关系如下:

TriCore

那这个__far到底指的是什么呢?根据手册描述,指的是能够访问所有memory区域的数据,难不成这些个限定符还会对汇编代码有所影响吗?这些限定符与链接文件有没有关联呢?

 

 

2.lsl链接文件Section分析

在ADS给的lsl模板中,可以看到关于上述限定符以及对应section type的描述,例如:

 


 
/*Near Abbsolute Addressable Data Sections*/
section_layout abs18
{
group
    {
    }
}


/*Relative A0/A1/A8/A9 Addressable Sections*/
section_layout linear
{
group
    {
    }
}

    其中,abs18表示18bit绝对寻址空间,linear表示线性地址空间,如下图所示:

TriCore

 

 

.bss:未初始化数据

.bss_a0a1a8a9:未初始化数据,用寄存器A0A1A8A9寻址

.data:已初始化数据

.data_a0a1a8a9:已初始化的数据,用寄存器A0A1A8A9寻址

.sbss:未初始化的数据,a0寻址

.sdata:已初始化的数据,a0寻址

.zbss:未初始化数据,abs18寻址

.zdata:已初始化数据,abs18寻址

我们在Cpu0_main.c里定义两个变量,不添加任何限定符,如下:

TriCore

编译生成出来的map,可以看到这两个变量是放在.bss中: TriCore 对应lsl定义的Far Data Section:

TriCore

如果加上限定符__near,如下:

 

uint32 __near example_x ;
uint32 __near example_y;

    编译出来发现已经放到了zbss段

TriCore

如果加上限定符__a0,我们会发现这时候编译出了问题,如下:

 

 

ltc E121: relocation error in "task1": relocation value 0x50000000, type R_TRICORE_16SM, offset 0x34, section ".text.Cpu0_Main.core0_main" at address 0x800023bc is not within a 16-bit signed range from the value of A0 as defined by the symbol _SMALL_DATA_

这就意味着,如果要使用寄存器+偏移寻址的方式,那么就必须是A0A1...寄存器中内容上下偏移±32KB,例如,当A0寄存器里内容为0xD0018000时,那么通过A0寄存器寻址的所有变量就应该在0xD0010000 - 0xD001FFFF。这个场景后面构建了我们再讨论,但至少我们确定了利用寄存器+偏移的方式多用于局部变量访问。

3.限定符对于代码的影响

第二节我们发现了利用不同限定符将变量发到不同的section里,但是变量的地址始终没有变化,那这到底有什么用呢? 编译出来的C代码最终会以汇编形式展示给机器,因此我们来看看不同限定符下对于代码的影响。 1)添加__near限定符,编译得到的结构,代码如下:

 

uint32 __near example_x ;
uint32 __near example_y;
void main(void)
{
example_x = 3;
example_y=example_x+2;
}
得到汇编代码如下

TriCore

解释如下:

 

 

将立即数3赋给寄存器D15

D15的值直接赋给变量(x)

立即数3赋给寄存器D15

D15和2相加

将D15的值直接赋给变量(y)

统计拢共5条指令完成x=3,y=x+2这个操作;  2)添加__far限定符,得到如下

 

uint32 __far example_x ;
uint32 __far example_y;
void main(void)
{
example_x = 3;
example_y=example_x+2;
}
汇编代码如下:

TriCore

解释如下:

 

 

x的赋值:

将0x7000给到地址寄存器A15高16bit,低位补0,这时候A15 = 0x70000000

加载有效地址到A15,因为x地址为0x70000004,故A15 = 0x70000004

将数据3移至D15;

将D15赋给A15指向的地址

y的赋值

将0x7000给到地址寄存器A15高16bit,低位补0,这时候A15 = 0x70000000

加载有效地址到A15,因为y地址为0x70000008,故A15 = 0x70000008

将数据3移至D15,并加2;

将D15赋给A15指向的地址

总计9条指令,咋一看仅仅节省了4条指令,但从统计角度来看,效率提升了44.44%,Flash消耗更少了。 同样两行C代码,仅仅因为寻址方式的不同,汇编指令差异如此之大 ,从而影响系统运行效率。

4.小结

现在MCU的性能越来越强大,导致我在使用上越来越随意,对于这种特别底层的知识非常匮乏,直到遇到了系统优化问题,才会去从这些角度来考虑。总结下来,在系统性能优化时要注意:

构建memory限定符使用场景以优化代码执行效率;

多使用靠近CPU的memory,例如ARM TCM、Tricore DSPR、PSPR;

DCache数据一致性问题

通过调试汇编代码,也更进一步了解了Tricore内核的运行原理;接下来,思考如何将这些理论引入到工程代码中。

 

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分