Actually you can build large scale programs in a large model mode segaments may be restricted to 64kb code but you can write many segaments, people give the argument against ASM as it is an old language and we don't need to preserve memory anymore, If that were the case why would we be packing our PC's with memory, the only Flaw I can find with ASM is that it is more or less Processor based so most programs written for the intel architecture Most likely would not run on An AMD Architecture. As for C being faster than ASM there is no language faster than ASM and ASM can do many thing's C and other HLL's can not do at processor level. ASM is a difficult language to learn but once you learn it no HLL can translate it better than you. If you could only see some of the things HLL's Do to you code, and understand what it is doing, you would wonder why More people don't use ASM and why assembers are no longer being updated ( For general public use anyway). So no C is not faster than ASM. Even experiences C++ programmers still use and write code Chunks in ASM added to there C++ code for speed. Other Languages Also that some people think are obsolete or possibly no good is a myth at times for instance Photoshop is written in Pascal/ASM 1st release of souce has been submitted to the technical history museum, and paintshop pro is written still written in Python,TCL and ASM ... a common denominator of these to "Fast and Great image processors is ASM, although photoshop may have Upgraded to delphi now it is still pascal. and any speed problems are comming from pascal but this is because we like the way programs look and not what they do now days. I would like to make a Photoshop Clone in pure ASM which I have been working on and its comming along rather well. not code,interpret,arange,rewwrite,etc.... Just code and go process complete.

这很难具体地回答，因为这个问题非常不具体:到底什么是“现代编译器”?

理论上，几乎任何手动的汇编器优化都可以由编译器来完成——实际上它是否已经完成，不能笼统地说，只能说特定编译器的特定版本。许多可能需要花费大量的精力来确定它们是否可以在特定的上下文中应用而不产生副作用，以至于编译器编写者不会为它们烦恼。

在我的工作中，有三个原因让我了解和使用组装。按重要性排序:

Debugging - I often get library code that has bugs or incomplete documentation. I figure out what it's doing by stepping in at the assembly level. I have to do this about once a week. I also use it as a tool to debug problems in which my eyes don't spot the idiomatic error in C/C++/C#. Looking at the assembly gets past that. Optimizing - the compiler does fairly well in optimizing, but I play in a different ballpark than most. I write image processing code that usually starts with code that looks like this: for (int y=0; y < imageHeight; y++) { for (int x=0; x < imageWidth; x++) { // do something } } the "do something part" typically happens on the order of several million times (ie, between 3 and 30). By scraping cycles in that "do something" phase, the performance gains are hugely magnified. I don't usually start there - I usually start by writing the code to work first, then do my best to refactor the C to be naturally better (better algorithm, less load in the loop etc). I usually need to read assembly to see what's going on and rarely need to write it. I do this maybe every two or three months. doing something the language won't let me. These include - getting the processor architecture and specific processor features, accessing flags not in the CPU (man, I really wish C gave you access to the carry flag), etc. I do this maybe once a year or two years.

这完全取决于你的工作量。

对于日常操作，C和c++已经很好了，但是有一些特定的工作负载(任何涉及视频的转换(压缩、解压缩、图像效果等))几乎需要组装才能达到性能。

它们通常还涉及使用特定于CPU的芯片组扩展(MME/MMX/SSE/等等)，这些扩展是为这些类型的操作而优化的。

只要有合适的程序员，汇编程序总是可以比C程序快(至少稍微快一点)。如果不能从汇编器中取出至少一条指令，则很难创建一个C程序。

在历史上插话。

当我还年轻的时候(20世纪70年代)，根据我的经验，汇编是很重要的，更重要的是代码的大小，而不是代码的速度。

如果一个高级语言的模块是1300字节的代码，但该模块的汇编版本是300字节，那么当您试图将应用程序装入16K或32K的内存时，这1K字节就非常重要。

那时候编译器还不是很好。

在老式的Fortran中

X = (Y - Z)
IF (X .LT. 0) THEN
 ... do something
ENDIF

当时的编译器在X上执行了一个SUBTRACT指令，然后是一个TEST指令。 在汇编程序中，您只需在减法之后检查条件代码(LT零，零，GT零)。

对于现代系统和编译器来说，这些都不是问题。

我认为理解编译器在做什么仍然很重要。 当您使用高级语言编写代码时，您应该了解什么允许或阻止编译器执行循环展开。

当编译器执行“类似分支”的操作时，使用管道内衬和包含条件的前瞻计算。

当执行高级语言不允许的事情时，仍然需要汇编程序，比如读取或写入处理器特定的寄存器。

但在很大程度上，普通程序员不再需要它，除非对代码如何编译和执行有基本的了解。