为什么字节码编程不如汇编编程那么流行或盛行？
您可以在互联网上看到汇编代码和汇编编码器，但字节码上几乎没有任何内容。这是为什么 ？汇编编程的需求和优点也适用于字节码编程。
You see assembly code and assembly coders all over the internet but there's almost nothing on bytecode. Why is that ? The needs and the advantages of programming in assembly should all hold for programming in bytecode too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
字节码编程远不如汇编编程流行/常见的另一个原因是字节码的通用性——它的简单性。
字节码指令集主要是“ultra-RISC”，非常简单的指令。设计有两个目的，为虚拟机提供快速翻译/映射为本机指令集的能力，并允许高级编译器轻松创建接近本机的字节码。
另一方面，汇编器也有这样简单的通用部分 - 这些是字节码解释器/即时编译器实际用来实现字节码功能的部分。很少有人专门使用本机指令集的这些部分来编写汇编程序。 （即时）编译器会为您完成这项工作。
但汇编程序的功能远不止这些，尤其是 SIMD/向量指令。这些指令对于非常特殊的工作负载（最广泛意义上的“数据流” - 任何像德古拉（dracula）通过女士喉咙一样搅动数据的东西）来说都是专用且高效的。迄今为止，在某些情况下，一些人为干预可能会超出编译器结果几个数量级。这样做通常需要使用此类向量指令，以一种编译器可能不会被迫为您执行的特定方式。
付出的代价是必须编写本机汇编函数。
字节码缺乏这些特殊用途的指令扩展，并且像这样扩展字节码将首先失去字节码的最大优势之一。这将使其无法在 CPU 类型之间移植 - 例如，x86/x64 (SSEx)、ARM (Neon) 或 PowerPC (AltiVec) 的矢量扩展差异太大，无法在顶部映射单个垫片层。
就教学汇编级编程而言，不需要实际的 CPU 指令集；而是需要实际的 CPU 指令集。 Donald Knuth 在《计算机编程的艺术》中使用了名为 MIX/MMIX 的“虚拟”汇编器很长时间，以至于它比“字节码”一词的出现还要早几十年。可以通过 x86 汇编语言教授的概念也可以通过 .NET 字节码教授。
但是人们编写汇编语言的主要原因（学术界之外，请参阅上一段）——利用通过特殊指令集扩展实现的特定于平台的优化——并不是直接编写字节码的有效理由。
Another reason why bytecode programming is far less popular / common than assembly programming is the genericity of bytecode - its simplicity.
Bytecode instruction sets are largely "ultra-RISC", very simple instructions. Designed for two purposes, to provide the virtual machine with the ability to quickly translate / map into a native instruction set and to allow a high-level compiler to easily create near-native bytecode.
Assembler, on the other hand, also has such simple generic parts - and those are the ones that the bytecode interpreter / just-in-time compiler will actually use to implement bytecode functionality. Few people exclusively use these parts of a native instruction set to write assembler programs. The (Just-in-time-)compiler does that for you.
But assembler has much more than that, especially SIMD / vector instructions. These instructions are special-purpose and highly efficient for very particular workloads ("data streaming", in the widest sense - anything that churns through data like dracula through ladies' throats). To this date, there's situations where a bit of human intervention can surpass a compiler result by orders of magnitude. Doing so often requires the use of such vector instructions, in a particular way that the compiler may not be coerced into doing for you.
The price to pay is having to write a native assembly function.
Bytecode lacks these special-purpose instruction extensions, and extending bytecode like that would give away one of the largest advantages of having bytecode in the first place. It would make it unportable between CPU types - the vector extensions of, say, x86/x64 (SSEx), ARM (Neon) or PowerPC (AltiVec) are too different to map a single shim layer on top.
As far as teaching assembly-level programming goes, one doesn't need an actual CPU instruction set for that; Donald Knuth in "Art of Computer programming" has used a "virtual" assembler called MIX/MMIX for so long that it predates the existance of the word "bytecode" by a few decades. Concepts that one can teach via x86 assembly language one could also teach via .NET bytecode.
But the main reason (beyond academia, see prev paragraph) why people write assembly language - to exploit platform-specific optimizations made possible by special instruction set extensions - is not a valid reason to write bytecode directly.
大多数字节码（无论如何我见过的所有字节码）都被设计为易于编译的目标。使用 x86（例如），您可以通过手写汇编获得相当多的收益，因为编译起来非常痛苦。编译 Java 字节码（例如）要容易得多，因此手工编写它们的收益往往相对较小。
.NET 使编写生成和使用其 IL 的程序变得更容易，因此它往往会发生更多一些，尽管说实话，我看到的大多数示例在我看来几乎都完成了，因为它在那里是因为它确实有必要。
Most bytecodes (all of them I've seen, anyway) are designed to be an easy target to compile for. With x86 (for example) you can gain a fair amount with hand written assembly, because it's such a pain to compile for. It's much easier to compile for Java byte codes (for one example) so the gain from writing them by hand tends to be comparatively small.
.NET makes it a bit easier to write programs that generate and use its IL, so it tends to happen a bit more there, though in all honesty most of the examples I've seen looked to me like they were done almost as much because it was there as because it was really necessary.
我对您关于汇编编程流行的说法表示怀疑，但这不是重点。
答案很简单，“因为没有必要”。人工汇编语言旨在服务于其设计语言的需求，并且与它们而不是硬件有非常密切的关系。使用它们可以做的事情，用高级语言可以轻松实现。
I have doubts about your claims of popularity of programming in assembly, but that's besides the point.
The answer is simply "because there isn't any need to". Artificial assembly languages are designed to service the need of the language for which they are designed, and have a very close relationship with them rather than hardware. There's not much than can be done with them that can't just as easily be achieved in the higher-level language.
汇编语言流行但不适用于字节码的另一个原因是，有时您需要使用汇编语言（例如：在编写操作系统的某些依赖于 CPU 的部分时）。
Another reason for the popularity of assembly that does not apply to bytecode, is that sometime you need to use assembly (e.g: when writing certain CPU-dependant portions of an OS).