在 Rust 中使用型別級程式設計可以使硬體抽象更加安全。
Rust 是一種日益流行的程式語言，被視為硬體介面的最佳選擇。通常會將其與 C 的抽象級別相比較。本文介紹了 Rust 如何通過多種方式處理按位元運算，並提供了既安全又易於使用的解決方案。
| 語言 | 誕生於 | 官方描述 | 總覽 |
|---|---|---|---|
| C | 1972 年 | C 是一種通用程式語言，具有表示式簡約、現代的控制流和資料結構，以及豐富的運算子集等特點。（來源：CS 基礎知識） | C 是（一種）命令式語言，旨在以相對簡單的方式進行編譯，從而提供對記憶體的低階存取。（來源：W3schools.in） |
| Rust | 2010 年 | 一種賦予所有人構建可靠、高效的軟體的能力的語言（來源：Rust 網站） | Rust 是一種專注於安全性（尤其是安全並行性）的多正規化系統程式語言。（來源：維基百科） |
在系統程式設計領域，你可能經常需要編寫硬體驅動程式或直接與記憶體對映裝置進行互動，而這些互動幾乎總是通過硬體提供的記憶體對映暫存器來完成的。通常，你通過對某些固定寬度的數位型別進行按位元運算來與這些暫存器進行互動。
例如，假設一個 8 位暫存器具有三個欄位：
+----------+------+-----------+---------+| (unused) | Kind | Interrupt | Enabled |+----------+------+-----------+---------+ 5-7 2-4 1 0欄位名稱下方的數位規定了該欄位在暫存器中使用的位。要啟用該暫存器，你將寫入值 1（以二進位制表示為 0000_0001）來設定 Enabled 欄位的位。但是，通常情況下，你也不想干擾暫存器中的現有設定。假設你要在裝置上啟用中斷功能，但也要確保裝置保持啟用狀態。為此，必須將 Interrupt 欄位的值與 Enabled 欄位的值結合起來。你可以通過按位元操作來做到這一點：
1 | (1 << 1)通過將 1 和 2（1 左移一位得到）進行“或”（|）運算得到二進位制值 0000_0011 。你可以將其寫入暫存器，使其保持啟用狀態，但也啟用中斷功能。
你的頭腦中要記住很多事情，特別是當你要在一個完整的系統上和可能有數百個之多的暫存器打交道時。在實踐上，你可以使用助記符來執行此操作，助記符可跟蹤欄位在暫存器中的位置以及欄位的寬度（即它的上邊界是什麼）
下面是這些助記符之一的範例。它們是 C 語言的宏，用右側的程式碼替換它們的出現的地方。這是上面列出的暫存器的簡寫。＆ 的左側是該欄位的起始位置，而右側則限制該欄位所佔的位：
#define REG_ENABLED_FIELD(x) (x << 0) & 1#define REG_INTERRUPT_FIELD(x) (x << 1) & 2#define REG_KIND_FIELD(x) (x << 2) & (7 << 2)然後，你可以使用這些來抽象化暫存器值的操作，如下所示：
void set_reg_val(reg* u8, val u8);fn enable_reg_with_interrupt(reg* u8) { set_reg_val(reg, REG_ENABLED_FIELD(1) | REG_INTERRUPT_FIELD(1));}這就是現在的做法。實際上，這就是大多數驅動程式在 Linux 核心中的使用方式。
有沒有更好的辦法？如果能夠基於對現代程式語言研究得出新的型別系統，就可能能夠獲得安全性和可表達性的好處。也就是說，如何使用更豐富、更具表現力的型別系統來使此過程更安全、更持久？
繼續用上面的暫存器作為例子：
+----------+------+-----------+---------+| (unused) | Kind | Interrupt | Enabled |+----------+------+-----------+---------+ 5-7 2-4 1 0你想如何用 Rust 型別來表示它呢？
你將以類似的方式開始，為每個欄位的偏移定義常數（即，距最低有效位有多遠）及其掩碼。掩碼是一個值，其二進位制表示形式可用於更新或讀取暫存器內部的欄位：
const ENABLED_MASK: u8 = 1;const ENABLED_OFFSET: u8 = 0;const INTERRUPT_MASK: u8 = 2;const INTERRUPT_OFFSET: u8 = 1;const KIND_MASK: u8 = 7 << 2;const KIND_OFFSET: u8 = 2;接下來，你將宣告一個 Field 型別並進行操作，將給定值轉換為與其位置相關的值，以供在暫存器內使用：
struct Field { value: u8,}impl Field { fn new(mask: u8, offset: u8, val: u8) -> Self { Field { value: (val << offset) & mask, } }}最後，你將使用一個 Register 型別，該型別會封裝一個與你的暫存器寬度匹配的數位型別。 Register 具有 update 函數，可使用給定欄位來更新暫存器：
struct Register(u8);impl Register { fn update(&mut self, val: Field) { self.0 = self.0 | field.value; }}fn enable_register(&mut reg) { reg.update(Field::new(ENABLED_MASK, ENABLED_OFFSET, 1));}使用 Rust，你可以使用資料結構來表示欄位，將它們與特定的暫存器聯絡起來，並在與硬體互動時提供簡潔明瞭的工效。這個例子使用了 Rust 提供的最基本的功能。無論如何，新增的結構都會減輕上述 C 範例中的某些晦澀的地方。現在，欄位是個帶有名字的事物，而不是從模糊的按位元運算子派生而來的數位，並且暫存器是具有狀態的型別 —— 這在硬體上多了一層抽象。
用 Rust 重寫的第一個版本很好，但是並不理想。你必須記住要帶上掩碼和偏移量，並且要手工進行臨時計算，這容易出錯。人類不擅長精確且重複的任務 —— 我們往往會感到疲勞或失去專注力，這會導致錯誤。一次一個暫存器地手動記錄掩碼和偏移量幾乎可以肯定會以糟糕的結局而告終。這是最好留給機器的任務。
其次，從結構上進行思考：如果有一種方法可以讓欄位的型別攜帶掩碼和偏移資訊呢？如果可以在編譯時就發現硬體暫存器的存取和互動的實現程式碼中存在錯誤，而不是在執行時才發現，該怎麼辦？也許你可以依靠一種在編譯時解決問題的常用策略，例如型別。
你可以使用 typenum 來修改前面的範例，該庫在型別級別提供數位和算術。在這裡，你將使用掩碼和偏移量對 Field 型別進行引數化，使其可用於任何 Field 範例，而無需將其包括在呼叫處：
#[macro_use]extern crate typenum;use core::marker::PhantomData;use typenum::*;// Now we'll add Mask and Offset to Field's typestruct Field<Mask: Unsigned, Offset: Unsigned> { value: u8, _mask: PhantomData<Mask>, _offset: PhantomData<Offset>,}// We can use type aliases to give meaningful names to// our fields (and not have to remember their offsets and masks).type RegEnabled = Field<U1, U0>;type RegInterrupt = Field<U2, U1>;type RegKind = Field<op!(U7 << U2), U2>;現在，當重新存取 Field 的建構函式時，你可以忽略掩碼和偏移量引數，因為型別中包含該資訊：
impl<Mask: Unsigned, Offset: Unsigned> Field<Mask, Offset> { fn new(val: u8) -> Self { Field { value: (val << Offset::U8) & Mask::U8, _mask: PhantomData, _offset: PhantomData, } }}// And to enable our register...fn enable_register(&mut reg) { reg.update(RegEnabled::new(1));}看起來不錯，但是……如果你在給定的值是否適合該欄位方面犯了錯誤，會發生什麼？考慮一個簡單的輸入錯誤，你在其中放置了 10 而不是 1：
fn enable_register(&mut reg) { reg.update(RegEnabled::new(10));}在上面的程式碼中，預期結果是什麼？好吧，程式碼會將啟用位設定為 0，因為 10＆1 = 0。那真不幸；最好在嘗試寫入之前知道你要寫入欄位的值是否適合該欄位。事實上，我認為截掉錯誤欄位值的高位是一種 1未定義的行為（哈）。
如何以一般方式檢查欄位的值是否適合其規定的位置？需要更多型別級別的數位！
你可以在 Field 中新增 Width 引數，並使用它來驗證給定的值是否適合該欄位：
struct Field<Width: Unsigned, Mask: Unsigned, Offset: Unsigned> { value: u8, _mask: PhantomData<Mask>, _offset: PhantomData<Offset>, _width: PhantomData<Width>,}type RegEnabled = Field<U1,U1, U0>;type RegInterrupt = Field<U1, U2, U1>;type RegKind = Field<U3, op!(U7 << U2), U2>;impl<Width: Unsigned, Mask: Unsigned, Offset: Unsigned> Field<Width, Mask, Offset> { fn new(val: u8) -> Option<Self> { if val <= (1 << Width::U8) - 1 { Some(Field { value: (val << Offset::U8) & Mask::U8, _mask: PhantomData, _offset: PhantomData, _width: PhantomData, }) } else { None } }}現在，只有給定值適合時，你才能構造一個 Field ！否則，你將得到 None 信號，該信號指示發生了錯誤，而不是截掉該值的高位並靜默寫入意外的值。
但是請注意，這將在執行時環境中引發錯誤。但是，我們事先知道我們想寫入的值，還記得嗎？鑑於此，我們可以教編譯器完全拒絕具有無效欄位值的程式 —— 我們不必等到執行它！
這次，你將向 new 的新實現 new_checked 中新增一個特徵系結（where 子句），該函數要求輸入值小於或等於給定欄位用 Width 所能容納的最大可能值：
struct Field<Width: Unsigned, Mask: Unsigned, Offset: Unsigned> { value: u8, _mask: PhantomData<Mask>, _offset: PhantomData<Offset>, _width: PhantomData<Width>,}type RegEnabled = Field<U1, U1, U0>;type RegInterrupt = Field<U1, U2, U1>;type RegKind = Field<U3, op!(U7 << U2), U2>;impl<Width: Unsigned, Mask: Unsigned, Offset: Unsigned> Field<Width, Mask, Offset> { const fn new_checked<V: Unsigned>() -> Self where V: IsLessOrEqual<op!((U1 << Width) - U1), Output = True>, { Field { value: (V::U8 << Offset::U8) & Mask::U8, _mask: PhantomData, _offset: PhantomData, _width: PhantomData, } }}只有擁有此屬性的數位才實現此特徵，因此，如果使用不適合的數位，它將無法編譯。讓我們看一看！
fn enable_register(&mut reg) { reg.update(RegEnabled::new_checked::<U10>());}12 | reg.update(RegEnabled::new_checked::<U10>()); | ^^^^^^^^^^^^^^^^ expected struct `typenum::B0`, found struct `typenum::B1` | = note: expected type `typenum::B0` found type `typenum::B1`new_checked 將無法生成一個程式，因為該欄位的值有錯誤的高位。你的輸入錯誤不會在執行時環境中才爆炸，因為你永遠無法獲得一個可以執行的工件。
就使記憶體對映的硬體進行互動的安全性而言，你已經接近 Rust 的極致。但是，你在 C 的第一個範例中所寫的內容比最終得到的一鍋粥的型別引數更簡潔。當你談論潛在可能有數百甚至數千個暫存器時，這樣做是否容易處理？
早些時候，我認為手工計算掩碼有問題，但我又做了同樣有問題的事情 —— 儘管是在型別級別。雖然使用這種方法很不錯，但要達到編寫任何程式碼的地步，則需要大量樣板和手動轉錄（我在這裡談論的是型別的同義詞）。
我們的團隊想要像 TockOS mmio 暫存器之類的東西，而以最少的手動轉錄生成型別安全的實現。我們得出的結果是一個宏，該宏生成必要的樣板以獲得類似 Tock 的 API 以及基於型別的邊界檢查。要使用它，請寫下一些有關暫存器的資訊，其欄位、寬度和偏移量以及可選的列舉類的值（你應該為欄位可能具有的值賦予“含義”）：
register! { // The register's name Status, // The type which represents the whole register. u8, // The register's mode, ReadOnly, ReadWrite, or WriteOnly. RW, // And the fields in this register. Fields [ On WIDTH(U1) OFFSET(U0), Dead WIDTH(U1) OFFSET(U1), Color WIDTH(U3) OFFSET(U2) [ Red = U1, Blue = U2, Green = U3, Yellow = U4 ] ]}由此，你可以生成暫存器和欄位型別，如上例所示，其中索引：Width、Mask 和 Offset 是從一個欄位定義的 WIDTH 和 OFFSET 部分的輸入值派生的。另外，請注意，所有這些數位都是 “型別數位”；它們將直接進入你的 Field 定義！
生成的程式碼通過為暫存器及欄位指定名稱來為暫存器及其相關欄位提供名稱空間。這很繞口，看起來是這樣的：
mod Status { struct Register(u8); mod On { struct Field; // There is of course more to this definition } mod Dead { struct Field; } mod Color { struct Field; pub const Red: Field = Field::<U1>new(); // &c. }}生成的 API 包含名義上期望的讀取和寫入的原語，以獲取原始暫存器的值，但它也有辦法獲取單個欄位的值、執行集合操作以及確定是否設定了任何（或全部）位集合的方法。你可以閱讀完整生成的 API上的文件。
將這些定義用於實際裝置會是什麼樣？程式碼中是否會充斥著型別引數，從而掩蓋了檢視中的實際邏輯？
不會！通過使用型別同義詞和型別推斷，你實際上根本不必考慮程式的型別層面部分。你可以直接與硬體互動，並自動獲得與邊界相關的保證。
這是一個 UART 暫存器塊的範例。我會跳過暫存器本身的宣告，因為包括在這裡就太多了。而是從暫存器“塊”開始，然後幫助編譯器知道如何從指向該塊開頭的指標中查詢暫存器。我們通過實現 Deref 和 DerefMut 來做到這一點：
#[repr(C)]pub struct UartBlock { rx: UartRX::Register, _padding1: [u32; 15], tx: UartTX::Register, _padding2: [u32; 15], control1: UartControl1::Register,}pub struct Regs { addr: usize,}impl Deref for Regs { type Target = UartBlock; fn deref(&self) -> &UartBlock { unsafe { &*(self.addr as *const UartBlock) } }}impl DerefMut for Regs { fn deref_mut(&mut self) -> &mut UartBlock { unsafe { &mut *(self.addr as *mut UartBlock) } }}一旦到位，使用這些暫存器就像 read() 和 modify() 一樣簡單：
fn main() { // A pretend register block. let mut x = [0_u32; 33]; let mut regs = Regs { // Some shenanigans to get at `x` as though it were a // pointer. Normally you'd be given some address like // `0xDEADBEEF` over which you'd instantiate a `Regs`. addr: &mut x as *mut [u32; 33] as usize, }; assert_eq!(regs.rx.read(), 0); regs.control1 .modify(UartControl1::Enable::Set + UartControl1::RecvReadyInterrupt::Set); // The first bit and the 10th bit should be set. assert_eq!(regs.control1.read(), 0b_10_0000_0001);}當我們使用執行時值時，我們使用如前所述的選項。這裡我使用的是 unwrap，但是在一個輸入未知的真實程式中，你可能想檢查一下從新呼叫中返回的某些東西： 1 2
fn main() { // A pretend register block. let mut x = [0_u32; 33]; let mut regs = Regs { // Some shenanigans to get at `x` as though it were a // pointer. Normally you'd be given some address like // `0xDEADBEEF` over which you'd instantiate a `Regs`. addr: &mut x as *mut [u32; 33] as usize, }; let input = regs.rx.get_field(UartRX::Data::Field::Read).unwrap(); regs.tx.modify(UartTX::Data::Field::new(input).unwrap());}根據你的個人痛苦忍耐程度，你可能已經注意到這些錯誤幾乎是無法理解的。看一下我所說的不那麼微妙的提醒：
error[E0271]: type mismatch resolving `<typenum::UInt<typenum::UInt<typenum::UInt<typenum::UInt<typenum::UInt<typenum::UTerm, typenum::B1>, typenum::B0>, typenum::B1>, typenum::B0>, typenum::B0> as typenum::IsLessOrEqual<typenum::UInt<typenum::UInt<typenum::UInt<typenum::UInt<typenum::UTerm, typenum::B1>, typenum::B0>, typenum::B1>, typenum::B0>>>::Output == typenum::B1` --> src/main.rs:12:5 |12 | less_than_ten::<U20>(); | ^^^^^^^^^^^^^^^^^^^^ expected struct `typenum::B0`, found struct `typenum::B1` | = note: expected type `typenum::B0` found type `typenum::B1`expected struct typenum::B0, found struct typenum::B1 部分是有意義的，但是 typenum::UInt<typenum::UInt, typenum::UInt... 到底是什麼呢？好吧，typenum 將數位表示為二進位制 cons 單元！像這樣的錯誤使操作變得很困難，尤其是當你將多個這些型別級別的數位限制在狹窄的範圍內時，你很難知道它在說哪個數位。當然，除非你一眼就能將巴洛克式二進位制表示形式轉換為十進位制表示形式。
在第 U100 次試圖從這個混亂中破譯出某些含義之後，我們的一個隊友簡直《瘋了，地獄了，不要再忍受了》，並做了一個小工具 tnfilt，從這種名稱空間的二進位制 cons 單元的痛苦中解脫出來。tnfilt 將 cons 單元格式的表示法替換為可讓人看懂的十進位制數位。我們認為其他人也會遇到類似的困難，所以我們分享了 tnfilt。你可以像這樣使用它：
$ cargo build 2>&1 | tnfilt它將上面的輸出轉換為如下所示：
error[E0271]: type mismatch resolving `<U20 as typenum::IsLessOrEqual<U10>>::Output == typenum::B1`現在這才有意義！
當在軟體與硬體進行互動時，普遍使用記憶體對映暫存器，並且有無數種方法來描述這些互動，每種方法在易用性和安全性上都有不同的權衡。我們發現使用型別級程式設計來取得記憶體對映暫存器互動的編譯時檢查可以為我們提供製作更安全軟體的必要資訊。該程式碼可在 bounded-registers crate（Rust 包）中找到。
我們的團隊從安全性較高的一面開始，然後嘗試找出如何將易用性滾軸移近易用端。從這些雄心壯志中，“邊界暫存器”就誕生了，我們在 Auxon 公司的冒險中遇到記憶體對映裝置的任何時候都可以使用它。
此內容最初發布在 Auxon Engineering 部落格上，並經許可進行編輯和重新發布。
從技術上講，從定義上看，從暫存器欄位讀取的值只能在規定的範圍內，但是我們當中沒有一個人生活在一個純淨的世界中，而且你永遠都不知道外部系統發揮作用時會發生什麼。你是在這裡接受硬體之神的命令，因此與其強迫你進入“可能的恐慌”狀態，還不如給你提供處理“這將永遠不會發生”的機會。 ?
get_field 看起來有點奇怪。我正在專門檢視 Field::Read 部分。Field 是一種型別，你需要該型別的範例才能傳遞給 get_field。更乾淨的 API 可能類似於：regs.rx.get_field::<UartRx::Data::Field>(); 但是請記住，Field 是一種具有固定的寬度、偏移量等索引的型別的同義詞。要像這樣對 get_field 進行引數化，你需要使用更高階的型別。 ?