Appendix R: Assembly Language Assembly languages are available for virtually every make and model of computer hardware, and each specific type of hardware has its own assembly language. Some computer manufacturers have families of computers which use the same instruction set, and, therefore, they use the same assembly language. Otherwise, there is little in common from one assembly language to another. An assembly language is considered a 2GL because it is just one step up from the native language of the hardware, called machine language, which is a set of instructions in the form of combinations of ones and zeros. An assembly language provides an instruction mnemonic, usually three letters long, corresponding to each machine instruction. The letters used are usually abbreviations of a sort for what the instruction does. Hence, assembly languages make it easier for people to remember how to write instructions to the computer, but an assembly language is still a representation of the computer’s native instruction set. Since each different type of computer uses a different native instruction set, assembly languages cannot be standardized from one machine to another, and instructions from one computer cannot be expected to work on another. Language Criteria It is impossible to assess individual assembly languages, but the language characteristics vary little from one to another. The following assesses the category of assembly languages with respect to the language criteria presented in the Criteria for a Good Language section in the main document: Its definition should be independent of any particular hardware or operating system. Each assembly language is specific to a particular computer hardware architecture. Its definition should be standardized, and compiler implementations should comply with this standard. Assembly languages cannot be standardized because each type of computer has a different instruction set and, therefore, a different assembly language. It should support software engineering technology, discouraging or prohibiting poor practices, and promoting or supporting maintenance activities. Assembly languages provide no support for software engineering technology. They do not work with abstractions, just machine-level specifics. It should effectively support the application domain(s) of interest. Assembly languages support a particular hardware architecture, and, in general, they have no inherent relationship with any particular application domains. It should support the required level of system reliability and safety. Assembly languages provide no support for reliability or safety. The assembly language will not object to any form of programming, good or bad. Its compiler implementations should be commensurate with the current state of technology. In the sense that an assembler, the "compiler" for an assembly language, is created for each new assembly language as it is introduced, language implementations keep up with computer technology. However, in the sense of supporting the current level of software technology, assembly languages do not. Appropriate software engineering-based supporting tools and environments should be available. The tools available for working with assembly languages are typically other very low-level tools, and they do not provide software engineering support. Language Characteristics In this section, assembly languages are rated with respect to the language characteristics used in Table 2 in the main document. The given ratings are for this category of languages, rather than a specific language. The ratings range from 0 to 10, where 0 means the language provides no support for the characteristic, and 10 means it provides extensive support. The ratings given below are those provided in Table 2. The reader must bear in mind that the support for a good characteristic in a language does not necessarily mean that it is always used, or used appropriately. Unskilled programmers can write bad code in any language, but a good language facilitates the production of good code by skilled programmers. Clarity of source code – the extent to which inherent language features support source code that is readable and understandable and that clearly reflects the underlying logical structure of the program. The source code for an assembly language is cryptic and in a very low machine-specific form. Hence, it is error-prone, and the structure of the program is not evident. Rating: 1 Complexity management (architecture support) – the extent to which inherent language features support the management of system complexity, in terms of addressing issues of data, algorithm, interface, and architectural complexity. An assembly language provides minimal support for complexity management. Modern assembly languages have some algorithmic complexity management and limited structuring. Rating: 2 Concurrency support – the extent to which inherent language features support the construction of code with multiple threads of control (also known as parallel processing). An assembly language will often provide instructions for accomplishing multiple threads of control. However, such support is neither straightforward nor easy to use. Rating: 2 Distributed system support – the extent to which inherent language features support the construction of code to be distributed across multiple platforms on a network. An assembly language provides no specific support for distributed systems. Rating: 0 Maintainability – the extent to which inherent language features support the construction of code that can be readily modified to satisfy new requirements or to correct deficiencies. An assembly language provides no inherent support for maintainability. Rating: 0 Mixed language support – the extent to which inherent language features support interfacing to other languages. An assembly language provides no capability to interface to a higher level language (however, some high level languages provide a capability to interface with an assembly language). Rating: 0 Object-oriented programming support – the extent to which inherent language features support the construction of object-oriented code. An assembly language provides no object-oriented programming support. Rating: 0 Portability – the extent to which inherent language features support the transfer of a program from one hardware and/or software platform to another. An assembly language is not portable from one type of computer to another. At best, it can be portable to another computer within the same family of computers built by the same manufacturer. Rating: 1 Real-time support – the extent to which inherent language features support the construction of real-time systems. An assembly language inherently supports a streamlined version of code because it does not contain the inefficiencies of expression found in HOLs. This is often assumed to mean that an assembly language produces the best possible performance, but this is not the case. Today’s compiler technology benefits both from current technology improvements as well as from the experience of hundreds of language performance experts. Hence, compiler optimizers can often do a better job of streamlining code than a programmer can do using an assembly language [Lawlis 92]. Assembly languages are also inherently more difficult to use to accomplish streamlining. Rating: 5 Reliability – the extent to which inherent language features support the construction of components that can be expected to perform their intended functions in a satisfactory manner throughout the expected lifetime of the product. An assembly language provides no inherent support for reliability. Rating: 0 Reusability – the extent to which inherent language features support the adaptation of code for use in another application. Assembly languages provide very little opportunity for reuse. Rating: 1 Safety – the extent to which inherent language features support the construction of safety-critical systems, yielding systems that are fault-tolerant, fail-safe, or robust in the face of systemic failures. Assembly languages provide no inherent support for safety-critical systems, although they are often used in this domain. Rating: 0 Standardization – the extent to which the language definition has been formally standardized (by recognized bodies such as ANSI and ISO) and the extent to which it can be reasonably expected that this standard will be followed in a language translator. Assembly languages are not standardized. Rating: 0 Support for modern engineering methods – the extent to which inherent language features support the expression of source code that enforces good software engineering principles. Assembly languages provide no inherent support for software engineering principles. Rating: 0

Sections

1

2

3

4

5

6

7

Appendices

A	B	C	D	E	F	G	H	J
K	L	M	N	P	Q	R	S