Runtime: MIPS32 和 MIPS64 支持

我不认为排除 MIPS 是意识形态问题，而是实用主义问题：没有针对 MIPS 硬件的客户。

CoreCLR 是开源的。 没有什么可以阻止 Imagination Technologies（MIPS 的所有者）为其处理器添加支持。 Imagination Tech 是一家拥有大量财务资源的大公司。 他们不需要依靠“技术福利”来支持他们的产品。

没有针对 MIPS 硬件的客户。

我怀疑您（不是真的）错过了（不再）MIPS 支持 Android 以及运行 Android 的基于 MIPS 的平板电脑的消息，并且此类设备的开发仍在进行中。

让我扩展一下：
没有 [Microsoft] 客户针对 MIPS 硬件。

我完全支持 MIPS。 我只是指出，目前缺乏支持并不是由于任何邪恶的议程。 此外，MIPS 支持不依赖于 Microsoft。 任何人，包括 Imagination Tech，都可以添加它。 您应该通过电子邮件或在他们的论坛上发布您对在包含其产品的设备上使用 CoreCLR 的兴趣。

没有 [Microsoft] 客户针对 MIPS 硬件。

你怎么能这么肯定？ 我是 Microsoft 客户，拥有一台基于 MIPS 的平板电脑，并且很想在我的设备上运行 .NET 应用程序。

您应该通过电子邮件或在他们的论坛上发布您对在包含其产品的设备上使用 CoreCLR 的兴趣。

你误会了。 这不是它的工作原理。

@jasonwilliams200OK我猜在这种情况下，Microsoft 客户是指 Microsoft 内部的一个产品组。 另外，你能解释一下“它”是如何工作的吗？

@jasonwilliams200OK是 100% 正确的。 那不是它的工作原理。 它的工作原理是，如果人们对新平台或架构特别热情，他们应该提交拉取请求。 我很高兴查看 MIPS 支持的所有 PR。 我在车库里有一个 MIPS 盒子，我可以在上面进行验证。

我猜真的没有关于在新平台上进行 JIT 启动过程的任何文档吗？ MIPS 肯定会很有趣，但我猜 MS 不会愿意花时间在上面的东西，因为他们的任何产品都没有真正针对它。 我不太确定需要做什么才能让 JIT 从当前的代码库中工作在一个新的架构上，尽管如果作为一个社区项目来完成它会令人印象深刻。

@kangaroo和@jasonwilliams200OK是正确的。 这是一个开源项目。 顾名思义，它是与各种个人和公司的合作。 您当前看到的代码库是 Microsoft 的 CLR 组在过去 15 年中生成的实际产品代码。 这显然是基于微软过去的商业利益。

就我们未来的兴趣和投资而言：我们已经宣布将在非 Microsoft 平台上支持此运行时。 但从务实的角度来说，我们（尽管这对某些人来说可能很难相信）没有无限的资源来“简单地”在任何地方支持 CoreCLR。 但是，我们确实希望与其他人合作，将代码移植到更多平台。 我们的承诺水平肯定会根据路线图、优先级以及与我们已经在开展的其他项目的重叠而有所不同。

话虽如此，这并不意味着我们不会接受微软目前不感兴趣的平台的 PR。这只是意味着社区必须提供愿意在一定程度上维护架构的人感觉成为这个存储库的一部分。 这种模式不仅是一种选择——它非常受欢迎！

我们知道一个事实，即 .NET 比 Microsoft 大得多。 因此，请保留有关端口的建议。 有许多技术娴熟、充满热情的人关心并愿意合作——正如@kangaroo刚刚通过提供代码审查和验证所证明的那样。

我在 .NET Foundation 论坛上发布了一个关于 .NET Compact 的开源关键部分的建议，该部分已经在 MIPS、PPC 等上运行多年： http :

我认为能够将其用作参考源将大大有助于本主题的工作。 如果我是对的，你也可以考虑提出这个建议:)

即使它最终没有多大帮助，也不会伤害任何可用的东西。

@kangaroo和@jasonwilliams200OK是正确的。

这种模式不仅是一种选择——它是非常受欢迎的！ [http://blogs.msdn.com/b/dotnet/archive/2015/07/14/first-net-port-award.aspx]

有许多技术娴熟、充满热情的人关心并愿意合作——正如@kangaroo刚刚通过提供代码审查和验证所证明的那样。

玛西娅，玛西娅，玛西娅！

（对不起， @kangaroo ，无法抗拒。:wink
（对于那些不熟悉参考的人：https://www.youtube.com/watch?v=w2fXs3bf-p0 “The Brady Bunch: Marcia, Marcia, Marcia！”）

备案： https :
3A2000 型号 CPU 在 mini-itx 主板上出售http://www.lemote.com/html/product/miniitx/2015/1230/28.html
性能与 Intel Ivy-Bridge 一代相当。

它运行Java 、 Go 、 Ruby ......

@xied75 ，我从在 qemu-mips 上运行的 Debian Jesse (MIPS) 开始，.S汇编代码转换为其 MIPS 对应代码。 有几个 SIMD 指令在 MIPS 中是不同的（有些本身不需要），它们需要一些我缺乏的严重的 MIPS 组装暗黑技术。如果您对 MIPS 组装有丰富的知识，请做出贡献！ :)

更多关于设备的信息； 在他们的博客https://imgtec.com/blog/上发布了许多有趣的设备，其中大部分是 SOC 板、arduinos 和物联网解决方案。 现在甚至还有一体机： http :

第一步是让 PAL 在 MIPS 上工作，这应该相当容易。 在 MIPS 上获取 JIT 需要做很多工作，我想有解释器回退，这在启动过程中很有用，但在尝试获取之前等待 RyuJIT 在 x86 或 ARM 上运行良好可能是有意义的另一个 32 位平台工作。 我知道有 MIPS64，但我很确定它是一个严格的超集，所以 MIPS32 端口似乎更有意义。

@benpye ，谢谢！ :)

第一步：

• 我们应该只在 PAL 下配置 cmake 吗？
• 我们可以在不构建 JIT 的情况下运行PAL 测试吗？
• 关于让 JIT 解释器回退并运行的任何进一步建议？

PAL 和 PAL 测试几乎是独立的，它们可以在没有 coreclr 的其余部分的情况下工作。 您将不得不稍微修改顶级 CMakefile，我会查看 ARM 定义并为 MIPS 添加合适的定义。 你可以让它只为 MIPS 构建 PAL。

要启动并运行 JIT，您必须询问 @dotnet/jit-contrib ，有https://github.com/dotnet/coreclr/blob/master/Documentation/botr/porting-ryujit.md但它是一个相当高水平的概述。 社区 JIT 端口肯定会令人印象深刻。

@jasonwilliams200OK我搜索了来源：

root<strong i="7">@da1f6193b184</strong>:~/github/coreclr# find . -name "*.s"

只能找到两个 .s 文件？

./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/sparcinterloc.s
./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/hpitinterlock.s

我们是否仍然需要先转换它？

@benpye我可以做一些足够小的任务吗？

@xied75 ，尝试使用大写.S 。 在 MIPS 上构建 PAL 是第一步，它不需要这种转换。

移植 PAL 相当简单，大部分架构
具体文件在
https://github.com/dotnet/coreclr/tree/master/src/pal/src/arch虽然有
是各种可能需要更新的定义和 ifdef。
https://github.com/dotnet/coreclr/blob/master/src/pal/src/exception/seh-unwind.cpp
也有很多特定于架构的代码。 如果你有更具体的
问题我可以尝试并从我记得移植 PAL 的内容中给出指示
到 ARM。

2016 年 8 月 23 日，星期二，谢东，16:50， notifications@ github.com 写道：

@jasonwilliams200OK https://github.com/jasonwilliams200OK我做了一个
搜索来源：

root@da1f6193b184 :~/github/coreclr# find . -名称“*.s”

只能找到两个 .s 文件？

./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/sparcinterloc.s
./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/hpitinterlock.s

我们是否仍然需要先转换它？

@benpye https://github.com/benpye我可以做的足够小
任务？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/dotnet/coreclr/issues/969#issuecomment -241779501，或者静音
线程
https://github.com/notifications/unsubscribe-auth/AAbA_-1MBcwd8ghAilgBbOqE78y-mgieks5qixacgaJpZM4EU3NU
.

哦我只是在转换vm层，PAL中也有汇编代码！ 祝我好运.. ：（

你有什么关于 MIPS 支持的好消息吗？

有什么新进展吗？

关于 MIPS 支持的任何更新？
我需要它在 MIPS 24Kc 处理器上运行

关于 MIPS 支持的任何更新？

@myFirstway @ievdokdm我正在开发一个项目（在早期阶段）以更快地解决此类问题： https :

我现在可以在 MIPS 上编译，但运行时需要做更多的工作才能通用。

即将为我们的嵌入式应用程序使用 .Net Core，但这是一个障碍。 在 ARM32 和很快的 ARM64 之上，我们需要 MIPS 支持，而且这种要求似乎不会很快改变。 Go 和 Rust 确实支持 MIPS。

关于 MIPS 支持的任何更新？

关于 MIPS 支持的任何更新？

Microsoft 当前没有支持 MIPS 的计划或正在进行的工作。 当然，我们愿意酌情接受外部对这一目标的贡献。 请注意，将 .NET Core 移植到新平台当然需要大量工作。

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

@theaoqi仅供参考，master 分支使用 GCC 和 Clang 构建，而release/2.1仅使用 Clang 构建。 我正在使用 master 进行 SmartOS (Solaris) amd64 端口工作。 :)

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

有发布计划吗？

@theaoqi仅供参考，master 分支使用 GCC 和 Clang 构建，而 release/2.1 仅使用 Clang 构建。 我正在使用 master 进行 SmartOS (Solaris) amd64 端口工作。 :)

谢谢！ 我不知道，会考虑这个:)

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

有发布计划吗？

还没有。 虽然我们有一些将 OpenJDK 移植到 MIPS64 的经验，但我们对 .NET 并不熟悉。 这是一项巨大的工作，我现在无法给出计划。

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

建议根据最新版本执行此操作。

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

谢谢你的好消息。
我们想在 MIPS64（龙芯）上运行 .netcore 应用程序。
希望支持最新版本（9月发布3.0）。
期待你的好消息。

我们（龙芯）正在尝试将 .NET Core（现在为 2.1，然后将更新为 master）移植到 MIPS64，并且最近刚刚开始这项工作。 @liujianm @ibbcall

有发布计划吗？

还没有。 虽然我们有一些将 OpenJDK 移植到 MIPS64 的经验，但我们对 .NET 并不熟悉。 这是一项巨大的工作，我现在无法给出计划。

现在有什么进展？

期待看到 .Net Core 在龙芯上运行！ @theaoqi你能分享一下进展吗？

代码库升级到 3.0。 Hello World 和 coreclr 中的多项测试现在可以在 MIPS64 上运行。 @kchanlee @myFirstway @liujianm

@theaoqi看来您没有将与 MIPS 相关的更改推送回 GitHub（或者至少没有推送回 master）？

你是在使用解释器，还是在移植 RyuJIT？

在 coreclr 存储库中是否记录了整体 MIPS 移植计划？

请注意此处描述的存储库整合计划： https :

@theaoqi看来您没有将与 MIPS 相关的更改推送回 GitHub（或者至少没有推送回 master）？

还没有打开源:(

你是在使用解释器，还是在移植 RyuJIT？

我们跳过了解释器，现在正在移植 JIT。 我们发现解释器即使在 x86 上也不能很好地工作。

在 coreclr 存储库中是否记录了整体 MIPS 移植计划？

不。

请注意此处描述的存储库整合计划：dotnet/coreclr#27549

非常感谢你提供的信息。 我将继续关注这个问题。 我们计划发布 3.x（可能是 3.1）然后赶上大师。 对于 3.x，存储库合并不会影响我们，对吗？

对于 3.x，存储库合并不会影响我们，对吗？

没错。 已发布的产品和服务分支将保持原样。

我们跳过了解释器，现在正在移植 JIT。 我们发现解释器即使在 x86 上也不能很好地工作。

有趣的。 我们过去发现，使用解释器可以让我们更快地构建架构，或者至少可以让人们并行工作，因此每个人都不会等待 JIT 端口取得进展。 确实，我们最近没有保留解释器的构建和测试，所以它可能已经降级了。 在某一时刻，它会成功运行超过 95% 的外环测试。

我们跳过了解释器，现在正在移植 JIT。 我们发现解释器即使在 x86 上也不能很好地工作。

有趣的。 我们过去发现，使用解释器可以让我们更快地构建架构，或者至少可以让人们并行工作，因此每个人都不会等待 JIT 端口取得进展。 确实，我们最近没有保留解释器的构建和测试，所以它可能已经降级了。 在某一时刻，它会成功运行超过 95% 的外环测试。

随着我们对 coreclr 和代码质量的了解越来越多，也许我们应该再次对解释器进行一些研究和测试。 纯口译员应该工作吗？ 或者它必须是解释器和 jit 混合的？ @xiangzhai可能会提供更多详细信息。

纯口译员应该工作吗？

这应该。 但是，目前还没有进行积极测试，所以我不知道需要修复多少“位腐烂”。

在启动期间，您确实需要设置一些变量，例如：

COMPlus_InterpreterDoLoopMethods=1   // allow the interpreter to run on functions with loops
COMPlus_GCgen0size=9999999 // prevent the GC from running very often; useful for bring-up

检查 src\inc\clrconfigvalues.h 中的其他COMPlus_Interpret*变量——其他一些变量可能是必要的或有用的。

嗨@BruceForstall

请查看此问题https://github.com/dotnet/coreclr/issues/24824关于完全禁用 JIT。

谢谢，
翟国丽

\cc @乔万科

目前进展如何？我很快就会有一个 MIPS 服务器，我需要运行 .NET Core 程序。

目前进展如何？我很快就会有一个 MIPS 服务器，我需要运行 .NET Core 程序。

请参阅https://github.com/dotnet/coreclr/issues/969#issuecomment -550129085

@theaoqi 情况如何？ 是否可以开发和部署项目？ 有什么进展和计划吗？ 你也可以提供你的电子邮件吗？ 我的账户信息有我的邮箱

@theaoqi 情况如何？

我们仍在研究 MIPS 端口。 coreclr 中超过 9000 次测试通过了 MIPS（总共接近 9700 次）。 我们目前的主要问题是 GC 和其他一些问题。 接下来我们将使用各种COMPlus_*参数做更多的测试，并会尝试一些其他的测试，比如corefx中的测试。 我们的代码库目前是 3.0。 我们计划先发布 3.1（3.0 可能会被跳过），然后在 dotnet/runtime 中赶上 master。

是否可以开发和部署项目？

你是说 .NET Core 应用程序吗？ 我想是的。 我们希望今年发布 .NET Core MIPS 端口，但我不能保证。 在 GA 版本之前，我们可能会发布一些 EA 版本或 RC 进行测试。

有什么进展和计划吗？

正如刚才提到的。 但是，我们希望听取意见和建议，计划可能会有所变化。

你也可以提供你的电子邮件吗？ 我的账户信息有我的邮箱

[email protected]

谢谢。

你好，

FlightFinder示例现在只能用于 MIPS64 :)

# CoreFX && AspNetCore ALLIN1
export CORE_LIBRARIES=/home/loongson/corefx-3.1-Linux.mips64.Debug
# Optimization Disabled
export COMPlus_JITMinOpts=1
./bin/Product/Linux.mips64.Release/corerun /home/loongson/aspnet-samples/samples/aspnetcore/blazor/FlightFinder/FlightFinder.Server/bin/Debug/netcoreapp3.1/FlightFinder.Server.dll --urls http://10.2.5.91:5000

干杯! 🍷 @theaoqi @QiaoVanke @jkotas @BruceForstall @janvorli

我们需要一些比FlightFinder复杂得多的开源 aspnet 项目或示例来测试 MIPS64 的 CoreCLR。

谢谢，
翟国丽

@香斋恭喜你取得了良好的进展！

您是否有计划将您的工作开源并将其合并回master分支？

嗨@BruceForstall

是的，我们会尽快开源！ 我们将迁移到 5.x（主）分支。

干杯，
翟国丽

嗨@BruceForstall

您是否有计划将您的工作开源并将其合并回master分支？

尝试迁移到 5.x（主）分支时存在一个小问题。 请检查一下。

谢谢，
翟国丽

嗨@BruceForstall

我发现 LLDB+诊断通常用于寻找GC问题，但我不知道为什么 LLDB 为 ARM64 和 MIPS64 挂起https://github.com/dotnet/runtime/issues/37405请给我一些提示。

谢谢，
翟国丽

我们很高兴地宣布，我们的 CoreCLR MIPS64 端口已经开源。 #38069

@theaoqi这是一个伟大的时刻。 恭喜进步！

MIPS64 端口的早期访问 (EA) 版本已发布。 随时提供任何反馈。

这是 MIPS64-only 端口还是 MIPS32 也支持？

这是 MIPS64-only 端口还是 MIPS32 也支持？

仅 MIPS64R2

@lmcdougald只是好奇，截至今天，您想到的典型/目标 MIPS32 解决方案/平台/CPU 是什么？

也许由于它的内核有多旧，它是不现实的，但是我有一个 Imagination Technology Creator CI20，我最近没有使用过它，我很乐意在其上构建和测试我的代码/应用程序。 它可能是美国最常见的 MIPS 开发板。 据我所知，它从未被上游化并使用内核 3.18，因此除非有人们关心的其他 MIPS32 目标，否则不完全值得移植。

鉴于原始问题的时间（大约在 CI20 发布后一个月），这可能也是原始海报的董事会。

@lmcdougald 非常感谢您的详细回答。 我同意你的看法。 我相信，如果当前流行的硬件很容易上手，社区会愿意进行移植。 在 MIPS32（如“哪个”板）明确之前，我想现在需要休息一下。 另一个想法，对于可能对随机时间空间感兴趣的人，使用 MIPS64R2 端口作为基础可能会有所帮助，必须有很多共同点。

需要说明的是，获得 Creator CI20 仍然很容易。 ImgTech 真的认为他们会在智能手机和平板电脑方面与 ARM 竞争，并生产了大量这样的板。 新 CI20 板的购买价格略高于 MSRP。 然而，自从 MIPS 和 ImgTech 分道扬镳以来，MIPS32 平台除了在消费领域的新颖性之外，再没有引人入胜的故事。

一些特斯拉汽车使用 MIPS。 很长一段时间以来，它不仅仅是一种新奇事物。
我不认为运行时应该很难移植，除非他们像 .NET JIT 那样尝试重新发明轮子，而不是使用 LLVM。 遗憾的是，当 .NET Core 开始时，它并不是基于像 LLVM 这样已经存在多年的更可移植的 asm 代码生成器。 更不用说这对 AOT 来说有多好。

.NET IL 比 LLVM 存在的时间更长，所以这是一个非常奇怪的批评。

消费级 MIPS32 处理器是一种新奇事物。 除了几款平板电脑（可能还有一两部销量不佳的手机）与 CI20 板几乎同时发货，他们已经多年没有推出任何通用计算产品了。 这使它们成为消费领域的新奇事物。 有大量的汽车平台具有非常模糊的硬件和软件。

从它的声音来看，MIPS64 端口即将完成。 如果有任何新的消费产品使用 MIPS，他们希望会使用 MIPS64。

@zezba9000曾尝试使用 llvm 作为 .net 核心的 aot 后端。 该项目被称为 LLILC。 显然，LLVM 需要进行太多更改才能正常工作或类似的事情。

但更重要的是，LLVM 造成了较差的 JIT，因为它在生成代码方面表现相对较差，并且 JIT 支持不被视为 LLVM 的主要用例。

@lmcdougald哈哈，这是一个很好的观点。

我只是在发泄，但...

@lmcdougald “.NET IL 比 LLVM 存在的时间更长，所以这是一个非常奇怪的批评。”
-- 这与 IL 无关，而是来自该 IL 的汇编代码生成（您几乎可以用任何东西来做到这一点）。 LLVM 的存在时间比 .NET Core 的要长得多。

“消费者 MIPS32 处理器是一种新奇事物。”
-- 我知道 MS 只关心他们只关心的东西..（毫无意义地重新发明轮子是.NET 世界中的一种模式，它让很多人感到沮丧，而不仅仅是我）。 我认为这是第 1 天的设计缺陷，因为它显然要求人们重新发明很多 LLVM 已经根据我所知道的已经做得更好的东西。

@JakeSays “该项目被称为 LLILC。显然 LLVM 需要进行太多更改才能正常工作或类似的东西。”
-- 重点是 .NET Core 应该从 LLVM IMO 开始，那么这不会成为问题，AOT 会好得多，这一直是 .NET 多年来的一个大问题。

“但更重要的是，LLVM 造成了糟糕的 JIT”
-- 然后改进 LLV​​M 而不是重新创建一个更糟糕的版本。 浪费了那么多时间。

@zezba9000微软已经拥有出色的 JIT 技术——切换到 LLVM 将重新发明轮子。 .net core 不是一个全新的项目。 它基于现有的运行时（实际上是 Silverlight clr），以及现有的 JIT 等。

您可以在此处阅读 LLILC 项目历程和挑战： https :

微软放弃 JIT64 是有原因的。 它基于 VC++ 优化编译器后端，与使用 LLVM 的方式类似。 如果他们不能“修复”他们自己的产品，那么说“只修复 LLVM”也行不通。

@JakeSays .NET 运行时的原始 CF 分支支持 MIPS、SPARC、ARM、PPC（我认为）、big-endian 等。Silverlight 是 CF 的一个分支......一切都是一个分支，而不仅仅是改进一个运行时、平台和独立的 UI 框架哈哈（Mono 完成了 MS 被迫接受的所有工作）。 MS 花了 10 到 15 年的时间才最终意识到没有其他人像他们一样这样做。 有时我只是想把我的头发拉出来，想一想 MS 这么长时间以来一直否认 Mono 的相关性。 设计一个运行时来只解决短期问题会让你陷入困境……Mono 理解的东西。 要是 MS 在 10 年前支持它就好了……

@BruceForstall “但是 LLVM 仍然缺少 .NET 代码生成的许多基础知识。”
-- 那么为什么 Mono 在 JIT 和 AOT 中支持它呢？

@zezba9000微软开发产品以满足客户在特定时间点的需求。 您抱怨的每个运行时分叉在不同时间都满足了不同的需求。 此外，您不能假设它们是叉子。 它们很可能都来自相同的代码库，只是针对不同的用例构建不同（只需查找 FEATURE_* 定义）。 .net core 完全有可能是第一个真正的分支。

Mono 是 .net 的一个完全不同的实现。 它有不同的目标等。此外，mono 需要很长时间才能获得 llvm 支持才能可靠地运行。

@reflectronic再一次，MS 使 .NET Native（一个疯狂的快速 AOT）但等待！ 没错，它基于 VC++ 后端而不是 LLVM。 它不仅不能在 Windows 上运行，而且只支持 WinRT LOL。 这种解决事情的策略好像一切都是短期问题，仅在 Windows 生态系统中相关，MS 认为在当时的某些狭隘的现金掠夺愿景中相关，在这一点上是非常令人沮丧的。

与此同时，我只是看着所有其他 AOT lang 能够在几周或几个月内瞄准几乎任何新事物，这令人难过。

@zezba9000命名一个运行时环境，该环境已在一个月内重新定位并准备好投入生产。

@JakeSays Nim，Rust langs。 那些编译为 C89 和 LLVM。
便携和快速。

@zezba9000您还需要考虑时间表。 .net native 早在 llvm 可用作可靠的 jit 平台之前就已经开发出来了，因为 jit 从来都不是 llvm 的优先事项。 事实上，这是 Lattner 的实验结果，只是为了看看它是否有效。

您对 llvm 和 microsoft 的 jit/aot 解决方案的比较无效。

@zezba9000这些语言是

@JakeSays “.net native 早在 llvm 可用作可靠的 jit 平台之前就开发了”
——这句话没有任何意义。 .NET Native 是 AOT，没有 JIT。 LLVM 在 .NET Native 出现之前就已经存在了。

同样，用于 JIT 参数的 LLVM 仅适用于 .NET Core……Mono 甚至支持它，所以不要告诉我它不可能。 它更可能是经过验证的，并且是 .NET AOT 解决方案的基础。

无论如何，喜欢 C# 只是讨厌多年来承诺它的运行时和 UI 噩梦。

@zezba9000 llilc 项目证明 llvm 不是 .net 核心的可行解决方案。 llvm 所需的更改是巨大的。

我从来没有说过这是不可能的——只是说它没有意义。

请原谅我使用 jit 而不是 aot，但是使用 llvm 它们是一样的。 我从 v1.8 开始就一直在使用 llvm，我可以告诉你，将它用作 aot 编译器比将它用作编译器（c/c++ 等）的静态后端要复杂得多。

.NET CF 有一个“愚蠢的 JIT”。 它基本上是一组直接从 IL 翻译的预定代码块，没有额外的传递。 将这样的东西用于服务器级应用程序将是一场性能灾难。 Silverlight 在某个时候从 .NET Framework 获得了 JIT 及其所有优化。

Mono 支持 LLVM，但它有一些怪癖。 它使用保守的 GC，并不能正确支持所有异常行为。 像这样的问题对于需要 Mono 的地方来说是可以的，但对于 CoreCLR 的目的来说还不够通用。 这仍然忽略了它对（完全有效的）JIT 场景造成的吞吐量问题。

mono MIPS32 O32 ABI刚好可以工作。