作為過來人，我發現很多程序猿新手，在編寫代碼的時候，特別喜歡定義很多獨立的全局變量，而不是把這些變量封裝到一個結構體中，主要原因是圖方便，但是要知道，這其實是一個不好的習慣，而且會降低整體代碼的性能。

另一方面，最近有幸與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=gcd
TARGETC=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賦值給r2
16. 將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. 反彙編代碼如下：

由上圖可知：

結構體變量peng位於bss段，地址是4000802c
訪問結構體成員也需要利用pc找到結構體變量peng對應的文字池中地址40008028，然後間接找到結構體變量peng地址4000802c

與定義成3個全局變量相比，優點：

結構體的所有成員在literal pool 中共用同一個地址；而每一個全局變量在literal pool 中都有一個地址，節省了8個字節。
訪問結構體其他成員的時候，不需要再次裝載基地址，只需要2條指令即可實現賦值；訪問3個成員，總共需要7條指令，節省了5條指令

彩！

所以對於需要大量訪問結構體成員的功能函數，所有訪問結構體成員的操作只需要加載一次基地址即可。

使用結構體就可以大大的節省指令周期，而節省指令周期對於提高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內存中

彩！彩！彩！彩！

想真正了解程式語言，怎能不掌握彙編？和一口君一起學習吧！

C語言為什麼使用結構體效率會高？一文給你講透