目錄
1.Tricore尋址模式
2.lsl鏈接文件Section分析
3.限定符對(duì)于代碼的影響
4.小結(jié)
1.Tricore尋址模式
今天聊個(gè)好玩的事情。 之前ARM培訓(xùn)的時(shí)候,他們對(duì)于函數(shù)形參的先后順序、數(shù)據(jù)類型、對(duì)齊方式等等做了介紹,詳細(xì)分析了上述操作不同寫法對(duì)于CPU的通用寄存器使用效率上的影響,這給我留下了一點(diǎn)印象,但不多。 而最近我在用ADS驗(yàn)英飛凌LMU、DSPR、PSRP等等訪問效率時(shí),發(fā)現(xiàn)了這樣一行代碼:
#pragma section farbss lmubss#pragma ,section,咱們都非常熟悉了,這個(gè)farbss是什么意思呢?以前做BSW還真沒多大關(guān)注這個(gè)。 查看Tasking的手冊(cè),得到了一些答案,如下:
可以看到,上述farbss這類屬于lsl里的section類型,而對(duì)于其memory 限定符則為__far,它表示遠(yuǎn)程數(shù)據(jù);再看其他的限定符,分別出現(xiàn)了__a0,__a1等等,很明顯講的是Tricore內(nèi)核的尋址模式,那么順著這個(gè)思路來捋捋線索,為代碼能力和系統(tǒng)優(yōu)化打基礎(chǔ)。 Tricore 1.6.2的編程模型長(zhǎng)這樣:
總共32個(gè)通用寄存器,其中16個(gè)作為數(shù)據(jù)寄存器D[0]-D[15],16個(gè)作為地址寄存器A[0]-A[15],特別的,A[0]、A[1]、A[8]、A[9]還可以作為系統(tǒng)Global寄存器進(jìn)行使用,我們?cè)倩剡^頭來看看Tasking文件里給的memory限定符,似乎有某種聯(lián)系,因此接下來我們了解Tricore的尋址模式。 Tricore是32位機(jī),很明顯可以訪問4GBytes(2^32)的memory空間,這4GB空間分成了16個(gè)Segment[0H-FH],用地址高四位來索引,每個(gè)Segment為256MBytes,其用法如下:
所謂尋址模式,就是LoadStore這類指令訪問數(shù)據(jù)元素的機(jī)制,這些數(shù)據(jù)元素長(zhǎng)度可以為8163264bits。Tricore提供了7種尋址模式,如下圖:
絕對(duì)尋址:主要用于I/O 外設(shè)寄存器和全局?jǐn)?shù)據(jù)的訪問,值得一提的是,這種方式只能訪問每個(gè)segment的前16K,原因如下:
利用高四位定位segment,利用低14位定位目標(biāo),而2^14剛好為16KB,這與Tasking memory限定符__near關(guān)聯(lián)。 基地址+偏移:主要用于局部變量、靜態(tài)數(shù)據(jù)等訪問,根據(jù)偏移的不同尋址方式可以分為short offset尋址(10 bits)和long offset尋址(16bits)。long offset尋址剛好就對(duì)應(yīng)__a0a1a8a9訪問。 故對(duì)于尋址方式與限定符關(guān)聯(lián)關(guān)系如下:
那這個(gè)__far到底指的是什么呢?根據(jù)手冊(cè)描述,指的是能夠訪問所有memory區(qū)域的數(shù)據(jù),難不成這些個(gè)限定符還會(huì)對(duì)匯編代碼有所影響嗎?這些限定符與鏈接文件有沒有關(guān)聯(lián)呢?
2.lsl鏈接文件Section分析
在ADS給的lsl模板中,可以看到關(guān)于上述限定符以及對(duì)應(yīng)section type的描述,例如:
/*Near Abbsolute Addressable Data Sections*/ section_layout abs18 { group { } } /*Relative A0/A1/A8/A9 Addressable Sections*/ section_layout linear { group { } }
其中,abs18表示18bit絕對(duì)尋址空間,linear表示線性地址空間,如下圖所示:
.bss:未初始化數(shù)據(jù)
.bss_a0a1a8a9:未初始化數(shù)據(jù),用寄存器A0A1A8A9尋址
.data:已初始化數(shù)據(jù)
.data_a0a1a8a9:已初始化的數(shù)據(jù),用寄存器A0A1A8A9尋址
.sbss:未初始化的數(shù)據(jù),a0尋址
.sdata:已初始化的數(shù)據(jù),a0尋址
.zbss:未初始化數(shù)據(jù),abs18尋址
.zdata:已初始化數(shù)據(jù),abs18尋址
我們?cè)贑pu0_main.c里定義兩個(gè)變量,不添加任何限定符,如下:
編譯生成出來的map,可以看到這兩個(gè)變量是放在.bss中: ?對(duì)應(yīng)lsl定義的Far Data Section:
如果加上限定符__near,如下:
uint32 __near example_x ; uint32 __near example_y;
編譯出來發(fā)現(xiàn)已經(jīng)放到了zbss段
如果加上限定符__a0,我們會(huì)發(fā)現(xiàn)這時(shí)候編譯出了問題,如下:
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...寄存器中內(nèi)容上下偏移±32KB,例如,當(dāng)A0寄存器里內(nèi)容為0xD0018000時(shí),那么通過A0寄存器尋址的所有變量就應(yīng)該在0xD0010000 - 0xD001FFFF。這個(gè)場(chǎng)景后面構(gòu)建了我們?cè)儆懻摚辽傥覀兇_定了利用寄存器+偏移的方式多用于局部變量訪問。
3.限定符對(duì)于代碼的影響
第二節(jié)我們發(fā)現(xiàn)了利用不同限定符將變量發(fā)到不同的section里,但是變量的地址始終沒有變化,那這到底有什么用呢? 編譯出來的C代碼最終會(huì)以匯編形式展示給機(jī)器,因此我們來看看不同限定符下對(duì)于代碼的影響。 1)添加__near限定符,編譯得到的結(jié)構(gòu),代碼如下:
uint32 __near example_x ; uint32 __near example_y; void main(void) { example_x = 3; example_y=example_x+2; }得到匯編代碼如下
解釋如下:
將立即數(shù)3賦給寄存器D15
D15的值直接賦給變量(x)
立即數(shù)3賦給寄存器D15
D15和2相加
將D15的值直接賦給變量(y)
統(tǒng)計(jì)攏共5條指令完成x=3,y=x+2這個(gè)操作; 2)添加__far限定符,得到如下
uint32 __far example_x ; uint32 __far example_y; void main(void) { example_x = 3; example_y=example_x+2; }匯編代碼如下:
解釋如下:
x的賦值:
將0x7000給到地址寄存器A15高16bit,低位補(bǔ)0,這時(shí)候A15 = 0x70000000
加載有效地址到A15,因?yàn)閤地址為0x70000004,故A15 = 0x70000004
將數(shù)據(jù)3移至D15;
將D15賦給A15指向的地址
y的賦值
將0x7000給到地址寄存器A15高16bit,低位補(bǔ)0,這時(shí)候A15 = 0x70000000
加載有效地址到A15,因?yàn)閥地址為0x70000008,故A15 = 0x70000008
將數(shù)據(jù)3移至D15,并加2;
將D15賦給A15指向的地址
總計(jì)9條指令,咋一看僅僅節(jié)省了4條指令,但從統(tǒng)計(jì)角度來看,效率提升了44.44%,F(xiàn)lash消耗更少了。 同樣兩行C代碼,僅僅因?yàn)閷ぶ贩绞降牟煌瑓R編指令差異如此之大 ,從而影響系統(tǒng)運(yùn)行效率。
4.小結(jié)
現(xiàn)在MCU的性能越來越強(qiáng)大,導(dǎo)致我在使用上越來越隨意,對(duì)于這種特別底層的知識(shí)非常匱乏,直到遇到了系統(tǒng)優(yōu)化問題,才會(huì)去從這些角度來考慮。總結(jié)下來,在系統(tǒng)性能優(yōu)化時(shí)要注意:
構(gòu)建memory限定符使用場(chǎng)景以優(yōu)化代碼執(zhí)行效率;
多使用靠近CPU的memory,例如ARM TCM、Tricore DSPR、PSPR;
通過調(diào)試匯編代碼,也更進(jìn)一步了解了Tricore內(nèi)核的運(yùn)行原理;接下來,思考如何將這些理論引入到工程代碼中。
-
寄存器
+關(guān)注
關(guān)注
31文章
5343瀏覽量
120348 -
效率
+關(guān)注
關(guān)注
0文章
149瀏覽量
20052 -
TriCore
+關(guān)注
關(guān)注
0文章
15瀏覽量
11751
原文標(biāo)題:TC3xx分析--如何提高系統(tǒng)運(yùn)行效率
文章出處:【微信號(hào):eng2mot,微信公眾號(hào):汽車ECU開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論