WebRTC编译系统之gn files
WebRTC编译系统之gn files
在“WebRTC 构建系统介绍之gn和ninja”中，大概介绍了gn 和ninja 的简单用法，这次来看看gn 用到的项目文件.gn 、.gni 和DEPS ，它们指导了如何生成ninja 构建文件。
借用C++ 的概念，如果把gn 看成一个编译系统，.gn 就是源文件，.gni 就是头文件。我们姑且这么理解就好了（其实gni 里做的事情，gn 都可以做）。DEPS 主要用来设定包含路径。
gn 和gni 文件都在源码树中，比如src 目录。当执行gn gen 时，gn 工具根据gn 和gni 生成ninja 文件并将这些ninja 文件放到指定的构建目录中。
.gn
.gn 文件是GN build 的“源文件”，在这里可以做各种条件判断和配置，gn 会根据这些配置生成特定的ninja 文件。
.gn 文件中可以使用预定义的参数，比如is_debug ，target_os ，rtc_use_h264 等。
.gn 中可以import .gni 文件。
看一下src/BUILD.gn ：
import("webrtc/webrtc.gni")
group("default") {
testonly = true
deps = [
"//webrtc",
"//webrtc/examples",
"//webrtc/tools",
]
if (rtc_include_tests) {
deps += [ "//webrtc:webrtc_tests" ]
}
}
.gn 和.gni 文件中用到各种指令，都在这里有说明：GN Reference。
这个gn 文件中，导入了webrtc/webrtc.gni 文件。
这个gn 文件，用group 指令声明了一个default 目标，这个目标依赖webrtc 、webrtc/examples 和webrtc/tools ，你可以在webrtc 、webrtc/examples 、webrtc/tools 目录下找到对应的BUILD.gn 。你可以把group 当做VS 的solution ，或者QtCreator 的dir 项目。
gn 文件中也可以通过defines 来定义宏，通过cflags 来指定传递给编译器的标记，通过ldflags 指定传递给链接器的标记，还可以使用sources 指定源文件。下面是webrtc/BUILD.gn 文件的部分内容：
if (is_win) {
defines += [
"WEBRTC_WIN",
"_CRT_SECURE_NO_W ARNINGS", # Suppress warnings about _vsnprinf
]
}
if (is_android) {
defines += [
"WEBRTC_LINUX",
"WEBRTC_ANDROID",
]
}
if (is_chromeos) {
defines += [ "CHROMEOS" ]
}
if (rtc_sanitize_coverage != "") {
assert(is_clang, "sanitizer coverage requires clang")
cflags += [ "-fsanitize-coverage=${rtc_sanitize_coverage}" ]
ldflags += [ "-fsanitize-coverage=${rtc_sanitize_coverage}" ]
}
.gni
gni 文件是GN build 使用的头文件，它里面可以做各种事情，比如定义变量、宏、定义配置、定义模板等。
看下webrtc/webrtc.gni 文件：
# Copyright (c) 2014 The WebRTC project authors. All Rights Reserved.
#
# Use of this source code is governed by a BSD-style license
# that can be found in the LICENSE file in the root of the source
# tree. An additional intellectual property rights grant can be found
# in the file PATENTS. All contributing project authors may
# be found in the AUTHORS file in the root of the source tree.
import("//build/config/arm.gni")
import("//build/config/features.gni")
import("//build/config/mips.gni")
import("//build/config/sanitizers/sanitizers.gni")
import("//build_overrides/build.gni")
import("//testing/test.gni")
declare_args() {
# Disable this to avoid building the Opus audio codec.
rtc_include_opus = true
# Enable this if the Opus version upon which WebRTC is built supports direct # encoding of 120 ms packets.
rtc_opus_support_120ms_ptime = false
# Enable this to let the Opus audio codec change complexity on the fly.
rtc_opus_variable_complexity = false
# Disable to use absolute header paths for some libraries.
rtc_relative_path = true
# Used to specify an external Jsoncpp include path when not compiling the # library that comes with WebRTC (i.e. rtc_build_json == 0).
rtc_jsoncpp_root = "//third_party/jsoncpp/source/include"
# Used to specify an external OpenSSL include path when not compiling the # library that comes with WebRTC (i.e. rtc_build_ssl == 0).
rtc_ssl_root = ""
# Selects fixed-point code where possible.
rtc_prefer_fixed_point = false
# Enables the use of protocol buffers for debug recordings.
rtc_enable_protobuf = true
# Disable the code for the intelligibility enhancer by default.
rtc_enable_intelligibility_enhancer = false
# Enable when an external authentication mechanism is used for performing # packet authentication for RTP packets instead of libsrtp.
rtc_enable_external_auth = build_with_chromium
# Selects whether debug dumps for the audio processing module
# should be generated.
apm_debug_dump = false
# Set this to true to enable BWE test logging.
rtc_enable_bwe_test_logging = false
# Set this to disable building with support for SCTP data channels.
rtc_enable_sctp = true
# Disable these to not build components which can be externally provided. rtc_build_expat = true
rtc_build_json = true
rtc_build_libjpeg = true
rtc_build_libsrtp = true
rtc_build_libvpx = true
rtc_libvpx_build_vp9 = true
rtc_build_libyuv = true
rtc_build_openmax_dl = true
rtc_build_opus = true
rtc_build_ssl = true
rtc_build_usrsctp = true
# Enable to use the Mozilla internal settings.
build_with_mozilla = false
rtc_enable_android_opensl = false
# Link-Time Optimizations.
# Executes code generation at link-time instead of compile-time.
# https://https://www.wendangku.net/doc/f810405225.html,/wiki/LinkTimeOptimization
rtc_use_lto = false
# Set to "func", "block", "edge" for coverage generation.
# At unit test runtime set UBSAN_OPTIONS="coverage=1".
# It is https://www.wendangku.net/doc/f810405225.html,end to set include_examples=0.
# Use llvm's sancov -html-report for human readable reports.
# See https://www.wendangku.net/doc/f810405225.html,/docs/SanitizerCoverage.html .
rtc_sanitize_coverage = ""
# Enable libevent task queues on platforms that support it.
if (is_win || is_mac || is_ios || is_nacl) {
rtc_enable_libevent = false
rtc_build_libevent = false
} else {
rtc_enable_libevent = true
rtc_build_libevent = true
}
if (current_cpu == "arm" || current_cpu == "arm64") {
rtc_prefer_fixed_point = true
}
if (!is_ios && (current_cpu != "arm" || arm_version >= 7) &&
current_cpu != "mips64el") {
rtc_use_openmax_dl = true
} else {
rtc_use_openmax_dl = false
}
# Determines whether NEON code will be built.
rtc_build_with_neon =
(current_cpu == "arm" && arm_use_neon) || current_cpu == "arm64"
# Enable this to build OpenH264 encoder/FFmpeg decoder. This is supported on
# all platforms except Android and iOS. Because FFmpeg can be built
# with/without H.264 support, |ffmpeg_branding| has to separately be set to a
# value that includes H.264, for example "Chrome". If FFmpeg is built without
# H.264, compilation succeeds but |H264DecoderImpl| fails to initialize. See
# also: |rtc_initialize_ffmpeg|.
# CHECK THE OPENH264, FFMPEG AND H.264 LICENSES/PATENTS BEFORE BUILDING.
# https://www.wendangku.net/doc/f810405225.html,, https://https://www.wendangku.net/doc/f810405225.html,/
rtc_use_h264 = proprietary_codecs && !is_android && !is_ios
# Determines whether QUIC code will be built.
rtc_use_quic = false
# By default, use normal platform audio support or dummy audio, but don't
# use file-based audio playout and record.
rtc_use_dummy_audio_file_devices = false
# When set to true, test targets will declare the files needed to run memcheck
# as data dependencies. This is to enable memcheck execution on swarming bots.
rtc_use_memcheck = false
# FFmpeg must be initialized for |H264DecoderImpl| to work. This can be done
# by WebRTC during |H264DecoderImpl::InitDecode| or externally. FFmpeg must
# only be initialized once. Projects that initialize FFmpeg externally, such
# as Chromium, must turn this flag off so that WebRTC does not also
# initialize.
rtc_initialize_ffmpeg = !build_with_chromium
# Build sources requiring GTK. NOTICE: This is not present in Chrome OS
# build environments, even if available for Chromium builds.
rtc_use_gtk = !build_with_chromium
}
# A second declare_args block, so that declarations within it can
# depend on the possibly overridden variables in the first
# declare_args block.
declare_args() {
# Include the iLBC audio codec?
rtc_include_ilbc = !(build_with_chromium || build_with_mozilla)
rtc_restrict_logging = build_with_chromium
# Excluded in Chromium since its prerequisites don't require Pulse Audio.
rtc_include_pulse_audio = !build_with_chromium
# Chromium uses its own IO handling, so the internal ADM is only built for
# standalone WebRTC.
rtc_include_internal_audio_device = !build_with_chromium
# Include tests in standalone checkout.
rtc_include_tests = !build_with_chromium
}
# Make it possible to provide custom locations for some libraries (move these
# up into declare_args should we need to actually use them for the GN build).
rtc_libvpx_dir = "//third_party/libvpx"
rtc_libyuv_dir = "//third_party/libyuv"
rtc_opus_dir = "//third_party/opus"
# Desktop capturer is supported only on Windows, OSX and Linux.
rtc_desktop_capture_supported = is_win || is_mac || is_linux
############################################################################### # Templates
#
# Points to //webrtc/ in webrtc stand-alone or to //third_party/webrtc/ in
# chromium.
# We need absolute paths for all configs in templates as they are shared in
# different subdirectories.
webrtc_root = get_path_info(".", "abspath")
# Global configuration that should be applied to all WebRTC targets.
# You normally shouldn't need to include this in your target as it's
# automatically included when using the rtc_* templates.
# It sets defines, include paths and compilation warnings accordingly,
# both for WebRTC stand-alone builds and for the scenario when WebRTC
# native code is built as part of Chromium.
rtc_common_configs = [ webrtc_root + ":common_config" ]
# Global public configuration that should be applied to all WebRTC targets. You # normally shouldn't need to include this in your target as it's automatically
# included when using the rtc_* templates. It set the defines, include paths and # compilation warnings that should be propagated to dependents of the targets # depending on the target https://www.wendangku.net/doc/f810405225.html,ving this config.
rtc_common_inherited_config = webrtc_root + ":common_inherited_config"
# Common configs to remove or add in all rtc targets.
rtc_remove_configs = []
rtc_add_configs = rtc_common_configs
set_defaults("rtc_test") {
configs = rtc_add_configs
suppressed_configs = []
}
set_defaults("rtc_source_set") {
configs = rtc_add_configs
suppressed_configs = []
}
set_defaults("rtc_executable") {
configs = rtc_add_configs
suppressed_configs = []
}
set_defaults("rtc_static_library") {
configs = rtc_add_configs
suppressed_configs = []
}
set_defaults("rtc_shared_library") {
configs = rtc_add_configs
suppressed_configs = []
}
template("rtc_test") {
test(target_name) {
forward_variables_from(invoker,
"*",
[
"configs",
"public_configs",
"suppressed_configs",
])
configs += invoker.configs
configs -= rtc_remove_configs
configs -= invoker.suppressed_configs
public_configs = [ rtc_common_inherited_config ]
if (defined(invoker.public_configs)) {
public_configs += invoker.public_configs
}
}
}
template("rtc_source_set") {
source_set(target_name) {
forward_variables_from(invoker,
"*",
[
"configs",
"public_configs",
"suppressed_configs",
])
configs += invoker.configs
configs -= rtc_remove_configs
configs -= invoker.suppressed_configs
public_configs = [ rtc_common_inherited_config ]
if (defined(https://www.wendangku.net/doc/f810405225.html,.public_configs)) {
public_configs += invoker.public_configs
}
}
}
template("rtc_executable") {
executable(target_name) {
forward_variables_from(invoker,
"*",
[
"deps",
"configs",
"public_configs",
"suppressed_configs",
])
configs += invoker.configs
configs -= rtc_remove_configs
configs -= invoker.suppressed_configs
deps = [
"//build/config/sanitizers:deps",
]
deps += invoker.deps
public_configs = [ rtc_common_inherited_config ]
if (defined(invoker.public_configs)) {
public_configs += invoker.public_configs
}
}
}
template("rtc_static_library") {
static_library(target_name) {
forward_variables_from(invoker,
"*",
[
"configs",
"public_configs",
"suppressed_configs",
])
configs += invoker.configs
configs -= rtc_remove_configs
configs -= invoker.suppressed_configs
public_configs = [ rtc_common_inherited_config ]
if (defined(invoker.public_configs)) {
public_configs += invoker.public_configs
}
}
}
template("rtc_shared_library") {
shared_library(target_name) {
forward_variables_from(invoker,
"*",
[
"configs",
"public_configs",
"suppressed_configs",
])
configs += invoker.configs
configs -= rtc_remove_configs
configs -= invoker.suppressed_configs
public_configs = [ rtc_common_inherited_config ]
if (defined(https://www.wendangku.net/doc/f810405225.html,ublic_configs)) {
public_configs += invoker.public_configs
}
}
}
webrtc.gni 是一个比较特殊的gni 文件，你可以把它看做全局配置文件。
webrtc.gni 定义了WebRTC 项目用到的一些标记，比如rtc_build_libvpx、rtc_build_ssl、rtc_use_h264 等。
还使用template 语句定义了几个模板，比如rtc_executable 、rtc_static_library 、rtc_shared_library ，这几个模板定义了生成可执行文件、静态库、动态库的规则。在webrtc/examples/BUILD.gn 中就有用到这些模板，用它们来指导如何生成可执行文件、静态库等。
你也可以直接使用gn 内置的shared_library 和static_library 来声明目标，比如third_party/ffmpeg/BUILD.gn 就使用shared_library 来生成动态库。
DEPS 文件
给个例子看看吧，webrtc/examples/DEPS ：
include_rules = [
"+WebRTC",
"+webrtc/api",
"+webrtc/base",
"+webrtc/media",
"+webrtc/modules/audio_device",
"+webrtc/modules/video_capture",
"+webrtc/p2p",
"+webrtc/pc",
]
include_rules 定义了包含路径。
修改.gn 和.gni
了解.gn 和.gni 文件的目的是修改它们。比如你想打开WebRTC 对H264 的支持，就可以修改webrtc/webrtc.gni ，直接把rtc_use_h264 设置为true 。
比如你想为某个模块加一些文件，就可以修改.gn 文件，修改sources 变量，直接把你的源文件加进去。
编译程序和解释程序
编译程序和解释程序 程序设计语言处理系统是系统软件中的一大类，它随被处理的语言及其处理方法和处理过程的不同而不同。任何一个语言处理系统通常都包括一个编译程序，它把一种语言的程序翻译成等价的另一种语言的程序。被翻译的语言和程序分别称为源语言和源程序，而翻译生成的语言和程序分别称为目标语言和目标程序，按照不同的翻译处理方法，翻译程序可分为以下三类： ⑴从汇编语言到及其语言的翻译程序，称为汇编程序。 ⑵按源程序中语句的执行顺序，逐条翻译并立即执行相关功能的处理程序、称为解释程序。 ⑶从高级语言到汇编语言（或机器语言）的翻译程序，称为编译语言。 除了翻译程序外，语言处理系统通常还包括连接程序（将多个分别编译或汇编过的目标程序和库文件进行组合）和装入程序（将目标程序装入内存并启动执行）等。 由于汇编语言的指令与机器语言指令大体上保持一一对应关系，因而汇编程序较为简单，一下只对解释程序和编译程序做简单说明。 1、解释程序 解释程序对源程序进行翻译的方法相当于两种自然语言间的口译。解释程序对源程序的语句从头到尾逐句扫描、逐句翻译、并且翻译一句执行一句，因而这种翻译方式并不形成机器语言形式的目标程序。 解释程序的优点是实现算法简单，且易于在解释过程中灵活方便地插入所需要的修改和测试措施；其缺点是运行效率低。例如，对于源程序中需要多次重复执行的语句，解释程序将要反复的取出、翻译和执行它们。根据这些特点，解释程序通常适合于以交互方式工作的、或在测试状态下运行的、或运行时间与解释时间差不多的程序。 2、编译程序 编译程序对源程序进行解释的方法相当于笔译。在编译程序的执行过程中，要对源程序扫描一遍或几遍，最终形成一个可在具体计算机上执行的目标程序。编译程序的实现算法较为复杂，但通过编译程序的处理可以产生高效运行的目标程序，并把它保存在磁盘上，以备多次执行。因此，编译程序更适合于翻译那些规模大、结构复杂、运行时间长的大的应用程序。
编译原理作业参考答案
第1章引言 1、解释下列各词 源语言:编写源程序的语言（基本符号，关键字），各种程序设计语言都可以作为源语言。 源程序: 用接近自然语言（数学语言）的源语言（基本符号，关键字）编写的程序，它是翻译程序处理的对象。 目标程序: 目标程序是源程序经过翻译程序加工最后得到的程序。目标程序 （结果程序）一般可由计算机直接执行。 低级语言：机器语言和汇编语言。 高级语言：是人们根据描述实际问题的需要而设计的一个记号系统。如同自然语言（接近数学语言和工程语言）一样，语言的基本单位是语句，由符号组和一组用来组织它们成为有确定意义的组合规则。 翻译程序: 能够把某一种语言程序（源语言程序）改变成另一种语言程序（目标语言程序），后者与前者在逻辑上是等价的。其中包括：编译程序，解释程序，汇编程序。 编译程序: 把输入的源程序翻译成等价的目标程序（汇编语言或机器语言）， 然后再执行目标程序（先编译后执行），执行翻译工作的程序称为编译程序。 解释程序: 以该语言写的源程序作为输入，但不产生目标程序。按源程序中语句动态顺序逐句的边解释边执行的过程，完成翻译工作的程序称为解释程序。 2、什么叫“遍”？ 指对源程序或源程序的中间形式（如单词，中间代码）从头到尾扫描一次，并作相应的加工处理，称为一遍。 3、简述编译程序的基本过程的任务。 编译程序的工作是指从输入源程序开始到输出目标程序为止的整个过程，整个过程可以划分5个阶段。 词法分析：输入源程序，进行词法分析，输出单词符号。 语法分析：在词法分析的基础上，根据语言的语法规则把单词符号串分解成各类语法单位，并判断输入串是否构成语法正确的“程序”。 中间代码生成：按照语义规则把语法分析器归约（或推导）出的语法单位翻译成一定形式的中间代码。 优化：对中间代码进行优化处理。 目标代码生成：把中间代码翻译成目标语言程序。 4、编译程序与解释程序的区别？ 编译程序生成目标程序后，再执行目标程序；然而解释程序不生成目标程序，边解释边执行。 5、有人认为编译程序的五个组成部分缺一不可，这种看法正确吗？ 编译程序的5个阶段中，词法分析，语法分析，语义分析和代码生成生成是必须完成的。而中间代码生成和代码优化并不是必不可少的。优化的目的是为了提高目标程序的质量，没有这一部分工作，仍然能够得到目标代码。 6、编译程序的分类 目前基本分为：诊断编译程序，优化编译程序，交叉编译程序，可变目标编译程序。
C、C++程序编译过程
C/C++程序编译过程 学习各种外挂制作技术，马上去百度搜索"魔鬼作坊"点击第一个站进入、快速成为做挂达人。 当我们进行编译的时候，要使用一系列的工具，我们称之为工具链。 其中包括： 预处理器CPP 编译器gcc/g++ 汇编器as 连接器ld 一个C/C++程序编译过程包括下面几个阶段： 1.预处理预处理器cpp将对源文件中的宏进行展开。 2.编译gcc将c文件编译成汇编文件。 3.汇编汇编器as将汇编文件编译成机器码。 4.连接链接器ld将目标文件和外部符号进行连接，得到一个可执行二进制文件。 下面以一个很简单的hello.c来探讨这个过程。 #include #define BUFSIZE1024 int main（int argc,char*argv[]） { char hello[BUFSIZE]="Hello my friend!"; printf（"%s\n",hello）； return0; }
1.预处理（预处理器cpp）： gcc会首先调用CPP进行预处理： [butbueatiful@xt myhello]$cpp hello.c>hello.i 或 [butbueatiful@xt myhello]$gcc-E hello.c>hello.i 我们用vi hello.i查看hello.i的内容如下： …… int main（int argc,char*argv[]） { char hello[1024]="Hello my friend!"; printf（"%s\n",hello）； return0; } 我们可以看到，文件中宏定义BUFSIZE出现的位置被1024替换掉了，其它的内容保持不变。 2.gcc将c文件编译成汇编文件（编译器gcc）： 接下来gcc会执行 [butbueatiful@xt myhello]$gcc-S hello.i#得到汇编文件hello.s 3.as将汇编文件编译成机器码（汇编器as）： [butbueatiful@xt myhello]$as hello.s-o hello.o 得到输出文件为hello.o hello.o中为目标机器上的二进制文件
C语言编译过程总结详解
C语言的编译链接过程要把我们编写的一个c程序（源代码）转换成可以在硬件上运行的程序（可执行代码），需要进行编译和链接。编译就是把文本形式源代码翻译为机器语言形式的目标文件的过程。链接是把目标文件、操作系统的启动代码和用到的库文件进行组织形成最终生成可执行代码的过程。过程图解如下： 从图上可以看到，整个代码的编译过程分为编译和链接两个过程，编译对应图中的大括号括起的部分，其余则为链接过程。 编译过程 编译过程又可以分成两个阶段：编译和会汇编。 编译 编译是读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，源文件的编译过程包含两个主要阶段： 第一个阶段是预处理阶段，在正式的编译阶段之前进行。预处理阶段将根据已放置在文件中的预处理指令来修改源文件的内容。如#include指令就是一个预处理指令，它把头文件的内容添加到.cpp文件中。这个在编译之前修改源文件的方式提供了很大的灵活性，以适应不同的计算机和操作系统环境的限制。一个环境需要的代码跟另一个环境所需的代码可能有所不同，因为可用的硬件或操作系统是不同的。在许多情况下，可以把用于不同环境的代码放在同一个文件中，再在预处理阶段修改代码，使之适应当前的环境。 主要是以下几方面的处理： （1）宏定义指令，如 #define a? b 对于这种伪指令，预编译所要做的是将程序中的所有a用b替换，但作为字符串常量的 a 则不被替换。还有 #undef，则将取消对某个宏的定义，使以后该串的出现不再被替换。 （2）条件编译指令，如#ifdef，#ifndef，#else，#elif，#endif等。 这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件，将那些不必要的代码过滤掉。 （3）头文件包含指令，如#include "FileName"或者#include
C语言编译全过程
编译的概念：编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。 编译的完整过程：C源程序－－>预编译处理(.c)－－>编译、优化程序（.s、.asm）－－>汇编程序(.obj、.o、.a、.ko)－－>链接程序（.exe、.elf、.axf等） 1. 编译预处理 读取c源程序，对其中的伪指令（以#开头的指令）和特殊符号进行处理 伪指令主要包括以下四个方面： （1）宏定义指令，如#define Name TokenString，#undef等。 对于前一个伪指令，预编译所要做的是将程序中的所有Name用TokenString替换，但作为字符串常量的Name则不被替换。对于后者，则将取消对某个宏的定义，使以后该串的出现不再被替换。 （2）条件编译指令，如#ifdef，#ifndef，#else，#elif，#endif等。 这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件，将那些不必要的代码过滤掉 （3）头文件包含指令，如#include "FileName"或者#include
编译原理练习题参考答案
一、填空题: 1-01.编译程序的工作过程一般可以划分为词法分析,语法分析,语义分析，之间代码生成,代码优化等几个基本阶段,同时还会伴有表格处理和出错处理 . 1-02.若源程序是用高级语言编写的,目标程序是机器语言程序或汇编程序 ,则其翻译程序称为编译程序. 1-03.编译方式与解释方式的根本区别在于是否生成目标代码 . 1-04.翻译程序是这样一种程序,它能够将用甲语言书写的程序转换成与其等价的用乙语言书写的程 序 . 1-05.对编译程序而言,输入数据是源程序 ,输出结果是目标程序 . 1-06.如果编译程序生成的目标程序是机器代码程序,则源程序的执行分为两大阶段: 编译阶段和运行阶段 .如果编译程序生成的目标程序是汇编语言程序,则源程序的执行分为三个阶段: 编译阶段 , 汇编阶段和运行阶段 . 1-07.若源程序是用高级语言编写的，目标程序是机器语言程序或汇编程序，则其翻译程序称为编译程序。 1-08.一个典型的编译程序中，不仅包括词法分析、语法分析、中间代码生成、代码优化、目标代码生成等五个部分，还应包括表格处理和出错处理。其中，词法分析器用于识别单词。 1-09.编译方式与解释方式的根本区别为是否生成目标代码。 2-01.所谓最右推导是指：任何一步αβ都是对α中最右非终结符进行替换的。 2-02.一个上下文无关文法所含四个组成部分是一组终结符号、一组非终结符号、一个开始符号、一组产生式。 2-03.产生式是用于定义语法成分的一种书写规则。 2-04.设G[S]是给定文法，则由文法G所定义的语言L(G)可描述为：L(G)＝{x│S x,x∈V T*} 。 2-05.设G是一个给定的文法，S是文法的开始符号，如果S x （其中x∈V*），则称x是文法的一个句型。 2-06.设G是一个给定的文法，S是文法的开始符号，如果S x(其中x∈V T*),则称x是文法的一个句子。 3-01.扫描器的任务是从源程序中识别出一个个单词符号。 4-01.语法分析最常用的两类方法是自上而下和自下而上分析法。 4-02.语法分析的任务是识别给定的终极符串是否为给定文法的句子。 4-03.递归下降法不允许任一非终极符是直接左递归的。 4-04.自顶向下的语法分析方法的关键是如何选择候选式的问题。 4-05.递归下降分析法是自顶向上分析方法。 4-06.自顶向下的语法分析方法的基本思想是：从文法的开始符号开始，根据给定的输入串并按照文法的产生式一步一步的向下进行直接推导，试图推导出文法的句子，使之与给定的输入串匹配。 5-01.自底向上的语法分析方法的基本思想是：从给定的终极符串开始，根据文法的规则一步一步的向上进行直接归约，试图归约到文法的开始符号。 5-02.自底向上的语法分析方法的基本思想是：从输入串入手，利用文法的产生式一步一步地向上进行直接归约，力求归约到文法的开始符号。
编译原理过程
编译原理过程及分析 姓名：王伟 学号： 20142217 （2016.12）
编译原理过程及分析 编译器最基本的功能就是把高级语言(例如C/Fortran)编写的代码转化为机器指令(就是01串)，从这个角度来说它本质上是个转换过程。经典的编译过程主要包括： 1、词法分析(Lexical Analysis) 词法分析就是从输入代码中识别出各种记号(token)，例如对于C语言我们就需要知道if,else等是语言的关键字，myvar是个标识，而123myvar不能被识别为一个标识。负责实现词法分析的模块有时也称为scanner。 词法分析的关键当然是语言定义的规则了，比如哪些是关键词，哪些是合法的标识等，这些规则一般是通过正则表达式(RE，Regular Expression)来给出，运行时从输入缓冲区中读入一部分，然后看和哪个RE匹配就知道它到底是个什么token。 下一个问题就是正则表达式的匹配过程如何实现，经典理论对此都会提到有限状态机(FSM, Finite State Machine)。关于FSM在可行性计算里一般都会有不少篇幅分析，在编译里谈到的FSM和RE主要是如何从输入的构成出对应的FSM。 构造的过程一般分为三个步骤： (1)根据Thompson构造法从RE构造出对应的非确定性有限状态机(NFA, Non-deterministic Automata)； (2)经过不断计算epison-闭包(也成为可到达集)构造出确定性有限状态机(DFA, deterministic Automata)； (3)将DFA最小化，方法是增量式地合并不可区分(对于同一输入的下一个状态都一样)的两个状态。 2、语法分析 语法分析的输入是一连串的token(词法分析的输出)，根据语言的语法规则不断解析最后得到一棵抽象语法树(AST, Abstract Syntax Tree)，负责语法分析模块通常也被叫做Parser。在词法分析中，我们经常使用正则表达式来表示语言所接受的token的规则，类似的，在语法分析中，我们使用文法(Grammar)来表示语言的语法规则，这也早期计算机语言设计中的研究热点(同样也是大学里学习编译时最容易让人头晕的东西)。 编译里常说的文法指的是一种上下文无关文法(Context-Free Grammar)，简单地说文法里包含终结符(terminal，就是26个字符、数字等等)、非终结符(nonterminal，实际是一种抽象)和产生式(production)。上下文无关文法要求每个产生式的左边必须恰好是一个非终结符，而右边是0个或多个终结符与非终结符的组合，最后整个文法还必须有一个起始符(某个终结符)。文法里还有些很重要的基本概念，例如推导(derivation)、归约(reduction)、二义性(ambiguity)、最左推导等等。 文法中最重要的基本概念是FIRST集和FOLLOW集的构造。根据这两个集合就可以很容易构造出一个预测分析表，每个行的名字是一个非终结符，每个列的名字是一个终结符，如果每个表格内没有两个以上的项，那么说明是一个LL(1)文法(Left-to-right parse, Leftmost-derivation, 1-symbol lookhead)，简单地说就是向右边看一个符号就能确定下一步动作。当原文法不是LL(1)文法时，可以尝试通过消除左递归(Eliminate Left Recursion)和提取左因子(Left Factoring)对原文法进行变形得到等价的LL(1)文法。
C程序编译过程详解
C程序编译过程详解 概述： C语言编译的整个过程是非常复杂的，里面涉及到的编译器知识、硬件知识、工具链知识都是非常多的，深入了解整个编译过程对工程师理解应用程序的编写是有很大帮助的，希望大家可以多了解一些，在遇到问题时多思考、多实践。一般情况下，我们只需要知道分成编译和连接两个阶段，编译阶段将源程序（*.c)转换成为目标代码（，一般是obj文件，至于具体过程就是上面说的那些阶段），连接阶段是把源程序转换成的目标代码（obj文件）与你程序里面调用的库函数对应的代码连接起来形成对应的可执行文件（exe文件）就可以了，其他的都需要在实践中多多体会才能有更深的理解。 一. 简单解释： 程序的编译过程如上图所示，分为预处理、编译、汇编、链接等几个阶段。 预处理：预处理相当于根据预处理命令组装成新的C程序，不过常以i为扩展名。 编译：将得到的i文件翻译成汇编代码。s文件。 汇编：将汇编文件翻译成机器指令，并打包成可重定位目标程序的O文件。该文件是二进制文件，字节编码是机器指令。 链接：将引用的其他O文件并入到我们程序所在的o文件中，处理得到最终的可执行文件. 二.详细解释 编译的概念：编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。 编译的完整过程：C源程序－－>预编译处理(.c)－－>编译、优化程序（.s、.asm）－－>汇编程序(.obj、.o、.a、.ko)－－>链接程序（.exe、.elf、.axf等） 编译，编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。 C源程序头文件－－>预编译处理(cpp)－－>编译程序本身－－>优化程序－－>汇编程序－－>链接程序-->可执行文件 1.编译预处理 读取c源程序，对其中的伪指令（以#开头的指令）和特殊符号进行处理
程序的编译、运行和调试
2.5 程序的编译、运行和调试(1) 2.5.1 编译和运行 应用程序开发的最后一步就是编译、运行，检查程序错误，并提供用户最终可使用的程序。Delphi 7提供了两种方法对程序进行编译： （1）使用Project菜单中的Compile命令。该命令编译当前项目中所有修改过的文件（自上次生成执行文件以来），生成可执行的EXE文件。如果使用项目组，且要编译项目组中的所有项目，使用Compile All Projects命令。 （2）使用Project菜单中的Build命令。该命令编译当前项目中的所有文件，生成可执行的EXE文件，而不管这些文件修改没有。如果使用项目组，且要编译项目组中所有项目，使用Build All Projects命令。 Delphi 7编译器在生成EXE文件时，遵循下列规则： （1）项目文件（.DPR）每次都要被编译。 （2）如果一个单元的源代码自上次编译后修改过，该单元就要再编译。单元编译后，会生成一个带有.DCU扩展名的文件。 （3）如果Delphi不能定位一个单元的源代码，则那个单元不被编译。 （4）如果一个单元的interface（接口）部分被修改，则所有使用到该单元的单元都要被重新编译。 （5）如果一个单元连接了一个OBJ文件，则OBJ文件一旦被修改，该单元也要被编译。（6）如果一个单元包含一个Include文件，则Include文件一旦被修改，该单元也要被修改。为了显示编译进度和结果，可以选择Tools菜单中Environment Options命令，在对话框中选择Preferences选项卡，从中选择Show compile progress（显示编译进度）选项。如图2.21所示。 如果程序编译成功，单击OK按钮，关闭编译对话框。如果遇到错误，Delphi 7在代码编辑器的状态行报告错误，并把光标定位在包含错误代码的程序行上。出错后的窗体界面如图2.22所示。 要运行程序，可以使用Run菜单中的Run命令，或单击加速条上的Run按钮。该命令同样要编译当前项目中自上次生成执行文件以来所有修改过的文件，生成可执行的EXE文件，并运行该程序。 2.5.2 调试 Delphi提供了一个功能强大的Integrated Debugger（内置调试器），因而对程序的调试不用离开集成开发环境就可以进行。 程序错误基本可以分为两类，即运行时错误和逻辑错误。所谓运行时错误是指程序能正常编译但在运行时出错。逻辑错误是指程序设计和实现上的错误，程序语句是合法的，并顺利执行了，但执行结果却不是所希望的。 对于这两类错误，调试器都可以帮助你快速定位错误，并通过对程序运行的跟踪和对变量值的监视帮助你寻找错误的真正原因和解决错误的途径。 程序调试的主要内容可以概括为如下几方面： （1）准备和开始； （2）控制程序的执行； （3）断点的使用； （4）检查数据的值。 程序调试只有用户实际上机操作才能真正掌握。在这一节中我们主要对调试中的主要问题和一些关键点进行介绍。 1. 调试的准备和开始
编译原理试题及答案
华中科技大学武昌分校 《编译原理》试卷A 专业班级：_________学号：_________姓名：__________总分 一、单项选择题(共10小题，每小题2分) （题分 20分） 1．语言是 A ．句子的集合 B ．产生式的集合 C ．符号串的集合 D ．句型的集合 2．编译程序前三个阶段完成的工作是 A ．词法分析、语法分析和代码优化 B ．代码生成、代码优化和词法分析 C ．词法分析、语法分析、语义分析和中间代码生成 D ．词法分析、语法分析和代码优化 3．一个句型中称为句柄的是该句型的最左 A ．非终结符号 B ．短语 C ．句子 D ．直接短语 4．下推自动机识别的语言是 A ．0型语言 B ．1型语言 C ．2型语言 D ．3型语言 5．扫描器所完成的任务是从字符串形式的源程序中识别出一个个具有独立含义的最小语法单位即 A ． 字符 B ．单词 C ．句子 D ．句型 6．对应Chomsky 四种文法的四种语言之间的关系是 A ．L 0?L 1?L 2?L 3 B ．L 3?L 2?L 1?L 0 C ．L 3=L 2?L 1?L 0 D ．L 0?L 1?L 2=L 3 7．词法分析的任务是 A ．识别单词 B ．分析句子的含义 C ．识别句子 D ．生成目标代码 8．常用的中间代码形式不含 A ．三元式 B ．四元式 C ．逆波兰式 D ．语法树 9． 代码优化的目的是 A ．节省时间 B ．节省空间 装 订 线 得分
C ．节省时间和空间 D ．把编译程序进行等价交换 10．代码生成阶段的主要任务是 A ．把高级语言翻译成汇编语言 B ．把高级语言翻译成机器语言 C ．把中间代码变换成依赖具体机器的目标代码 D ．把汇编语言翻译成机器语言 二、填空题（本大题共5小题，每小题2分）（题分 10分） 1．编译程序首先要识别出源程序中每个( )，然后再分析每个( )并翻译其意义。 2．编译器常用的语法分析方法有( )和( )两种。 3．通常把编译过程分为分析前端与综合后端两大阶段。词法、语法和语义分析是对源程序的( )，中间代码生成、代码优化与目标代码的生成则是对源程序的( )。 4．程序设计语言的发展带来了日渐多变的运行时存储管理方案，主要分为两大类，即：( )方案和( )方案。 5．对编译程序而言，输入数据是( )，输出结果是( )。 三、名词解释题(共5小题，每小题4分) （题分 20分） 1．词法分析 2．LL(1)文法 3．语法树 4．LR(0)分析器 5．语言和文法 四、简答题(共4小题，每小题5分) （题分 20分） 1．编译程序和高级语言有什么区别? 2．编译程序的工作分为那几个阶段? 3．简述自下而上的分析方法。 4．简述代码优化的目的和意义。 五、综合应用题(共3小题，每小题10分) （题分 30分） 得分 得分 得分
C语言的编译系统
从源代码到可执行的目标程序，除了编译器之外往往还需要预处理器、汇编器和链接器。而想让目标代码运行还需要一些工具的支撑，如动态连接程序、无用单元收集程序等，这些工具的集合称为运行系统。 就C 语言而言，其源代码往往分成若干个模块而存储在不同的源文件中，C 编译系统对这些源文件分别进行预处理、编译、汇编过程以形成可重定位的目标文件；然后再使用链接器将这些可重定位的目标文件和必要的库文件链接成一个可执行的目标文件，即具有绝对地址的机器代码，如图： 大多数编译系统提供一个驱动程序来调用预处理器、编译器、汇编器、链接器，以便支持用户完成从源程序到可执行程序的整个开发过程，例如典型的GCC 。 预处理器主要完成文件包含、宏的替换、条件编译等工作。 编译器对预处理器后的C 语言代码进行词法分析和语法分析，在确认所有的指令都符合语法规则之后，将其翻译成等价、优化的中间代码表示或汇编代码。 汇编器主要负责①将表示存储单元的所有标识符都存入符号表并分配地址②将每个操作码译为目标机器代表该操作的二进制位串，并把代表存储单元的每个标识符翻译成符号表中这个标识符所分配的地址。我们必须明确，由于许多没有解决的问题（例如一个汇编文件中存在外部符号的引用，即某个源文件引用了另一源文件中定义的某个符号，如变量或者函数调用等；或者在程序中调用了某个库文件中的函数），所以由汇编器生成的除平坦二进制文件外的其他目标文件都不能立即执行，所有的这些问题都需要经链接器的处理才能解决。 链接是一个收集、组织程序所需的不同代码和数据（因为他们可能在不同的目标文件中），以便程序能被装入内存并被执行的过程。这样，链接器的主要工作就是将有关的目标文件彼此相连接，将在一个文件中引用的符号同该符号在另外一个文件中的定义连接起来，使得所有的这些目标文件成为一个能够被操作系统装入执行的统一整体。 这样，我们就知道目标文件由汇编器或链接器创建，实际上主要分为可重定位的目标文件和可执行的目标文件有两种（还有共享的目标文件）： 可重定位的目标文件包含二进制代码和数据，可以和其他可重定位目标文件链接成一个 可执行的目标文件或更大的可重定位的目标文件 预处理器cpp 源程序 修改后的源程序 *.i 可重定位的目标程序 *.o 库 可重定位的目标文件 编译器ccl 汇编器as 汇编程序 *.s 连接器ld 可执行的目标程序
编译程序和解释程序的区别.doc
编译程序和解释程序的区别 编译和解释的区别是什么? 编译器是把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快; 而解释器则是只在执行程序时,才一条一条的解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行的快的. 这是因为计算机不能直接认识并执行我们写的语句,它只能认识机器语言(是二进制的形式) 一、低级语言与高级语言 最初的计算机程序都是用0和1的序列表示的，程序员直接使用的是机器指令，无需翻译，从纸带打孔输入即可执行得到结果。后来为了方便记忆，就将用0、1序列表示的机器指令都用符号助记，这些与机器指令一一对应的助记符就成了汇编指令，从而诞生了汇编语言。无论是机器指令还是汇编指令都是面向机器的，统称为低级语言。因为是针对特定机器的机器指令的助记符，所以汇编语言是无法独立于机器(特定的CPU体系结构)的。但汇编语言也是要经过翻译成机器指令才能执行的，所以也有将运行在一种机器上的汇编语言翻译成运行在另一种机器上的机器指
令的方法，那就是交叉汇编技术。 高级语言是从人类的逻辑思维角度出发的计算机语言，抽象程度大大提高，需要经过编译成特定机器上的目标代码才能执行，一条高级语言的语句往往需要若干条机器指令来完成。高级语言独立于机器的特性是靠编译器为不同机器生成不同的目标代码(或机器指令)来实现的。那具体的说，要将高级语言编译到什么程度呢，这又跟编译的技术有关了，既可以编译成直接可执行的目标代码，也可以编译成一种中间表示，然后拿到不同的机器和系统上去执行，这种情况通常又需要支撑环境，比如解释器或虚拟机的支持，Java程序编译成bytecode，再由不同平台上的虚拟机执行就是很好的例子。所以，说高级语言不依赖于机器，是指在不同的机器或平台上高级语言的程序本身不变，而通过编译器编译得到的目标代码去适应不同的机器。从这个意义上来说，通过交叉汇编，一些汇编程序也可以获得不同机器之间的可移植性，但这种途径获得的移植性远远不如高级语言来的方便和实用性大。 二、编译与解释 编译是将源程序翻译成可执行的目标代码，翻译与执行是分开的;而解释是对源程序的翻译与执行一次性完成，不生成可存储的目标代码。这只是表象，二者背后的最大区别是：对解释执行而言，程序运行时的控制权在解释器而不在用户程序;对编译执
C程序的编译过程
C程序的编译过程 编译，编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。 C源程序头文件－－>预编译处理(cpp)－－>编译程序本身－－>优化程序－－>汇编程序－－>链接程序-->可执行文件elf 1.编译预处理 读取c源程序，对其中的伪指令（以#开头的指令）和特殊符号进行处理 [析] 伪指令主要包括以下四个方面 （1）宏定义指令，如#define Name TokenString,#undef等。对于前一个伪指令，预编译所要做的是将程序中的所有Name用TokenString替换，但作为字符串常量的Name则不被替换。对于后者，则将取消对某个宏的定义，使以后该串的出现不再被替换。 （2）条件编译指令，如#ifdef,#ifndef,#else,#elif,#endif,等等。这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件，将那些不必要的代码过滤掉 （3）头文件包含指令，如#include "FileName"或者#include
c语言编译过程详解
C语言编译过程总结详解 C语言的编译链接过程要把我们编写的一个c程序（源代码）转换成可以在硬件上运行的程序（可执行代码），需要进行编译和链接。编译就是把文本形式源代码翻译为机器语言形式的目标文件的过程。链接是把目标文件、操作系统的启动代码和用到的库文件进行组织形成最终生成可执行代码的过程。过程图解如下： 从图上可以看到，整个代码的编译过程分为编译和链接两个过程，编译对应图中的大括号括起的部分，其余则为链接过程。 编译过程 编译过程又可以分成两个阶段：编译和会汇编。
编译 编译是读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，源文件的编译过程包含两个主要阶段： 第一个阶段是预处理阶段，在正式的编译阶段之前进行。预处理阶段将根据已放置在文件中的预处理指令来修改源文件的内容。如 #include指令就是一个预处理指令，它把头文件的内容添加到.cpp文件中。这个在编译之前修改源文件的方式提供了很大的灵活性，以适应不同的计算机和操作系统环境的限制。一个环境需要的代码跟另一个环境所需的代码可能有所不同，因为可用的硬件或操作系统是不同的。在许多情况下，可以把用于不同环境的代码放在同一个文件中，再在预处理阶段修改代码，使之适应当前的环境。 主要是以下几方面的处理： （1）宏定义指令，如 #define a b 对于这种伪指令，预编译所要做的是将程序中的所有a用b替换，但作为字符串常量的 a则不被替换。还有 #undef，则将取消对某个宏的定义，使以后该串的出现不再被替换。 （2）条件编译指令，如#ifdef，#ifndef，#else，#elif，#endif 等。 这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件，将那些不必要的代码过滤掉
编译系统内核的基本步骤
编译系统内核的基本步骤 1.将USB线接在3100分析仪两个USB口靠内侧的那个口上，另一端接在我们的电脑上。 准备一条串口线，一端与USB转串口线相连，另一端接3100分析仪的串口。把USB 转串口线接在我们的电脑上。 2.打开系统内核编译软件DNW。 3.在DNW菜单栏上选择Configuration菜单，在弹出的下拉菜单栏选择Option，进入 UART/USB Options界面。 4.在UART/USB Options界面下波特率选择115200，端口选择我们电脑上USB转串口线 正在使用着的端口。设置USB的下载地址为0x30200000。 5.在菜单栏上选择Serial Port菜单，在弹出的下拉菜单中选择Connect。 6.上电启动ARM板。 7.按下ARM板复位键。如果软件设置正确，USB转串口线已接上，DNW软件界面上将 会出现一系列串口打印信息。 8.观察这些信息中的一系列选项。我们会用到的选项有选项0，选项2，选项4，选项7。 选项0意思是通过USB口下载文件。选项2意思是将下载的文件写入flash。选项4意思是擦除flash中已有内容。选项7意思是自启动linux/wince。由于我们用的是Linux 系统，所以选择选项7将会直接启动linux系统。 9.明白各选项所表示的意思后再次按下ARM板的复位键重启ARM板，在按下的同时立 即按下数字键4，擦除flash中已有内容。一定要在按下ARM板复位键的同时立即选择选项4，如果慢了一些的话Linux系统会直接自启动，这时再选择选项4就没有作用了。 10.如果成功选择了选项4，会显示如下4个分区可供选择。
c程序编译连接的原理与过程
从C/C++源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler)翻译成机器代码(再加上其它相关信息)后输出到一个个目标文件(objectfile,VC的编译器编译出的目标文件默认的后缀名是.obj)中；(2)链接器(linker)将一个个的目标文件(或许还会有若干系统库)链接在一起生成一个完整的可执行文件。 C语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态链接库(staticlibrary)。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把(且只把)它们从库中拷贝出来参与构建可执行文件。 链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；(2)集合U是未解析符号(unresolvedsymbols，比如已经被引用但是还未被定义的符号)的集合；(3)集合D是所有之前已被加入到E的目标文件定义的符号集合。一开始，E、U、D都是空的 (1):对命令行中的每一个输入文件f，链接器确定它是目标文件还是库文件，如果它是目标文件，就把f加入到E，并把f中未解析的符号和已定义的符号分别加入到U、D集合中，然后处理下一个输入文件。 (2):如果f是一个库文件，链接器会尝试把U中的所有未解析符号与f中各目标模块定义的符号进行匹配。如果某个目标模块m定义了一个U中的未解析符号，那么就把m加入到E中，并把m中未解析的符号和已定义的符号分别加入到U、D集合中。不断地对f中的所有目标模块重复这个过程直至到达一个不动点(fixed point)，此时U和D不再变化。而那些未加入到E中的f里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。 (3):如果处理过程中往D加入一个已存在的符号，或者当扫描完所有输入文件时U非空，链接器报错并停止动作。否则，它把E中的所有目标文件合并在一起生成可执行文件。 VC带的编译器名字叫cl.exe，它有这么几个与系统库有关的选项: /ML、 /MLd、/MT、/MTd、/MD、/MDd。
编译原理基本知识
编译原理基本知识 基本概念 ?程序生成过程 ?源程序 ---用汇编语言或高级语言编写的程序称为源程序。 ?目标程序 ---用目标语言所表示的程序。可以是介于源语言和机器语言之间的“中间语言”，可以是某种机器的机器语言,也可以是某机器的汇编语言。 ?翻译程序 ---将源程序转换为目标程序的程序称为翻译程序。它是指各种语言的翻译器，包括汇编程序和编译程序，是汇编程序、编译程序以及各种变换程序的总称。 ●诊断编译程序 ●优化编译程序 ●交叉编译程序 ●可变目标编译程序 汇编程序：若源程序用汇编语言书写，经过翻译程序得到用机器语言表示的程序，这时的翻译程序就称之为汇编程序，这种翻译过程称为“汇编”(Assemble）。 编译程序：若源程序是用高级语言书写，经加工后得到目标程序，这种翻译过程称“编译”（Compile)。
需预处理的源程序 绝对机器代码 可再装配目标文件 编译器 编译器就是一个程序，它读入用某种语言编写的源程序，并翻译成一个与之等价的另一种语言编写的源程序。
编译过程的基本阶段 编译过程是指将高级语言程序翻译为等价的目标程序的过程。其一般包含5个基本阶段： 词法分析 任务：分析和识别单词。 描述：源程序是由字符序列构成的，词法分析扫描源程序(字符串)，根据语言的词法规则分析并识别单词，并以某种编码形式输出。 方法：词法分析依照词法规则，识别出正确的单词，转换成统一规格备用。 转换： —对基本字，运算符，界符的转换 —标识符的转换 —常数的转换 —转换完成后的格式（类号，内码） 工具：正规式和有限自动机 例子1： X1:= ( 2.0 + 0.8 ) * C1 1 2 3 4 5 6 7 8 9 例子2： V oid jisuan( ) { int y,c,d;
C语言编译过程 简介和详解
C编译的整个过程很复杂，大致可以分为以下四个阶段： 1）预处理阶段在该阶段主要完成对源代码的预处理工作，主要包括对宏定义指令，头文件包含指令，预定义指令和特殊字符的处理，如对宏定义的替换以及文件头中所包含的文件中预定义代码的替换等，总之这步主要完成一些替换工作，输出是同源文件含义相同但内容不同的文件。 2)编译、优化阶段编译就是将第一阶段处理得到的文件通过词法语法分析等转换为汇编语言。优化包括对中间代码的优化，如删除公共表达式，循环优化等；和对目标代码的生成进行的优化，如如何充分利用机器的寄存器存放有关变量的值，以减少内存访问次数。 3）汇编阶段将汇编语言翻译成机器指令 4）链接阶段链接阶段的主要工作是将有关的目标文件连接起来，即将在一个文件中引用的符号同该符号在另外一个文件中的定义连接起来，使得所有的目标文件成为一个能够被操作系统装入执行的统一整体。 C语言编译编译，编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。 C源程序头文件－－>预编译处理(cpp)－－>编译程序本身－－>优化程序－－>汇编程序－－>链接程序-->可执行文件 1.编译预处理读取c源程序，对其中的伪指令（以#开头的指令）和特殊符号进行处理伪指令主要包括以下四个方面 （1）宏定义指令，如#define Name TokenString,#undef等。对于前一个伪指令，预编译所要做的是将程序中的所有Name用TokenString替换，但作为字符串常量的Name则不被替换。对于后者，则将取消对某个宏的定义，使以后该串的出现不再被替换。