網頁

2005年10月28日 星期五

64 位元好猛啊!

64 位元真的不是蓋的,好大啊。一般對於 32 bits 的系統來講要把 int 玩到 overflow 似乎不是什麼很困難的事,可是對於 64 bits 的系統來說就很難講。以下就來介紹我昨天被嗆的原因以及試圖要幹的蠢事 XD。

昨天被機八鴉嗆說「你計概去重念」,原因是因為我看到 BSD 板上有人在問 FreeBSD 用的 FileSystem UFS 在每個 DIR 當中可以塞多少檔案的這篇文章。照著回覆者的指示,我去翻了FreeBSD 底下的 /usr/include/ufs/ufs/dir.h 檔案,找到當中 MAXDIRSIZE 如下:

/*
* Theoretically, directories can be more than 2Gb in length, however, in
* practice this seems unlikely. So, we define the type doff_t as a 32-bit
* quantity to keep down the cost of doing lookup on a 32-bit machine.
*/
#define doff_t int32_t
#define MAXDIRSIZE (0x7fffffff)

然後看到有 0x 的東西習慣性的到 RW 上下了 eval 來看結果:

/doc/driver/perl/> eval printf("%d",0x7fffffff)
printf():
2147483647
效率評估: 81
系統時間: 0.000000 s
使用時間: 0.000000 s
運算時間: 0.000061 s
編譯成功。

然後再試了 0xffffffff 之後發現結果一樣,那表示一定有問題:

eval printf("%d",0xffffffff)
printf():
2147483647
效率評估: 81
系統時間: 0.000000 s
使用時間: 0.000000 s
運算時間: 0.000066 s
編譯成功。

於是就把這東西隨手丟給機八鴉,然後說「檔案系統之前轉成 64bits 之後現在保留了 32bits 嗎?」,然後說剛剛 printf 的東西 overflow ,結果機八鴉回 說「沒有ㄚ,最後一個 bit 不用...2^31」,然後我不知道在想什麼回了一句「那是 HEX 不是 Binary 耶..他是 7 又不是 E」,然後就被嗆「計概回去重念」了。嗚~人家已經四年沒碰了,這樣就被嗆,又不是不知道我從來不唸書的 XD。

不過也因此,忽然想之前不知道在那裡看到的一篇 AMD 64 的指標跟 int/long type 的長度,然後 google 了一下發現原來是 gslin長輩 所寫的這篇,然後我也順手 google 了一些資源。幾個比較有趣的:

不過我要說的重點不是這個,因為好奇所以想知道他的能耐在那裡,所以寫了個 code 來跑:


#include

int main()
{
long a=1;

while( a++ > 0 );
printf("%d\n",a);
printf("%d\n",a-1);
}
這段 code 在一般的 32 bits machine 底下跑都很正常,按下去等一下大概就會出來。不過換到 AMD64 平台下跑可就不一樣了!已經跑了很久卻都還沒停,用 top 看的話可以發現

6918 cookys 1 139 0 2364K 528K RUN 16.9H 92.48% a.out
已經跑了 17 個小時卻還沒結果。於是我很好奇的稍微估計了一下。 從 1 加到 2^31 大約要 5 sec 才能夠做完,也就是說 2^63 大概是 5 sec 乘以 2^32 ,也就是 4294967296 個五秒鐘。看到這裡我已經呆掉了,天啊,我竟然天真的想等他跑完!還好我沒讓第一版程式真的把數字都寫到檔案,那不然保證硬碟一定會被塞暴!還不知道是多 少嘛?借一下 windows 的工程模式計算機算一下:

4294967296 *5
=21474836480(秒)
=357913941.33333333333333333333333(分)
=5965232.3555555555555555555555556(時)
=248551.34814814814814814814814815(天)
=680.9625976661593099949264332826(年)。

是的沒看錯,就是 680 年 -_-。會不會太歡樂了點啊,我只是要從 1 加到他 overflow 啊~~~(抱頭)!!!所以說呢,來去把程式停掉吧 -_-。