作者认为Solidity中内联汇编和高级代码的区分是一个错误，它限制了语言特性，使得编码变得繁琐。作者建议将底层功能直接作为内置函数暴露给高级语言，或者引入真正的内联汇编，而不是复制概念，从而优化开发者体验。
我真诚地认为，Solidity中内联汇编和“更高级别”代码之间的明确区分是一个错误。我看到在博客上的某些示例代码段中建议为solidity core也这样做。这就是为什么我想说明我的理由，说明为什么我认为这是一个错误，以及你应该努力实现的目标。
问题
在两个作用域之间隔离语言特性会给双方带来限制，这使得编码变得不必要的麻烦，和/或需要语言本身复制概念以使其符合人体工程学，例如：
- 定义、导出、导入和调用函数的能力
- 控制流结构（if-else-if条件链、switch、for循环、while循环、do-while等）
- 通过结构体、自定义类型和关联方法（通过
using）创建数据抽象的能力
- 访问底层不安全内存操作
- 静态类型
- 访问非 uint256 常量
此外，由于这些差异，跨越边界变得很麻烦，因为你必须考虑并处理不同的语义（所有变量都是u256，而不是类型化的）。
为什么没有必要
你无法使用高级solidity执行的主要操作，而需要使用内联汇编的操作包括：
- 底层内存控制
- switch控制流语句
- 直接访问某些EVM操作码/功能（例如，原始
tstore，tload，byte操作码，log0-log4等）
- 一般优化
所有这些功能都可以并且将极大地受益于直接从高级语言公开为内置函数。 这就是其他主流系统编程语言（如C、Rust或Zig）所做的事情。 接近硬件底层的原始操作主要通过高级包装器公开和访问。
对于优化，开发人员通常所做的大多数事情都是高级语言已经提供但执行效果不佳的事情：
用户通常执行的优化应该直接合并到编译器中，因为这些优化通常遵循一个非常规则的模式。 对于其他优化，添加不安全转换并允许你直接对布尔值执行算术和/或逻辑运算（例如，非分支按位或）涵盖了另一大部分常见的优化。
你甚至可以借鉴Rust的unsafe设计概念：一个简单的函数着色系统，让开发人员专门指定边界，在这些边界上必须手动维护核心编译器不变性，或者只是作为棘手的底层代码的一般约定。
为什么其他语言有内联汇编
“如果其他主流语言有内联汇编，为什么Solidity不应该有？”
我的观点是，Solidity的内联汇编不具有可比性。 其他语言中的内联汇编让你可以在很大程度上绕过编译器，并直接手写将包含在最终二进制文件中的指令。 这带来了很大的DX权衡，但可以让你在需要时真正控制一切。 Solidity的内联汇编没有给你这种能力。 它为你提供了更低级别的访问权限，但不足以让你：
- 用跳转编写自己的控制流
- 管理堆栈
- 准确选择最终编译器将生成的算术/逻辑指令
- 包含编译器尚未识别的指令字节
但是，这并不意味着Solidity不能或不应该拥有“真正的”内联汇编，我只是认为当前的方法不是最佳的，应该完全放弃或在新的编译器中进行重新设计。
结论
当前形式的内联汇编提供了次优的开发人员体验，并通过复制概念来膨胀编译器。 Solidity Core应该利用其从头开始的授权，要么完全弃用内联汇编，将更低级别的功能提升到内置函数中，要么引入真正的内联汇编。
