专业使用汇编语言在嵌入式世界中相当普遍。我们周围有很多微控制器做简单但有用的事情的应用。例如，看看tinyAVR family of microcontrollers from Atmel，特别是ATtiny13，它的程序内存小得可笑，只有1kB，除了32个8位CPU寄存器之外根本没有RAM。这很神奇，这些芯片是什么capable of。大量购买时，这种芯片的成本约为1美元。因此，当您生产大量需要简单（甚至不太简单）逻辑的设备时，硬件生产成本的节省远远超过手工制作汇编代码以使其在极其有限的平台上工作的开销。

我有很多次需要在工作中编写asm代码，在C中你根本不能做某些事情（例如访问特殊的CPU寄存器或使用CPU的系统指令），或者编译的C代码太慢或太大（编译器不够好）。
尽管如此，asm代码的一小部分或花在编写它上的时间是相当微不足道的。
学习asm是很好的。它让你“看到”你的C代码，预测什么指令和它会变成多少指令，粗略估计部分代码的速度。在此过程中，您将学习许多优化和其他技巧以及一些很酷的算法/方法，然后你可以转移到你的C代码。只要看看那些关于C指针或二进制和十进制之间的数字转换或任意精确算术。了解asm有助于这些和其他事情。

到目前为止，我在2011年做了两次，我主要从事Java业务线应用程序的工作。在快速创建setup.exe来 Package JRE和应用程序安装时派上用场。本可以在C中完成，但是它比编译器更快地抓取和设置汇编器，对于这样一个简单的应用程序，编写时间是可比的..由于未知的原因通过JNA失败了，所以我用汇编语言编写它，以确保我知道每一位的去向和时间。

是的，我们仍然每天使用汇编语言编写代码。我们不会坐下来用汇编语言编写整个程序-我们只是提供汇编语言内核函数来加速高性能代码。
这是必要的，因为编译器想象的机器工作方式和他们实际工作的方式之间的差距越来越大。特别是对于现代系统，数据移动对性能的重要性远远超过计算。但编译器仍然植根于SpecInt很重要的时代，并且倾向于将数据移动视为逻辑上的无操作。
我们必须使用汇编语言而不是内部函数的最大原因是寄存器分配。编译器在寄存器阻塞方面很糟糕，或者理解哪些数据存储在哪些缓存中。对于编译器来说，所有缓存未命中都被认为是等价的，并且编译器通常不知道您如何动态使用数据或数据在哪里。
具有讽刺意味的是，即使没有寄存器阻塞，这就是为什么编译器很少实现SIMD性能优势，即使它们擅长发出SIMD代码进行计算-它们总是倾向于在“I/O”端搞砸事情-也就是说，当SIMD信息需要从内存中读取和写入时。
现在，如果你写的代码是声明式的而不是命令式的，也就是说，你的工作是指定要做什么，而不是如何去做，这就是编译器的目的，这是一个很好的匹配。
顺便说一下，有些人专注于使用C语言尽可能接近汇编语言的性能，由于可移植性的好处。他们使用的技巧的一个例子是他们限制一个函数只使用比机器上可用寄存器少的变量-这样，编译器就不会溢出任何变量，正确的寄存器分配是没有意义的。因为一切都只是停留在寄存器中。当这种类型的编码成为可能时，您可以实现75%-90%的汇编语言性能，尽管通常需要更高的功耗，因为发射的指令远远超过所需的指令。正如您所期望的那样，您使用的内核越多，数据密集型任务越多，C语言的性能就越落后于汇编语言。

尽管用汇编语言编写代码变得越来越少，但学习汇编语言只是为了了解底层的工作原理仍然是非常好的。现代C/C的优化编译器让你用C语言编写代码，转换成非常高质量的汇编指令，通常超过了您可以手动编写的内容，但代价是结果可读性较差（例如，通过插入空指令来优化CPU流水线的使用）。
如果你为一个新的体系结构、一个非常低级的库或一个有严格资源限制的嵌入式系统编写编译器，你可能需要使用汇编。对于其他一切，C和C都可以做得很好，甚至更好。

这是罕见的。我从来没有在23年以上的职业生涯。但我主要在客户端服务器数据库应用程序空间工作，有工作，你会使用它很多，或至少需要知道处理器实际上是如何工作的。
然而，这是我学到的第一件事，不算基本的数字电子产品，我想说学习对我的职业生涯和业余爱好编程有很大的帮助。

我本来打算写一篇很长的文章，但决定总结一下：
1.嵌入式代码、 Boot 加载程序、编译器后端
1.是的，它将帮助您理解和调试编译后的代码
1.我唯一一次在c中使用它是为了阅读真实的时间时钟寄存器