午夜dy888国产精品影院,少妇精品导航,天天狠天天透天干天天怕∴

論壇徽章:: 0

電梯直達

1樓 [收藏(0)] [報告]

發(fā)表于 2009-09-23 22:31 |只看該作者 |倒序瀏覽

本來嘛：我就不打算再對你發(fā)表任何的看法和回復(fù)

即使，你發(fā)貼罵我“垃圾”，本來也就算了，不打算作進一步行動！

但是，過了一天，你不知反醒，反而變本加勵！

表現(xiàn)得十分的無恥，和極度的愚蠢、白癡

我早已說過，你的爛貼，不值一批

原帖由 rawa9999 于 2009-9-23 08:57 發(fā)表
恩，關(guān)于表限我說錯了。實際上我所說的LDT索引存放在LDTR寄存器中，不是GDTR的低16位，GDTR存放是表長度，這部分程序不可見，所以存放在哪用戶也看不到這個過程：
LDTR寄存器 LDTR高速緩存
15 0 47 16 15 0
選擇符(16位) LDT表基址(32位)表限(16位表長度)
LDTR寄存器中的16位
Bit15~Bit3：選擇子
Bit12：0表示GDT 1表示 LDT
Bit0~Bit1:處理器當前運行的級別－－CPL,四個等級0、1、2、3
LDTR寄存器本質(zhì)上是一個16位段寄存器，386段寄存器的最大可用選擇是2^14而不是2^16
所以LDTR寄存器最大可選虛擬內(nèi)存是2^14*4G=64T,這個跟GDT和LDT根本沒關(guān)系。至于段
寄存器的剩余兩位則表示CPL（CPU運行權(quán)限或級別）。終于把這個問題搞清楚了。歡迎不同觀點。
－－－－－－－－－－－－－－－－－－－－－
你批駁一下我的觀點！ ...

原帖由 rawa9999 于 2009-9-23 08:55 發(fā)表
2007年2月的帖子
http://bbs.gd-emb.org/archive/?/t-8890.html
我貼這段源碼的原因是為了輔助說明一下，64T跟GDT和LDT根本沒關(guān)系。
你的博客有這段源碼，要想證明你就發(fā)帖講解一下。SB

好，我就來批了一下你，但是，我不會講知識給你聽，我是來批你的人品

一、說一下你的白癡！

原帖由 rawa9999 于 2009-9-22 09:43 發(fā)表
386CPU是一個16位和32位混合的處理器，這個不是我說的。
虛擬地址空間由GDT 映射的全局地址空間和由LDT映射的局部地址空間組成。
選擇符的索引部分由13 個比特位表示，加上區(qū)分GDT 和LDT 的1 個比特位；
因此Intel 80X86 CPU 共可以索引16384 個選擇符。
———————————————————————————
這個也不是我說的。GDT只有一個表，所以無法得出16384，必須分析GDTR處理地址的過程，mik列不出這些匯編指令所以他也不是高手，給出一段處理一個虛擬地址的源碼就清楚了。
幾乎所有的386CPU都有64T虛擬內(nèi)存這個承諾。
mik你認為不對，為什么不反駁我呢？我知道你很忙在寫代碼，那就列出些源碼吧。分析GDTR處理地址的過程。64T，16、32位混合CPU這不是我說的，你站錯位置了。 ...

1、你爺我，4 年前匯編編譯器都寫過，寫不出匯編指令？　你說：你是不是很白癡！
　　x86/x64 的指令集我了如指掌！寫不出匯編指令？　你說：你是不是很白癡！

2、看一看，你所列出來的匯編知識：

原帖由 rawa9999 于 2009-9-21 13:18 發(fā)表
簡單點，mik說64T根本沒有這回事，這是徹底錯誤的。
立即尋址（immediate addressing）：操作數(shù)包含在指令中
直接尋址（direct addressing）：操作數(shù)的地址包含在指令中
間接尋址（indirect addressing）：指令中包含一個存有實際操作數(shù)地址的指示器（如寄存器）。
相對尋址（relative addressing）：地址由計算機再處理產(chǎn)生
虛擬內(nèi)存屬于間接尋址（indirect addressing）386中叫做寄存器間接尋址（Register Indirect Addressing），因為64T空間的任何一個地址都可以存方在48bit的寄存器中，但不能一個指令存取，因為通用寄存器都是32位的，需要讀高低位，但是這個48bit寄存器的存在表示一個指令就能完成一次64T空間范圍的地址指向。 ...

你所列出來的匯編指令，指的是這些�！∧阏f：你是不是很白癡！

3、 >> 16、32位混合CPU這不是我說的，你站錯位置了。

原帖由 rawa9999 于 2009-9-21 08:55 發(fā)表
LDTR是多少位寄存器？16位。386就是一個32位16位的混合處理器，不然怎樣運行當時的16位程序，動不動就是手冊，根本不動腦子。你為什么結(jié)帖？懶得跟你廢話。88

原帖由 rawa9999 于 2009-9-21 10:39 發(fā)表
386 是 32 位寄存器和 16 位寄存器混合的處理器。
指令兼容16位指令，又有16位寄存器（可能你不知道LDTR不是真正的寄存器，是緩存的一段空間，這個你的手冊上沒有）你回答我這是什么樣的處理器呢？

你 TMD 的，你在第 1 貼就說了，還說了 2 次，還不是你說的，自打嘴巴！　你說：你是不是白癡！

至于，貼子里的錯誤，我就是不指出，你省著吧！

二、說一下你的愚蠢

1、你所有貼子都是錯誤的！簡直是錯誤連篇，臭 P 還大放特放，愚蠢透頂！

2、

原帖由 rawa9999 于 2009-9-22 09:43 發(fā)表
386CPU是一個16位和32位混合的處理器，這個不是我說的。
虛擬地址空間由GDT 映射的全局地址空間和由LDT映射的局部地址空間組成。
選擇符的索引部分由13 個比特位表示，加上區(qū)分GDT 和LDT 的1 個比特位；
因此Intel 80X86 CPU 共可以索引16384 個選擇符。
———————————————————————————
這個也不是我說的。GDT只有一個表，所以無法得出16384，必須分析GDTR處理地址的過程，mik列不出這些匯編指令所以他也不是高手，給出一段處理一個虛擬地址的源碼就清楚了。
幾乎所有的386CPU都有64T虛擬內(nèi)存這個承諾。
mik你認為不對，為什么不反駁我呢？我知道你很忙在寫代碼，那就列出些源碼吧。分析GDTR處理地址的過程。64T，16、32位混合CPU這不是我說的，你站錯位置了。 ...

看一看，你給出了什么源碼：

原帖由 rawa9999 于 2009-9-23 03:45 發(fā)表
給出一個定位內(nèi)存和虛擬內(nèi)存的源碼
call 1a:804304c （call cs:eip即cs = 1a, eip = 804304c）
target_cs = 1a;
target_eip = 0x0804304c;
CPL = CS.RPL;          /* 當前執(zhí)行的代碼段的權(quán)限級別就是CPL */
RPL = target_cs.RPL;    /* 目標段 selector 的低3位是RPL */
target_si = target_cs.SI; /* 目標段 selector 的索引是Bit15~Bit3 */
target_ti = target_cs.TI; /* 目標段selector的描述符表索引是Bit2 */
CODESEG_DESCRIPTOR target_descriptor;
if (target_ti == 0) { /* target_cs.TI為0 就是參考到 GDT（全局描述符表） */
/* 以GDTR寄存器的base 為基地址加上selector的索引乘以8即得出目標
   段描述符，目標描述符的DPL就是目標段所需的訪問權(quán)限 */
target_descriptor = GDTR.base + target_si * 8
} else {             /* 否則就是參考 LDT （局部描述符表）*/
/* 以 LDTR寄存器的base 為基地址得出目標段描述符 */
target_descriptor = LDTR.base + target_si * 8;
}
DPL = target_descriptor.DPL;    /* 獲取DPL */
if (target_descriptor.type & 0x06) { /* conforming */
if (CPL >= DPL) { /* 允許執(zhí)行高權(quán)限代碼 */
   /* go ahead */
} else {
   /* 引發(fā) #GP 異常 */
goto DO_GP_EXCEPTION;
}
} else {                /* nonconforming */
if (CPL == DPL && RPL <= CPL) {
      /* go ahead */
} else {
      /* 引發(fā) #GP 異常 */
   goto DO_GP_EXCEPTION;
}

}
/****** go ahead … …******/
CS = target_cs;          /* 加載目標段CS 進入 CS 寄存器 */
EIP = target_eip;       /* 加載目標指令EIP 進入 EIP 寄存器 */
               /* 當前執(zhí)行權(quán)限 CPL 不改變 */
goto target_descriptor.base + target_eip; /* 跳轉(zhuǎn)到目標地址執(zhí)行 */
DO_GP_EXCEPTION:    /* 執(zhí)行 #GP異常點 */
         … …    ...

不知從哪里抄了我 2 年前寫的東東，還居然在我面前貼出來，以此來反駁我。

你說，你是不是很愚蠢透頂了！

詳見我 blog 里的一篇文章：http://blog.chinaunix.net/u/11773/showart.php?id=368316

3、這個代碼只不過是用 C 語言來描述 x86 體系的“轉(zhuǎn)移控制權(quán)時cpu 的行為”　的偽代碼

　　算不上源碼！你居然當成了源碼。愚蠢透頂了。

　　而且，有些地方可存在筆誤！

三、接著說一說，你的無恥

1、拿了別人的東西，居然反過來指責作者！比小偷還惡劣！小偷偷了東西還不會指責主人！

　無恥！

看如下：

原帖由 rawa9999 于 2009-9-23 08:32 發(fā)表
呵呵，我承認這個確實是我找來的，你說是你寫的，這個無法佐證，也不是你的博客，但是你為什么不貼出來讓大家明白呢？
你說你寫的你給大家講解一下吧

真是無恥透頂了！

TMD 的，別人轉(zhuǎn)載，還需要貼出轉(zhuǎn)載出處

2、還說不是我寫的，無恥�。�！

原帖由 rawa9999 于 2009-9-23 08:55 發(fā)表
2007年2月的帖子
http://bbs.gd-emb.org/archive/?/t-8890.html
我貼這段源碼的原因是為了輔助說明一下，64T跟GDT和LDT根本沒關(guān)系。
你的博客有這段源碼，要想證明你就發(fā)帖講解一下。SB

原帖由 rawa9999 于 2009-9-23 09:24 發(fā)表
從你的文章根本讀不出64T的根本原因，以上是我的觀點，根本跟那個源碼是兩碼事，所以用－－－－－－－－－－－－－－－線分割。SB

原帖由 rawa9999 于 2009-9-23 09:50 發(fā)表
我仔細看了兩段源碼錯誤也一樣，誰抄誰的？我的這段源碼地址也忘記了，所以無法從時間上判斷，大家可以分析一下在網(wǎng)上哪個版本應(yīng)該是原版。即便是mik的是原版，他也沒能從這個源碼當中得出64T虛擬內(nèi)存的結(jié)論。

你 TMD 的，你真無恥！

還有：你 TMD 的，我從來都說過 64T虛存這回事

3、現(xiàn)在，我來看一看，誰抄了我的東西！

google 的了一下，找到 3 篇文章，內(nèi)容完全一樣的。

（１）http://hi.baidu.com/zhushouqqq/blog/item/7312ed6c156cb7f2421694fa.html

很好，人家是標明了轉(zhuǎn)載字樣！！　時間的：2009-06-15 00:26，

但是，沒注明出處，這也是不道德的！

（2）http://hi.baidu.com/sodarfish/blog/item/b2da86a8b21296b4ca130cea.html/cmtid/cb97662ae77eda92023bf674

這篇文章，就很尊重作者了，標明了出處！

（３）http://blog.csdn.net/w5543081/archive/2008/11/11/3278008.aspx

這篇文章，注明了轉(zhuǎn)自 blog ，但也沒注明出處！發(fā)表于 @ 2008年11月11日　17:18:00

在 google 上找到這 3 篇文章！

就你　TMD 的 rawa9999 不注明轉(zhuǎn)載，沒得到作者同意，完全是侵權(quán)

你ＴＭＤ的至少要向我道歉！�。�！
你ＴＭＤ的還罵我垃圾！　無恥�。�！

　　你這個愚蠢、白癡、無恥之人，我將你驅(qū)出這個版塊�。�！