Full Chapter Microprocessor 5 Software and Hardware Aspects of Development Debugging and Testing The Microcomputer 1St Edition Philippe Darche PDF
Full Chapter Microprocessor 5 Software and Hardware Aspects of Development Debugging and Testing The Microcomputer 1St Edition Philippe Darche PDF
https://textbookfull.com/product/microprocessor-1-prolegomena-
calculation-and-storage-functions-models-of-computation-and-
computer-architecture-1st-edition-philippe-darche/
https://textbookfull.com/product/software-development-design-and-
coding-with-patterns-debugging-unit-testing-and-refactoring-2nd-
edition-john-f-dooley/
https://textbookfull.com/product/hands-on-penetration-testing-on-
windows-unleash-kali-linux-powershell-and-windows-debugging-
tools-for-security-testing-and-analysis-1st-edition-phil-
Heterogeneous Computing Hardware Software Perspectives
1st Edition Mohamed Zahran
https://textbookfull.com/product/heterogeneous-computing-
hardware-software-perspectives-1st-edition-mohamed-zahran/
https://textbookfull.com/product/challenging-the-modern-
synthesis-adaptation-development-and-inheritance-1st-edition-
philippe-huneman/
https://textbookfull.com/product/software-supply-chain-security-
securing-the-end-to-end-supply-chain-for-software-firmware-and-
hardware-1st-edition-cassie-crossley/
https://textbookfull.com/product/computer-organization-and-
design-the-hardware-software-interface-risc-v-edition-david-a-
patterson/
https://textbookfull.com/product/computer-organization-and-
design-risc-v-edition-the-hardware-software-interface-david-a-
patterson/
Microprocessor 5
Series Editor
Jean-Charles Pomerol
Microprocessor 5
Philippe Darche
First published 2020 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as
permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced,
stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers,
or in the case of reprographic reproduction in accordance with the terms and licenses issued by the
CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the
undermentioned address:
www.iste.co.uk www.wiley.com
Quotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Quotation
Shadokian philosophy1
1 The Shadoks are the main characters from an experimental cartoon produced by the
Research Office of the Office de Radiodiffusion-Télévision Française (ORTF). The two-
minute-long episodes of this daily cult series were broadcast on ORTF’s first channel (the
only one at the time!) beginning in 1968. The birds were drawn simply and quickly using an
experimental device called an animograph.
The Shadoks are ridiculous, stupid and mean. Their intellectual capacities are completely
unusual. For example, they are known for bouncing up and down, but it is not clear why!
Their vocabulary consists of four words: GA, BU, ZO and MEU, which are also the four
digits in their number system (base 4) and the musical notes in their four-tone scale. Their
philosophy is comprised of famous mottos such as the one cited in this book.
Preface
This five-volume series deals with the general operating principles of the
microprocessor. It focuses in particular on the first two generations of this
programmable component, that is, those that handle integers in 4- and 8-bit formats.
In adopting a historical angle of study, this deliberate decision allows us to return to
its basic operation without the conceptual overload of current models. The more
advanced concepts, such as the mechanisms of virtual memories and cache memory
or the different forms of parallelism, will be detailed in a future book with the
presentation of subsequent generations, that is, 16-, 32- and 64-bit systems.
The first volume addresses the field’s introductory concepts. As in music theory,
we cannot understand the advent of the microprocessor without talking about the
history of computers and technologies, which is presented in the first chapter. The
second chapter deals with storage, the second function of the computer present in the
microprocessor. The concepts of computational models and computer architecture
will be the subject of the final chapter.
x Microprocessor 5
The third volume deals with the hardware aspects of the microprocessor. It first
details the component’s external interface and then its internal organization. It then
presents the various commercial generations and certain specific families such as the
Digital Signal Processor (DSP) and the microcontroller. The volume ends with a
presentation of the datasheet.
The fourth volume deals with the software aspects of this component. The main
characteristics of the Instruction Set Architecture (ISA) of a generic component are
detailed. We then study the two ways to alter the execution flow with both classic
and interrupt function call mechanisms.
The final volume presents the hardware and software aspects of the development
chain for a digital system as well as the architectures of the first microcomputers in
the historical perspective.
Multi-level organization
specialize in one of these fields. I wish you a pleasant stroll through these different
worlds.
Original company names have been used, although some have merged. This will
allow readers to find specification sheets and original documentation for the
mentioned integrated circuits on the Internet and to study them in relation to this
work.
The concepts presented are based on the concepts studied in selected earlier
works (Darche 2000, 2002, 2003, 2004, 2012), which I recommend reading
beforehand.
Philippe DARCHE
August 2020
Introduction
The two preceding volumes respectively addressed the hardware and software
characteristics of the microprocessor. This last volume complements them by
focusing on the software development chain and on development and testing tools.
The final chapter in this book, which is also Part 2, presents structural changes in the
first generations of microcomputers.
PART 1
The first part of this last volume is divided into two chapters. The first presents
the software development chain, and the second illustrates the hardware and
software tools used in development and testing.
Development Chain
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,”
Microprocessor 5: Software and Hardware Aspects of Development,
Debugging and Testing – The Microcomputer,
First Edition. Philippe Darche.
© ISTE Ltd 2020. Published by ISTE Ltd and John Wiley & Sons, Inc.
4 Microprocessor 5
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.
1 High-level languages like C (Kernighan 1983) are sometimes classified by some authors
(cf. Doyle (1985), for example) in the “low-level” category because they offer instructions
close to the microprocessor such as sequential and combinatorial logic operators, and because
they make it possible to manipulate variable addresses (concept of the pointer). This argument
will not be adopted in this work because these languages provide high-level control structures
and the idea of data typing, which is not the case for AL.
6 Microprocessor 5
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.
Development Chain 7
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.
Compatibility at the object code level makes it possible to distribute the program
without supplying the source code. It is then necessary to carry out link editing (cf.
§ 1.2.2) with system libraries on the host computer, an example being libc in the C
language. The specification takes over from the source code with, in addition, the
definition of an object file format such as COFF or ELF (respectively Common
Object File Format and Executable and Linkable Format, cf. § 1.2.2 for more
details).
2 Or programs.
3 The hardware layers and their interfaces will be covered in a future book by the author.
Development Chain 11
Figure 1.6. API and ABI interfaces and Hardware Abstraction Layer. For a color
version of this figure, see www.iste.co.uk/darche/microprocessor5.zip
The ABI is a set of specifications to which the executable must conform so that it
can be executed in a given execution environment. It defines a standard binary
interface to be able to execute the compiled application. It is located between the
applicable program and the OS, a library, or a set of I/O routines such as the BIOS
(Basic Input/Output System, cf. § 4.2.2 in Darche (2003) and § 3.5.3). It enables
portability of applications at the binary level. We can consider the ABI as equivalent
to the API at the object code level. An example is System V (SCO 1996a, 1996b,
1997). We should also mention iBCS (Intel Binary Compatibility Standard), which
allows the same binary code to function on x86 platforms under different Unix
systems. It is generally made up of two parts, one that is common for all
architectures and one that is specific to a particular architecture. It specifies a set of
functions that the OS provides to the program user as well as how they should be
called. The ABI instructions belong to the user set, not the system. The transfer of
control to the OS is done through the intermediary of software interruption, which
can be compared to a function call with (potential) passing of parameters under
constraint. The potential parameters are generally passed by registers, or less
commonly on the stack. The ABI therefore includes low-level information specific
to the target architecture. This is the machine interface, the function call sequence
and the interface with the OS. The machine interface describes the underlying
architecture (i.e. ISA) and the data representation. The data representation
specification provides its types with the format, order of storage (endianness; Cohen
1981, cf. § 2.6.2 in Darche (2012)) and associated alignments. The detail of the call
sequence includes the register usage conventions, the stack frame layout convention
and the passing of parameters (number, passing mode and type). The interface with
the OS describes the exception interface, signal management, virtual addressing,
process initialization (stack, registers, etc.) and debugging support. The executable
and object file format are also specified (header, sections, etc.) as well as a library
format. The ABI secondarily specifies the alphanumeric code used, for example, for
character-based data control (\n, for example), or for the package data file. It
provides information about loading the program and about potential dynamic
linking. The ABI must support the API’s libraries. Tools such as the compiler, the
assembler and the linker, that is, the development chain, make reference to the ABI.
An EABI (Embedded ABI) refers to the ABI version used in embedded systems. Its
specific characteristics are the absence of a linker and modified memory
management.
The interface between the OS and the hardware, the latter of which is optional, is
called the Hardware Abstraction Layer. It is a software layer in the OS that abstracts
the underlying hardware and is accessible via an API. An example is Windows.
Drivers and hardware-specific software such as hot-swap management belong to this
layer. It enables the addition of new hardware without having to change the OS’s
programs. Real-Time Operating Systems (RTOS) may not use a kernel (kernel-less
approach), but instead a library linked to the application (library-based RTOS).
Development Chain 13
Using a standard API or ABI enables software compatibility (cf. § V4-3.3.2). The
former enables application portability at the source-language level, and the latter
does so at the binary level.
It should be noted that the idea of the machine is relative. As specified by Smith
and Nair (2000), it depends on the point of view under consideration. As part of an
operating system, the machine is the hardware support enabling execution, and the
software interface is the ISA. As part of a process executing a program for a user,
the machine is the OS, which supplies storage and memory as well as services such
as I/O, and hardware support for execution is the ABI.
The three primary tools required to develop an application are the assembler, the
linker and the loader/launcher; there is also a tool called a disassembler. “Tuning
and testing” will be addressed in the following chapter.
1.2.1. Assembler
The assembly of a source file will give rise to the creation of an output file
named “listing” (the extension for the generated file is .lst), an object module, either
absolute or relocatable, and a list of cross references (Figure 1.7). It should be noted
that comments are deleted, which is handled by the precompiler (preprocessor) for a
high-level language.
4 The term “address” refers to the logical address, a term belonging to the concept of Virtual
Memory (VM, this will be covered in a future book by the author on storage). If there is no
logical translation, it is a Physical Address (PA).
5 The original definition from IBM was Symbolic Assembly Program.
6 A contraction of the two names Windows and Intel.
14 Microprocessor 5
7 An identifier or username is a noun (cf. a character string) designating, among other things,
a variable, a constant, a subprogram or a label.
Development Chain 15
describing a grammar is the Backus–Naur Form (BNF, Backus et al. 1960, 1963;
Knuth 1964; ISO 1996). During this step, syntax errors are addressed. Semantic
analysis is the penultimate step. It verifies, among other things, whether the variable
format is coherent between registers and/or variables. Code generation is the final
step. Code generation will involve symbolic evaluation. It associates an operation
code or opcode with each instruction and, to each identifier, an address, when this
correspondence is possible. If not, the linker stops associating to generate the final
executable. The mode of assembly can be absolute or relative. This refers to the
addressing mode (cf. § V4-1.2) used to reference the identifiers. Relative addressing
enables address translation (relocation, cf. § V4-3.1.4), which makes it possible to
install the code and the variables anywhere in memory without having to recalculate
the addresses.
The structure of the symbol table will change depending on the step in the
development chain. During assembly (assembly time), this data structure will
contain, in its most complete form, the lexical units and, in less complete forms,
16 Microprocessor 5
only identifiers with their attributes. When included in an object module, it makes it
possible to resolve references during linking time by connecting the identifier and
the reference. During execution, this table, which can be optionally included,
enables the debugger to know the names of the identifiers. Figure 1.9 shows an
example of this kind of table, extracted from the listing file in Figure 1.10.
The structure of the generated file, that is, the object module, can be broken
down into a general information header, code and data, the area for useful address
translation during a change of address, the global symbol table and the optional
debugging information. The object module can be called absolute if the address of
the program start was fixed and all of the identifiers’ addresses are generated from it
(this is the case in a mono-pass assembler). The memory dump therefore cannot be
moved to main memory, contrary to a relocatable module. Modern assemblers
generate this second kind of object module.
At the programmer’s request, a listing file can be generated. The data line for
this type of file (Figure 1.10) is typically divided into three areas called fields that
are, from left to right, the line number (expressed in base-10 most of the time), the
memory address (expressed in hexadecimal), the size, the variable name (optional)
and the initialization value (optional), which corresponds to the assembly of the
fourth zone, the source, as described in § 1.3.
The instruction line is typically divided into three areas called fields that are,
from left to right, the line number (expressed in base-10 most of the time), the
memory address (expressed in hexadecimal8), the machine code, then the source. A
cross reference table can be constructed from the symbol table during assembly. For
each symbol, whether internal to the program or external (i.e. public), there will be
an entry in this table with its name, its value and the list of instructions it references,
or even the number of the corresponding line. This can be seen in this file. This list
facilitates debugging, among other things, and it can be used by a compiler.
will be executed is not sufficiently powerful (i.e. MPU power and memory and
storage capacities) to run the development tools. It is often used to develop
embedded applications. A multiprocessor assembler is capable of generating code
for microprocessors in a different family. There is also something called a
meta-assembler, a scientific curiosity that makes it possible to write an assembler as
they were initially described (Ferguson 1966). A High-Level Assembler (HLA)
approaches high-level languages by enabling variable types and using control
structures and macro-instructions. One of the first was described by Wirth (1968)
with his PL360 language for the IBM System/360. A modern version of this type of
language is HLA, proposed by Hyde (2010). Some high-level language compilers,
such as the one for C, make it possible to insert lines of assembly language. This is
referred to as an inline assembler. This is useful for directly accessing the MPU’s
instruction set or for calls to the OS. The downside is the loss of portability since
this language is specific to an architecture or a specific MPU. Finally, we can
mention the patch assembler, which is used in debuggers to modify application code
in real-time to correct an error and test it immediately.
1.2.2. Linker
During the last step before obtaining the program executable, the linker (linkage
editor) or link editor provides address translation functions (relocation,
cf. § V4-3.1.4) and symbolic resolution. It selects the implementation address for the
code and the variables as a function of the memory model, for example. It defines a
size as an assembler and a start address (TOS for Top Of Stack) for the stack. If all
of the modules are presented, it resolves the address correspondence if necessary.
Generally, from the object modules and static and dynamic libraries (or DLL, for
Dynamic Link Library), that is, shared between several applications, and following
the arguments entered on the command line, it generates a module, either an
executable or a relocatable, as illustrated in Figure 1.11. The executable file has an
extension of .com, .exe (Windows environment), or an execution permission9
(x for UNIX), or is a file for programming an EPROM (file extension .hex, for
example). The second case, in which a new relocatable object module is generated,
is due to the fact that the linker does not continue to the end, that is, that there
remain unresolved references because, for example, of a missing library. Symbolic
information generated optionally during assembly can be supplied as well for
debugging at the executable source level (traditional file extension .map). This
information can be related to sections (number, type, start address and size) and