可移植C编译器设计与实现：英文原版详解

5星 · 超过95%的资源需积分: 50 56 浏览量更新于2024-07-21 5 收藏 17.82MB PDF 举报

《可重配置C编译器设计与实现》（ARetargetable C Compiler: Design and Implementation）是由Christopher W. Fraser和David R. Hanson合著的一本编译原理方面的专业书籍，两位作者分别来自AT&T贝尔实验室和普林斯顿大学。该书是英文原版，由The Benjamin/Cummings Publishing Company出版，涵盖了一系列关于设计和实现可适应不同目标平台的C语言编译器的关键知识点。本书的核心内容围绕可移植性和灵活性展开，讲述了如何设计一个能够跨平台工作的C语言编译器，这对于软件工程、系统架构和嵌入式系统开发等领域具有重要意义。编译器设计涉及到诸多原理，如词法分析、语法分析、语义分析、中间代码生成、优化、目标代码生成等关键阶段。作者详细解释了如何处理不同的指令集架构（ISA），以及如何通过诸如宏指令、类型转换和代码生成策略等技术来适应不同的硬件环境。书中可能还讨论了以下几点： 1. **词法分析**：解析源代码中的标识符、关键字、运算符和标点符号，将其转化为内部表示形式。 2. **语法分析**：采用文法分析算法（如LR（1）、LL（1）或SLR）构造抽象语法树（AST），确保代码符合语言规范。 3. **语义分析**：检查语法树的正确性，包括类型检查和作用域解析，确保程序逻辑的正确性。 4. **中间代码生成**：将AST转化为一种中间形式，如三地址码（Three-address code）或寄存器分配图（Register Transfer Language, RTL），以便进行进一步优化。 5. **优化**：通过循环展开、常量折叠、消除冗余操作等方式提高程序性能，同时保持其功能不变。 6. **目标代码生成**：根据目标平台的特定指令集和体系结构，将中间代码转化为机器可执行代码。 7. **编译器前端与后端**：阐述了如何构建模块化的编译器，前端负责处理输入代码，后端负责生成针对特定目标平台的代码。 8. **工具链集成**：可能介绍了如何将编译器与其他开发工具（如链接器、调试器）协同工作。 9. **性能评估与调试**：讨论了在实际应用中编译器性能和错误检测的重要性。由于这是一本教科书，它不仅提供了理论知识，还可能包含了大量的示例代码和练习，帮助读者深入理解编译原理的实际应用。对于任何对编译器设计感兴趣的开发者，无论是研究者还是实践者，这本书都是宝贵的参考资料。

CHAPTER

7 • INTRODUCTION

a single fragment. noweave identifies this concatenation by using + =

instead

continued definitions:

...

(afragmentlabel1)+=

pri

ntf("%d\n",

sum);

Fragment definitions are like macro definitions;

notangle

extracts a pro-

gram

expanding one fragment.

its definition refers to other frag-

ments, they are themselves expanded,

and

so on.

Fragment definitions include aids to help readers navigate among

them. Each fragment name ends with the

number

the page

which

the fragment's definition begins.

there's no number, the fragment

isn't defined

this book,

but

its code does appear

the companion

diskette. Each continued definition also shows the previous definition,

...

and

the next continued definition,

there is one. J 4 is

example

previous definition

that

appears

page 14,

and

31 says the definition

,,,.

is continued

page 31. These annotations form a doubly linked list

definitions; the

arrow points to the previous definition in the list

and

dmvn arrow points to the next one. The previous link

the first defi-

nition in a list is omitted,

and

the next link

the definition is omitted.

These lists are complete:

some

a fragment's definitions appear

the same page

V\ith

each other, the links refer to the page

which they

appear.

Most fragments also show a list

pages

which the fragment is

used, as illustrated by the number

1 to the right

the definition for

(increment

sum), above. These

unadorned

use

lists are omitted for root

fragments, which define modules,

and

for some fragments that occur too

frequently, as detailed below.

notangl

e also implements one extension to

A long string literal

can be split across several lines by ending the lines to be continued with

underscores.

notangle

removes leading white space from continuation

lines

and

concatenates

them

to form a single string. The first argument

error

page 119 is

example

this extension.

1.2

How

Read

This

Book

Read this book front-to-back. A few variants are possible.

• Chapter 5 describes the interface between the front end

and

back

ends

the compiler. This chapter has been made as self-contained

as possible.

• Chapters

13-18

describe the back ends

the compiler. Once you

know the interface, you can read these chapters \vith few excur-

sions back into their predecessors. Indeed, people have

replaced

the front end

and

the back ends without reading, much less under-

standing, the other half.

1.2 •

HOW

TO READ THIS BOOK

• Chapters

16-18

describe the modules that capture all information

about the three targets the

MIPS,

SPARC,

and

Intel 386 and suc-

cessor architectures. Each

these chapters is independent, so you

may read any subset of them.

you read more

than

one, you may

notice some repetition,

but

it shouldn't be too irritating because

most

code common to all three targets has been factored out into

Chapters

13-15.

Some

parts

of the book describe l cc from the

bottom

up. For example,

the chapters

managing storage, strings, and symbol tables describe

functions that are at

near the ends

call chains. Little context is

needed to

understand

them.

Other parts of the book give a top-down presentation. For example,

the chapters

parsing expressions, statements,

and

declarations begin

with the top-level constructs. Top-down material presents some func-

tions or fragments well after the code that uses them, but material near

the first use tells enough about the function or fragment to

understand

what's going

the interim.

Some

parts

of the book alternate between top-down

and

bottom-up

presentations. A less variable explanation order would be nice,

but

it's

unattainable.

most

compilers, l cc includes mutually recursive func-

tions, so it's impossible to describe all callees before all callers or all

callers before all callees.

Some fragments are easier to explain before you see the code. Others

are easier to explain afterward.

you need help with a fragment,

don't

struggle before scanning the text

just

before and after the fragment.

Most of the code for l cc appears in the text,

but

a few fragments are

used

but

not

shown. Some

these fragments hold code that is omitted

to save space. Others implement language extensions, optional debug-

ging aids, or repetitious constructs. For example, once you've seen the

code that handles C's for statement, the code

that

handles the do-while

statement adds little. The only wholesale omission is the explanation

how l cc processes C's initializers, which

skipped because it is long,

not

very interesting,

and

not

needed to

understand

anything else. Frag-

ments that are

used

but

not

defined are easy to identify: no page number

follows the fragment name.

Also omitted are assertions. l cc includes hundreds

assertions.

Most assert something that the code assumes about the value

a param-

eter or data structure. One is

assert

(0),

which guarantees a diagnostic

and

thus

identifies states that are

not

supposed to occur. For example,

a switch is

supposed

to have a bona fide case for all values

the switch

expression,

then

the default case might include

assert(O).

The companion diskette is complete. Even the assertions

and

frag-

ments that are omitted from the text appear

the diskette. Many

them are easily

understood

once the documented code nearby is under-

stood.

~---------------------

CHAPTER

1 • INTRODUCTION

A "mini-index" appears in the middle

the

outside margin

many

pages.

lists each

program

identifier

that

appears

the

page

and

the

page

number

which

the

identifier is defined

code

explained

text. These indices

not

only help locate definitions,

but

highlight circu-

larities: Identifiers

that

are

used

before they are defined appear

the

mini-indices with page

numbers

that

follow the page

which they are

used. Such circularities

can

confusing,

but

they are inevitable

any

description

a large program. A few identifiers are listed with more

than

one definition; these name

important

identifiers

that

are

used

for

than

one purpose

that

are defined

both

code

and

prose.

1.3

Overview

1 cc transforms a source

program

assembler language program.

Following a sample

program

through

the intermediate

steps

this trans-

formation illustrates

cc's

major components

and

data

structures. Each

step

transforms the

program

into a different representation: prepro-

cessed source, tokens, trees, directed acyclic graphs,

and

lists

these

graphs are examples. The initial source code is:

int

round(f)

float

{

return

f +

0.5;

/*truncates

}

round

has

prototype, so the argument is

passed

as a double

and

round

reduces

a float

upon

entry. Then round

adds

truncates the

result

integer,

and

returns

it.

The first phase is the C preprocessor, which expands macros, includes

header

files,

and

selects conditionally compiled code. 1 cc now

runs

un-

der

DOS

and

UNIX

systems,

but

it originated

UNIX

systems.

many

UNIX

compilers, l cc

uses

a separate preprocessor, which

runs

as a sepa-

rate

process

and

not

part

this book.

often

use

the

preprocessor

that

comes with

the

GNU

C compiler.

A typical preprocessor reads

the

sample code and emits:

"sample.c"

int

round(f)

float

{

return

f +

0.5;

}

The sample

uses

preprocessor features,

the preprocessor

has

noth-

ing to do

but

strip

the comment

and

insert

a # directive

tell the com-

piler the file name

and

line

number

the

source code for

use

when

issuing diagnostics. These sample coordinates are straightforward,

but

program

with numerous

#include

directives brackets each included

CHAPTER

•INTRODUCTION

ASGN+F

RET+I

ADDRF+P

CVD+F

CVD+I

' i

INDIR+D

ADD+D

ADDRF+P

CVF+D

CNST+D

0.5

INDIR+F

"caller

"f"-double

ADDRF+P

;.:

----------·

callee

"f"---

oat

FIGURE

1.2

Abstract syntax trees for the sample.

The second tree implements the sample's lone explicit statement,

and

returns an int

(RET

+I). The value is computed by fetching the float

(INDIR+F) from the cell with the address

(ADDRF+P),

converting it to

double, adding

(ADD+D)

the

double

constant 0. 5

(CNST

+D),

and truncating

the result to int

(CVD+I).

These trees make explicit many facts

that

are implicit in the source

code. For example, the conversions above are all implicit in the source

code,

but

explicit in the

ANSI

standard

and thus

the trees. Also, the

trees type all operators explicitly; for example, the addition in the source

code has no explicit type,

but

its counterpart in the tree does. This

semantic analysis is done as l cc's

parser

recognizes the input,

and

covered

Chapters 7

-11.

From the trees

shmivn

Figure 1.2, l cc produces the directed acyclic

graphs -

dags - shown in Figure 1.3. The dags labelled 1

and

2 come

from the trees shovvn in Figure

1.2. The operators are written without

the plus signs to identify the structures as dags instead

trees. The

transition from trees to dags makes explicit additional implicit facts. For

example, the constant 0.

which appeared

CNST

node in the tree,

appears as the value

a static variable

named

2 in the dag,

and

the

CNST

operator has

been

replaced by operators that develop the address

the variable

(ADDRGP)

and

fetch its value (INDIRD).

The third dag, shown

Figure 1.3, defines the label named 1

that

appears at the

end

round. Return statements are compiled into

jumps

to this label,

and

trivial ones are elided.

detailed in Chapter 12, the transition from trees to dags also elim-

inates repeated instances

the same expression, which are called com-

mon subexpressions. Optionally, each multiply referenced dag node can

剩余587页未读，继续阅读

江荣波

粉丝: 488
资源: 49

可移植C编译器设计与实现：英文原版详解

ARetargetableCCompilerDesignandImplementationFreePdfBooks.com.pdf 英文原版

retargetable-c-compiler：此仓库将紧随Christopher Fraser和David Hanson所著的“ A Retargetable C Compiler：设计与实现”一书

可变目标C编译器设计与实现.pdf

可变目标C编译器—设计与实现.pdf

C语言接口与实现--创建可重用软件的技术.pdf

C语言接口与实现 pdf 免费

C语言接口与实现——创建可重用软件的技术

lcc c编译器源代码

可变目标C编译器——设计与实现.pdf

可变目标C编译器—设计与实现lcc.pdf

最新资源