關連式資料庫已經落伍了！？

關連式資料庫已經落伍了！？

Relational database pioneer says technology is obsolete
http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9034619

Eric Lai
September 06, 2007 (Computerworld)

身 為加州大學柏克萊分校的研究者，在 1970 年代早期，Michael Stonebraker 共同創造了 Ingres 與 Postgres 技術，那是今日許多主要關連式資料庫的基礎：微軟的 SQL Server、Sybase Inc. 的 Adaptive Server Enterprise、Ingres Corp. 的知名產品還有 IBM 的 Informix 與其他。

但 Stonebraker 現在議論，關連式資料庫，又稱為 RDBMS，已經「老掉牙了（long in the tooth）」而且「應該被列為遺產技術（legacy technology）」。

在一個新 blog（The Database Column，參見相關報導一）星期二的一篇文章裡，Stonebraker 也爭論今日的關連式資料庫的效能嚴重落後在新一波資料庫之後，這些新資料庫將資料表（database tables）翻轉了 90 度。

直 欄導向式資料庫（Column-oriented databases，參見相關報導二）-- 例如由 Stonebraker 的新公司，位在麻州 Andover 的 Vertica Systems Inc.，所打造的 -- 將資料垂直儲存在表格的直欄（columns）中，而非連續的橫列（rows）裡。

藉由把相似的資料放在一起，直欄導向式資料庫將磁碟讀取的時間最小化，當執行大規模的計算時，諸如那些在資料倉儲（data warehouse）當中所進行的，可獲得加倍成效。

" 總有天"，直欄資料庫 "將奪取資料倉儲市場，完全迫使橫列儲存離開，" Stonebraker 寫道。"因為許多資料倉儲使用者都遇到相當大的痛苦（無法從可用的載入視窗載入、無法支援點對點 [ad-hoc] 的查詢，若不經「分支提升 [fork-lift]」的升級就無法獲得更好的效能），我預期過渡到直欄儲存將迅速發生。"

直欄導向式資料庫並不新。Sybase 已成功銷售它基於直欄的 IQ 資料庫多年，成為一種高效能的商業智慧（BI）解決方案。最近的 BigTable，這個資料庫是由 Google Inc. 所打造，用來處理一些應用，資料則以直欄方式儲存。

但它們仍是一種利基祭品（niche offering）。相較下，在主流資料庫市場（那估計每年有 150 億美金）當中的領導玩家，全都倚賴使用基於橫列式資料表的系統。

以橫列組織資料也有它的優勢。將資料寫入磁碟時會比直欄式要快。這是高交易（transaction，異動）資料庫應用的關鍵，在那裡資料持續不斷地讀取與寫入資料庫，然而，這對於資料倉儲市場顯然不怎麼重要，在那裡資料通常只寫入一次，並且在之後存取許多次。

Stonebraker，他是 Vertica 的共同創辦人以及 CTO，宣稱他的新公司擁有其他效能提升的功能，例如非常具侵略性的資料壓縮以及查詢執行者（query executor），那能在「已壓縮的資料中運行」。

所以，"Vertica 打敗地球上所有橫列式儲存 -- 通常可勝過 50 倍，" 他寫道。"唯一能與之相比擬的引擎是其他的直欄儲存，對於那些，Vertica 大約勝過 10 倍。"

Stonebraker 表示，其他類似 Vertica 的公司無法做這麼好。

"In every major application area I can think of, it is possible to build a SQL DBMS engine with vertical market-specific internals（在本質上專注於特定垂直市場的） that outperforms the 'one size fits all（一體適用的）' engines by a factor of 50 or so," 他寫道。

其他 Database Column 的貢獻者包括 Don Haderle，IBM 退休員工，他被認為是 DB2 資料庫之父，以及 Jerry Held，他曾協助創造 Tandem Computer 的 NonStop 資料庫。

※ 相關報導：

＊ One Size Fits All - A Concept Whose Time Has Come and Gone - The Database Column
http://www.databasecolumn.com/2007/09/one-size-fits-all.html

＊ Column-oriented DBMS - Wikipedia
http://en.wikipedia.org/wiki/Column-oriented_DBMS

＊ 英特爾研發大量多核處理器
＊ 科學家觀測到普適態
＊ 「模擬地球」預測未來
＊ 物理學家創造「幽靈般」的量子通訊

USB 3.0 在 2008 帶來光學連接

2007-09-20

USB 3.0 在 2008 帶來光學連接

USB 3.0 brings optical connection in 2008
http://www.news.com/8301-10784_3-9780794-7.html

Posted by Stephen Shankland
September 18, 2007

舊金山 -- Intel 與其他廠商計畫要在 2008 上半年釋出 USB 技術的新版本。革新這項技術的晶片製造者表示，除了傳統的銅線之外，還增加了光纖連線，其資料傳輸速率將快上 10 倍。

Intel 目前正與 USB 3.0 Promoters Group 的成員（Microsoft, Hewlett-Packard, Texas Instruments, NEC 與 NXP Semiconductors）一同研究，準備在 2009 年上半年推出 USB 3.0 的規格書，Pat Gelsinger ，Intel Digital Enterprise Group 的總經理，在 Intel IDF 的一場演講中表示。

在演講之後的訪談中，Gelsinger 表示，在規格書釋出與可使用這項技術之間通常會有一到二年的延遲，故 USB 3.0 產品很可能在 2009 或 2010 年上市。一個在演講中展示的原型正在運作中，而 USB 3.0「從第一天開始」就會光學與銅線連接，他提道。

當前的 USB 2.0 版最高傳輸速率是 480 mbps，故速度增加 10 倍之後，將會有 4.8 gbps 的速率。很多裝置都不需要這麼快的能力，不過某些東西可用得更多，例如：硬碟、讀卡機與光學裝置，例如：DVD, Blu-ray 與 HD DVD。今日最快的快閃記憶卡讀卡機是使用 IEEE 1394 "FireWire" 連接，那可達到 800 mbps 的速率。

此外，USB 3.0 將提供更大的能量效率，Gelsinger 說。它將會向下相容，所以 USB 2.0 裝置，將能直接用在 USB 3.0 的埠上。

※ 希望它們能解決 USB 供電問題，這樣才拼的過 IEEE 1394。

＊ IronKey 號稱最安全的隨身碟
＊ What's the Matter with HDMI?
＊ Multi-gigabit 無線網路即將問世
＊ 新乙太網路標準：40Gbps 與 100Gbps
＊ 物理學家創造「幽靈般」的量子通訊
＊ 奈米電腦儲存能以千倍速度檢索資料

資源 - 各類協定

.

◆ 各類通訊標準 (網路存取、行動通訊)


◆ Transaction



◆ OS



◆ Encoding

　‧unicode.org

.

清單 - VM

◆ VM Common News

　‧2013/07/23 ARM與甲骨文簽下Java合作(連結)
　‧2011/12/04 微軟Hyper-V伺服器虛擬化簡介
　‧2007/09/14 VMware展示下一代虛擬技術新功能
　‧2007/05/25 讓 Linux 軟體可以到處執行的VM


　* QEMU支援多種CPU之簡介



◆ VM 及 Simulator Skills

　‧2007/07/24 Linux KVM 虛擬化技術
　‧2007/02/27 KVM竄紅虛擬化業界
　‧2007/02/15 Red Hat為KVM虛擬技術背書
　‧2007/03/00 Kernel 2.6.21 將正式加入 VMI（Virtual Machine Interface）


　*VMware Player - 虛擬機器執行器
　*綜論虛擬化技術



.

VMware展示下一代虛擬技術新功能

VMware展示下一代虛擬技術新功能

CNET 新聞專區：Stephen Shankland　　14/09/2007
友善列印 Email文章給朋友 儲存文章

VMware已經開發一些新技術來解決一個困擾系統管理員已久的難題：伺服器當機時，如何確保運算服務的可用性？

靠虛擬技術起家的VMware自然將虛擬技術看作是解決這一所謂的高可用性問題的方案。本週四，VMware合夥創始人、首席科學家Mendel Rosenblum在VMworld上作主題演講時，展示二台同步執行的電子郵件伺服器。他關閉主伺服器，僅僅在數秒鐘內，次伺服器就完全接管主伺服器的任務。

Rosenblum表示，專用硬體和軟體能夠提供較高的可用性，但虛擬技術能夠使高可用性「大眾化」。他說，最酷的是它適合所有負載。

這一高可用性技術是VMware的Workstation產品中「replay」功能的延伸。「replay」使VMware的軟體能夠記錄在虛擬機器上執行軟體的活動。在週四的示範中，次伺服器記錄主伺服器執行的指令，只有主伺服器當機後才會執行系統。

Rosenblum 沒有承諾這一技術是否/或會在何時提供給用戶，但很顯然的是，VMware正在向這一方向努力。包括微軟、XenSource、Virtual Iron、Parallels在內的競爭對手仍然在開發基本的虛擬技術，VMware希望能夠在這一領域保持領先地位。

但是，新技術由示範發展到商用階段之間還有很長的路要走。Illuminata分析師Gordon Haff 表示，VMware是否有興趣進行投資，使這一技術發展成為可商用的產品還有待觀察。

Rosenblum表示，最終，虛擬技術將實現伺服器廠商數年前的夢想：動態調整、自我管理的資料中心。

在主題演講中，Rosenblum還示範一項與儲存系統相關的高可用性功能。透過一種名為VMotion的技術，正在執行的虛擬機器能夠從一台實體伺服器轉移到另一台伺服器上。

Rosenblum示範一項名為Storage VMotion的技術。在示範中，系統管理員將一個甲骨文資料庫的資料儲存系統由一台實體儲存系統上轉移到另一台實體儲存系統上。在轉移過程中，甲骨文資料庫仍然在執行。目前，資料儲存也能轉移，但需要首先關閉虛擬機器。

	分析：虛擬技術 該走硬體還是軟體？	12/09/2007
	虛擬軟體廠商聯合制訂新標準	11/09/2007
	虛擬市場火紅 Citrix以5億美元買下XenSource	16/08/2007
	VMWare上市熱 虛擬化前景看漲	15/08/2007

Linux 核心變革，採用新的 CFS 行程排班器

Linux : Linux 核心變革，採用新的 CFS 行程排班器
發表人 ols3 於 2007/8/8 12:21:08 (1705 人讀取)
Linux

小三報導:

七月中旬到八月初期間，Linux 核心開發社群裡頭，出現了一點爭論話題。

從 Linux 2.6.23 開始，Linux 核心將把使用多時的 0/1 行程排班器換掉，新採用的 scheduler 稱為完全公平排班器(CFS: Completely Fair Scheduler)，這個排班器是由目前在 RedHat 任職的開發人員 Ingo Molnar 在今年 4 月 11 日開始發展的，CFS 在 62 個小時內就被設計出來。在此之前，Linux 核心開發社群中，早有一群人長期擁護的另一個 SD 排班器，卻始終不被 Linus 接受，CFS 的開發時間最短，但卻能立即出線，這讓 SD 的擁護者十分不能接受，因此對於 CFS vs SD 孰優孰劣的爭論，成為最近核心開發社群中的一個熱門話題。

在 Linus 選擇 CFS 成為新的 Linux 行程排班器之後，長期以來專注於提升 Linux 桌面應用效能的業餘核心開發者 Con Kolivas (本職是墨爾本一家醫院的麻醉師，核心開發是他業餘的興趣)宣佈他將不再維護 SD 行程排班器的 ck- 修補程式碼，並且宣佈退出 Linux 核心的開發行列。ck- patch 最早可追溯到 2002 年 Linux 2.4 系列的核心。不過，多年來 Con Kolivas 的修補程式一直無法被核心主力開發群所接受，因此從未進入 Linux 核心主流程式碼中。Con Kolivas 並發表了一些對 Linux 核心開發群始終不重視桌面應用的言論，他在接受 APCMag 專訪時，詳細地解釋他為何要離開(Why I quit: kernel developer Con Kolivas, http://apcmag.com/6735/interview_con_kolivas)。對於這篇專訪，Linus 在郵件論壇中罕見地帶著生氣的口吻反駁，Linus 表示大部份核心開發人員都是 Linux 桌面的使用者，不但不可能忽視 Linux 核心在桌面應用的效能關注，相反地 Linus 認為 Linux 桌面應用一直是核心開發範圍中最重要的一部份(Torvalds rebukes desktop critics, http://www.techworld.com/opsys/news/index.cfm?newsid=9652)。

CFS vs SD 的爭論在核心郵遞論壇中漫延一陣子之後，Linus 最後出面說明他為什麼捨棄 SD 而選擇 CFS 的緣由(http://kerneltrap.org/node/14008)。

Linus 說道: "那些認為 SD 排班器是完美的人，根本忽略了現實問題，很遺憾地，包括 Con Kolivas 自己都是如此，這也是為什麼長期以來我從不接受 SD 程式碼進入 Linux 核心的主要原因之一；Con 始終無法面對使用者回報的問題，採取的態度是爭論對抗，而不是願意用心和使用者一起解決問題。"， Linus 強調朝向一個對所有層面都好的解決方案的重要性。" SD 一直沒有一個可以讓人信任的維護者，除了能專注自己的主題之外，也能關注其它層面，這便是 SD 為何會被判出局的原因。"

Linus 推崇 CFS 的開發者 Ingo Molnar 道: "相信我！ 做為一個長期的核心開發者，我最清楚什麼才是最重要的，任何能夠不怕麻煩地接受問題回報，並且持續改進的人，絕對比採取對抗問題心態者更為重要"。

Linus 也提到，我知道已有一群人正在測試 CFS 和 SD 在各種狀況下的效能比較，大部份的人應該都會同意 CFS 和 SD 會比原來使用的 0/1 排班器優秀，但 CFS 和 SD 之間卻不會有什麼重大的效能差異。

至此，情況已經很清楚了，由 Linus 的表態，我們可以了解為何 Linus 選擇 CFS 而不是 SD 的原因；Linus 希望任何一個核心開發方案，都能夠注意到其它層面，而不是只顧專注自己的主題，卻排除其它人對各核心領域可能產生影響的考量，最重要的是，開發者要能夠接受問題回報，並且持續改進它。

不管如何，這個爭論應該算是塵埃落定了，近日推出的 Linux 2.6.23-rc2 中已改用 CFS 程式碼(馬上就有人對它進行效能測試:http://www.phoronix.com/scan.php?page=article&item=797&num=1 )，這個事實說明了 Linus 的堅持，許多人應該願意相信 Linus 最終的決定應該是對的。

AMD Barcelona大幅提升虛擬化技術

AMD Barcelona大幅提升虛擬化技術

記者曠文溱／台北報導　　07/09/2007

AMD的首款四核心Opteron晶片（代號為Barcelona），投注了不少心力在虛擬化技術。

在英特爾於日（7）昨發表四核心Xeon MP晶片X7300系列（代號為Tigerton），宣告虛擬化技術由處理器層級步入I/O——讓I/O資源可以分別劃分給特定的虛擬機器（VM），以加快存取速度後；AMD也宣佈即將於本（9）月13日露相的四核心Opteron晶片Barcelona，不落人後地支援多項虛擬化技術。

「虛擬化技術是Barcelona的四大重點技術之一，」AMD伺服器暨工作站事業部全球業務發展經理John Fruehe在上週表示。另外的三大方向則是節電、效能、保障客戶既有投資，即AMD一向訴諸的新款處理器可與過去平台相容。

Barcelona的其中一項虛擬化技術，類似於英特爾即將在今年底發表的45奈米製程的Penryn處理器中的「FlexMigration」。AMD的版本名為「AMD-V Extended Migration」的技術，係指讓虛擬機器（VM）在不同世代的Opteron系統上線上轉移（Live Migration）。過去倘若是不同世代的Opteron系統，必須暫時關閉應用程式的運作後，才能將虛擬機器從一台實體伺服器轉換到另外一台機器。

另外，Barcelona還包括了名為「Rapid Virtualization Indexing」的技術，宣稱前者係將存放在快取裡面的資料打上標籤，因此在虛擬機器每次載入（load）資料的時候，被打上標籤的資料可以讓處理器得知是從那個虛擬機器而來，這些索引（index）將有助於減少其他的虛擬機器載入資料時的延遲時間。

「Opteron的晶片設計整合了記憶體控制器，才能夠達到上述技術。換言之英特爾無法做到這點，」AMD說。

而另一點Barcelona對虛擬化技術的貢獻，則是彌補過去諸如VMWare等虛擬化軟體的不足。AMD表示，一名為「Nested Paging」的技術，可以讓在虛擬機器裡面的應用程式，繞過Hypervisor和硬體層溝通。

根據AMD提供的資料，2GHz的Barcelona在執行VMWare時，表現高出3GHz雙核Opteron的79%。

呈現在空氣中的 3D 影像

呈現在空氣中的 3D 影像

-- 使用雷射電漿將「真正的 3D 影像」視覺化

Three Dimensional Images in the Air
- Visualization of "real 3D images" using laser plasma -
http://www.aist.go.jp/aist_e/latest_research/2006/20060210/20060210.html

Key Points

1. 我們使用雷射所產生的電漿技術在空氣中製造閃光點（flashpoint）
2. 我們藉由最佳化雷射光束，大大地改進電漿的亮度、對比與生產距離。
3. 利用雷射電漿，我們首次成功的在空間中顯示「真正的 3D 影像」，除了空氣之外什麼都沒有。

概要

在 National Institute of Advanced Industrial Science and Technology（AIST, 總裁: Hiroyuki Yoshikawa）、慶應義塾大學（Keio University ，校長：Yuichiro Anzai）與 Burton Inc.（CEO: Hidei Kimura）的合作下，已成功完成實驗性裝置的製造，該裝置能在空間中顯示由點陣列構成的 "真正 3D 影像。"

到目前為止，大部分已報導的 3D 顯示都是在 2D 平面上利用人類雙眼視覺像差（binocular disparity）描繪假的 3D 影像。然而，這會產生許多問題，例如，有限的視野，以及因為虛擬影像錯判（misidentification）在生理上所引起的不適。

我們所開發的裝置利用已聚焦雷射光束之焦點附近的電漿放射現象。藉由控制聚焦雷射在 x-, y-, z- 軸上的位置，我們成功的顯示由空氣中的點陣列所構成的真正 3D 影像。

研究歷史

慶應義塾大學與 Burton Inc. 注意到一個現象，當雷射光束能強力聚焦時，可在焦點附近誘發空氣電漿放射。因此，它們成功地實驗性製造出一種，由點陣列（結合雷射光源與電流計鏡 [galvanometric mirrors] 所構成）所構成，能在空氣當中顯示 2D 影像的裝置。為了更進一步在空氣當中顯示3D 影像，能夠沿著雷射光軸將（雷射光）焦點在深處方向掃描（scanning）是必要的。然而，為達此目標，雷射的品質與改變焦點位置的技術都必須要改進，也因此當時並未製造出 3D 顯示裝置。

研究細節

在 AIST、慶應義塾大學與 Burton Inc. 的合作之下，在前述 2D 裝置中增添線性馬達系統；高品質、高亮度之紅外線脈衝雷射，並成功地利用這種裝置所構成的點陣列在空間當中顯示 3D 影像。

線性馬達系統讓雷射焦點的位址，能經由馬達軌道上透鏡組的高速掃描而改變。在該系統的合作之下，讓影像在 z 軸方向掃描成為可能。為了要掃 x與 y 軸方向，利用了傳統的電流計鏡。

我們在此使用的雷射光源是高品質、高亮度的紅外線脈衝雷射（脈衝重複頻率約 100 Hz），由此電漿產生可以更精確地被控制，讓更明亮、對比更高的影像能夠繪出。此外，裝置與描繪點之間的距離可大大地延展（數公尺）。

雷射脈衝的放射時間是在奈秒（10^-19 秒）等級。我們的裝置在每一點上使用一個脈衝，對此，人眼可利用視覺暫留（after-image）效應來識別出電漿放射，且能夠達到每秒 100 點的顯示。

藉由將這些脈衝同步化，並透過軟體來控制我們的裝置，我們可以在空氣中繪出任何 3D 物體。

下面是利用我們的裝置所顯示出來的各種圖形。

※ 現在該團隊有新的改進了，可以在空氣中繪出「イ」這個片假名。

＊ 産総研：プレス・リリース　「空間立体描画（３Ｄディスプレー）」技術の高性能化実験に成功
http://www.aist.go.jp/aist_j/press_release/pr2007/pr20070710/pr20070710.html

＊ AIST improves 3D projector ::: Pink Tentacle
http://www.pinktentacle.com/2007/07/aist-improves-3d-projector/

＊ AIST develops 3D image projector ::: Pink Tentacle
http://www.pinktentacle.com/2006/02/aist-develops-3d-image-projector/

資源 - BIOS 及 IO

■ EFI (Extensible Firmware Interface)

• 英特爾的EFI首頁
• 聯合可擴展介面論壇
• 英特爾公司對EFI的標準實現:Intel EFI創新架構
• 英特爾公司發起的EFI核心實現的一個半開源的計劃TianoCore

The Segment Descriptor Cache

By Robert R. Collins

---

It is easy to underestimate the importance of something when you don’t know what it is or how it works. As early as the 80286, all Intel x86 processors have included an entity called the "segment-descriptor cache" which works behind the scenes, hidden from you. It is updated each time a segment register is loaded. It is used for all memory accesses by all Intel x86 processors since the 80286. If you’re an end user, you’ve probably used programs that depend upon the functions of the segment-descriptor cache. If you’re an engineer, there is a high probability that you’ve relied upon the functions of the segment-descriptor cache – and you might not have realized it. If you’re an engineer who writes any low-level code, programs hardware, or programs in protected mode, then you should be aware of the segment-descriptor cache and how it works.
From the 80286 to 80486, the meaning of "segment-descriptor cache" was unambiguous, referring to an internal microprocessor structure that stores the internal representation of the segment registers. This representation includes the segment base address, limit, and access rights. With the Pentium, Intel introduced a 94-entry, two-way set associative cache of segment-descriptor cache entries. Therefore, the phrase "segment-descriptor cache" is now ambiguous, with two possible meanings. Making matters worse, the new segment-descriptor cache was removed from the Pentium Pro design, but reintroduced in the Pentium II. (The lack of the new segment-descriptor cache in the Pentium Pro largely accounted for its poor 16-bit performance.) In this column, I’ll discuss the original segment-descriptor cache that has existed since the 80286 (and remains in all modern Intel x86 processors) and the role of the segment-descriptor cache in microprocessor memory management.

Loading Descriptor Cache Registers

Whether in real, protected, virtual-8086, or system-management mode, the microprocessor stores the base address of each segment in a hidden descriptor-cache registers. Each time a segment register is loaded, the segment-base address, segment-size limit, and segment-access attributes (access rights) are loaded (cached) into these hidden registers. To enhance performance, subsequent memory references are made via the descriptor-cache registers. Without this optimization, each memory access would require the microprocessor to perform many time-consuming tasks. In real mode, the microprocessor would need to calculate the physical address from the segment register value. The access rights would always indicate a read/write data segment (even for the code segment). The limit would always be 64 KB of memory. In protected mode, the segment base must be looked up in the appropriate descriptor table. The segment base is composed of a combination of fields in the descriptor table. The segment access rights and segment limit are also contained in the descriptor table. The microprocessor would need to access those structures for each memory access. These descriptor-table values reside in memory, where accesses tend to be slow when compared to accesses within the microprocessor. Therefore, without an internal segment-descriptor cache to cache these values, each memory access would implicitly require many other accesses to memory.
Now consider the differences between real mode and protected mode. If the segment descriptor cache didn’t exist, determining segment base, limit, and access rights would require more than one CPU cycle to complete. Therefore, the segment-descriptor cache exists to eliminate these potential deficiencies. It exists to allow all of these differences to be resolved at the time each segment is loaded. The performance penalty is incurred only once. Thereafter, all memory management is performed according to the values in the segment descriptor caches for each respective segment register.
At power-up, the descriptor-cache registers are loaded with fixed, default values – the CPU is in real mode, and all segments are marked as read/write data segments, including the code segment (CS). According to Intel, each time any segment register is loaded in real mode, the base address is calculated as 16 times the segment value, while the access rights and size limit attributes are given fixed, "real-mode compatible" values. This is not true. In fact, only the CS descriptor caches for the 286, 386, and 486 get loaded with fixed values each time the segment register is loaded. Loading CS, or any other segment register in real mode, on later Intel processors doesn’t change the access rights or the segment size limit attributes stored in the descriptor cache registers. For these segments, the access rights and segment size limit attributes from any previous setting are honored. Thus, it is possible to have a four-GB read-only data segment in real mode on the 80386 – but Intel won’t acknowledge this mode of operation, though it is implicitly supported. Furthermore, Intel can’t remove it without rendering many software programs ineffective.
Protected mode differs from real mode in this respect: As each time a segment register is loaded, the descriptor cache register gets fully loaded; no values are honored. The descriptor cache is loaded directly from the descriptor table. The CPU checks the validity of the segment by testing the access rights in the descriptor table. Complete checks are made, and illegal values will generate exceptions. Any attempt to load CS with a read/write data segment will generate a protection error. Likewise, any attempt to load a data segment register as an executable segment will also generate an exception. The CPU strictly enforces these protection rules. If the descriptor-table entry passes all the tests, then the descriptor-cache register gets loaded.

Format of Descriptor Cache Registers

The layout of the segment-descriptor cache registers change with almost every processor generation, though their functions do not. These differences are known as "implementation specific" because their exact layout and contents depend on the design and implementation of the microprocessor. For the most part, the fields of the segment-descriptor cache mirror the fields in the protected mode descriptor table. For 32-bit descriptor-table entries, the segment-base address, segment-access rights, and segment-limit fields are not contiguous. These related fields are combined before being put in the segment-descriptor cache. Figure 1 shows the relationship between fields in the descriptor table and segment-descriptor cache.

Figure 1: Combining fields from the descriptor table into the segment-descriptor cache.

Offset	63..56	55	54	53	52	51..48	47	46..45	44	43..40	39..16	15..00
Description	Base[31:24]	G	D/B	0	AVL	Limit[19:16]	P	DPL	S	Type	Base[23:00]	Limit[15:00]

Segment Base

Segment Access Rights

Segment Limit

Segment-Descriptor Cache

It is useful to know the layout of the fields inside the segment-descriptor cache. The segment base and segment limit are always combined from the descriptor table to form a complete base address and segment limit inside the segment-descriptor cache. The format of the access rights within the segment-descriptor cache changes from implementation to implementation. Likewise, the order of the fields within the cache can change. Regardless, knowing the format of the segment-descriptor cache can make you more productive, reducing both development and debugging time. Tables 1 through 4 show the descriptor cache entry format for all Intel x86 processors from the 80286 through Pentium Pro.

Table 1 - 80286 Descriptor Cache Entry

Bit Position	47..32	31	30..29	28	27..24	23..00
Description	16-bit Limit	P	DPL	S	Type	24-bit Base

Table 2 - 80386 and 80486 Descriptor Cache Entry

Bit Position	95..64	63..32	31..24	23	22..21	20	19..16	15	14	13..0
Description	32-bit Limit	32-bit Base	0	P	DPL	S	Type	0	D / B	0

Table 3 - Pentium Descriptor Cache Entry

Bit Position	95..79	78	77..72	71	70..69	68	67..64	63..32	31..00
Description	0	D/B	0	P	DPL	S	Type	32-bit Base	32-bit Limit

Table 4 - Pentium Pro Descriptor Cache Entry

Bit Position	95..64	63..32	31	30	29..24	23	22..21	20	19..16	15..00
Description	32-bit Base	32-bit Limit	0	D/B	0	P	DPL	S	Type	Segment Selector

Descriptor-Cache Registers In Real Life

There are different ways to take advantage of the segment-descriptor cache registers. System-management mode (SMM) gives you direct control over each field in the segment-descriptor cache. (See my DDJ January/March/May 1997 columns for an in-depth look at System Management Mode.) In-circuit emulators (ICEs) also allow direct control over each field in the segment descriptor cache. (Refer to my DDJ July/September/November 1997 columns for information on in-circuit emulation.)
For instance, when writing any low-level assembly-language programs (such as OS kernels, device drivers, BIOS, or protected-mode programming), I make common, simple mistakes. I sometimes make a mistake when creating my segment descriptor table, usually the Global Descriptor Table (GDT). I may have created the GDT using an incorrect base address, segment limit, or access rights. Ultimately, my program fails, and I must use the ICE as a debugging tool. I’ll then insert the undocumented ICEBP instruction into my code to instruct the ICE to breakpoint at the suspected point of failure (see http://www.x86.org/secrets/opcodes/ICEBP.html). Within moments, I discover that I used incorrect values in building the descriptor table. Using the ICE, I can load each field of the segment-descriptor cache. If I used an incorrect segment base address, I can correct it and continue. Likewise, I can make the same corrections for the segment limit and segment access rights. I know that these values are "sticky," meaning that they don’t get changed until a new segment register value is loaded. Therefore, I can make these changes, and continue debugging my program. Using this technique, I can usually discover six or more bugs in my program before recompiling. Because I don’t need to recompile my program after discovering each and every mistake, I save valuable development and debugging time.
Programming in SMM implicitly takes advantage of the segment-descriptor cache registers. The segment-descriptor cache registers are saved and restored along with the remaining microprocessor state in the SMM state save map. These values are saved and restored upon entry and exit to system-management mode. In my March 1997 DDJ column, I disclosed all of the undocumented fields (known as "reserved" fields in Intel parlance) in the Pentium SMM state save map. As I discussed, the segment-descriptor cache registers are stored in these reserved fields.
It is possible to manipulate these segment-descriptor cache values from within the SMM handler. The segment base may be changed to a value that is inconsistent with its associated segment register value. The segment access rights may be manipulated to give current-privilege-level-3 (CPL-3) tasks CPL-0 access (an obvious breach of security). The segment limit may be changed to create a segment with a four-GB limit while in real mode. Using SMM, it is possible to change the segment attributes to values that are programmatically impossible; for example, a real-mode segment at two MB, a segment limit size of 4-gigabytes minus 16, or a read/write code segment in protected mode (not to mention CPL-0 access within a CPL-3 task).

Descriptor Cache Anomalies and creating "Unreal Mode"

Using either of these methods to manipulate segment-descriptor caches can be challenging. However, there’s another programatic way of putting segment-descriptor caches to work – creating a CPU operating mode known as "unreal" mode.
Unreal mode is created when a real-mode segment has a four-GB segment limit. Unreal mode can be created without any hardware debuggers or SMM programming with a simple assembly-language program. Imagine a program that begins in real mode then transitions into protected mode. Once in protected mode, the program loads all of the segment registers with descriptors containing four-GB segment limits. After setting the segment limits, return immediately to real mode without restoring the segment registers to segments containing 64-KB segments (real-mode-compatible segments). Once in real mode, the segment limits will always retain their four-GB limits. Thereafter, DOS programs can take advantage of the entire 32-bit address space without resorting to protected-mode programming.
Unreal mode has been used commonly since it was discovered on the 80386. Unreal mode is so commonly used, in fact, that Intel has been forced to support this mode as part of legacy 80x86 behavior, though it’s never been documented. Memory managers and games often take advantage of unreal mode. Source code that demonstrates how you can create unreal mode is available electronically from DDJ (see "Resource Center,") or at ftp://ftp.x86.org/dloads/UNREAL.ZIP.
The real-mode code segment (CS) descriptor cache behavior has changed between generations of Intel processors. The role of the code segment-descriptor cache in real mode differs between the 80286, 80386, and 80486 and all later Intel microprocessors: The earlier microprocessors honor the real-mode segment access rights in real mode until a far control transfer occurs; later processors ignore any access rights in the CS descriptor cache irrespective of far control transfers. On the earlier processors, any far control transfer set the CS descriptor cache access rights to its real-mode compatible value as a readI-write data segment (value=0x93). Later processors leave the original value intact, but ignore its contents. Therefore, transitions from real to protected mode on the later processors immediately causes the behavior to revert to its stagnant CS descriptor-cache access rights value. On earlier processors, the CS limit is also restored to its real-mode compatible value (64 KB). Later processors leave the CS segment limit alone, making its behavior consistent with the other data segment registers.
From the 80286 to the Pentium, all Intel processors derive their current privilege level (CPL) from the SS access rights. The CPL is loaded from the SS descriptor table entry when the SS register is loaded. The undocumented LOADALL instruction (or system-management mode RSM instruction) can be used to manipulate the SS descriptor-cache access rights, thereby directly manipulating the CPL of the microprocessors. (See http://www.x86.org/articles/loadall/ for a description of LOADALL.) The Pentium Pro behaves differently: Once the CPL is loaded into the Pentium Pro, it is not internally derived from the SS access rights. The Pentium Pro retains a separate CPL register. Through the system-management mode RSM instruction, you can directly manipulate the CPL of the Pentium Pro, though not by manipulating the SS access rights value. (I will discuss the Pentium Pro SMM state save map and all of the secrets contained therein in a future column.)

Conclusion

I use the segment-descriptor cache registers every day – when I’m debugging on my ICE to help correct common protected-mode programming errors, programming in system-management mode to create events, or creating real-mode segments that can address the entire four-GB address space. The use of the segment-descriptor cache is highly implementation specific, meaning the behavior and layout of the segment-descriptor cache is dependant upon the implementation of the specific microprocessor. Intel doesn’t guarantee that the behavior of the descriptor cache will remain the same from microprocessor to microprocessor. Therefore, it would be foolhardy to write any production-quality source code which depends upon this behavior (except unreal mode).