MPLAB XC8 C编译器用户指南：2012-2016年Microchip技术简介与注意事项

4星 · 超过85%的资源需积分: 50 139 浏览量更新于2024-07-17 收藏 5.8MB PDF 举报

"MPLAB XC8 C Compiler 是一款由 Microchip Technology Inc. 在 2012 至 2016 年间发布的编译器，专为 Microchip 的 8 位微控制器（MCU）设计，如 PIC 微控制器系列。DS50002053G 用户手册提供了这款编译器的详细指南，用户可以在此找到针对特定设备的应用程序信息，但请注意，其中提供的内容可能随时间更新，用户应自行确认其应用是否符合自身需求。 MPLAB XC8 C Compiler 是一个针对 C 语言编程的工具，它支持 C99 标准，并优化了对 Microchip 微处理器的性能。该编译器旨在简化开发过程，提供高效、低功耗的代码，适用于嵌入式系统和实时应用。它具有代码优化功能，能够生成高效的目标代码，以满足严格的内存和处理速度要求。手册强调，虽然 Microchip 提供的信息是出于便利性考虑，但它不承担任何明示或暗示的义务，包括但不限于关于产品质量、性能、适销性或特定用途的保证。在使用 Microchip 设备于生命支持或安全相关应用时，用户需自行承担风险，并同意承担由此产生的任何损害、索赔或费用。值得注意的是，MPLAB XC8 C Compiler 不会隐含地授予任何知识产权许可，除非另有明确声明。此外，用户使用本编译器时必须遵守所有适用的法律和规定，确保其项目符合版权和许可证要求。 MPLAB XC8 C Compiler 是一个强大的工具，对于希望利用 Microchip MCU 的开发者来说，学习和掌握它的使用方法对于高效开发和优化嵌入式系统的性能至关重要。在使用过程中，务必注意信息的时效性和适用范围，并遵守相关的法律责任。"

MPLAB

XC8 C Compiler User’s Guide

DS50002053G-page 16  2012-2016 Microchip Technology Inc.

2.2.1 The ANSI Standard

The ANSI C Standard has to reconcile two opposing goals: freedom for compilers ven-

dors to target new devices and improve code generation, with the known functional

operation of source code for programmers. If both goals can be met, source code can

be made portable.

The standard is implemented as a set of rules which detail not only the syntax that a

conforming C program must follow, but the semantic rules by which that program will

be interpreted. Thus, for a compiler to conform to the standard, it must ensure that a

conforming C program functions as described by the standard.

The standard describes implementation, the set of tools, and the runtime environment

on which the code will run. If any of these change, e.g., you build for, and run on, a dif-

ferent target device, or if you update the version of the compiler you use to build, then

you are using a different implementation.

The standard uses the term behavior to mean the external appearance or action of the

program. It has nothing to do with how a program is encoded.

Since the standard is trying to achieve goals that could be construed as conflicting,

some specifications appear somewhat vague. For example, the standard states that an

int type must be able to hold at least a 16-bit value, but it does not go as far as saying

what the size of an int actually is; and the action of right-shifting a signed integer can

produce different results on different implementations; yet, these different results are

still ANSI C compliant.

If the standard is too strict, device architectures cannot allow the compiler to conform.

But, if it is too weak, programmers would see wildly differing results within different

compilers and architectures, and the standard would lose its effectiveness.

The standard organizes source code whose behavior is not fully defined into groups

that include the following behaviors:

Code that strictly conforms to the standard does not produce output that is dependent

on any unspecified, undefined, or implementation-defined behavior. The size of an

int, which was used as an example earlier, falls into the category of behavior that is

defined by implementation. That is to say, the size of an int is defined by which com-

piler is being used, how that compiler is being used, and the device that is being

targeted.

All the MPLAB XC compilers conform to the ANSI X3.159-1989 Standard for program-

ming languages (with the exception of the MPLAB XC8 compiler’s inability to allow

recursion, as mentioned in the footnote). This is commonly called the C89 Standard.

Some features from the later standard, C99, are also supported.

1. For example, the mid-range PIC

microcontrollers do not have a data stack. Because a compiler

targeting this device cannot implement recursion, it (strictly speaking) cannot conform to the ANSI

C Standard. This example illustrates a situation in which the standard is too strict for mid-range

devices and tools.

Implementation-defined

behavior

This is unspecified behavior in which each

implementation documents how the choice is made.

Unspecified behavior The standard provides two or more possibilities and

imposes no further requirements on which possibility is

chosen in any particular instance.

Undefined behavior This is behavior for which the standard imposes no

requirements.

Common C Interface

 2012-2016 Microchip Technology Inc. DS50002053G-page 17

For freestanding implementations (or for what we typically call embedded applications),

the standard allows non-standard extensions to the language, but obviously does not

enforce how they are specified or how they work. When working so closely to the

device hardware, a programmer needs a means of specifying device setup and inter-

rupts, as well as utilizing the often complex world of small-device memory

architectures. This cannot be offered by the standard in a consistent way.

While the ANSI C Standard provides a mutual understanding for programmers and

compiler vendors, programmers need to consider the implementation-defined behavior

of their tools and the probability that they may need to use extensions to the C language

that are non-standard. Both of these circumstances can have an impact on code

portability.

2.2.2 The Common C Interface

The Common C Interface (CCI) supplements the ANSI C Standard and makes it easier

for programmers to achieve consistent outcomes on all Microchip devices when using

any of the MPLAB XC C compilers.

It delivers the following improvements, all designed with portability in mind.

Refinement of the

ANSI C Standard

The CCI documents specific behavior for some code in which

actions are implementation-defined behavior under the ANSI

C Standard. For example, the result of right-shifting a signed

integer is fully defined by the CCI. Note that many

implementation-defined items that closely couple with device

characteristics, such as the size of an int, are not defined by

the CCI.

Consistent syntax

for non-standard

extensions

The CCI non-standard extensions are mostly implemented

using keywords with a uniform syntax. They replace keywords,

macros and attributes that are the native compiler implementa-

tion. The interpretation of the keyword can differ across each

compiler, and any arguments to the keywords can be device

specific.

Coding guidelines The CCI can indicate advice on how code should be written so

that it can be ported to other devices or compilers. While you

may choose not to follow the advice, it will not conform to the

CCI.

MPLAB

XC8 C Compiler User’s Guide

DS50002053G-page 20  2012-2016 Microchip Technology Inc.

2.4.3.2 DIFFERENCES

Header file specifications that use directory separators have been allowed in previous

versions of all compilers. Compatibility problems arose when Windows-style separa-

tors “\” were used and the code was compiled under other host operating systems.

Under the CCI, no directory separators should be used.

2.4.3.3 MIGRATION TO THE CCI

Any #include directives that use directory separators in the header file specifications

should be changed. Remove all but the header file name in the directive. Add the direc-

tory path to the compiler’s include search path or MPLAB X IDE equivalent. This will

force the compiler to search the directories specified with this option.

For example, the following code:

#include <inc/lcd.h>

should be changed to:

#include <lcd.h>

and the path to the inc directory added to the compiler’s header search path in your

MPLAB X IDE project properties, or on the command-line as follows:

-Ilcd

2.4.4 Include Search Paths

When you include a header file under the CCI, the file should be discoverable in the

paths searched by the compiler that are detailed below.

Header files specified in angle bracket delimiters < > should be discoverable in the

search paths that are specified by -I options (or the equivalent MPLAB X IDE option),

or in the standard compiler include directories. The -I options are searched in the

order in which they are specified.

Header files specified in quote characters " " should be discoverable in the current

working directory or in the same directories that are searched when the header files are

specified in angle bracket delimiters (as above). In the case of an MPLAB X project, the

current working directory is the directory in which the C source file is located. If unsuc-

cessful, the search paths should be to the same directories searched when the header

file is specified in angle bracket delimiters.

Any other options to specify search paths for header files do not conform to the CCI.

2.4.4.1 EXAMPLE

If including a header file, as in the following directive:

#include "myGlobals.h"

The header file should be locatable in the current working directory, or the paths spec-

ified by any -I options, or the standard compiler directories. A header file being located

elsewhere does not conform to the CCI.

2.4.4.2 DIFFERENCES

The compiler operation under the CCI is not changed. This is purely a coding guideline.

2.4.4.3 MIGRATION TO THE CCI

Remove any option that specifies header file search paths other than the -I option (or

the equivalent MPLAB X IDE option), and use the -I option in place of this. Ensure the

header file can be found in the directories specified in this section.

剩余605页未读，继续阅读

ff1234evf

粉丝: 0
资源: 1

MPLAB XC8 C编译器用户指南：2012-2016年Microchip技术简介与注意事项

MPLAB xc8 1.35版本可用破解

最新版xc8 v2.0破解

XC8破解文件及PIC编译器资源包

MPLAB® XC8 C Compiler

MPLAB_XC8_C_Compiler_User_Guide_for_PIC.pdf

MPLAB XC8 C编译器用户指南：PIC MCUs应用详解

MPLAB XC8编译器：CCI特性和使用

MPLAB XC8C编译器的CCI特性与选项详解

MPLAB® XC16 C 编译器用户指南

MPLAB编译器xc16-v1.70

最新资源