biefield與endian 2

karma303

  本來想更新到這篇舊帖子里的，但覺得這部分有點(diǎn)兒“地理大發(fā)現(xiàn)”的感覺，就專門貼出來，跟各位交流。
  我說的“地理大發(fā)現(xiàn)”，是說wiki上的ip header的布局圖，它們用0,1,2,3,4,5,6,7細(xì)分出每個字節(jié)的bit，但wiki上的0,1,2,3,4,5,6,7,分別對應(yīng)常規(guī)思維的7,6,5,4,3,2,1,0。


   到這里我才發(fā)現(xiàn)，原來wiki上給出的布局圖，是徹徹底底的按照“大端思維“來走的。
   其實(shí)wiki就從RFC里摘的圖，1981年的文檔，那時的程序員為什么會反著看bit？(是沒經(jīng)過x86的洗禮嗎？)
   
   題外話：
   在上一篇帖子里，我貼了一點(diǎn)關(guān)于bitfield跨字節(jié)的測試。
   其實(shí)今天意識到這個問題，也是從ip header里的offset成員開始的，我發(fā)現(xiàn)沒辦法用bitfield來表示這個成員。


  如果編譯目標(biāo)是小端機(jī)器，gcc是沒有辦法用bitfield來表示offset這個成員的。
  所以linux內(nèi)核里，很粗暴的定義成:
  __be16        frag_off;
  __be16就是unsigned short。
  然后在代碼里再分解它：
        offset = ntohs(ip_hdr(skb)->frag_off);
        flags = offset & ~IP_OFFSET;
        offset &= IP_OFFSET;
        offset <<= 3;                /* offset is in 8-byte chunks */

Godbach

回復(fù) 1# karma303

佩服 LZ 深度鉆研的精神！

   

Godbach

回復(fù) 1# karma303
最后一個圖，太能說明問題了。


   

mordorwww

karma303 發(fā)表于 2016-07-06 17:17
本來想更新到這篇舊帖子里的，但覺得這部分有點(diǎn)兒“地理大發(fā)現(xiàn)”的感覺，就專門貼出來，跟各位交流。
   ...

在部分平臺或許可以，linux要用在各種CPU平臺上，所以這樣了

nswcfd

精彩的分析！

對于線上的bit，估計是先到的算0號吧？

karma303

回復(fù) 5# nswcfd



   網(wǎng)線按什么樣的bit序傳遞數(shù)據(jù)，似乎影響不到軟件編程。連寫網(wǎng)卡驅(qū)動時都不需要關(guān)心它。
   我在osdev上問過相關(guān)的問題，但得到的回答有不痛不癢，可能是我英文水平有限吧。
   forum.osdev.org/viewtopic.php?f=1&t=30485

nswcfd

嗯，forum.osdev.org/viewtopic.php?f=1&t=30485，很有意思的討論。

https://en.wikipedia.org/wiki/Bit_numbering
里面有一句話

The recommended style for Request for Comments documents is "MSB 0" bit numbering.[3][4]

[3]  Scott, Gregor (June 1998 ). "RFC 2360 - Guide for Internet Standards Writers". Internet Engineering Task Force (IETF). p. 11. Retrieved 2010-02-14. The preferred form for packet diagrams is a sequence of long words in network byte order, with each word horizontal on the page and bit numbering at the top
[4]  "RFC 1166 - INTERNET NUMBERS". Internet Engineering Task Force (IETF). July 1990. p. 1. Retrieved 2014-06-11. Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit

nswcfd

struct BYTE {
  char bit:1;
};

bitfield是C語言的概念，所以C編譯器需要關(guān)心，BYTE.bit到底使用MSB還是使用LSB。
*選擇LSB，BYTE.bit =1 對應(yīng) or 0x01；
*選擇MSB，BYTE.bit = 1對應(yīng) or 0x80；
*選擇其它bit應(yīng)該也是可以的吧？

我的問題是，雖然x86上的gcc事實(shí)上選擇了LSB（沒說錯吧？），
但是如果假設(shè)它選擇了使用MSB，那有沒有違反C標(biāo)準(zhǔn)的規(guī)定？或者會造成其它語義上的錯誤？

karma303

回復(fù) 8# nswcfd

《程序員的自我修養(yǎng)》的附錄A.1講了byte order，不知道你看過沒。
類似這樣的句子，

Big-endian和little-endian的區(qū)別就是big-endian規(guī)定MSM在存儲時放在低地址，在傳輸時MSB放在流的開始；LSB存儲時放在高地址，在傳輸時放在流的末尾。little-endian則相反。

講的很好。

但我?guī)缀醪魂P(guān)心LSB和MSB的概念，它只會讓我困擾。
所以你的問題，都不在我的思維模式里，抱歉我一個答不上來。
   

karma303

回復(fù) 4# mordorwww

對，像MIPS上，用bitfield訪問就很自然。
這種東西，只要道理明白了，剩下的都事在人為。像我的內(nèi)核(x86)里，照樣的用bitfield訪問：
struct iphdr{
        u32 len: 4;                                                /* header length */
        int version: 4;
        u8 ignore;
        u16 tot_len;                                        /* total length, header included */
        u16 msgid;                                                /* IP datagram identification */
        union{
                struct{
                        u16 me_offset: 13;                                /* the offset of this IP fragment */
                        int flag_mf: 1;                                        /* more fragments */
                        int flag_df: 1;                                        /* don't fragment */
                        int flag_reserved: 1;
                };
                u16 flag_off;
        };
        u8 ttl;
        u8 protocol;
        u16 chksum;
        u32 myip;
        u32 yourip;
};
每當(dāng)接收到一個ip報文時，我先把flag_off成員字節(jié)翻轉(zhuǎn)，然后就可以用bitfield訪問了。