总结
DMDARM后端
Razvan问Walter他对DMD的ARM后端的分发,并想知道他是否考虑过其他选择,如整合DMD前端与LDC后端.
Walter说,人们写信告诉他,他们喜欢使用DMD,因为它体积小,速度快.多年来,就要求他实现ARM后端.
有的人想写一个,但后来因为太难或太耗时而丢弃了.所以他决定完成它.
他最初不打算优化.ARM指令集复杂得离谱,但有一条简单的路径.他坚持使用简单路径,且不会生成超出全局优化器和寄存器分配器已完成的优化代码.
一旦实现简单路径并正常工作,就可基于每条指令微优化.当前,他的进度很快.可编译简单的函数,且生成的代码是正确的.
他已为它编写了一个反汇编器,这样,就方便检查生成的代码.一个大问题是缺少内联汇编器.如果没有它,就无法编译所有运行时.
BradRoberts已编写了一个ARM反汇编器,并表示想适配ARM64.这与编写ARM后端无关,所以如果他能完成就好了.
Razvan认为,用D认真工作的人都会因ARM使用LDC.
虽然这对D的总体方向可能很有趣,但他不确定这是否是Walter的最好分配时间.
沃尔特说,这很对,但他对它所带来的惊讶之多感到兴趣.此外,从头到尾控制编译器是件好事.他不知道LDC和GDC的后端工作原理,因此他很难添加新功能.
Walter说,DMD中的Intelx86内联汇编器并不是他编造的什么笨拙的东西.它与Intel的规范匹配,因此有一一对应的关系.
ARM的反汇编器及他打算搞的汇编器匹配规范.他对LDC和GDC使用的语法一无所知.
Martin说,对x86,有两个方言,Intel和AT&T.LDC和GDC都使用了AT&T方言,而该方言恰好不太常用.但对ARM来说,他们恰好到处都是相同方言.
重要的是它是基于串的,因此可独立于架构.
他说内联汇编器是个小问题.关于Razvan对Walter使用时间的问题,Martin说根据Walter.如果他认为价值,他就应该去做.
几年前,当该讨论前出现时,Martin认为Walter的时间最好花在修复漏洞上.但他现在有很多行业经验.甚至Symmetry也仅是因为它的速度,而使用DMD来调试构建.
他同意Walter.在一个代码基中,而不是依赖有巨大后端的巨大代码基中,放置所有内容真是太好了.在DMD中快速的完成了所有操作.
这是最主要的事情.所以他觉得如果Walter想做这件事,他应该有自由.
Rikki说,如果没有ARM支持,DMD在OSX上已死了.他说明Atila想在守护进程中单元测试.如果你正在编写目标文件,则已失败了.DMD的后端非常适合JIT.
沃尔特说还有另一个小问题.很难理解DMD后端的工作原理,及如何改进或修改它.
他已很多年没有看过太多代码了,在试实现ARM后端时,他不得不重新投入其中,弄清楚它工作原理.他能看出这是多么难以理解.
它的结构相当简单,但所有x86的大量怪指令集,所有特例,所有来各种对象的奇怪指令序列,只是很难梳理出他们的实现.
他觉得ARM的实现要简单得多.
当前,它简单得多,但它遵守与x86实现相同结构.对想要增强代码生成器的人来说,它会更容易.它还可帮助想要修改x86后端的人.
因为结构是相同,所以可查看它以了解x86版本中的给定函数正在做什么.
Walter同意Rikki的视图,即可用作简单的JIT.他没有想到它.
Walter说,很少需要内联汇编.但这是当你需要它时,很重要.否则,你将以十六进制编程.
蒂蒙说,这是他会在所有方面都支持沃尔特的案例之一.为DMD提供ARM后端很重要,因为DMD是一个非常容易理解的编译器.
它很容易克隆和构建.如果它在ARM上继续工作,那就太好了.至于内联汇编器,DMD为x86干的,要优于LDC和GDC.
Walter说明,他不会试适配现有内联汇编器,因为它是一段可怕的代码.他不是原作者,每次有新的Intel指令他必须支持时,他总是担心他无法让它工作.
Rikki认为,如果今天有人使用内联汇编,那就是编译器错误.它表明缺乏内联.如,原子都应该是内置.
这些都不应是内联汇编.因此,内联汇编器的优先级应该是低优先级的.
d标准库与运行时
应该把d运行时精简到编译器的期望核心,并在其他位置放置其余部分.
沃尔特说,它不一定非得去其他地方.可在不同包中放置编译器和库来处理.
为什么vibe.d没有赢得基准测试
Rikki说,他在上个月受到了启发,审查了vibe.d,因为它没有赢得基准测试.他查看了核心,发现它轮询每线程的64个句柄来处理事件.
然后,纤程重载都可安全地移动.
沃尔特说他对此没有异议.
Walter说,另一个方法可能是使函数变为纯.纯函数禁止访问可变的全局数据,而TLS数据就是这样.Rikki说,这对VM勾挂等等不行.
最好是禁止TLS并有黑名单和白名单.至少它提供了一条移动路径,直到取得合适的协程.
Mathias建议每线程运行一个分发器.Rikki说,问题总结为IOCP事件.要用IOCP.即必须支持在线程间移动纤程.
否则,将每线程有64个句柄.Adam对此表示赞同.他说,现在窗口上的一切都依赖IOCP.没有它,你取得无法性能,吞吐量或低懒.
不得不接受它.
Mathias问这是否是仅限窗口的要求.Adam说Linux上的iou_ring是一样的.Rikki对epoll说了同样的话.
Mathias说你可在每个内核上运行一个epoll.Rikki说,你仍只会在其中一个线程上取得句柄的事件.自窗口2k以来,IOCP一直是25年的黄金标准.
.di生成器
Rikki一直在研究.di生成器,并认为它当前对DI文件无用.
但他一直分发使用ImportC和.di生成来重做d运行时的头文件,与窗口模块一样.
Razvan说明,DMD内部使用了DI生成器的一部分.如,如果你想打印一些AST节点,则你使用DI生成器中的功能.
Adam说,根据他的经验,窗口头文件和API非常稳定,尽管他确信可找到边角.使用ImportC生成DI比所有其他选项都要好.
它接受了后处理版本,因为D编译器也是一个C编译器,所以它就可正常工作了.他在ODBC头文件上使用它,效果非常好.
这些现在是d运行时中窗口头文件的一部分.
可开始制作更多此窗口头文件.然后,当有新的窗口SDK时,更新与提供新SDK的路径给构建系统并生成DI文件一样简单.
之所以这样,是因为他一直在研究Phobosv3和d运行时,弄清楚需要做什么.为此,使用ImportC和DI生成比从C头文件生成约束的其他工具都要好.
Adam说,动力来自工具.他常用VSCode,而code-d可在你只使用普通版本时读取DI文件.不经常预处理可能会带来性能优势,但这不是动机.
Steve说还有一个问题,即你无法组织ImportC文件,但你可组织DI文件.DI文件是独立的模块,但ImportC文件放在一个大模块中,因此如果从多个地方导入,就会冲突.
Adam说他从ImportC生成了DI文件,来他使用zstd一些工作,效果很好.
D的文档/用户指南
略.