在程序集中完全编写操作系统有什么好处？
MenuetOS是完全用Assembly编写的操作系统的一个例子。 在Assembly中编写它而不是像C这样的低级编程语言有什么好处吗？
与操作系统的接口在编写的语言中往往是最简单的 – 在UNIX和Win32中使用C，在BeOS中使用C ++等.TartetetOS专门用于使开发组装应用程序变得容易，因此最好的选择是编写操作系统本身在集会中。
对于不打算用于通用目的的操作系统，例如嵌入式系统和微控制器，通过将C机械转换（即编译）到组件中而引入的开销是不可接受的。 编译器并不像人类那么聪明，特别是当涉及到嵌入式平台上需要的各种极少的优化时，直接编写汇编保证不会有编译器弄乱精心设计的算法。
大概你可以编写一个紧凑而快速的操作系统。 虽然你可能无法快速写出来，但你却失去了琐碎便携性的希望。
优化的assembly是您可以获得的最快速度。 即使是经过精心优化的C也会比精心制作的assembly速度慢得多。 但是，对于通用操作系统来说，收益并不值得。 在这个领域，我无法想象assembly操作系统的扩展性。 如果我记得，Menuet适用于非常小巧，简单的嵌入式系统，其中组装代码的复杂性增加超过了性能优势。
我想，考虑到我看过这个故事的地方数量，它给了他们很多好的公关。 声誉为您提供最好的工作……
主要优点： 您不需要C编译器 。 次要优势：如果你必须使代码大小真正，非常小，那么（a）现代编译器的目标是快速执行而不是小代码大小，（b）如果工件是伪造的，那么编写汇编代码的人为惩罚会更小小。
因此，如果你正在为一些新的嵌入式ISA做一些非常小的操作系统并且它都必须适合4K，那么在汇编中写入可能是一个不错的选择……
仍然有一群活跃的人群在集会中敲响了演示。 有些网站甚至为C64和Atari XL机器等8位点编码器进行了编码演示。 它只是“选择的武器”。 他们喜欢以这种格式编码。 并提供更高程度的控制，但需要更好地了解机器。 他们对机器的掌控能力以及在开销标准C libs所占用的内存中完成整个可执行文件的能力使他们获得了强烈的满足感。
无论编译器有多好，它仍然遵循生成代码的机制过程。 程序集几乎可以让您完全控制，允许您执行即使像C这样的语言也不易表示的事情。例如，“primefaces操作”通常由OS调用或函数调用包装，使得它们的效率大大降低，因为那里没有标准的方式用它自己的语言来表示它们。 （有时它们将由C的编译器内部扩展表示。）
此外，它允许完成非传统的事情，例如以C中不能使用处理器堆栈的方式。（因此在C中，您使用动态内存分配创建“堆栈”数据结构，以复制处理器本身可以执行的操作。）
大小wize，我见过全屏文本模式，文本编辑器需要少于512字节的可执行映像。 那是我从公告板上认识的那个人写的。 （之前的WWW时代。）我见过C启动代码占用了更多的内存！
我想只是性能和尺寸。
有人可以说 – 速度和小代码（通过小代码我当然不是指源代码，而是编译一个代码），至于第二个 – 可能是的，至于速度 – 我不知道差异有多大，假设你有一个体面的c编译器。 但是我可以给你一个很大的缺点 – 你不能将这样的操作系统移植到其他架构，在汇编程序中编写操作系统会将你绑定到一个并选择处理器架构。 与C.相比，我甚至不会提到你必须花时间编写这样的软件。
在这一点上，并不多，虽然它自然取决于您为操作系统编写的系统和资源。 几乎所有现代计算机都捆绑了一个C编译器，它基本上与你可以获得的机器一样接近，所以使用Assembly无济于事。 另一方面，如果您正在为机器人编写代码，那么Assembly将非常有用。