把变量赋值给寄存器_散装 vs 批发谁效率高?变量访问被ARM架构安排的明明白白...
作為過來人,我發現很多程序猿新手,在編寫代碼的時候,特別喜歡定義很多獨立的全局變量,而不是把這些變量封裝到一個結構體中,主要原因是圖方便,但是要知道,這其實是一個不好的習慣,而且會降低整體代碼的性能。
另一方面,最近有幸與大神「公眾號:裸機思維」的傻孩子交流的時候,他聊到:“其實Cortex在架構層面就是更偏好面向對象的(哪怕你只是使用了結構體),其表現形式就是:「Cortex所有的尋址模式都是間接尋址」——換句話說「一定依賴一個寄存器作為基地址」。
舉例來說,同樣是訪問外設寄存器,過去在8位和16位機時代,人們喜歡給每一個寄存器都單獨綁定地址——當作全局變量來訪問,而現在Cortex在架構上更鼓勵底層驅動以寄存器頁(也就是結構體)為單位來定義寄存器,這也就是說,同一個外設的寄存器是借助擁有同一個基地址的結構體來訪問的。”
以Cortex A9架構為前提,下面一口君詳細給你解釋為什么使用結構體效率會更高一些。
一、全局變量代碼反匯編
1. 源文件
「gcd.s」
.text.global?_start
_start:
??ldr??sp,=0x70000000?????????/*get?stack?top?pointer*/
??b??main
「main.c」
/*?*?main.c
?*
?*??Created?on:?2020-12-12
?*??????Author:?pengdan
?*/
int?xx=0;
int?yy=0;
int?zz=0;
int?main(void){
?xx=0x11;
?yy=0x22;
?zz=0x33;
?while(1);
????return?0;
}
「map.lds」
OUTPUT_FORMAT("elf32-littlearm",?"elf32-littlearm",?"elf32-littlearm")/*OUTPUT_FORMAT("elf32-arm",?"elf32-arm",?"elf32-arm")*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
?.?=?0x40008000;
?.?=?ALIGN(4);
?.text??????:
?{
??gcd.o(.text)
??*(.text)
?}
?.?=?ALIGN(4);
????.rodata?:?
?{?*(.rodata)?}
????.?=?ALIGN(4);
????.data?:?
?{?*(.data)?}
????.?=?ALIGN(4);
????.bss?:
?????{?*(.bss)?}
}
「Makefile」
TARGET=gcdTARGETC=main
all:
?arm-none-linux-gnueabi-gcc?-O1?-g?-c?-o?$(TARGETC).o??$(TARGETC).c
?arm-none-linux-gnueabi-gcc?-O1?-g?-c?-o?$(TARGET).o?$(TARGET).s
?arm-none-linux-gnueabi-gcc?-O1?-g?-S?-o?$(TARGETC).s??$(TARGETC).c
?arm-none-linux-gnueabi-ld?$(TARGETC).o?$(TARGET).o?-Tmap.lds??-o??$(TARGET).elf?
?arm-none-linux-gnueabi-objcopy?-O?binary?-S?$(TARGET).elf?$(TARGET).bin
?arm-none-linux-gnueabi-objdump?-D?$(TARGET).elf?>?$(TARGET).dis
clean:
?rm?-rf?*.o?*.elf?*.dis?*.bin
【交叉編譯工具,自行搜索安裝】
2. 反匯編結果:
由上圖可知,每存儲1個int型全局變量需要「8個字節」,
「literal pool (文字池)占用4個字節」
literal pool的本質就是ARM匯編語言代碼節中的一塊用來存放常量數據而非可執行代碼的內存塊。
使用literal?pool?(文字池)的原因當想要在一條指令中使用一個?4字節長度的常量數據(這個數據可以是內存地址,也可以是數字常量)的時候,由于ARM指令集是定長的(ARM指令4字節或Thumb指令2字節),所以就無法把這個4字節的常量數據編碼在一條編譯后的指令中。此時,ARM編譯器(編譯C源程序)/匯編器(編譯匯編程序)?就會在代碼節中分配一塊內存,并把這個4字節的數據常量保存于此,之后,再使用一條指令把這個4?字節的數字常量加載到寄存器中參與運算。
在C源代碼中,文字池的分配是由編譯器在編譯時自行安排的,在進行匯編程序設計時,開發者可以自己進行文字池的分配,如果開發者沒有進行文字池的安排,那么匯編器就會代勞。
「bss段占用4個字節」
每訪問1次全局變量,總共需要3條指令,訪問3次全局變量用了「12條指令」。
14.?通過當前pc值40008018偏移32個字節,找到xx變量的鏈接地址40008038,然后取出其內容40008044存放在r3中,該值就是xx在bss段的地址15.?通過將立即數0x11即#17賦值給r216.?將r2的內容那個寫入到r3對應的指向的內存,即xx標號對應的內存中二、結構體代碼反匯編
1. 修改main.c如下:
?/*??2??*?main.c???????????????????????????????????????????????????????????
??3??*
??4??*??Created?on:?2020-12-12
??5??*??????Author:?一口Linux
??6??*/
??7?struct
??8?{
??9?????int?xx;
?10?????int?yy;
?11?????int?zz;
?12?}peng;
?13?int?main(void)
?14?{
?15?????peng.xx=0x11;
?16?????peng.yy=0x22;
?17?????peng.zz=0x33;
?18?
?19?????while(1);
?20?????return?0;
?21?}
2. 反匯編代碼如下:
由上圖可知:
與定義成3個全局變量相比,優點:
「彩!」
所以對于需要大量訪問結構體成員的功能函數,所有訪問結構體成員的操作只需要加載一次基地址即可。
使用結構體就可以大大的節省指令周期,而節省指令周期對于提高cpu的運行效率自然不言而喻。
「所以,重要問題說3遍」
「盡量使用結構體」「盡量使用結構體」「盡量使用結構體」
三、繼續優化
那么指令還能不能更少一點呢?答案是可以的, 修改Makefile如下:
TARGET=gcd????????????????????????????????????????????????????????????????????????????????TARGETC=main
all:
?????arm-none-linux-gnueabi-gcc?-Os???-lto?-g?-c?-o?$(TARGETC).o??$(TARGETC).c
?????arm-none-linux-gnueabi-gcc?-Os??-lto?-g?-c?-o?$(TARGET).o?$(TARGET).s
?????arm-none-linux-gnueabi-gcc?-Os??-lto?-g?-S?-o?$(TARGETC).s??$(TARGETC).c
?????arm-none-linux-gnueabi-ld???$(TARGETC).o????$(TARGET).o?-Tmap.lds??-o??$(TARGET).elf
?????arm-none-linux-gnueabi-objcopy?-O?binary?-S?$(TARGET).elf?$(TARGET).bin
?????arm-none-linux-gnueabi-objdump?-D?$(TARGET).elf?>?$(TARGET).dis
clean:
?????rm?-rf?*.o?*.elf?*.dis?*.bin
仍然用第二章的main.c文件
執行結果可以看到代碼已經被優化到5條。
14.?把peng的地址40008024裝載到r3中15.?r0寫入立即數0x11
16.?r1寫入立即數0x22
17.?r0寫入立即數0x33
18.?通過stm指令將r0、r1、r2的值順序寫入到40008024內存中
「彩!彩!彩!彩!」
文中用到的匯編知識可以參考ARM系列文章
《從0學arm合集》
推薦閱讀
【1】嵌入式工程師到底要不要學習ARM匯編指令?必讀【2】7. 從0學ARM-匯編偽指令、lds詳解【3】IP協議入門必讀【4】【從0學ARM】你不了解的ARM處理異常之道【5】4. 從0開始學ARM-ARM匯編指令其實很簡單【6】【典藏】大佬們都在用的結構體進階小技巧【7】[粉絲問答6]子進程進程的父進程關系【8】C和匯編如何互相調用?嵌入式工程師必須掌握進群,請加一口君個人微信,帶你嵌入式入門進階。
總結
以上是生活随笔為你收集整理的把变量赋值给寄存器_散装 vs 批发谁效率高?变量访问被ARM架构安排的明明白白...的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 便捷与安全兼得 华为终端云服务为你的智慧
- 下一篇: 8万元“人字拖”Halo系统又立功了!F