青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Welcome to ErranLi's Blog!

  C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
  106 Posts :: 1 Stories :: 97 Comments :: 0 Trackbacks

常用鏈接

留言簿(12)

搜索

  •  

積分與排名

  • 積分 - 178126
  • 排名 - 152

最新評論

閱讀排行榜


看了這篇(http://m.shnenglu.com/Randy/archive/2007/10/15/34288.aspx)關于字節(jié)對其的隨筆,覺得迷迷糊糊的,腦袋里只有字節(jié)對其這個概念,具體都忘的差不多了,又另外找了篇細讀了下,總算理解了。

來源:http://www.yuanma.org/data/2006/0723/article_1213.htm

一.什么是字節(jié)對齊,為什么要對齊?

??? 現(xiàn)代計算機中內(nèi)存空間都是按照byte劃分的,從理論上講似乎對任何類型的變量的訪問可以從任何地址開始,但實際情況是在訪問特定類型變量的時候經(jīng)常在特 定的內(nèi)存地址訪問,這就需要各種類型數(shù)據(jù)按照一定的規(guī)則在空間上排列,而不是順序的一個接一個的排放,這就是對齊。
??? 對齊的作用和原因:各個硬件平臺對存儲空間的處理上有很大的不同。一些平臺對某些特定類型的數(shù)據(jù)只能從某些特定地址開始存取。比如有些架構(gòu)的CPU在訪問 一個沒有進行對齊的變量的時候會發(fā)生錯誤,那么在這種架構(gòu)下編程必須保證字節(jié)對齊.其他平臺可能沒有這種情況,但是最常見的是如果不按照適合其平臺要求對 數(shù)據(jù)存放進行對齊,會在存取效率上帶來損失。比如有些平臺每次讀都是從偶地址開始,如果一個int型(假設為32位系統(tǒng))如果存放在偶地址開始的地方,那 么一個讀周期就可以讀出這32bit,而如果存放在奇地址開始的地方,就需要2個讀周期,并對兩次讀出的結(jié)果的高低字節(jié)進行拼湊才能得到該32bit數(shù) 據(jù)。顯然在讀取效率上下降很多。

二.字節(jié)對齊對程序的影響:

??? 先讓我們看幾個例子吧(32bit,x86環(huán)境,gcc編譯器):
設結(jié)構(gòu)體如下定義:
struct A
{
??? int a;
??? char b;
??? short c;
};
struct B
{
??? char b;
??? int a;
??? short c;
};
現(xiàn)在已知32位機器上各種數(shù)據(jù)類型的長度如下:
char:1(有符號無符號同)????
short:2(有符號無符號同)????
int:4(有符號無符號同)????
long:4(有符號無符號同)????
float:4????double:8
那么上面兩個結(jié)構(gòu)大小如何呢?
結(jié)果是:
sizeof(strcut A)值為8
sizeof(struct B)的值卻是12

結(jié)構(gòu)體A中包含了4字節(jié)長度的int一個,1字節(jié)長度的char一個和2字節(jié)長度的short型數(shù)據(jù)一個,B也一樣;按理說A,B大小應該都是7字節(jié)。
之所以出現(xiàn)上面的結(jié)果是因為編譯器要對數(shù)據(jù)成員在空間上進行對齊。上面是按照編譯器的默認設置進行對齊的結(jié)果,那么我們是不是可以改變編譯器的這種默認對齊設置呢,當然可以.例如:
#pragma pack (2) /*指定按2字節(jié)對齊*/
struct C
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對齊,恢復缺省對齊*/
sizeof(struct C)值是8。
修改對齊值為1:
#pragma pack (1) /*指定按1字節(jié)對齊*/
struct D
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對齊,恢復缺省對齊*/
sizeof(struct D)值為7。
后面我們再講解#pragma pack()的作用.

三.編譯器是按照什么樣的原則進行對齊的?

??? 先讓我們看四個重要的基本概念:
1.數(shù)據(jù)類型自身的對齊值:
? 對于char型數(shù)據(jù),其自身對齊值為1,對于short型為2,對于int,float,double類型,其自身對齊值為4,單位字節(jié)。
2.結(jié)構(gòu)體或者類的自身對齊值:其成員中自身對齊值最大的那個值。
3.指定對齊值:#pragma pack (value)時的指定對齊值value。
4.數(shù)據(jù)成員、結(jié)構(gòu)體和類的有效對齊值:自身對齊值和指定對齊值中小的那個值。
有 了這些值,我們就可以很方便的來討論具體數(shù)據(jù)結(jié)構(gòu)的成員和其自身的對齊方式。有效對齊值N是最終用來決定數(shù)據(jù)存放地址方式的值,最重要。有效對齊N,就是 表示“對齊在N上”,也就是說該數(shù)據(jù)的"存放起始地址%N=0".而數(shù)據(jù)結(jié)構(gòu)中的數(shù)據(jù)變量都是按定義的先后順序來排放的。第一個數(shù)據(jù)變量的起始地址就是數(shù) 據(jù)結(jié)構(gòu)的起始地址。結(jié)構(gòu)體的成員變量要對齊排放,結(jié)構(gòu)體本身也要根據(jù)自身的有效對齊值圓整(就是結(jié)構(gòu)體成員變量占用總長度需要是對結(jié)構(gòu)體有效對齊值的整數(shù) 倍,結(jié)合下面例子理解)。這樣就不能理解上面的幾個例子的值了。
例子分析:
分析例子B;
struct B
{
??? char b;
??? int a;
??? short c;
};
假 設B從地址空間0x0000開始排放。該例子中沒有定義指定對齊值,在筆者環(huán)境下,該值默認為4。第一個成員變量b的自身對齊值是1,比指定或者默認指定 對齊值4小,所以其有效對齊值為1,所以其存放地址0x0000符合0x0000%1=0.第二個成員變量a,其自身對齊值為4,所以有效對齊值也為4, 所以只能存放在起始地址為0x0004到0x0007這四個連續(xù)的字節(jié)空間中,復核0x0004%4=0,且緊靠第一個變量。第三個變量c,自身對齊值為 2,所以有效對齊值也是2,可以存放在0x0008到0x0009這兩個字節(jié)空間中,符合0x0008%2=0。所以從0x0000到0x0009存放的 都是B內(nèi)容。再看數(shù)據(jù)結(jié)構(gòu)B的自身對齊值為其變量中最大對齊值(這里是b)所以就是4,所以結(jié)構(gòu)體的有效對齊值也是4。根據(jù)結(jié)構(gòu)體圓整的要求, 0x0009到0x0000=10字節(jié),(10+2)%4=0。所以0x0000A到0x000B也為結(jié)構(gòu)體B所占用。故B從0x0000到0x000B 共有12個字節(jié),sizeof(struct B)=12;其實如果就這一個就來說它已將滿足字節(jié)對齊了, 因為它的起始地址是0,因此肯定是對齊的,之所以在后面補充2個字節(jié),是因為編譯器為了實現(xiàn)結(jié)構(gòu)數(shù)組的存取效率,試想如果我們定義了一個結(jié)構(gòu)B的數(shù)組,那 么第一個結(jié)構(gòu)起始地址是0沒有問題,但是第二個結(jié)構(gòu)呢?按照數(shù)組的定義,數(shù)組中所有元素都是緊挨著的,如果我們不把結(jié)構(gòu)的大小補充為4的整數(shù)倍,那么下一 個結(jié)構(gòu)的起始地址將是0x0000A,這顯然不能滿足結(jié)構(gòu)的地址對齊了,因此我們要把結(jié)構(gòu)補充成有效對齊大小的整數(shù)倍.其實諸如:對于char型數(shù)據(jù),其 自身對齊值為1,對于short型為2,對于int,float,double類型,其自身對齊值為4,這些已有類型的自身對齊值也是基于數(shù)組考慮的,只 是因為這些類型的長度已知了,所以他們的自身對齊值也就已知了.
同理,分析上面例子C:
#pragma pack (2) /*指定按2字節(jié)對齊*/
struct C
{
??? char b;
??? int a;
??? short c;
};
#pragma pack () /*取消指定對齊,恢復缺省對齊*/
第 一個變量b的自身對齊值為1,指定對齊值為2,所以,其有效對齊值為1,假設C從0x0000開始,那么b存放在0x0000,符合0x0000%1= 0;第二個變量,自身對齊值為4,指定對齊值為2,所以有效對齊值為2,所以順序存放在0x0002、0x0003、0x0004、0x0005四個連續(xù) 字節(jié)中,符合0x0002%2=0。第三個變量c的自身對齊值為2,所以有效對齊值為2,順序存放
在0x0006、0x0007中,符合 0x0006%2=0。所以從0x0000到0x00007共八字節(jié)存放的是C的變量。又C的自身對齊值為4,所以C的有效對齊值為2。又8%2=0,C 只占用0x0000到0x0007的八個字節(jié)。所以sizeof(struct C)=8.

四.如何修改編譯器的默認對齊值?

1.在VC IDE中,可以這樣修改:[Project]|[Settings],c/c++選項卡Category的Code Generation選項的Struct Member Alignment中修改,默認是8字節(jié)。
2.在編碼時,可以這樣動態(tài)修改:#pragma pack .注意:是pragma而不是progma.

五.針對字節(jié)對齊,我們在編程中如何考慮?


??? 如果在編程的時候要考慮節(jié)約空間的話,那么我們只需要假定結(jié)構(gòu)的首地址是0,然后各個變量按照上面的原則進行排列即可,基本的原則就是把結(jié)構(gòu)中的變量按照 類型大小從小到大聲明,盡量減少中間的填補空間.還有一種就是為了以空間換取時間的效率,我們顯示的進行填補空間進行對齊,比如:有一種使用空間換時間做 法是顯式的插入reserved成員:
???????? struct A{
?????????? char a;
?????????? char reserved[3];//使用空間換時間
?????????? int b;
}

reserved成員對我們的程序沒有什么意義,它只是起到填補空間以達到字節(jié)對齊的目的,當然即使不加這個成員通常編譯器也會給我們自動填補對齊,我們自己加上它只是起到顯式的提醒作用.

六.字節(jié)對齊可能帶來的隱患:

??? 代碼中關于對齊的隱患,很多是隱式的。比如在強制類型轉(zhuǎn)換的時候。例如:
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;

p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后兩句代碼,從奇數(shù)邊界去訪問unsignedshort型變量,顯然不符合對齊的規(guī)定。
在x86上,類似的操作只會影響效率,但是在MIPS或者sparc上,可能就是一個error,因為它們要求必須字節(jié)對齊.

七.如何查找與字節(jié)對齊方面的問題:

如果出現(xiàn)對齊或者賦值問題首先查看
1. 編譯器的big little端設置
2. 看這種體系本身是否支持非對齊訪問
3. 如果支持看設置了對齊與否,如果沒有則看訪問時需要加某些特殊的修飾來標志其特殊訪問操作。

八.相關文章:轉(zhuǎn)自http://blog.csdn.net/goodluckyxl/archive/2005/10/17/506827.aspx

?ARM下的對齊處理
from DUI0067D_ADS1_2_CompLib

3.13 type? qulifiers

有部分摘自ARM編譯器文檔對齊部分

對齊的使用:
1.__align(num)
?? 這個用于修改最高級別對象的字節(jié)邊界。在匯編中使用LDRD或者STRD時
?? 就要用到此命令__align(8)進行修飾限制。來保證數(shù)據(jù)對象是相應對齊。
?? 這個修飾對象的命令最大是8個字節(jié)限制,可以讓2字節(jié)的對象進行4字節(jié)
?? 對齊,但是不能讓4字節(jié)的對象2字節(jié)對齊。
?? __align是存儲類修改,他只修飾最高級類型對象不能用于結(jié)構(gòu)或者函數(shù)對象。
??
2.__packed
? __packed是進行一字節(jié)對齊
? 1.不能對packed的對象進行對齊
? 2.所有對象的讀寫訪問都進行非對齊訪問
? 3.float及包含float的結(jié)構(gòu)聯(lián)合及未用__packed的對象將不能字節(jié)對齊
? 4.__packed對局部整形變量無影響
? 5.強制由unpacked對象向packed對象轉(zhuǎn)化是未定義,整形指針可以合法定
? 義為packed。
???? __packed int* p;? //__packed int 則沒有意義
? 6.對齊或非對齊讀寫訪問帶來問題
? __packed struct STRUCT_TEST
?{
? char a;
? int b;
? char c;
?}? ;??? //定義如下結(jié)構(gòu)此時b的起始地址一定是不對齊的
???????? //在棧中訪問b可能有問題,因為棧上數(shù)據(jù)肯定是對齊訪問[from CL]
//將下面變量定義成全局靜態(tài)不在棧上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
?__packed int* q;? //此時定義成__packed來修飾當前q指向為非對齊的數(shù)據(jù)地址下面的訪問則可以

?p = (char*)&a;?????????
?q = (int*)(p+1);?????
?
?*q = 0x87654321;
/*??
得到賦值的匯編指令很清楚
ldr????? r5,0x20001590 ; = #0x12345678
[0xe1a00005]?? mov????? r0,r5
[0xeb0000b0]?? bl?????? __rt_uwrite4? //在此處調(diào)用一個寫4byte的操作函數(shù)
?????
[0xe5c10000]?? strb???? r0,[r1,#0]?? //函數(shù)進行4次strb操作然后返回保證了數(shù)據(jù)正確的訪問
[0xe1a02420]?? mov????? r2,r0,lsr #8
[0xe5c12001]?? strb???? r2,[r1,#1]
[0xe1a02820]?? mov????? r2,r0,lsr #16
[0xe5c12002]?? strb???? r2,[r1,#2]
[0xe1a02c20]?? mov????? r2,r0,lsr #24
[0xe5c12003]?? strb???? r2,[r1,#3]
[0xe1a0f00e]?? mov????? pc,r14
*/

/*
如果q沒有加__packed修飾則匯編出來指令是這樣直接會導致奇地址處訪問失敗
[0xe59f2018]?? ldr????? r2,0x20001594 ; = #0x87654321
[0xe5812000]?? str????? r2,[r1,#0]
*/

//這樣可以很清楚的看到非對齊訪問是如何產(chǎn)生錯誤的
//以及如何消除非對齊訪問帶來問題
//也可以看到非對齊訪問和對齊訪問的指令差異導致效率問題
}
posted on 2007-10-16 22:56 erran 閱讀(1878) 評論(3)  編輯 收藏 引用 所屬分類: C & C++

Feedback

# re: 轉(zhuǎn):字節(jié)對齊詳解 2007-10-17 10:00 螞蟻終結(jié)者
不錯的文章。  回復  更多評論
  

# re: 轉(zhuǎn):字節(jié)對齊詳解 2007-10-19 21:04 Minidx全文檢索
這個很有用,收下了~  回復  更多評論
  

# re: 轉(zhuǎn):字節(jié)對齊詳解[未登錄] 2012-02-07 15:27 Frog
很經(jīng)典的一篇文章,看過了。  回復  更多評論
  

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲视频观看| 亚洲一区二区精品| 一区二区三区四区在线| 国内外成人免费激情在线视频网站 | 日韩视频精品在线| 亚洲国产91精品在线观看| 国产精品你懂的| 国产精品一区在线播放| 欧美日韩大片| 欧美精品一级| 欧美成在线观看| 狼狼综合久久久久综合网| 久久视频这里只有精品| 欧美大胆成人| 亚洲欧洲在线看| 欧美成人午夜剧场免费观看| 欧美成人免费小视频| 欧美激情第4页| 亚洲国语精品自产拍在线观看| 99ri日韩精品视频| 午夜精品短视频| 国产欧美日韩免费看aⅴ视频| 国产日韩欧美在线播放| 激情综合五月天| 日韩视频一区二区三区在线播放免费观看 | 亚洲春色另类小说| aⅴ色国产欧美| 羞羞色国产精品| 久久综合九色| 国产精品xxx在线观看www| 国产欧美在线视频| 亚洲国产成人高清精品| 一区二区三区日韩精品| 久久久久久久久久久一区| 国产精品久久91| 亚洲激情av| 亚洲欧美日韩一区| 欧美国产日产韩国视频| 亚洲先锋成人| 欧美 日韩 国产精品免费观看| 欧美激情视频在线播放 | 久久久精品一区| 欧美日韩精品欧美日韩精品 | 欧美激情一区二区三区四区| 国产精品久久久久久久电影| 国产视频在线观看一区二区| 亚洲欧洲日夜超级视频| 亚洲影院免费观看| 欧美黄色影院| 欧美在线观看天堂一区二区三区| 欧美激情亚洲综合一区| 国语精品中文字幕| 亚洲嫩草精品久久| 亚洲高清久久久| 欧美在线地址| 国产日韩av高清| 亚洲男女自偷自拍| 亚洲免费电影在线观看| 久久综合精品国产一区二区三区| 国产精品青草久久久久福利99| 亚洲精品影院在线观看| 裸体素人女欧美日韩| 午夜日本精品| 国产精品有限公司| 亚洲欧美一区二区原创| 日韩小视频在线观看| 欧美成在线观看| 亚洲国产国产亚洲一二三| 久久久久天天天天| 欧美一区在线看| 国产日韩在线看| 欧美一级二级三级蜜桃| 亚洲桃色在线一区| 国产精品久久久久久久久| 亚洲欧美福利一区二区| 99精品欧美一区二区蜜桃免费| 欧美激情第二页| 亚洲精品日韩一| 亚洲黄色av一区| 欧美久久影院| 亚洲一区在线观看视频 | 亚洲美女av黄| 亚洲美女精品一区| 欧美色图首页| 欧美亚洲网站| 久久蜜臀精品av| 国产精品国产| 亚洲视频图片小说| 一区二区三区日韩欧美| 国产精品久久久久久影视| 亚洲男同1069视频| 午夜亚洲精品| 一色屋精品视频在线观看网站| 蜜臀久久99精品久久久画质超高清| 久久精品一区二区三区不卡| 亚洲国产精品va在线看黑人| 亚洲欧洲日本专区| 国产精品户外野外| 久久五月天婷婷| 欧美激情1区| 西瓜成人精品人成网站| 久久国产精彩视频| 亚洲国产精品ⅴa在线观看| 亚洲欧洲一区二区天堂久久 | 久久伊人亚洲| 一本色道精品久久一区二区三区| 一区二区免费看| 韩国亚洲精品| 亚洲精品日韩久久| 亚洲免费人成在线视频观看| 香蕉久久国产| 亚洲精品女人| 午夜欧美不卡精品aaaaa| 亚洲欧洲一区| 亚洲欧美日韩国产一区二区三区| 在线观看欧美激情| av不卡在线| 亚洲第一中文字幕| 亚洲一区免费| 99日韩精品| 久久久久久亚洲精品中文字幕| 一本一本久久a久久精品综合麻豆 一本一本久久a久久精品牛牛影视 | 久久av一区二区三区漫画| 麻豆91精品| 欧美一区成人| 欧美日韩午夜精品| 欧美电影在线播放| 国产亚洲午夜| 亚洲一区二区在线免费观看| 在线视频亚洲| 亚洲日本成人女熟在线观看| 亚洲欧美精品在线观看| 亚洲精品免费在线| 久久免费午夜影院| 久久久久高清| 国产精品综合| 亚洲一区在线观看视频| 一本色道久久| 欧美激情2020午夜免费观看| 久久久综合网站| 国产毛片一区二区| 亚洲一级高清| 亚洲欧美一区二区精品久久久| 欧美日韩精品伦理作品在线免费观看 | 久久久91精品国产一区二区精品| 欧美日韩精品| 亚洲美女中文字幕| 99热这里只有精品8| 欧美va天堂va视频va在线| 免费在线播放第一区高清av| 韩国免费一区| 久久嫩草精品久久久久| 欧美va天堂| 91久久久一线二线三线品牌| 麻豆av一区二区三区| 亚洲国产清纯| 一区二区日韩欧美| 欧美三级网页| 一区二区成人精品| 欧美一级日韩一级| 国产亚洲欧美日韩在线一区| 欧美在线日韩在线| 久久免费视频网站| 欲色影视综合吧| 欧美成年人视频网站| 亚洲国产一区二区三区a毛片| 亚洲三级性片| 欧美日韩久久久久久| 亚洲一区二区三区激情| 欧美在线不卡| 黄色成人在线免费| 欧美.日韩.国产.一区.二区| 亚洲日本黄色| 欧美一区二区成人| 在线观看日韩欧美| 欧美国产成人精品| 一区二区三区日韩欧美| 久久久久久亚洲综合影院红桃| 加勒比av一区二区| 欧美精品在线播放| 亚洲欧洲美洲综合色网| 亚洲一区日韩在线| 黄色亚洲网站| 欧美精品一区二区三| 午夜久久久久| 亚洲精品一线二线三线无人区| 久久精品青青大伊人av| 亚洲精品免费在线| 国产一区二三区| 欧美视频网址| 葵司免费一区二区三区四区五区| 99精品99| 欧美插天视频在线播放| 亚洲免费视频在线观看| 亚洲国内精品在线| 国产日韩一区在线| 国产精品久久一区二区三区| 久久午夜影视| 新狼窝色av性久久久久久| 一区二区三区产品免费精品久久75 |