d加整128

原文
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.我希望一切都通过,因为库类型和例程是字节序无关的.