<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    大端還是小端?

    Posted on 2006-11-07 13:29 nemo 閱讀(4857) 評論(4)  編輯  收藏

    今天研究SHA-1算法源碼,發(fā)現(xiàn)注釋中一個詞怎么也搞不懂:Big-Endian. 在網(wǎng)上查了才知道是大端在前的意思。在http://blog.vckbase.com/smileonce/archive/2005/02/22/3202.aspx?和 http://blog.myrice.com/reddenedmaple/archives/50001922.html中有比較多地介紹。但是很亂,我整理了一下,并加入了自己的一些理解。感謝提供信息的人們。

    這兩個術(shù)語來自于?Jonathan?Swift?的《《格利佛游記》其中交戰(zhàn)的兩個派別無法就應該從哪一端--小端還是大端--打開一個半熟的雞蛋達成一致。
    在那個時代,Swift是在諷刺英國和法國之間的持續(xù)沖突,Danny?Cohen,一位網(wǎng)絡協(xié)議的早期開創(chuàng)者,第一次使用這兩個術(shù)語來指代字節(jié)順序,后來這個術(shù)語被廣泛接納了,成為計算機專用名詞。除網(wǎng)絡傳輸之外,在計算機硬件中也有使用,通常表示邏輯最小處理單元大于物理最小處理單元時邏輯單元與物理單元的映射方式。
    由于這個概念第一次提出時是來指代字節(jié)順序,而且計算機物理最小處理單元通常為一個字節(jié),所以通常情況下無論是大端還是小端都是以字節(jié)(8bit)計,在字節(jié)之內(nèi)都是以大端順序排列。但不排除以后隨著計算機的發(fā)展將這個數(shù)字擴充。

    字節(jié)排序含義
    Big-Endian高位在前,低位在后。
    Little-Endian低位在前,高位在后


    請看下面這個例子:
    如果我們將0x1234abcd寫入到以0x0000開始的內(nèi)存中,則結(jié)果為
    ??????????????? big-endian???? little-endian
    0x0000???? 0x12????????????? 0xcd
    0x0001???? 0x34????????????? 0xab
    0x0002???? 0xab????????????? 0x34
    0x0003???? 0xcd????????????? 0x12

    然后,假如需要從內(nèi)存中取32位整數(shù)0x1234abcd中的高16位整數(shù),就需要知道是不是big-endian,如果是,需要從0x0002地址中去取,如果是little-endian,則需要從0x0000中取。也即怎么存就怎么取。

    為什么會出現(xiàn)這樣的情況呢?為什么要有這兩種方式來排列數(shù)據(jù)?我們可以看看Dr. William T. Verts所作的說明:

    Which?is?Better?

    You?may?see?a?lot?of?discussion?about?the?relative?merits?of?the?two?formats,?
    mostly?religious?arguments?based?on?the?relative?merits?of?the?PC?versus?the?Mac.?
    Both?formats?have?their?advantages?and?disadvantages.

    In?"Little?Endian"?form,?assembly?language?instructions?for?picking?up?a?1,?2,?4,?or?longer?byte?number?proceed?
    in?exactly?the?same?way?for?all?formats:?first?pick?up?the?lowest?order?byte?at?offset?0.?
    Also,?because?of?the?1:1?relationship?between?address?offset?and?byte?number?(offset?0?is?byte?0),?
    multiple?precision?math?routines?are?correspondingly?easy?to?write.

    In?"Big?Endian"?form,?by?having?the?high-order?byte?come?first,?
    you?can?always?test?whether?the?number?is?positive?or?negative?by?looking?at?the?byte?at?offset?zero.?
    You?don't?have?to?know?how?long?the?number?is,?nor?do?you?have?to?skip?over?any?bytes?to?find?the?byte?containing?the?sign?information.?
    The?numbers?are?also?stored?in?the?order?in?which?they?are?printed?out,?so?binary?to?decimal?routines?are?particularly?efficient.

    翻譯如下:
    你可能看見過很多關(guān)于這兩種形式的相對優(yōu)點的討論,最激烈的爭論是關(guān)于PC和MAC的相對優(yōu)點。這兩種形式都有其優(yōu)點和缺點。

    在“小終結(jié)者”形式中,提取一個,兩個,四個或者更長字節(jié)數(shù)據(jù)的匯編指令以與其他所有格式相同的方式進行:首先在偏移地址為0的地方提取最低位的字節(jié),因為地址偏移和字節(jié)數(shù)是一對一的關(guān)系,多重精度的數(shù)學函數(shù)就相對地容易寫了。

    在“大終結(jié)者”的形式中,靠首先提取高位字節(jié),你總是可以由看看在偏移位置為0的字節(jié)來確定這個數(shù)字是正數(shù)還是負數(shù)。你不必知道這個數(shù)值有多長,或者你也不必跳過一些字節(jié)來看這個數(shù)值是否含有符號位。這個數(shù)值是以它們被打印出來的順序存放的,所以從二進制到十進制的函數(shù)特別有效。

    因而,對于不同要求的機器,在設計存取方式時就會不同。
    IBM的370主機,多數(shù)基于RISC計算機,和Motorola的微處理器使用big-endian方法。TCP/IP也使用big-endian方法(big-endian方法也叫做網(wǎng)絡編碼)。對于人來說我們的語言都是從左到右的習慣方式。這看上去似乎被認為是自然的存儲字符和數(shù)字方式-你同樣也希望以同樣的方式出現(xiàn)在你面前。許多人因此也會認為big-endian是流行的存儲方式,正如我們平時所讀到的。

    然而,Intel處理器(CPUs)和DEC Alphas和至少一些在他們的平臺的其他程序都是little-endian的。對于little-endian有一個問題,那就是如果你增加數(shù)字的值,你可能在左邊增加數(shù)字(高位非指數(shù)函數(shù)需要更多的數(shù)字)。因此,經(jīng)常需要增加兩位數(shù)字并移動存儲器里所有Big-endian順序的數(shù)字,把所有數(shù)向右移,這會增加計算機的工作量。不過,使用little-endian的存儲器中不重要的字節(jié)可以存在它原來的位置,新的數(shù)可以存在它的右邊的高位地址里。這就意味著計算機中的某些計算可以變得更加簡單和快速。

    Feedback

    # 這個我研究過。  回復  更多評論   

    2006-11-08 08:43 by lvcha
    java因為存在虛擬機,所以把底層的大端和小端問題屏蔽了,內(nèi)部都是小端,恰恰與.net相反,它沒有屏蔽這件事情。
    呵呵,所以他們兩個序列化反序列化需要手工處理一下。java端。

    # re: 大端還是小端?  回復  更多評論   

    2006-11-10 10:36 by nemo
    對。Java等的語言編譯器必須明確他們開發(fā)的目標代碼使用的是什么存儲方式。如果有必要,可以使用轉(zhuǎn)換器可以用來轉(zhuǎn)換存儲順序。

    # re: 大端還是小端?  回復  更多評論   

    2009-04-04 21:03 by Moto
    反了吧,Big Endian是高位存低址啊。

    # re: 大端還是小端?  回復  更多評論   

    2009-04-04 21:05 by Moto
    哦,沒反。有點暈

    只有注冊用戶登錄后才能發(fā)表評論。


    網(wǎng)站導航:
     

    posts - 21, comments - 74, trackbacks - 0, articles - 3

    Copyright © nemo

    主站蜘蛛池模板: 国产亚洲福利一区二区免费看| 久久久久亚洲av无码尤物| 亚洲精品国产成人| 免费国产叼嘿视频大全网站| 亚洲日本在线观看视频| 亚洲AV无码AV日韩AV网站| 成年大片免费视频| 日韩亚洲国产综合高清| 免费人成在线视频| 亚洲精品精华液一区二区 | 在线看片免费人成视频福利| 久久久久久久尹人综合网亚洲| 黄色网站软件app在线观看免费| 久久亚洲综合色一区二区三区| 十八禁视频在线观看免费无码无遮挡骂过 | 四虎在线成人免费网站| 亚洲国产高清在线精品一区| 无码日韩人妻av一区免费| 亚洲成av人无码亚洲成av人| 又粗又硬免费毛片| 中文字幕免费在线看电影大全 | 亚洲日本一线产区和二线产区对比| 最近中文字幕mv免费高清电影| 亚洲AV成人无码久久WWW| 亚洲 综合 国产 欧洲 丝袜 | 日韩免费无码视频一区二区三区| 亚洲日韩乱码中文无码蜜桃臀| 国产无人区码卡二卡三卡免费| 亚洲色少妇熟女11p| 亚洲成a人片在线观看国产| 亚洲精品视频免费| 亚洲精品自产拍在线观看动漫| 动漫黄网站免费永久在线观看| 污视频网站免费在线观看| 亚洲av永久无码精品表情包| 91在线视频免费91| aa午夜免费剧场| 亚洲小说区图片区| 亚洲男人的天堂在线va拉文| 久久国产免费一区二区三区| 亚洲中文字幕久久精品蜜桃|