1
Development Chain

This chapter is focused on the software development chain for a microprocessor-based system. The different steps and their associated tools, including the first, the assembler, are examined. The debugging and testing aspects have taken on greater importance as hardware and software have grown more complex and become embedded in systems. These software and hardware tools are then described in detail. At first conceived to be used at the printed circuit level, they must be integrated progressively. To conclude, assembly language, a first level symbolic language, will be surveyed. The reader who is interested in a specific processor should refer to documentation from the relevant manufacturer. In addition, we will not here make a distinction between microprocessor and microcontroller because, in the latter case, we will only examine the "computation" component, that is, the processor, without addressing the other two subsystems, which are Input/Output (I/O) and RAM/ROM (Random Access/Read-Only Memory), including programmable memory, as relates to the latter type.

NOTE.- An understanding of the concepts of data representation and arithmetic operations in a computer is assumed. Otherwise, cf. Darche (2000). This will also be the case for logical operators. On this subject, cf. Darche (2002).

1.1. Layers of languages, stages of development and tools

The processor uses two-state logic. Instruction codes and data are therefore expressed in binary. This is machine language. Manipulating such data is not humanly possible for a program longer than about a hundred lines. The first computers were programmed in this language, and the program (i.e. machine code and data) was entered in binary format using switches as input peripherals. Because of the difficulty of use, an additional layer of language closer to natural language (English) was therefore necessary. This language is called "Assembly Language," which is abbreviated in this work as AL. The term assembly emerged from the EDSAC project (Electronic Delay Storage Automatic Calculator, Wilkes 1950, 1951) defining the action of reading subprograms from a symbolic instruction tape (a letter), translating them into binary, and making them executable by the main program (modern functions of a link editor and loading program combined). This mechanism is attributed to David J. Wheeler (Wheeler 1950). Excluding machine-oriented language, assembly language is therefore the processor's base programming language. It is referred to as symbolic. This indicates that it manipulates symbolic information, instruction words, variables and labels primarily. A specific assembly language corresponds to a single Instruction Set Architecture (ISA, cf. § V1-3.5). Assembly instructions are referred to using a form of abbreviated writing called operation code (or opcode) mnemonic (cf. § V4-2.1). An opcode mnemonic is a symbolic representation of a machine code. The assembler is the computing tool that translates between the symbolic name and the binary value. The first assembler was written by Nathaniel Rochester for the IBM 701 (1954). Recall that instructions in machine language, also called machine code or sometimes hard code (Bell 1973), are a series of binary instructions that are read and executed by the microprocessor. Figure 1.1 shows an example of assembly with two lines of instructions for the 8086 microprocessor. The assembler translated the mnemonics into machine code, here expressed in base 16 for readability. This tool is specialized for a processor or a family of processors. There is no efficiency loss between assembly languages and binary because the translation is direct. This is not the case for High-Level (programming) Language (HLL) compilers, where one high-level instruction (i.e. statement) corresponds to a sequence of several instructions in assembly language.

Figure 1.1. Example of lines from a program written in 80x86 assembly language

1.1.1. Levels of languages

Programming languages evolve in the direction of the increasing ease of programming by making it possible to manipulate higher-level abstractions, for example at the level of data structures or operators. Assembly language is downstream from high-level language, as shown in Figure 1.2. A language referred to as high level is as close as possible to human language. This is why machine and assembly languages are called Low-Level (programming) Languages1 (LLL). To move from one level to a lower level, it is necessary to use a translator that will substitute a source-language instruction with a series of instructions belonging to the lower-level (target) language. Each instruction in machine language that is executed will give rise to a series of commands inside the microprocessor, or micro-operations. In a micro-programmed architecture, these commands are naturally called micro-instructions (this will be covered in a future book by the author on microprocessors). This microprogramming language belongs to the language level reserved for processor designers (not represented).

Figure 1.2. Levels of languages in computing

It should be noted that there are microcontrollers with on-board high-level language interpreters (cf. § V3-5.3).

1.1.2. Development stages

Figure 1.3 presents the development chain for a computing application written in a compilable high-level language. It is also called the compilation chain or, more generally, the toolchain. A source program (or code) is written in a high-level language, for example in C (file extension .c) using a text editor. It is first precompiled (file extension .i for our example in the Microsoft environment or direct display on the standard output peripheral for UNIX). The precompiler is a preprocessor that will transform the source before delivering it to the compiler. It primarily provides functions for macro-expansion, macro(-definition) and file inclusion (cf. § 1.3.4). It also uses control structures to enable conditional compilation. Macro-operations are customizable thanks to its formal parameters, as are the functions, and they can be interlocked. The preprocessor is therefore no more or less than a manipulator of character strings with functions for search, deletion, insertion and substitution of character strings, just like a simple text editor. An additional function is the deletion of comments, which are useless to the machine. The transformed source is then compiled to obtain a file in assembly language (generated file extension .s or .asm, respectively under UNIX and Windows), which is then assembled. In simple cases, the obtained file is a file (example of an output file extension .hex), a binary memory image ready to be loaded into RAM or ROM (FW for FirmWare). The case of separate compilation (modular programming), or where the execution environment for the software is taken into account as, for example, with an Operating System (OS), generates a binary object file (output file extension .o or .obj depending on the OS), also referred to as an object module. An object program is therefore the final result from an assembler. In this latter case, it lacks code. This code corresponds to missing object modules. Once this code is available, the last step is called static linking. It is carried out by a linker or a link editor. This tool is generally automatically called by the compiler. It makes it possible to bring together all of the code forming the application based on a format that depends on the operating system. This missing code is presented in the form of independent object modules or compiled functions belonging to static libraries (file extension .a and .lib depending on the OS). This linker resolves address correspondence problems. The executable file is called a.out by default in UNIX; under Windows, it has a .exe extension or, formerly, a .com extension. This file can then be executed by the microprocessor (MPU for MicroProcessor Unit). To do so, it is loaded by the OS and then given execution control. The loader allocates memory, initializes the environment and can resolve address correspondence problems if necessary. It is also responsible for launching the program. To conclude, note that there are link editors/loaders.

Figure 1.3. Development chain for a program written in a compilable high-level language (here, C)

There are two main language families that determine how a program is executed: interpreted and compiled languages. In the first case, the interpreter analyzes an instruction from the source program each time it is to be executed to determine how to do so, and this is done at the time of execution (Figure 1.4). In the second case, compilation and assembly translate a source program (written in a high-level programming language) into an object module. This takes place during compilation and assembly. Following link editing, the execution of an object program takes place during execution. Between the two categories, there are hybrid languages that are compiled and then interpreted (semi-compiled language) like Java. For the latter, the source is compiled to obtain instruction byte code in an intermediate language. These instructions are then interpreted by the virtual machine or, for faster execution, compiled on the fly. Another approach is the Forth language, which is both interpreted and compiled.

Figure...