Microprocessor 5 Software and Hardware Aspects

of Development Debugging and Testing The

Microcomputer 1st Edition Philippe Darche
download
https://textbookfull.com/product/microprocessor-5-software-and-
hardware-aspects-of-development-debugging-and-testing-the-
microcomputer-1st-edition-philippe-darche/

Download more ebook from https://textbookfull.com

We believe these products will be a great fit for you. Click
the link to download now, or visit textbookfull.com
to discover even more!

Microprocessor 1 Prolegomena Calculation and Storage

Functions Models of Computation and Computer
Architecture 1st Edition Philippe Darche

https://textbookfull.com/product/microprocessor-1-prolegomena-
calculation-and-storage-functions-models-of-computation-and-
computer-architecture-1st-edition-philippe-darche/

Software Development, Design and Coding: With Patterns,

Debugging, Unit Testing, and Refactoring, 2nd Edition
John F. Dooley

https://textbookfull.com/product/software-development-design-and-
coding-with-patterns-debugging-unit-testing-and-refactoring-2nd-
edition-john-f-dooley/

Hardware and Software Verification and Testing 12th

International Haifa Verification Conference HVC 2016
Haifa Israel November 14 17 2016 Proceedings 1st
Edition Roderick Bloem
https://textbookfull.com/product/hardware-and-software-
verification-and-testing-12th-international-haifa-verification-
conference-hvc-2016-haifa-israel-
november-14-17-2016-proceedings-1st-edition-roderick-bloem/

Hands-On Penetration Testing on Windows: Unleash Kali

Linux, PowerShell, and Windows debugging tools for
security testing and analysis 1st Edition Phil Bramwell

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/

Challenging the Modern Synthesis: Adaptation,

Development, and Inheritance 1st Edition Philippe
Huneman

https://textbookfull.com/product/challenging-the-modern-
synthesis-adaptation-development-and-inheritance-1st-edition-
philippe-huneman/

Software Supply Chain Security: Securing the End-to-end

Supply Chain for Software, Firmware, and Hardware 1st
Edition Cassie Crossley

https://textbookfull.com/product/software-supply-chain-security-
securing-the-end-to-end-supply-chain-for-software-firmware-and-
hardware-1st-edition-cassie-crossley/

Computer Organization and Design The Hardware Software

Interface RISC V Edition David A. Patterson

https://textbookfull.com/product/computer-organization-and-
design-the-hardware-software-interface-risc-v-edition-david-a-
patterson/

Computer Organization and Design RISC V Edition The

Hardware Software Interface 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

Software and Hardware Aspects of Development,

Debugging and Testing – The Microcomputer

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:

ISTE Ltd John Wiley & Sons, Inc.

27-37 St George’s Road 111 River Street
London SW19 4EU Hoboken, NJ 07030
UK USA

www.iste.co.uk www.wiley.com

© ISTE Ltd 2020

The rights of Philippe Darche to be identified as the author of this work have been asserted by him in
accordance with the Copyright, Designs and Patents Act 1988.

Library of Congress Control Number: 2020943158

British Library Cataloguing-in-Publication Data

A CIP record for this book is available from the British Library
ISBN 978-1-78630-651-7
 Contents

Quotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Development Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1. Layers of languages, stages of development and tools . . . . . . . . . . . . . . 3
1.1.1. Levels of languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Development stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3. Mixed-language programming . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.4. Compatibility and software interfaces. . . . . . . . . . . . . . . . . . . . . 10
1.2. Fundamental software tools for development . . . . . . . . . . . . . . . . . . . 13
1.2.1. Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2. Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.3. Loader/launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.4. Disassembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3. Assembly language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.1. Software development methodology . . . . . . . . . . . . . . . . . . . . . 25
1.3.2. Standardization of assembly language . . . . . . . . . . . . . . . . . . . . 25
1.3.3. Structure of a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.4. Macro-instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 2. Debugging and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1. Hardware support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
vi Microprocessor 5

2.1.1. Generic electronic boards . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1.2. Programmers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2. Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.1. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2. Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.3. Hardware emulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.4. Software debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.5. Hardware support and debugging interfaces . . . . . . . . . . . . . . . . . 51
2.2.6. Remote debugging and virtualization . . . . . . . . . . . . . . . . . . . . . 59
2.2.7. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapter 3. Changes in the Organization of the Earliest Microcomputers . 71

3.1. Apple II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.2. IBM PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.1. The original PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2.2. The XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.3. The AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3. Chipset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4. Motherboard architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4.1. Form factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4.2. Current motherboard architecture . . . . . . . . . . . . . . . . . . . . . . . 103
3.5. Evolution of microcomputer firmware . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.2. Apple II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5.3. PC BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.5.4. Open firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Conclusion of Volume 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
 Quotation

Every advantage has its disadvantages and vice versa.

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

Computer systems (hardware and software) are becoming increasingly complex,

embedded and transparent. It therefore is becoming difficult to delve into basic
concepts in order to fully understand how they work. In order to accomplish this,
one approach is to take an interest in the history of the domain. A second way is to
soak up technology by reading datasheets for electronic components and patents.
Last but not least is reading research articles. I have tried to follow all three paths
throughout the writing of this series of books, with the aim of explaining the
hardware and software operations of the microprocessor, the modern and integrated
form of the central unit.

About the book

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 second volume is devoted to aspects of communication in digital systems

from the point of view of buses. Their main characteristics are presented, as well as
their communication, access arbitration, and transaction protocols, their interfaces
and their electrical characteristics. A classification is proposed and the main buses
are described.

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

This book gradually transitions from conceptual to physical implementation.

Pedagogy was my main concern, without neglecting formal aspects. Reading can
take place on several levels. Each reader will be presented with introductory
information before being asked to understand more difficult topics. Knowledge, with
a few exceptions, has been presented linearly and as comprehensively as possible.
Concrete examples drawn from former and current technologies illustrate the
theoretical concepts.

When necessary, exercises complete the learning process by examining certain

mechanisms in more depth. Each volume ends with bibliographic references
including research articles, works and patents at the origin of the concepts and more
recent ones reflecting the state of the art. These references allow the reader to find
additional and more theoretical information. There is also a list of acronyms used
and an index covering the entire work.

This series of books on computer architecture is the fruit of over 30 years of

travels in the electronic, microelectronic and computer worlds. I hope that it will
provide you with sufficient knowledge, both practical and theoretical, to then
 Preface xi

specialize in one of these fields. I wish you a pleasant stroll through these different
worlds.

IMPORTANT NOTES.─ As this book presents an introduction to the field of

microprocessors, references to components from all periods are cited, as well as
references to computers from generations before this component appeared.

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.

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.
 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,”
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.

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
 Development Chain 5

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 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

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.
 Development Chain 7

Figure 1.3. Development chain for a program written in a

compilable high-level language (here, C)
8 Microprocessor 5

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 1.4. Relationship between the type and levels of languages

1.1.3. Mixed-language programming

Mixed-language programming consists of developing an application by using

multiple languages. Programming is thus modular. A classic case is the combination
of C, C++ and AL. The linker is responsible for creating the executable. It
resolves reference problems (i.e. addresses) between different modules (Figure 1.5)
by linking the symbolic words to the implementation addresses. This type of
programming is complex and tends to generate errors. Each source is
compiled with the specific language’s compiler. At this stage, the tools become
shared. Link editing brings together the various object modules to generate the
application.
Figure 1.5. Software development chain in a mixed-language environment and with separated compilation
Development Chain
9
10 Microprocessor 5

1.1.4. Compatibility and software interfaces

The concept of software compatibility is presented in § V4-3.3.2. It is relevant at

three levels of the software development chain: source,2 object and machine code
(Figure 1.3).

Compatibility at the source code level today refers to high-level languages

because it is better for obvious reasons than assembly language. These languages
offer high-level software functionality (data type structures, control structures,
paradigms, etc.).

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).

Compatibility at the machine code level or binary compatibility allows an

application to be directly executed (ready-to-run). It requires the definition of
symbolic data types (compatible with the high-level language declarations such as
the long and int types in C, for example) and the specification of the alignment of
structures and data. The other definitions are sections (code, data, stack and heap),
their maximum sizes and the memory map (location), and the linker, which
generates absolute addresses before knowing them. An example specification is
BCS (Binary Compatibility Standard, Anderson et al. 1989) for Motorola’s M88000
RISC (Reduced Instruction Set Computer) processor (this will be covered in a future
book by the author on microprocessors). It is not necessary to compile or edit links
for the application before execution (ready-to-run application). It thus provides
independence from the programming language used.

These types of compatibility require standard interfaces. An interface is a bridge

between two software layers or between a software and a hardware3 layer. It
provides an abstraction of the lower layer. It was necessary to develop a standard
binary interface at the OS level (called the system interface), which is done
symbolically, either at the programming language level with an API (Application

2 Or programs.
3 The hardware layers and their interfaces will be covered in a future book by the author.
 Development Chain 11

Programming Interface) or at the binary level with an ABI (Application Binary

Interface), as illustrated in Figure 1.6. A Hardware Abstraction Layer (HAL) makes
it possible to detach the OS from the hardware implementation. ISA was described
in § V1-3.5.

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

An API or application programming interface enables compatibility at the source

level language in almost all cases for a high-level language (the C language, for
example). It enables portability of applications at the source level (cf. § V4-3.2.3). It
offers a set of services while masking the implementation details. The API is an
abstraction for service calls. The invocation of these services is done in the form of
standard or non-standard library functions. In the simplest case, the function is a
simple wrapper that adapts/translates the high-level conventions into those of the
lower-level. In the most complex cases, there are several system calls and the called
function is processed. An example is SVID (System V Interface Definition) which
defines the C language programming interface with UNIX System V (Novell 1995a,
1995b, 1995c). Another example is the IEEE 1003.1™-2013 – POSIX standard
(IEEE 2013). This specification defines a set of executable functions, a standard
library (library API) and a system API. A change in the API requires the application
to be recompiled. The API belongs to the Abstract Machine Interface (AMI) located
between applications and the OS. The latter also specifies the allowed instructions
and the memory access model.
12 Microprocessor 5

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.

1.2. Fundamental software tools for development

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 first assemblers were assembler-launchers (assemble-go system). They were

responsible for loading subprograms written in assembly language into memory by
translating binary instructions on the fly (i.e. a single program read), to call
addresses4 from the main program and to launch execution. In its modern form, it is
a language translator. The first assemblers in modern form were SOAP (Symbolic
Optimizer and Assembly Program) on the IBM 650 (Poley and Mitchell 1956) and
then SAP5 (SHARE Assembly Program) on the IBM 704 (Wegner 1976). A
description of the latter can be found in Helwig (1975). Two representatives from
the PC-Wintel6 world are MASM (Microsoft Macro Assembler) and
Turbo-Assembler® (tasm) from Borland.

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

Figure 1.7. Information flow for assembly

Given that this is a symbolic language, translation is more than transliteration,

hence the term assembly (Wegner 1968). Assembly can be broken down into two
parts, analysis and synthesis. The latter can be divided into phases or steps
(Figure 1.8). For a given language, syntax and semantics must be defined. Syntax
concerns the formal aspects of a language. It manages the organization of
instructions and data. Semantics concerns the meaning of instructions. Assembly
will therefore begin with a lexical or lexicographic analysis. Its function is to pick
out, from the data flow, a series of symbols called lexical or syntactical units,
lexemes or tokens, from whence its other name, the scanner or tokenizer, or linear
analysis, because the source is read from left to right, line by line. The typographic
space is the base separator. There exist predefined lexical units in the language such
as reserved words, operators, register names and separators (e.g. :, {, }, ;, etc.), as
well as others defined by the user, identifiers7 and numerical and alphanumeric
literals (i.e. character strings). A second stage consists of determining to which
family of units these lexemes belong. This is the sort phase carried out by the
analysis. A data structure called a “symbol table” was initialized during these first
two phases. This table will contain all of the elements to which the analyzer will add
information such as their name, username, unit type such as identifier, constant (also
called literal), language keyword or comment. These will also be initialized if
applicable. An identifier is the name of a variable, constant, subprogram or label. It
will then be elaborated during the following steps. From the point of view of
implementation, these two functionally distinct steps are united (Wilhelm and
Maurer 1994). This is followed by syntactic analysis, also called hierarchical
analysis. It is carried out by the analyzer with the same descriptor (parser). It
consists of verifying whether the source is respecting the grammar of the language.
A grammar defines the rules for constructing sentences in the language, that is, lines
of code containing declarations and instructions. One of the formal systems for

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.

Figure 1.8. Functional phases of assembly

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.

Figure 1.9. Example of a symbol table extracted

from the listing file in Figure 1.10
 Development Chain 17

As with high-level languages, assembly can be conditional (CA for Conditional

Assembly), which makes it possible to assemble only some parts of the program. An
example use case is the potential to choose whether to include instructions from an
application update. As with a compiler, the assembler, to carry out the translation,
generally performs two passes through the source code. A mono-pass assembler
directly translates symbolic references. But there are cases when this translation
cannot be done, particularly when there is a forward reference for a variable or a
label. There are therefore “two-pass,” or even multi-pass assemblers. Assembly time
is a function of the number of passes, of course.

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.

8 This foundation enables a more compact representation of values compared to NBC

(Natural Binary Code).
18 Microprocessor 5

Figure 1.10. Example of a listing file generated

by tasm (symbol table in Figure 1.9)

There are different types of assemblers. A macro-assembler is an evolution from

traditional assemblers that enables the creation of macro-instructions (cf. § 1.3.4),
which, once substituted, add to the code. This makes it possible to simplifying how a
program is written. A cross-assembler generates code for a different processor than
the one executing the assembler, as opposed to a naive or resident assembler, also
called a self-assembler. This is required when the target on which the application
 Development Chain 19

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

9 It is no longer a question of having run permissions because a program can be executed or

interpreted.
 Another Random Document on
Scribd Without Any Related Topics
First Glacial Stage, see Glacial Epoch

First Interglacial Stage, see Glacial Epoch

Fishing, 355, 385, 390, 450, 465, 471

Flake, see Levallois

Flaking, see Flint

Flint, chipping, 170;

cleavage, 171;
flaking, 169

Floors, Mousterian, 198, 199

Flora, 20;
Acheulean, 117, 118, 174, 175;
Chellean, 117, 118;
glacial, 65, 108, 117-119, 191, 192, 202, 208;
interglacial, 20, 67, 90, 91, 117-119;
Mousterian, 199;
Pliocene, 61, 63;
Postglacial, 361, 372, 375, 463, 488;
Pre-Chellean, 117, 118;
Pre-Neolithic, 488

Font-de-Gaume, 283, 314, 318, 319, 321, 325, 331, 349, 356, 358,
365, 372, 395-397, 399, 406-409, 412, 414-424, 435, 449

Font Robert, 277, 311, 314, 331, 340, 344

Forestian, Upper, 362;

Lower, 282
Forests, see Flora

Foro, 167

Fourth Glacial Stage, see Glacial Epoch

Fox, 43, 63, 71, 206, 265, 287, 333, 343, 348, 366, 447, 498, see
Vulpes;
arctic, 44, 46, 193, 207, 287, 289, 348, 370, 447, 468, 469, see
Canis lagopus.

Freudenthal, 279, 435

Frileuse, 167

Frontal, Trou de, 435

Fuente del Frances, 435

Furfooz, 7, 279, 481-483, Pl. II;

race, 278, 458, 480, 482-485, 489, 491, 492, 500;
see Grenelle, Ofnet, and Origin

Furninha, 167, 168

G
Galley Hill, 28, 302, 337, 338;
see Brünn race

Gansersfelsen, 435

Garenne, 435, 440

Gargano, 167

Gargas, 31, 307, 314, 317, 325, 327, 349, 394, 395

Germolles, 307, 314

Gibbon, 49-54, 58, 61, 63, 77, 511;

see Hylobates

Gibraltar skull, 7, 9, 140, 214, 215, 216, 219, 226, 228, 232, 233,
236

Glacial Epoch, 18-23, 33, 40, 41, 43, 54;

chronology, 18-23, 40, 41, 108, 188, 280, 362;
see Climate, Continental outline, Fauna, Glaciers;
First Glacial Stage (Günz), 23, 25, 26, 37, 38, 41, 43, 64-66;
Second Glacial Stage (Mindel), 23, 25, 26, 33, 37, 38, 41, 43, 65,
86-90;
Third Glacial Stage (Riss), 23, 25, 26, 33, 37-39, 41, 43, 94, 104-
106, 115;
Fourth Glacial Stage (Würm), 18, 22, 23, 25, 26, 30, 32, 33, 36-
38, 41, 43, 107, 108, 117, 160, 188-195, 205, 206, 280, 281, 284,
285, 362,
Laufenschwankung, 41, 108, 280, 362;
First Interglacial Stage (Günz-Mindel or Norfolkian), 23, 26, 29,
33-35, 38, 41, 43, 66-72, 84, 95, 115;
Second Interglacial Stage (Mindel-Riss), 23, 25, 29, 33, 38, 40, 41,
43, 69, 90-95, 109-111, 114, 115;
Third Interglacial Stage (Riss-Würm), 23, 25, 29, 33, 34, 36, 38-
41, 43, 69, 94, 107, 108, 112, 113, 115-119, 186-188, 280, 362;
Postglacial Stage, 18-23, 29, 32, 33, 36, 41, 43, 108, 280-284,
362, 468, 510,
Bühl, 23, 25, 26, 41, 108, 276, 280, 281, 361, 362, 370, 372,
446, 447, 449,
Gschnitz, 23, 41, 108, 276, 280, 281, 362, 363, 372, 449, 450,
Daun, 23, 41, 108, 276, 280, 281, 362, 363,
 Achenschwankung, 25, 26, 281, 282, 284

Glaciers, 64-66, 89, 90, 94, 104-106, 118, 189, 190, 361-363

Glutton, see Gulo luscus and Wolverene

Gobelsburg, 435, 448

Goccianello, 167, 168

Gorge d'Enfer, 331, 435

Gorilla, 49, 52, 54-56, 511, 512

Goulaine, 435, 438

Gourdan, 214, 279, 331, 341, 369, 388, 392, 435, 438

Goyet, 435

Grattoir, 129, 130, 177, 254, 270, 306-310, 386, 390, 470, 473,
494;
caréné, 308, 309, 463

Graver, see Burin

Gravette, etching tool, 270

Gravette, La, 277, 311, 314

Gray's Thurrock, 28, 109, 116, 128, 149, 152, 156, 157

Greek conception of nature and of the prehistory of man, 1-3

Grenelle, 279, 481, 482, 484;

race, see Furfooz
Grèze, La,
314, 317, 327, 331, 395, 396

Grimaldi, Grottes de (Baoussé Roussé), 245, 247, 262-265, 279,

294, 295, 312-314, 321, 323, 380;
Baousso da Torre, 263, 294;
Barma Grande, 263, 294;
Cavillon, Grotte de, 263, 294;
Enfants, Grotte des, 263-265, 292, 294-297, see Grimaldi race;
Prince, Grotte du, 262, 263

Grimaldi race, 7, 19, 245, 260, 262-269, 278, 279, 294, 301, 314,
490-492

Gschnitz, see Postglacial Stage

Guanches, 453-455, 507-510

Gudenushöhle, 245, 248, 279, 307, 314, 435, 448

Gulo luscus, 469;

borealis, 193;
see Wolverene

Günz, see Glacial Epoch

H
Hachette (tranchette, chopper, cleaver), 270, 488, 494

Hammer-stone, see Percuteur

Hamster, 46, 63, 147, 165, 287, 362, 364, 374

Hand-axe, see Coup de poing

Hand-stone, see Coup de poing

Hare, 289, 333, 368, 447, 468, 498, see Lepus (timidus);
arctic, 46, 207, 287, 348, 370, 447, 468, 469, see Lepus variabilis;
tailless, see Lagomys and Pika

Harpoons, 355, 383-385, 387, 388, 390, 391, 440, 443-445, 449,
450, 456, 460-462, 465, 466, 470, 474, 486, 487

Hastings, 471, 475

Heidelberg man, Mauer, 7, 23, 24, 40, 41, 53, 54, 90, 95-101, 114,
138, 143, 144, 214, 228, 229, 489, 491, 492, Pl. II

Heidelberg race, see Heidelberg man and Origin

Helin, 109, 116, 127, 128, 149, 152, 166, 167

Helvetian, see Dürntenian

Hermida, La, 435

Hippopotamus, H. major, 38, 39, 41, 43, 44, 47, 69, 71, 86, 91, 92-
94, 102, 117, 123-125, 134, 147, 148, 155, 157, 165, 174, 177, 186,
192, 199, 263, 264

Höhlefels bei Hütten, 435, 442

Höhlefels bei Schelklingen, 435, 442

Hohlestein, 314, 435

Hommes, Grotte des, 279, 435

Homo, aurignacensis, see Combe-Capelle man;

 heidelbergensis, see Heidelberg man;
mousteriensis, see Neanderthal race;
neanderthalensis, see Neanderthal race;
sapiens, 7, 9, 10, 54, 230-234, 257, 260, 261, 278, 334, 484, 490,
491, 500

Horace, on the prehistory of man, 3, 504

Hornos de la Peña, 245-247, 314, 331, 395, 435, 436

Horse, 45, 165, 182, 192, 225, 284, 355, 385, 392, 404, 405, 407,
408, 410, 412-414, 431, 432, 469, 498;
Desert, Plateau or Celtic, see Equus caballus celticus;
Forest or Nordic, 95, 147, 288, 289, 367, 369, 400, 498;
Hipparion, 63;
kiang or wild ass, 194, 285-287, 366, 367, 372-374, 400, 447;
Solutré, 288, 289, 414;
Steno's, 34, 96, 110, 111, 125, see Equus stenonis;
Steppe, see Equus przewalski

Hôteaux, Les, 279, 378, 379, 435

Hoxne, 158

Human figures, 317, 321-323, 328, 329, 337, 357, 393, 395, 399,
433, 434, 497

Human fossils, 4, 11;

distribution of, 214, 279;
tables of, 7, 219, 294, 336, 378, 490;
see Lists

Human races, see Lists and Origin

Hunting, 2, 11, 166, 202, 211-214, 283, 372, 456, 471, 496, 497
Hyæna, 43, 62, 76, 110, 147, 148, 155, 165, 188, 214, 245, 265,
317, 356, 476;
see Cave-hyæna and Hyæna

Hyæna, brevirostris, 125;

crocuta, 102, 147;
crocuta spelæa, 47, 102, 188;
striata, 92, 102;
see Hyæna

Hylobates, 6;
see Gibbon

I
Ibex, Ibex priscus, 44, 46, 201, 206, 264, 265, 287, 289, 321, 348,
357, 369, 371, 391, 401, 405, 433, 447, 466, 469, 497

Ice Age, see Glacial Epoch

Ice-fields, 19, 22;

see Glaciers

Implements, 11, 27-30, 130, 270, 271;

art, 270, 329, 330;
see Eolith, Flint, Industry, Lists, Neolith, Palæolith

Industry, 4, 11, 12-14, 19, 33, see Acheulean, Aurignacian, Azilian-

Tardenoisian, Chellean, Campignian, Magdalenian, Mousterian,
Neolithic, Pre-Chellean, Solutrean;
see Lists and Implements

Interglacial Stages, see Glacial Epoch

Iron Age, 12, 18, 21, 202, 267

Irpfelhöhle, 245, 248

Istein, 469, 471-473

Isturitz, 347, 395

J
Jackal, 43, 44;
see Canis neschersensis

Javelin point, see Sagaie

Jerboa, 46, 194, 287, 364;

see Alactaga jaculus

K
Kärlich, 314

Kartstein, 245, 248, 314, 435

Kastlhäng, 370, 435, 442

Kent's Hole, 10, 152, 244, 245, 435, 440

Kesslerloch, 279, 286, 355, 361, 364, 378, 383, 435, 436, 441, 442,
444-446, 449

Kiang, wild ass, see Horse

Kleinkems, 471

Knife, blade, see Couteau and Lame

Knight, Charles R., see Restorations

Kostelìk, 435, 448

Krapina, 7, 162, 167, 181-185, 214, 219, 220, 228, 229, 256

Krems, 119, 248, 289, 307, 314, 435, 448

L
Lacave, 279, 331, 340, 345, 347, 391

Lagomys, 63;
pusillus, 202, 370, see Pika

Lagopus, see Ptarmigan

Lamarck, on man, 4

Lame, blade, 271

Lampe, lamp, 270, 401, 402

Laufenschwankung, see Glacial Epoch

Laugerie Basse, 13, 14, 275, 279, 331, 348, 376-378, 385, 388,
392, 407, 434, 435, 471

Laugerie Haute, 13, 14, 279, 294, 296, 314, 331, 346, 352, 435
Laussel, 245, 246, 249, 275, 313, 314, 317, 326-329, 331, 352,
395, 435

Lauterach, 314

Lemming, 46, 191, 193, 194, 202, 207, 281, 287, 333, 348, 361,
364, 370, 469, 476;
see Myodes

Leopard, 265, 348;

see Cave-leopard and Felis pardus spelæa

Leptobos, 71;
elatus, 62;
etruscus, 63;
see Cattle

Lepus, 469;
cuniculus, 364, see Rabbit;
timidus, 364, see Hare;
variabilis, 206, see Hare, arctic

Levallois, 167, 179

Levallois flake, 167, 168, 179, 180, 199, 250, 251

Limeuil, 279, 435

Lion, 43, 86, 94-96, 98, 148, 165, 188, 281, 317, 348, 356, 365,
378, 400, 407, 446, 468, 472, 498;
see Cave-lion and Felis leo

Lissoir, polisher, smoother, 270, 271, 380, 388, 392, 456, 463, 466,
470

Lists and Tables, chronology, 18, 21, 22, 23, 33, 41, 54, 108, 280,
362;
climatic changes, 38, 39, 41, 43, 117, 191, 192, 275, 281, 284,
361-364;
fauna, 21, 41, 43, 54, 62, 95, 125, 147, 206, 207, 287;
human fossils, 7, 9, 219, 236, 237, 239, 266, 294, 295, 336, 378,
490;
human races, 41, 54, 108, 278, 280, 362, 458, 490, 491, 499,
500;
industries, divisions of, 18, 113, 114, 248, 249, 252, 340, 389;
succession of, 12, 13, 14, 16, 17, 18, 33, 41, 108, 280, 362;
implements, 130, 172, 254, 270, 271, 306, 308, 310

Liveyre, 331, 435

Loam, 5, 24, 27, 28

Loess, 5, 23-25, 29, 30, 36, 38, 46, 97, 103, 112, 115, 117-119,
122-124, 151, 159, 161, 162, 174, 176, 181, 252, 281, 282, 284,
286, 314, 334, 337, 364, 376, 442, 448;
stations, see Camps, open

Longueroche, 435, 471

Lorthet, 406, 407, 435, 438, 471

Lourdes, 279, 388, 432, 435, 436, 438, 471

Lower Rodent Layer, see Rodent Layers

Lucretius on the prehistory of man, 1, 2, 503

Lussac, 279, 435

Lutra vulgaris, 147;

see Otter
Lynchus lynx, 469;
see Lynx

Lynx, 43, 63, 206, 287, 367, 466;

see Lynchus lynx

M
Macaque, 54, 61, 63, 69, 76

Macerata, 167

Machærodus, 41, 69, 244;

see Sabre-tooth tiger

Madeleine, La, 13, 16, 279, 351, 383-389, 398, 435, 443, 445, 449,
471

Magdalenian, 14-16, 18, 276, 277, 351-360;

art, 351-357, 365, 366, 393, 395-434;
burial customs, 376-380;
chronology, 18, 33, 41, 108, 276, 280, 281, 351, 361-364;
climate, 276, 360-364, 370-376, 443, 447, 449, 450;
fauna, 361-376, 443, 445-447, 449, 450;
human fossils, 376-382;
industry, 14-16, 270, 271, 275, 276, 351-356, 358, 382-392,
436, 440, 443-450;
stations, 351, 434-449;
see Origin and Rodent Layers

Maglemose, 458, 471, 487, 488, 501

Magrite, Trou, 314, 331, 344, 435

Mairie, Grotte de la, 317, 395, 400, 405, 412, 413, 435, 442

Malarnaud, 214, 219

Mammoth, 10, 43, 102, 109, 117, 134, 147, 148, 177, 187, 194, 200,
202, 205, 206, 213, 218, 281, 288, 289, 316, 317, 321, 324-326,
333, 337, 348-350, 356, 364, 372, 385, 401, 403, 420, 421, 427,
429, 449, 450, 476, see Elephas;
woolly, 13, 40, 41, 43, 106, 117, 174, 187, 190-192, 196, 205,
207, 208, 210, 218, 221, 285-289, 334, 335, 363, 370, 372, 384,
397, 398, 420, 427, 446, see Elephas primigenius

Man, ancestry of, 3-7, 49-64, 491, 511

Mantes-la-Ville, 167

Marcilly-sur-Eure, 214

Mare-au-Clercs, La, 167

Marignac, 109, 126, 149, 152

Markkleeberg, 167

Marmot, Arctomys marmotta, 182, 201, 206, 265, 370

Marsoulas, 314, 319, 321, 328, 373, 394, 395, 396, 399, 403, 405,
415, 416, 435, 471, 485

Marten, 71, 165, 201, 265, 367, 380, 447, 498;

see Mustela martes

Martinshöhle, 435, 471

Mas d'Azil, 15, 16, 279, 319, 357, 375, 380, 385, 388, 391-396, 432,
433, 435, 437, 449, 458-465, 471, 472, 474
Massat, 437, 471

Mastodon, 62, 70, 134

Maszycka, 435, 436, 449

Mauer, see Heidelberg man

McGregor, J. Howard, see Restorations

Mediterranean race, 261, 278, 457, 458, 479, 480, 485, 489, 491,
492, 499, 500

Megaceros, 45, 68, 70, 106, 147, 182, 196, 287, 367;
see Deer, giant

Meles taxus, 147;

see Badger

Mentone, 247, 322, 395, 472, 473;

see Grimaldi, Grottes de

Merck's Rhinoceros, see Dicerorhinus and Rhinoceros

Mesaticephaly, 8, 479

Metternich, 284, 314

Micoque, La, 113, 167, 168, 179, 192, 196, 245, 246, 248, 249

Microlith, see Microlithique

Microlithique, microlith, 270, 306, 308, 310, 388, 396, 450, 470-472

Migration, of fauna, see Fauna;

 of human races and industries, see Origin

Mindel, see Glacial Epoch

Miskolcz, 245, 248, 331

Mommenheim, 245, 247, 248

Monkeys, 54, 61-63

Montconfort, 279, 331, 435

Montfort, 341, 471

Monthaud, 331, 346

Montières, 109, 127, 149, 152, 186, 244, 245, 283, 314, 331

Moose, 44, 94, 96, 265, 281, 348, 366, 468, 469, 472, 488, 496-
498;
see Alces

Moulin-de-Laussel, 331

Mousterian, 14-16, 18, 30, 186-188, 248-250;

burial customs, 222, 223, 271;
chronology, 18, 33, 41, 108, 280, 362;
climate, 117, 123, 188-199, 202, 205, 207;
fauna, 117, 190-194, 196, 199-214;
flora, 199;
human fossils, 218-226;
industry, 14-16, 113, 248-256, 270, 271;
stations, 194-202, 244-248;
see Caverns, life in, Floors, and Origin

Moustier, Le, 13, 16, 196-199, 214, 245, 246, 251, 253, 255;
 man, 7, 196, 214, 221-223, 226, 228, frontispiece

Mouthe, La, 17, 246, 279, 314, 317, 320, 321, 394, 395, 398, 399,
401

Mugem, 471, 474, 486

Munzingen, 160, 195, 435, 439, 442, 443

Murals, see Painting

Musk-ox, 42-44, 46, 65, 66, 187, 191, 193, 207, 285, 287, 289, 348,
362, 366, 370;
see Ovibos moschatus

Mustela, erminea, see Ermine;

martes, 147, 469, see Marten.

Myodes, lemmus, 210;

obensis, 206, 285, 370;
torquatus, 193, 202, 206, 285, 370, 441, 446, 447;
see Lemming

N
Narbonne, 435, 437

Naulette, La, 7, 214, 221, 228

Neanderthal, cave, 31, 214, 216, 217, Pl. II;

burial customs, see Mousterian;
man, 5, 7, 9, 56, 181, 216-219, 490;
race, frontispiece, 5-7, 9, 23, 40, 41, 54, 136, 182, 191, 196,
211-244, 256, 258, 263, 272, 491, 492,
 anatomical features, 53-56, 183, 184, 203, 219-223, 226-244,
490,
chronology, 41, 108, 257, 262, 280, 491,
compared with Crô-Magnon, 297, 298,
discoveries, 181-185, 215-226,
distribution of, 214, 219;
see Origin

Necklace, 302, 304, 376, 378, 437, 472

Needle, see Aiguille

Negroid race, 261, 262, 266-269, 278, 301, 302, 321, 492

Neolith, 11, 496

Neolithic, New Stone Age, 10, 13, 18, 19, 21, 41, 108, 280, 362,
447, 482, 484-486, 488, 493-501

Neopithecus, 49

Neschers, 245, 435, 438

Niaux, 314, 319, 353, 373, 391, 394, 395, 400, 406, 409-411,
412, 429, 435

Niedernau, 370, 435

Norfolkian, see First Interglacial Stage and Forest Bed of Cromer

Nutons, Trou des, 435

O
Oban, 474, 475, 486

Obercassel, man, 7, 279, 353, 378, 380-382, 435, 443

Oberlarg, 435

Ochos, 214, 219, 221, 228, 245, 248

Ofnet, 279, 285, 314, 331, 370, 435, 469, 471, 473, 475-481;
races, 442, 457-460, 480, 481, 490, 491, 500;
see Furfooz race and Origin

Ojcow, 331, 436, 449

Ondratitz, 331

Orang, 3, 49, 52-54, 56, 77, 511

Origin, of industries, Acheulean, 261, 492,

Aurignacian, 261, 289, 305-307, 322, 492,
Azilian-Tardenoisian, 457, 470-472, 492,
Chellean, 126, 261, 492,
Magdalenian, 351-353, 383,
Mousterian, 261,
Pre-Chellean, 126,
Solutrean, 330, 331, 340, 353, 492;
of human races,
Alpine, 458, 484, 485,
Brünn, 331, 492,
Crô-Magnon, 261, 322, 492,
Furfooz, 492,
Grimaldi, 262,
Heidelberg, 492,
Mediterranean, 492,
Neanderthal, 492,
Ofnet, 457, 484, 485,
 Piltdown, 492,
Teutonic, 486

Otter, 63, 71, 76, 165, 201, 287, 468, 498;

see Lutra vulgaris

Ovibos, 376;
moschatus, 193, 445, 447, see Musk-ox

Ovis argaloides, 369;

see Argali sheep

P
Painted Pebbles, see Azilian-Tardenoisian industry

Painting, 305, 316-318, 320, 321, 324, 325, 327, 328, 330, 358,
365, 394-396, 404-406, 408-429, 464, 465, 474, 496, 497

Pair-non-Pair, 279, 307, 314, 317, 320-322, 331, 336, 394-396

Palæolith, 11, 24, 84, 85, 109, 111, 158, 389

Palæolithic, Old Stone Age, 13, 16, 18, 19, 21, 28, 33, 41, 108, 160,
280, 362;
Lower Palæolithic, 14, 41, 108, 113, 114, 214, 280, 362, 490, 491;
Upper Palæolithic, 14, 41, 108, 214, 275, 276, 278, 280, 362, 395,
396, 490, 491, 500;
chronology, 18, 41, 108, 280, 362, 456

Palæopithecus, 49, 511

Parietal Art, see Painting

Pasiega, La, 319, 395, 402-405

Pataud, 245, 246, 331

Paviland, 279, 289, 290, 294, 314, 440

Pech de l'Azé, 214, 219, 245

Perçoir, drill, borer, 130, 135, 153, 172, 179, 253, 254, 270, 306,
308, 310, 311, 344, 346, 385, 386, 388, 390, 392, 470, 473, 488

Percuteur, hammer-stone, 130, 254, 270, 306

Pescara, 167

Petit Puymoyen, 214, 245, 246

Pic, pick, 494

Pierre de jet, throwing stone, 130, 172, 213, 254, 270, 306

Pika, 46, 362, 447;

see Lagomys (pusillus)

Piltdown, 109, 116, 128, 130-135, 149, 152, 214, Pl. II;
industry, 127, 128, 133-135;
man (Eoanthropus), 7, 23, 24, 40, 50, 53, 54, 56, 130-145, 214,
489-491;
race, see Piltdown man and Origin

Pindal, 314-316, 325, 349, 394, 395

Pithecanthropus, Trinil race, 7, 23, 24, 40, 53, 54, 86, 491, 511, Pl.
II;
anatomical features, 9, 10, 53, 56, 74, 77-84, 233, 234, 240,
490;
 discovery, 73-77

Placard, 279, 331, 333, 334, 340, 345-348, 352, 353, 355, 378-
380, 383, 385, 389, 435, 436, 438

Planing tool, see Grattoir

Pleistocene, see Glacial Epoch

Pliohylobates, 49, 54

Pliopithecus, 49, 54

Poignard, dagger, poniard, 271, 392, 432

Poinçon, awl, 271, 308, 346, 392, 470

Pointe, point, knife, lance head, spear head, 15, 113, 153, 172, 177,
179, 248-255, 270, 306, 308, 310, 311, 473;
Châtelperron, 306, 307, 311;
pointe à cran, shouldered, 270, 308, 310, 313, 334, 340, 342,
345, 346, 352;
pointe à face plane, 341;
pointe de lance, 271, 306;
pointe de laurier, laurel leaf, 15, 270, 310-312, 334, 337, 339-
341, 344, 345, 347, 348, 352;
pointe de sagaie, javelin point, 271, 308, 340, 346, 354, 355,
361, 364, 370, 383, 387, 390, 442, 449, 462, 494;
pointe de saute, willow leaf, 340, 344, 347;
pointe à soie, 270, 310, 311, 313, 340, 345

Polisher, see Lissoir

Portel, Le, 319, 394, 411, 412

Postglacial Stage, see Glacial Epoch

Pottery, 461, 466, 474, 486, 488, 496

Praule, Trou de, 435

Pre-Chellean, 16, 18, 36, 41;

chronology, 18, 33, 40, 41, 90, 107-115, 280, 362;
climate, 108, 112, 114, 117, 118, 123;
fauna, 108-112, 117, 124, 125;
industry, 40, 114, 120-130, 270;
stations, 109, 116, 122-128, 149, 150-152, 158, see Continental
outline and Origin

Předmost, 257, 279, 331, 341, 345, 348, 349, 366, 395, 427;
see Brünn race;
mammoth hunters, 279, 337

Primates, 3-10, 40, 49-64, 73-84, 86, 140, 141, 217, 219, 227, 231,
233-235, 237-240, 490, 491

Prince, Grotte du, see Grimaldi, Grottes de

Propliopithecus, 49, 54

Propstfels, 372, 435, 442, 469

Propulseur, spear thrower, dart thrower, 271, 355, 391, 432, 433,
436, 445, 449

Ptarmigan, Lagopus, 44, 206, 207, 287, 289, 370, 371, 375, 469

Q
Quartz, 166
Quartzite, 163, 164, 265

Quina, La, 9, 113, 211, 213, 214, 245, 246, 248, 253-256;
man, 7, 9, 214, 216, 217, 219, 221, 225, 236, 237, 248

R
Rabbit, 265, 343, 368, 468;
see Lepus cuniculus

Racloir, scraper, 113, 114, 130, 135, 172, 178, 209, 248, 250, 251,
253-255, 270, 306, 387, 388, 470, 472, 473, 488

Rangifer tarandus, 193, 209, 210, 285;

see Reindeer

Räuberhöhle, 245, 247, 248, 314

Raymonden, 349, 376, 388, 435

Reilhac, 331, 471

Reindeer, 13, 41, 43, 44, 46, 102, 103, 187, 191-194, 196, 197,
202, 205, 206, 209, 210-212, 214, 221, 223, 225, 284, 285, 286-
289, 314, 317, 332, 333, 365, 366, 370, 372, 385, 392, 399, 405,
407, 411-413, 415, 419-421, 429, 433, 440, 441, 445, 447, 461,
462, 468, 469, 471, 474, 481, 498;
see Rangifer

Reindeer Epoch, Period, 13, 14, 102, 192, 275, 286, 363, 375, 392,
438, 456, 459

Religion, 272, 358-360, 463, 465, 501

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com