Editing Assembly language (section)

===Current usage===
There has been debate over the usefulness and performance of assembly language relative to high-level languages.<ref name="Kauler_1997" />

Although assembly language has specific niche uses where it is important (see below), there are other tools for optimization.<ref name="Hsieh_2020"/>

{{As of|2017|07}}, the [[TIOBE index]] of programming language popularity ranks assembly language at 11, ahead of [[Visual Basic]], for example.<ref name="tiobe"/> Assembler can be used to optimize for speed or optimize for size. In the case of speed optimization, modern [[optimizing compiler]]s are claimed<ref name="Rusling_2012"/> to render high-level languages into code that can run as fast as hand-written assembly, despite some counter-examples.<ref name="Markoff_2005"/><ref name="bit-field"/><ref name="gcc-mess"/> The complexity of modern processors and memory sub-systems makes effective optimization increasingly difficult for compilers and assembly programmers alike.<ref name="Hyde_2008"/><ref name="compiler-fails1"/> Increasing processor performance has meant that most CPUs sit idle most of the time,<ref name="Click_2014"/> with delays caused by predictable bottlenecks such as cache misses, [[Input/output|I/O]] operations and [[Memory paging|paging]], making raw code execution speed a non-issue for many programmers.

There are still certain computer programming domains in which the use of assembly programming is more common:

* Writing code for systems with {{Clarify|date=June 2021|reason=Does this refer only to microprocessors or also to midrange and mainframe systems?|text=older processors}} that have limited high-level language options such as the [[Atari 2600]], [[Commodore 64]], and [[graphing calculator]]s.<ref name="Fargo_2008"/> Programs for these computers of the 1970s and 1980s are often written in the context of [[demoscene]] or [[retrogaming]] subcultures.
* Code that must interact directly with the hardware, for example in [[device driver]]s and [[interrupt handler]]s.
* In an embedded processor or [[Digital Signal Processor|DSP]], high-repetition interrupts require the shortest number of cycles per interrupt, such as an interrupt that occurs 1000 or 10000 times a second.
* Programs that need to use processor-specific instructions not implemented in a compiler. A common example is the [[circular shift|bitwise rotation]] instruction at the core of many encryption algorithms, as well as querying the parity of a byte or the 4-bit carry of an addition.
* Stand-alone executables that are required to execute without recourse to the [[run-time system|run-time]] components or [[library (computing)|libraries]] associated with a high-level language, such as the firmware for telephones, automobile fuel and ignition systems, air-conditioning control systems,and security systems.
* Programs with performance-sensitive inner loops, where assembly language provides optimization opportunities that are difficult to achieve in a high-level language. For example, [[linear algebra]] with [[Basic Linear Algebra Subprograms|BLAS]]<ref name="Markoff_2005"/><ref name="BLAS_2008"/> or [[Discrete cosine transform|discrete cosine transformation]] (e.g. [[Single instruction, multiple data|SIMD]] assembly version from [[x264]]<ref name="Videolan_2010"/>).
* Programs that create vectorized functions for programs in higher-level languages such as C.  In the higher-level language this is sometimes aided by compiler [[intrinsic function]]s which map directly to SIMD mnemonics, but nevertheless result in a one-to-one assembly conversion specific for the given vector processor.
* [[Real-time computing|Real-time]] programs such as simulations, flight navigation systems, and medical equipment. For example, in a [[fly-by-wire]] system, telemetry must be interpreted and acted upon within strict time constraints. Such systems must eliminate sources of unpredictable delays, which may be created by interpreted languages, automatic [[garbage collection (computer science)|garbage collection]], paging operations, or [[preemptive multitasking]]. Choosing assembly or [[low-level programming language|lower-level languages]] for such systems gives programmers greater visibility and control over processing details.
* Cryptographic algorithms that must always take strictly the same time to execute, preventing [[timing attack]]s.
* Video encoders and decoders such as rav1e (an encoder for [[AV1]])<ref>{{cite web |url=https://github.com/xiph/rav1e/blob/v0.6.3/README.md#features-1= |title=rav1e/README.md at v0.6.3 |website=[[GitHub]] |access-date=21 February 2023 |archive-date=22 February 2023 |archive-url=https://web.archive.org/web/20230222005925/https://github.com/xiph/rav1e/blob/v0.6.3/README.md |url-status=live}}</ref> and dav1d (the reference decoder for AV1)<ref>{{cite web |url=https://code.videolan.org/videolan/dav1d/-/blob/1.1.0/README.md |title=README.md · 1.1.0 · VideoLAN / dav1d |date=13 February 2023 |access-date=21 February 2023 |archive-date=22 February 2023 |archive-url=https://web.archive.org/web/20230222004317/https://code.videolan.org/videolan/dav1d/-/blob/1.1.0/README.md |url-status=live}}</ref> contain assembly to leverage [[AVX2]] and [[Neon (instruction set)|ARM Neon]] instructions when available.
* Modify and extend legacy code written for IBM mainframe computers.<ref name="Bosworth_2016"/><ref>{{cite web |url=https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236852/$file/idad500_v2r3.pdf |title=z/OS Version 2 Release 3 DFSMS Macro Instructions for Data Sets |publisher=IBM |date=15 February 2019 |access-date=14 September 2021 |url-status=live|archive-url=https://web.archive.org/web/20210625140314/https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236852/$file/idad500_v2r3.pdf |archive-date=25 June 2021 }}</ref>
* Situations where complete control over the environment is required, in extremely high-security situations where [[Trusting trust#Reflections on Trusting Trust|nothing can be taken for granted]].
* [[Computer virus]]es, [[bootloader]]s, certain [[device driver]]s, or other items very close to the hardware or low-level operating system.
* [[Instruction set simulator]]s for monitoring, tracing and [[debugging]] where additional overhead is kept to a minimum.
* Situations where no high-level language exists, on a new or specialized processor for which no [[cross compiler]] is available.
* [[Reverse engineering]] and modifying program files such as:
** existing [[binary file|binaries]] that may or may not have originally been written in a high-level language, for example when trying to recreate programs for which source code is not available or has been lost, or cracking copy protection of proprietary software.
** [[Video game]]s (also termed [[ROM hacking]]), which is possible via several methods. The most widely employed method is altering program code at the assembly language level.

Assembly language is still taught in most [[computer science]] and [[electronic engineering]] programs. Although few programmers today regularly work with assembly language as a tool, the underlying concepts remain important. Such fundamental topics as [[binary arithmetic]], [[memory management|memory allocation]], [[Stack (abstract data type)|stack processing]], [[character set]] encoding, [[interrupt]] processing, and [[compiler]] design would be hard to study in detail without a grasp of how a computer operates at the hardware level. Since a computer's behaviour is fundamentally defined by its instruction set, the logical way to learn such concepts is to study an assembly language. Most modern computers have similar instruction sets. Therefore, studying a single assembly language is sufficient to learn the basic concepts, recognize situations where the use of assembly language might be appropriate, and to see how efficient executable code can be created from high-level languages.<ref name="Hyde_2003"/>