原文
128整,正128未完成.

通用的任意固定大小整數類型會是更好補充.
通過core.int128公開.
cent/ucent按core.int128來暴露.

會支持128位字面嗎?還是必須等待importC有int128_t支持?

data.hi = lo >> 63

可加ulong版構造器.更清楚,在高位移動.

為何要手動特化模板?

Int128 opBinary(string op : "+")(Int128 op2) const {return Int128(add(this.data, op2.data)); }

這樣,更可讀,編譯器查找速度會更快,而不是約束,它需要求值靜態條件,此時,需要兩次.
更易閱讀.

1,缺少文檔單元測試.2,請添加變更日志項.

import默認為私,

bool opEquals(Int128 op2) const {return data.hi == op2.data.hi && data.lo == op2.data.lo; }

可否刪除,默認構比較應工作.

我不明白為什么應該在Phobos和druntime中.與與其他系統編程語言相比,把128位類型作為庫已經很奇怪了(即使隨后特殊處理它們來使用正確的編譯器內置函數(很差了),),但如果這樣,為何分成phobos和druntime兩塊?

應在druntime中定義像樣的公開接口,而不是從phobos中復制.對如std.math和core.math中的builtins/intrinsics做了類似復制,這很糟糕.
我在想把Cent包裝成不同對齊構,是否會使加載/存儲,構數據更慢?為什么不在對齊構上提供接口而不是包裝它.

:把128位類型作為庫已經很奇怪了
不是的.見std.complex.它曾是內置類型,但D已可按庫類型輕松實現.Int128是很少使用類型(是的,我知道有些人經常使用它).在45年的編程生涯中,我從未使用過它.則為什么要讓編譯器比需要的更復雜呢?
擁有128位整數會膨脹大量內部數據(加64位).那是相當昂貴.

:為什么分成phobos和druntime兩部分?
Druntime提供了需要針對每個目標調整的基礎.Phobos提供用戶接口.std.complex在火衛一中.還在druntime和phobos之間拆分了數學例程.
其他語言按內置類型,是因為它們的元編程設施不足或不存在.
最后,在Phobos中做表明現在可用了.

---

你的經驗并不普遍.128位整數在密碼學和生成隨機數等應用中非常有用.本實現對我用處不大,因為它既不提供ucent也不提供128位字面.
可用哪些元編程工具來支持128位字面?這通過isIntegral嗎?現在可用正128嗎?size_t變成128位時會怎樣?會是別名,還是D會拒絕支持這樣平臺?為什么有人會在現有實現上使用它?還會有128位浮點結構嗎?

我有一個置換同余生成器RNG實現,可簡單支持128位狀態和/或值,如果ucent支持字面,我需要的只是取消注釋兩行.相反,我需要重要重構來支持該點.我不會等待該模塊支持正128位整數,而是使用一些現有的128位正整數代碼或完全刪除代碼.

我在想后者,因為std.random的一部分(特別是uniform01)無法工作,除非RNG生成通不過isIntegral或isFloatingPoint的類型.
我很自豪實現比C++干凈得多.現在我必須削弱它或讓它像C++一樣丑陋.我很失望.

可這樣:

alias creal = __c_complex_real; alias cent = Cent;

我假設上面會,但最好只添加此接口到該別名,并置其他內部內容為私有,來兼容ABI.
我最初想法是,棄用cent時,會別名cent為模仿它的庫接口,使其為編譯器上特殊類型,因此特征按內置類型識別它.

我確實對各種代碼有很多經驗,兩者(密碼/隨機數)都只占編寫代碼的一小部分.是的,我都做過.

1,它是替代ucent.
2,擁有字面是非常簡單的,只需制作使用CTFE的int128!"92834572783456287346587324652834756"模板來創建Int128實例.都可寫它,它只是atoi().我還沒做,因為如果沒批準Int128,那是無意義的.
3,同樣,我還沒實現Uint128.
則128位指針有什么用呢?
可用重載來完成.

感覺這很黑客.如果有一天按內置類型支持,即使是庫實現的.那為什么不呢?

為什么任何代碼都應有不必要的摩擦?
系統設計人員可能會發現,在指針中編碼其他數據很有用.RISC-V及其計劃中的RV128IISA已在為此做準備.128位是必然的,而不是可能的.
isIntegral是模板.它明確拒絕除內置類型外的所有整數類型.

用戶接口應該是cent關鍵字,添加模塊,僅僅因為它比編譯器接口,更容易實現cent,這不充分.等待cent.

現在我并不介意這是在運行時,但我認為,顯然僅為了某些重載符號目的,而成為Phobos模塊,這對BetterC來說很奇怪而且有點煩人.

當我在語言中加位域時,我被阻止了,因為人們說應用元編程來完成.當我用元編程添加非常需要功能時,它會因為沒有內置而被阻止.

我為core.int128加了些編譯器內置函數,因此它幾乎是內置類型.唯一不利的是Cent布局對BigEndian不友好,并且庫<->本地間轉換,導致生成代碼比匹配本地cent布局時稍差.

即:導致與輸入參數就像ucent時,生成相同代碼.

// struct Cent { ulong lo; ulong hi } version (LittleEndian): const tmp1 = *cast(ucent*)&c1; // mov (load) const tmp2 = *cast(ucent*)&c2; // mov (load) const tmp3 = tmp1 OP tmp2; // op return *cast(Cent*)&tmp3; // ret (已在正確寄存器)

而這:

// struct Cent { ulong lo; ulong hi } version (BigEndian): const tmp1 = cast(ucent)c1.lo + (cast(ucent)c1.hi << 64); // mov+xor+ad[dc] (load) const tmp2 = cast(ucent)c2.lo + (cast(ucent)c2.hi << 64); // mov+xor+ad[dc] (load) const tmp3 = tmp1 OP tmp2;// op+mov return Cent(cast(ulong)tmp3, cast(ulong)(tmp3 >> 64)); // mov+ret

更多移位.用

enum Cent One = {lo:1};

替換

enum One = Cent(1);

看起來是錯的.交換高低字段來不及了.
為了一致性,加

this(U lo, U hi)

使事情更糟糕.

使用位域,你正給語言推動全新語義.cent另一方面,已經在規范中.此外,cent從規范角度看,比位域更簡單.
說白了,問題不在于實現是DRuntime還是內部編譯器.cent都可以.只是從用戶角度看,它需要成為語言功能.
如果達成共識,從規范中刪除cent,則會承認該模塊給Phobos(當然細節正確了).

我(在此例)說加它,但與druntime中的其他功能放在一起.druntime和dmd在語義上是同一個項目,因此atomics和arrayOp等等在druntime中,我認為128位整數是基礎,必須放在druntime中.

不是真的,沒人用Cent,因為對齊問題阻止了該PR.

我不記得int128是,在我最后一輪跨平臺測試之前還是之后.應再次運行來查看在sparc64-solaris上通過了多少int128.我希望一切都通過,因為庫類型和例程是字節序無關的.

總結

以上是生活随笔為你收集整理的d加整128的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。