ࡱ> c T bjbj W\W\F#F#001114111h^2J41V6jx<p<<<S ]`p$k!01b6S"XS|bb00<<Nmmmbx0<1<mbmmjx1J <p\%f20QjizQdQ1ܩbbmbbbbbkbbbbbbbQbbbbbbbbbF#> /: ACPI Component Architecture Design and Software Internals OS-Independent Kernel Subsystem, Debugger, and Utilities PRELIMINARY DRAFT/OUTLINE Revision 0.2 May 31, 2017 Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. Except as provided in Intels Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The ACPI Component Architecture may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Copyright 2015 - 2017 Intel Corporation *Other brands and names are the property of their respective owners. Contents  TOC \o "3-4" \t "Heading 1,1,Heading 2,2,App_Level 1,1,App_Level 2,2,App_Level 3,3,App_Level 4,4" 1 Introduction  PAGEREF _Toc483983684 \h 8 1.1 Document Structure  PAGEREF _Toc483983685 \h 8 1.2 Document History  PAGEREF _Toc483983686 \h 8 2 Internal Structural Overview  PAGEREF _Toc483983687 \h 9 3 Kernel-resident ACPICA  PAGEREF _Toc483983688 \h 10 3.1 Table Manager  PAGEREF _Toc483983689 \h 10 3.2 Namespace Manager  PAGEREF _Toc483983690 \h 10 3.2.1 Main Namespace Data Structure  PAGEREF _Toc483983691 \h 10 3.3 AML Interpreter Overview  PAGEREF _Toc483983692 \h 11 3.4 AML Parser  PAGEREF _Toc483983693 \h 11 3.4.1 AML Opcode Info Structure  PAGEREF _Toc483983694 \h 11 3.4.2 Walk State Data Structure  PAGEREF _Toc483983695 \h 11 3.5 AML Dispatcher  PAGEREF _Toc483983696 \h 11 3.6 AML Executer  PAGEREF _Toc483983697 \h 11 3.6.1 AML Opcode Dispatch  PAGEREF _Toc483983698 \h 11 3.7 Event Manager  PAGEREF _Toc483983699 \h 12 3.8 Hardware Manager  PAGEREF _Toc483983700 \h 12 3.9 Resource Manager  PAGEREF _Toc483983701 \h 12 3.10 AML Debugger  PAGEREF _Toc483983702 \h 13 3.11 AML Disassembler  PAGEREF _Toc483983703 \h 13 3.12 OS Services Layer (OSL)  PAGEREF _Toc483983704 \h 13 4 iASL Compiler/Disassembler  PAGEREF _Toc483983705 \h 14 4.1 Preprocessor  PAGEREF _Toc483983706 \h 14 4.2 Core ASL Compiler  PAGEREF _Toc483983707 \h 14 4.2.1 ASL+ Language Support  PAGEREF _Toc483983708 \h 14 4.2.2 Optimizations  PAGEREF _Toc483983709 \h 15 4.2.3 Constant Folding  PAGEREF _Toc483983710 \h 16 4.2.4 External declarations  PAGEREF _Toc483983711 \h 16 4.3 Data Table Compiler  PAGEREF _Toc483983712 \h 16 4.4 AML Disassembler  PAGEREF _Toc483983713 \h 16 4.4.1 ASL+ Language Support  PAGEREF _Toc483983714 \h 16 4.4.2 Disassembly of External objects  PAGEREF _Toc483983715 \h 17 4.4.2.1 Disassembly of External Op  PAGEREF _Toc483983716 \h 17 4.4.2.2 Guessing External objects  PAGEREF _Toc483983717 \h 17 4.4.3 Disassembly of Control Method Invocations  PAGEREF _Toc483983718 \h 17 4.4.3.1 ACPI 6.0 Solution External() AML Opcode  PAGEREF _Toc483983719 \h 18 4.5 ASL to ASL+ Code Converter  PAGEREF _Toc483983720 \h 18 4.5.1 Compile Phase  PAGEREF _Toc483983721 \h 19 4.5.2 Disassemble Phase  PAGEREF _Toc483983722 \h 19 4.5.3 Comment Types  PAGEREF _Toc483983723 \h 19 4.5.4 Multiple Input Files (via Include Directives)  PAGEREF _Toc483983724 \h 21 4.6 Output Options  PAGEREF _Toc483983725 \h 22 5 AcpiExec Utility  PAGEREF _Toc483983726 \h 23 5.1 ACPI Tables  PAGEREF _Toc483983727 \h 23 5.2 Operation Regions and Handlers  PAGEREF _Toc483983728 \h 23 6 AcpiDump and AcpiXtract Utilities  PAGEREF _Toc483983729 \h 24 7 ACPICA Source Code  PAGEREF _Toc483983730 \h 25 7.1 Source Code Structure  PAGEREF _Toc483983731 \h 25 7.2 Coding Standards and Conventions  PAGEREF _Toc483983732 \h 26 7.2.1 C Bitfields  PAGEREF _Toc483983733 \h 26 7.3 Generating ACPICA from Source Code  PAGEREF _Toc483983734 \h 26 7.3.1 Generic Unix Makefiles  PAGEREF _Toc483983735 \h 26 7.3.2 Visual Studio Project Files  PAGEREF _Toc483983736 \h 28 7.3.3 iASL Compiler  PAGEREF _Toc483983737 \h 29 8 Instructions and Tutorials  PAGEREF _Toc483983738 \h 32 8.1 Adding new ACPI Tables  PAGEREF _Toc483983739 \h 32 8.1.1 ACPICA Header Support  PAGEREF _Toc483983740 \h 32 8.1.1.1 ACPI Table Naming Conventions  PAGEREF _Toc483983741 \h 33 8.1.2 iASL Disassembler Support  PAGEREF _Toc483983742 \h 33 8.1.3 iASL Table Compiler Support  PAGEREF _Toc483983743 \h 34 8.1.4 iASL Template Support (-T option)  PAGEREF _Toc483983744 \h 35 8.2 Adding new ACPI Predefined Names  PAGEREF _Toc483983745 \h 36 8.2.1 Return Value Package Types  PAGEREF _Toc483983746 \h 37 8.2.1.1 PTYPE1 Return Package Objects  PAGEREF _Toc483983747 \h 37 8.2.1.2 PTYPE2 Return Package Objects  PAGEREF _Toc483983748 \h 37 8.3 Adding new AML Operators/Opcodes  PAGEREF _Toc483983749 \h 39 8.3.1 ACPICA Core and Interpreter  PAGEREF _Toc483983750 \h 39 8.3.2 iASL Compiler  PAGEREF _Toc483983751 \h 40 8.4 Adding new iASL Preprocessor Directives  PAGEREF _Toc483983752 \h 41 8.5 Building an ACPICA Release  PAGEREF _Toc483983753 \h 42 8.5.1 Required Tools  PAGEREF _Toc483983754 \h 42 8.5.1.1 Documentation Tools  PAGEREF _Toc483983755 \h 42 8.5.1.2 Windows Tools  PAGEREF _Toc483983756 \h 42 8.5.1.3 Cygwin for Windows  PAGEREF _Toc483983757 \h 43 8.5.1.4 Other Issues  PAGEREF _Toc483983758 \h 43 8.5.2 Generating the ACPICA Release  PAGEREF _Toc483983759 \h 44 8.5.2.1 Finish the Software and Documentation  PAGEREF _Toc483983760 \h 44 8.5.2.2 Write the Release Notes  PAGEREF _Toc483983761 \h 44 8.5.2.3 Build the Software  PAGEREF _Toc483983762 \h 44 8.5.3 Updating the ACPICA Website  PAGEREF _Toc483983763 \h 45 8.5.3.1 ACPICA Version Number  PAGEREF _Toc483983764 \h 45 8.5.3.2 File Pathnames  PAGEREF _Toc483983765 \h 45 8.5.3.3 ACPICA Documents  PAGEREF _Toc483983766 \h 45 8.5.3.4 Release Notes  PAGEREF _Toc483983767 \h 46  Figures  TOC \f f \c "Figure" Figure 1. Internal Modules of the ACPICA Subsystem  PAGEREF _Toc478124672 \h 9  Introduction This document is intended to present and describe the low-level internal designs of the ACPICA software. For a high-level overview and architecture of the ACPICA design, see the ACPI Component Architecture User Guide and Programmer Reference. Document Structure Document History April 2015 Initial version. Contains mostly instructions, data structures and other internals to be added later. May 2017 Added description of the ASL-to-ASL+ converter. Internal Structural Overview Figure  SEQ Figure \* ARABIC 1. Internal Modules of the ACPICA Subsystem  SHAPE \* MERGEFORMAT  Kernel-resident ACPICA The ACPICA subsystem has been optimized to minimize code and data size at the expense of performance. The relatively static internal namespace data structure has been optimized to minimize non-paged kernel memory use, and control method execution parse trees are created at the beginning of method execution and freed immediately upon method termination. OS-independence is achieved via the OS Services Layer which must be implemented anew to interface to each host OS. It abstracts common OS functions such as memory management and synchronization to common external interfaces. These common interfaces are in turn called by the ACPICA subsystem, and they are implemented within the OSL with primitives that are specific to the host. Table Manager The ACPI Table Manager controls the ACPI tables that are presented to the host OS by the BIOS. The ACPI subsystem owns and directly consumes the FADT, FACS, DSDT, and any SSDTs. All other ACPI tables are owned by the host power management code (OSPM) and the various ACPI-related device drivers. External interfaces are provided for the host to obtain these secondary ACPI tables. Namespace Manager The ACPI namespace is one of the fundamental data structures within the subsystem. It is constructed from the ACPI names that appear in the DSDT and any SSDTs. It is heirarchically organized, matching the object heirarchy that appears in the ACPI tables. Main Namespace Data Structure typedef struct acpi_namespace_node { ACPI_OPERAND_OBJECT *Object; /* Interpreter object */ UINT8 DescriptorType; /* Differentiate object descriptor types */ UINT8 Type; /* ACPI Type associated with this name */ UINT8 Flags; /* Miscellaneous flags */ ACPI_OWNER_ID OwnerId; /* Node creator */ ACPI_NAME_UNION Name; /* ACPI Name, always 4 chars per ACPI spec */ ACPI_NAMESPACE_NODE *Parent; /* Parent node */ ACPI_NAMESPACE_NODE *Child; /* First child */ ACPI_NAMESPACE_NODE *Peer; /* First peer */ } ACPI_NAMESPACE_NODE; AML Interpreter Overview The AML Interpreter component actually consists of three separate subcomponents: The AML Parser reads the raw AML code and builds parse trees. Before execution of each control method, the method is parsed and a parse tree is constructed. The Dispatcher builds an an execution stack that is appropriate for the interpreter, along with the AML opcode and the associated operands. It is essentially the interface layer between the AML Parser and the AML Executer. The AML Executer provides the actual execution of the individual AML opcodes. AML Parser The AML Parser performs the extraction of the raw AML code from the ACPI tables, organizing the operators and their arguments into parse trees. There are no external interfaces to the AML Parser. AML Opcode Info Structure AcpiGbl_OpTypeDispatch opcode class Walk State Data Structure ACPI_WALK_STATE AML Dispatcher The AML Dispatcher is the interface between the parser and the interpreter. There are no external interfaces to the Dispatcher. AML Executer The AML Interpreter provides the actual implementation of the various ASL operators (via their associated AML opcodes). AML Opcode Dispatch Dispatch by opcode class Naming convention for AML interpreter execution routines. The routines that begin execution of AML opcodes are named with a common convention based upon the number of arguments, the number of target operands, and whether or not a value is returned: AcpiExOpcode_xA_yT_zR Where: xA - ARGUMENTS: The number of arguments (input operands) that are required for this opcode type (0 through 6 args). yT - TARGETS: The number of targets (output operands) that are required for this opcode type (0, 1, or 2 targets). zR - RETURN VALUE: Indicates whether this opcode type returns a value as the function return (0 or 1). The AcpiExOpcode* functions are called via the Dispatcher component with fully resolved operands. Event Manager The Event Manager provides support and interfaces for the General Purpose Events (GPEs) and the Fixed Events such as the power button. It uses the Hardware Manager to communicate with the various ACPI registers. Hardware Manager The Hardware Manager owns the various ACPI hardware and the associated registers. This includes: SCI handler (System Control Interrupt) General Purpose Events Fixed Events ACPI PM Timer Resource Manager The resource manager simplifies the use of the various resource control methods and the data that they either return or accept as input. AML Debugger The Debugger is an optional component that is intended to be integrated with an existing kernel debugger. AML Disassembler In the context of a kernel environment, the disassembler works in conjunction with the AML debugger to enhance single-step support by disassembling the current AML operator to the corresponding ASL source code. OS Services Layer (OSL) An OS services layer provides the actual interface to the host operating system. It allows the rest of ACPICA to be OS-independent by implemented the standard OSL interfaces via host operating system primitives. iASL Compiler/Disassembler Three main components: ASL+ compiler Data Table compiler AML disassembler Preprocessor The ASL Preprocessor is used by both the iASL compiler and the iASL Data Table compiler. Core ASL Compiler Flex Bison Code Generation ASL+ Language Support Support for symbolic ASL operators (ACPI 6.0) is implemented almost entirely in the ASL parser (Bison generated). This is where the symbolic operators are converted to the identical parse tree as would be generated by the legacy operators. Legacy ASL Code (Pre-ACPI 6.0): If (LOr (LOr (LEqual (And (R510, 0x03FB), 0x02E0), LEqual (And (R520, 0x03FB), 0x02E0)), LOr (LEqual ( And (R530, 0x03FB), 0x02E0), LEqual (And (R540, 0x03FB), 0x02E0)))) { And (MEMB, 0xFFFFFFF0, SRMB) Store (MEMB, Local2) Store (PDBM, Local1) And (PDBM, 0xFFFFFFFFFFFFFFF9, PDBM) Store (SRMB, MEMB) Or (PDBM, 0x02, PDBM) } ASL+ Symbolic Code (ACPI 6.0 and later): If (((R510 & 0x03FB) == 0x02E0) || ((R520 & 0x03FB) == 0x02E0) || ((R530 & 0x03FB) == 0x02E0) || ((R540 & 0x03FB) == 0x02E0)) { SRMB = (MEMB & 0xFFFFFFF0) Local2 = MEMB Local1 = PDBM PDBM &= 0xFFFFFFFFFFFFFFF9 MEMB = SRMB PDBM |= 0x02 } Legacy ASL: Store (0x1234, Local1) Multiply (Add (Add (Local1, TEST), 0x20), Local2, Local3) Multiply (Local2, Add (Add (Local1, TEST), 0x20), Local3) Add (Local1, Add (TEST, Multiply (0x20, Local2)), Local3) Store (Index (PKG1, 0x03), Local6) Store (Add (Local3, Local2), Debug) Add (Local1, 0x0F, Local2) Add (Local1, Multiply (Local2, Local3), Local2) Multiply (Add (Add (Local1, TEST), 0x20), ToBCD (Local1), Local3) ASL+ version: Local1 = 0x1234 Local3 = (((Local1 + TEST) + 0x20) * Local2) Local3 = (Local2 * ((Local1 + TEST) + 0x20)) Local3 = (Local1 + (TEST + (0x20 * Local2))) Local6 = Index (PKG1, 0x03) Debug = (Local3 + Local2) Local2 = (Local1 + 0x0F) Local2 = (Local1 + (Local2 * Local3)) Local3 = (((Local1 + TEST) + 0x20) * ToBCD (Local1)) The implementation of each of the symbolic operators is relatively simple. There is a rule for each in: source/compiler/aslrules.c Each rule simply maps the symbolic operator and its operands to the equivalent legacy ASL operator: | TermArg PARSEOP_EXP_ADD {$$ = TrCreateLeafNode (PARSEOP_ADD);} TermArg {$$ = TrLinkChildren ($3,3,$1,$4,TrCreateNullTarget ());} This rule maps TermArg + TermArg to Add (TermArg, TermArg) Optimizations iASL provides several AML optimizations. These are optional and can be disabled. Integer optimizations Namestring optimizations Constant Folding Add (3, 4, X) ( Store (7, X) X = 3 + 4 ( Store (7, X) Constant Folding External declarations From the ACPI spec The External directive informs the ASL compiler that the object is declared external to this table so that no errors will be generated for an undeclaraed object. The iASL compiler generates a 0x15 opcode to represent external declarations. Since not all AML interpreters support this opcode, all 0x15 opcodes are surrounded by an if(0) statement to prevent this opcode from being evaluated. Past compilers have emitted conflicting declarations for named objects by emitting both External declarations and local declarations. Since the External declarations mean that the named object lies outside of the table and local declarations mean that the named object lies inside of the table, the declaration of the named object has a conflicting declaration if both cases are present within the same table. The current compiler results in a compilation error when it detects conflicting declarations. This can be solved by removing the unnecessary external declaration. In order to detect conflicting external declarations, each table is assigned an owner ID. Each namespace node is assigned an owner ID and the compiler uses this infromation to detect conflicting external declarations during namespace loading. Data Table Compiler Tables and SubTables DT_FIELD AML Disassembler The Disassembler is primarily used within the iASL compiler to disassemble ACPI AML tables (DSDT/SSDT) and Data Tables (FADT, MADT, etc.) It is also integrated with the ACPICA Debugger to provide source-level single-step support and disassembly of individual control methods. The AML Debugger is used within the AcpiExec utility and can also be integrated into a kernel-level debugger. ASL+ Language Support The ACPICA Disassembler is capable of disassembling code to both ASL formats both symbolic ASL+ code and legacy ASL code. In fact, use of the disassembler is a handy way to convert existing ASL/AML code to the symbolic ASL format. The default disassembler behavior is to disassemble to the ASL+ symbolic operator format. Disassembly of External objects External objects come in two forms: objects encoded with the External Op bytecode (0x15) and NamePaths that do not have declarations within its definition block. In the latter case, the NamePath is guessed as an external object. Disassembly of External Op The AML parser processes External opcodes similar to a named object. During namespace resolution, the semantics are relaxed to emit any potential conflicting external declarations. The disassembler does not fail in an error when emitting the conflicting declaration because the role of the disassembler is to emit ASL based on the input AML. The disassembler is not intended to fix the AML. Guessing External objects When the disassembler encounters a name string that is not defined, it guesses that namestring as an external object. This guessing is done during the namespace cross-reference after the AML parser has finished parsing. Disassembly of Control Method Invocations Summary of the external control method problem: When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in order to resolve control method references (invocations). The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number of arguments . Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the disassembler does not know how many arguments to parse. An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control methods that invoke ABCD and EFGH, named T1 and T2: Method (ABCD, 1) { } Method (EFGH, 0) { } Method (T1) { ABCD (Add (2, 7, Local0)) } Method (T2) { EFGH () Add (2, 7, Local0) } Here is the AML code that is generated for T1 and T2: 185: Method (T1) 0000034C: 14 10 54 31 5F 5F 00 ... "..T1__." 186: { 187: ABCD (Add (2, 7, Local0)) 00000353: 41 42 43 44 ............ "ABCD" 00000357: 72 0A 02 0A 07 60 ...... "r....`" 188: } 190: Method (T2) 0000035D: 14 10 54 32 5F 5F 00 ... "..T2__." 191: { 192: EFGH () 00000364: 45 46 47 48 ............ "EFGH" 193: Add (2, 7, Local0) 00000368: 72 0A 02 0A 07 60 ...... "r....`" 194: } Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the disassembler, otherwise it does not know how to handle the method invocations. In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless the owning SSDT has been loaded via the -e option. ACPI 6.0 Solution External() AML Opcode In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only purpose is to assist the disassembler with the control method argument count problem. c ASL to ASL+ Code Converter This section provides a high-level explanation of how the converter works. The converter can be described in 2 stages, a compile stage followed by a disassemble phase. Compile Phase The main goal in the compilation phase is to generate AML bytecode with a special comment op bytecode. The comments are extracted from ASL source in AslDoComment() and AslDoCommentType2() within aslsupport.l. Once a comment is captured, it is categorized using CvProcessCommentState() and placed within an acpi_parse_object using CvPlaceComment() within aslsupport.l. Once the ASL has been parsed and the comments have been associated with their respective parse node, the package lengths are computed. Since we need to output the comments in AML bytecode, the lengths of the comments will be accounted for within the parent parse node. After package length computation, the AML bytecode generation begins. Each comment associated with a parse node will be printed before the actual bytecode. The comment bytecode has the following format: [AML_COMMENT_OP] [Category number] [comment contents] [null terminator] As an example, a regular comment such as "/* Comment 1 */" will be encoded as 0xA9 0x01 /* Comment 1 */ 0x00 For more information on comment categories, refer to the Comment types section. Once the codegen walk has completed, the AML is ready to be disassembled. Disassemble Phase The disassembler takes AML containing the comment bytecode and outputs a dsl file with comments contained within the AML. As the AML is scanned, comments are detected within the parse loop through CvCaptureCommentsOnly() and CvCaptureComments() within cvparser.c. These functions store comments within global pointer variables and place them into the parse node associated with the bytecode that comes after the comment bytecode. For example, the following line is bytecode that encodes a comment that is preceded by a 0x08 opcode (also known as AML_NAME_OP). 0xA9 0x01 /* Comment 1 */ 0x00 0x08 ... When scanning the AML, CvCaptureCommentsOnly() will place the comment in a global list. After a new parse object is created for the 0x08 bytecode, the comments within this global list will be transferred to the newly created parse object of the 0x08 bytecode. After the parse tree has been built, the disassembler will walk the parse tree and generate ASL code of the parse tree. As the disassembler walks the parse tree comments are printed in the approperiate places using functions within cvdisasm.c. Comment Types There are several different places that a comment could show up within ASL code. The following is a list of comment types that are used in this converter: STANDARD_COMMENT - These are comments between blocks of code. Example: /* This is a STANDARD_COMMENT */ Name (a, 0) INLINE_COMMENT - These are comments that come after code on the same line but come before the closing paren. Example: Name (a, 0 /* this is an INLINE_COMMENT of 0*/ ) ENDNODE_COMMENT - These are inline comments that come after the closing paren. Example: Name (a, 0) /* this is an ENDNODE_COMMENT of name */ CLOSEBRACE_COMMENT - These are comments that come after a closing brace. Example: if(0){++i} /* this is a CLOSEBRACE_COMMENT of if */ ENDBLK_COMMENT - These are comments between a piece of code and close brace. Example: if(0){++i /* this is an ENDBLK_COMMENT of if */ } INCLUDE_COMMENT - These are comments above ASL include statements. Example: /* this is an include comment of Include */ Include ("file.asl") STANDARD_DEFBLK_COMMENT - These comments are comments that come before a definitionblock. Example: /* this is an STANDARD_DEFBLK_COMMENT */ DefinitionBlock(){} END_DEFBLK_COMMENT - These comments are comments that come after the closing brace of a definition block Example: /* this is a STANDARD_DEFBLK_COMMENT */ DefinitionBlock() { return 0 /* this is an ENDBLK_COMMENT */ } /* This is a CLOSEBRACE_COMMENT */ /* This one is an END_DEFBLK_COMMENT */ Since some comment types could span multiple lines, each line of STD_DEFBLK_COMMENT, END_DEFBLK_COMMENT, COMMENT_STANDARD, INCLUDECOMMENT, and ENDBLKCOMMENT are stored as separate nodes within a linked list. This facilitates indentation of each line of multiline comments. All other comments are stored within a single char* variable in ACPI_PARSE_COMMON. Multiple Input Files (via Include Directives) Multiple files - Because ASL files can contain include statements, the converter needs to be able to output the converted versions of the included files. In order to do this, the compiler generates FILENAME_COMMENT and PARENTFILENAME_COMMENT bytecodes in the AML. These bytecodes can appear as just a FILENAME_COMMENT or a FILENAME_COMMENT immediately followed by PARENTFILENAME_COMMENT. These comments serve as markers within the bytecode as to which parts of the bytecode belong to specific files. For example, lets say that we have the following ASL file structure: ex1.asl: DefinitionBlock("ex1.aml", "DSDT", 0x02, "Intel", "Many", 0x00000001) { [ ASL code for ex1.asl ] Include("ex2.asl") [ More ASL code for ex1.asl ] } ex2.asl: (Note, this file only contains a single ASL include statement) Include("ex3.asl") ex3.asl: [ ASL code for ex3.asl ] After compilation, the bytecode would look something like this: 1 [ AML table header ] 2 /* This is a marker to denote that ex1.dsl starts here */ 3 0xA9 0x08 "ex1.dsl" 0x00 4 [ AML code for ex1.asl ] 5 /* This is a marker that ex2.dsl starts here and that ex2.dsl is included in ex1.dsl */ 6 0xA9 0x08 "ex2.dsl" 0x00 0xA9 0x09 "ex1.dsl" 0x00 7 /* This is a marker that ex3.dsl starts here and that ex3.dsl is included in ex2.dsl */ 8 0xA9 0x08 "ex3.dsl" 0x00 0xA9 0x09 "ex2.dsl" 0x00 9 [ AML code for ex3.asl ] 10 /* This is a marker to denote that ex1.dsl starts again here */ 11 0xA9 0x08 "ex1.dsl" 0x00 12 [ More AML code for ex1.asl ] Given this bytecode, the AML parser builds a filetree based on examining the FILENAME_COMMENT and PARENTFILENAME_COMMENT. For the above bytecode, we will get a filetree that looks something like this: ex3.dsl -> ex2.dsl -> ex1.dsl note: the "->" denotes a parent relationship. Each node within this tree will contain a range of addresses for that file with the parent file spanning the entire length of all of their child files. After the file tree has been initialized, the AML parser begins parsing the AML bytecode. As the parser creates new parse objects, the AML address of that bytecode is searched in the filetree. If an AML address falls within a particular filenode's range, the parse node's filename field is assigned to the filenode's filename field. After the AML parsetree is built, each node is annotated with which file it belongs to. During the disassembly walk, each parsenode is output to their respective files. When a file change is detected, an include statement and comments associated with the include statement is printed and ASL output is switched to the included file. Output Options AcpiExec Utility Contains the entire ACPICA kernel subsystem, executing in user space. Does not attempt to access actual hardware. Human interface is based upon the ACPICA AML Debugger commands. Primary use is to load and debug foreign ACPI tables (not local to the machine where AcpiExec is running). Executes control methods and allows examination of all ACPI objects. ACPI Tables Operation Regions and Handlers AcpiDump and AcpiXtract Utilities Tools to obtain all ACPI tables, transport them via ASCII hex tables, and restore them to binary ACPI tables. AcpiDump Will extract all available ACPI tables on the platform AcpiXtract Restore ACPI tables to binary format from the AcpiDump Ascii hex dump format ACPICA Source Code Source Code Structure The ACPICA source code as released is organized as below. At the top level, there are separate directories for the ACPICA documentation, generation tools, and the actual C source code. The source code itself is organized into a separate directory for each major ACPICA component, tool, or test. acpica/ documents // Acpica/iASL documentation generate // Source generation tools: lint // PC-lint files linux // Linux makefiles msvc // Microsoft VC++ 6.0 makefiles(obsolete) msvc9 // Microsoft VC++ 9.0 makefiles release // Release utilities unix // Generic Unix/gcc makefiles source // Entire ACPICA source code tree: common // Common files compiler // iASL compiler components // Main ACPICA components: debugger // AML Debugger disassembler // AML Disassembler dispatcher // AML Interpreter dispatcher events // ACPI Event Manager (GPEs etc.) executer // Main AML Interpreter hardware // ACPI Hardware Manager namespace // ACPI Namespace Manager parser // AML Interpreter parser resources // ACPI Resource Manager tables // ACPI Table Manager utilities // Miscellaneous utilities include // Most ACPICA includes platform // Platform-specific files os_specific // OS-specific files service_layers // Various OSLs tools // ACPICA tools/utilities: acpibin // Binary file utility acpiexec // ACPI user space executer acpihelp // ACPI help utility acpinames // Example namespace dump utility acpisrc // Source translation utility acpixtract // Table extraction utility examples // ACPICA example code tests // ACPICA test suites: aapits // ACPICA interface tests aslts // ASL test suite misc // Miscellaneous ASL tests templates // iASL table template generation tests Coding Standards and Conventions ACPICA and related utilities are written entirely in ANSI C. The goal is to make the source code entirely portable across as many C compilers as possible. Complex expressions have been kept to a minimum wherever possible, in order to avoid possible C compiler bugs in the various compilers that are used to compile ACPICA. Bool C Bitfields C bitfields are not used in ACPICA (especially for the ACPI tables) for portability reasons: "Bitfields are great and easy to read, but unfortunately the C language does not specify the layout of bitfields in memory, which means they are essentially useless for dealing with packed data in on-disk formats or binary wire protocols." (Or ACPI tables and buffers.) "If you ask me, this decision was a design error in C. Ritchie could have picked an order and stuck with it." Norman Ramsey. See  HYPERLINK "http://stackoverflow.com/a/1053662/41661" http://stackoverflow.com/a/1053662/41661 In other words, the ordering of bits within a bitfield is up to the compiler. Therefore, within highly portable code such as ACPICA, bitfields cannot be used to decode bit values within the ACPI-defined ACPI tables as well as AML buffers. Generating ACPICA from Source Code ACPICA supplies generic Unix makefiles and MS Visual Studio project files to generate the source code. For specific or unusual environments, the makefiles can be easily modified to tailor them as necessary. Generic Unix Makefiles These makefiles are intended to generate the ACPICA utilities in a Unix-like environment, with the original ACPICA code (not linuxized), and in the original (git tree) ACPICA directory structure. Windows binary versions of these tools are available at: http://www.acpica.org/downloads/binary_tools.php Documentation is available at acpica.org: http://www.acpica.org/documentation/ The top level makefile will generate the following utilities: Note: These utilities are tested and supported as 32-bit versions only. acpibin acpiexec acpihelp acpinames acpisrc acpixtract iasl To generate all utilities: cd acpica/generate/unix make make install /* install all binaries to /usr/bin/ Requirements make gcc compiler (4+) bison or yacc flex or lex Configuration The Makefile.config file contains the configuration information: HOST = _CYGWIN /* Host system, must appear in acenv.h/ CC = gcc /* C compiler/ ACPICA_SRC = ../../../source /* Location of acpica source tree/ Intermediate Files The intermediate files for each utility (.o, etc.) are placed in the subdirectory corresponding to each utility, not in the source code tree itself. This prevents collisions when different utilities compile the same source modules with different options. Output The executable utilities are copied to the local bin directory. "make install" will install the binaries to /usr/bin 1) acpibin: a binary AML file tool acpibin compares AML files, dumps AML binary files to text files, extracts binary AML from text files, and other AML file manipulation. 2) acpiexec: a user-space AML interpreter acpiexec allows the loading of ACPI tables and execution of control methods from user space. Useful for debugging AML code and testing the AML interpreter. Hardware access is simulated. 3) acpihelp: syntax help for ASL operators and reserved names acpihelp displays the syntax for all of the ASL operators, as well as information about the ASL/ACPI reserved names (4-char names that start with underscore.) 4) acpinames: load and dump acpi namespace acpinames loads an ACPI namespace from a binary ACPI table file. This is a smaller version of acpiexec that loads an acpi table and dumps the resulting namespace. It is primarily intended to demonstrate the configurability of ACPICA. 5) acpisrc: a source code conversion tool acpisrc converts the standard form of the acpica source release (included here) into a version that meets Linux coding guidelines. This consists mainly of performing a series of string replacements and transformations to the code. It can also be used to clean the acpica source and generate statistics. 6) acpixtract: extract binary ACPI tables from an acpidump acpixtract is used to extract binary ACPI tables from the ASCII text output of an acpidump utility (available on several different hosts.) 7) iasl: an optimizing ASL compiler/disassembler iasl compiles ASL (ACPI Source Language) into AML (ACPI Machine Language). This AML is suitable for inclusion as a DSDT in system firmware. It also can disassemble AML, for debugging purposes. Visual Studio Project Files Generation of ACPICA with MS Visual Studio 2008 The Visual Studio project file (for Visual Studio 2008) appears in this directory: generate/msvc9/AcpiComponents.sln ACPICA generates with all MS C language extensions disabled, since the code is ANSI conformant and is meant to be highly portable. There are a couple of include files in MS Visual Studio 2008 that unfortunately contain non-ANSI "//" style comments. These will be flagged as warnings since language extensions are disabled. The VC include files are under one of these directories: \Program Files\Microsoft Visual Studio 9.0\VC\include \Program Files (x86)\Microsoft Visual Studio 9.0\VC\include To eliminate these warnings, modify each of these include files: sal.h stdlib.h For each file, add this statement to the start of the file: #pragma warning( disable : 4001 ) /* no warning about "//" comments/ and add this statement to the end of the file: #pragma warning( default : 4001 ) For stdlib.h, you may also need to disable warning 4001 again before this line, near line 774: #pragma warning (disable:6540) // the functions below have declspecs in their declarations in the windows headers, causing PREfast to fire 6540 here Note: you may have to change the permissions on these files in order to write to them. iASL Compiler Miscellaneous instructions for building and using the iASL compiler. 1) Generating iASL from source Generation of the ASL compiler from source code requires these items: The ACPICA source code tree. An ANSI C compiler. The Flex (or Lex) lexical analyzer generator. The Bison (or Yacc) parser generator. There are three major ACPICA source code components that are required to generate the compiler (Basically, the entire ACPICA source tree should be installed): The ASL compiler source. The ACPICA Core Subsystem source. In particular, the Namespace Manager component is used to create an internal ACPI namespace and symbol table, and the AML Interpreter is used to evaluate constant expressions (Constant Folding). The "common" source directory that is used for all ACPI components. 1a) Notes for Linux/Unix generation iASL has been generated with these versions of Flex/Bison: flex: Version 2.5.32 bison: Version 2.6.2 Other required packages: make gcc C compiler m4 (macro processor required by bison) On Linux/Unix systems, the following commands will build the compiler: cd acpica (or cd acpica/generate/unix) make clean make iasl 1b) Notes for Windows generation On Windows, the Visual Studio 2008 project file appears in this directory: generate/msvc9/AcpiComponents.sln The Windows versions of GNU Flex/Bison must be installed, and they must be installed in a directory that contains no embedded spaces in the pathname. They cannot be installed in the default "c:\Program Files" directory. This is a bug in Bison. The default Windows project file for iASL assumes that these tools are installed at this location: c:\GnuWin32 Once the tools are installed, ensure that this path is added to the default system $Path environment variable: c:\GnuWin32\bin Go to: ControlPanel/System/AdvancedSystemSettings/EnvironmentVariables Important: Now Windows must be rebooted to make the system aware of the updated $Path. Otherwise, Bison will not be able to find the M4 interpreter library and will fail. iASL has been generated with these versions of Flex/Bison for Windows: Flex for Windows: V2.5.4a Bison for Windows: V2.4.1 Flex is available at: http://gnuwin32.sourceforge.net/packages/flex.htm Bison is available at: http://gnuwin32.sourceforge.net/packages/bison.htm 2) Integration as a custom tool for Visual Studio This procedure adds the iASL compiler as a custom tool that can be used to compile ASL source files. The output is sent to the VC output window. a) Select Tools->Customize. b) Select the "Tools" tab. c) Scroll down to the bottom of the "Menu Contents" window. There you will see an empty rectangle. Click in the rectangle to enter a name for this tool. d) Type "iASL Compiler" in the box and hit enter. You can now edit the other fields for this new custom tool. e) Enter the following into the fields: Command: C:\Acpi\iasl.exe Arguments: -vi "$(FilePath)" Initial Directory "$(FileDir)" Use Output Window "Command" must be the path to wherever you copied the compiler. "-vi" instructs the compiler to produce messages appropriate for VC. Quotes around FilePath and FileDir enable spaces in filenames. f) Select "Close". These steps will add the compiler to the tools menu as a custom tool. By enabling "Use Output Window", you can click on error messages in the output window and the source file and source line will be automatically displayed by VC. Also, you can use F4 to step through the messages and the corresponding source line(s). 3) Integrating iASL into a Visual Studio ASL project build This procedure creates a project that compiles ASL files to AML. a) Create a new, empty project and add your .ASL files to the project b) For all ASL files in the project, specify a custom build (under Project/Settings/CustomBuild with the following settings (or similar): Commands: c:\acpi\libraries\iasl.exe -vs -vi "$(InputPath)" Output: $(InputDir)\$(InputPath).aml Instructions and Tutorials Adding new ACPI Tables This section describes how to add a new ACPI table to ACPICA and the iASL compiler. There are four main tasks that are needed to provide support for a new ACPI table: 1) Create a full definition of the table and any subtables in the ACPICA headers 2) Add disassembler support for the new table 3) Add iASL table compiler support for the new table 4) Create a default template for the new table for iASL T option Important Note: if any new typedefed struct definitions are added to the code, they must also be added to the AcpiSrc utility. This is so that the ACPICA source code can be properly converted to Linux format. Modify this file: source/tools/acpisrc/astable.c Notes for each of these tasks are provided in the sections below. When the new table integration is completed, the list of modified source files should look something like this: modified: source/common/dmtable.c modified: source/common/dmtbdump.c modified: source/common/dmtbinfo.c modified: source/compiler/dtcompiler.h modified: source/compiler/dttable.c modified: source/compiler/dttemplate.h modified: source/include/acdisasm.h modified: source/include/actbl3.h modified: source/tools/acpisrc/astable.c ACPICA Header Support New ACPI tables should be added to the appropriate ACPICA header: source/include/actbl.h Fundamental ACPI tables that are directly consumed by ACPICA. source/include/actbl1.h Other tables that are defined within the ACPI specification. source/include/actbl2.h Other known tables that are defined in documents other than the ACPI specification. source/include/actbl3.h Other known tables that are defined in documents other than the ACPI specification. Add a signature string of the form ACPI_SIG_XXXX for the new table at the start of the header. ACPI Table Naming Conventions This section describes the naming conventions for tables, within the ACPICA headers. An attempt is made to use these rules on all ACPI tables defined within ACPICA, for consistency and readability. Try to name the fields within the table struct to match the ACPI spec. However, we have a practical limit of about 30 characters in order to make the disassembler line things up nicely. Also, nobody likes to deal with very long identifiers. If the ACPI spec name is very long, tossing out words that dont really add information is a good way to shorten the name. Dont use abbreviations unless absolutely necessary. Full words are best as they are much more easily understood at a glance. Dont keep using the parent table name within field names. This is akin to the dont include the directory name in the filename rule. Use XXX count instead of Number of XXX or Num XXX Use one or two words. Three words is a bit wordy, but anything more is not good. Usually something like Address does not need to be embellished with additional words, unless there is more than one address within a table or subtable. Likewise with a length field after an address. The standard ACPI_TABLE_HEADER should be used for all tables. A subtable Type and Length should be just that, no more or less. This subtable header should be declared in its own struct to eliminate duplication across individual subtables. Other conventions: Subtables should be defined separately from the main table. Don't add placeholder fields for subtables and any other multiple data items. (Don't use xxxxx[1] for a field that can have multiple items.) Both the disassembler and data table compiler depend on this. For tables not defined in the ACPI spec, add a comment to indicate the document (and date) where the table came from. Use other existing table definitions for additional guidance. Find a similar table. Add any new struct types to the AcpiSrc utility so that the source code can be properly converted to Linux format. This is typically at least the ACPI_TABLE_XXXX name that describes the main table. Modify this file: source/tools/acpisrc/astable.c iASL Disassembler Support Add a definition of the table (and subtables) in source/common/dmtbinfo.c. The common ACPI table header is assumed and does not need to be defined again in this definition of the table. The name of the structure should be of the form AcpiDmTableInfoXXXXn, where n is typically the subtable type code (0, 1, 2, etc.) Add the ACPI_DMT_TERMINATOR at the end of every table/subtable definition. Add table access macro(s) of the form ACPI_xxxx_OFFSET. These are at the start of the dmtbinfo.c file. There will be one main macro, then additional macros, one per subtable. The additional subtable macros are of the form ACPI_XXXXn, where n is the id/opcode of the subtable. Add externals for all new table/subtable definitions in: source/include/acdisasm.h Add an entry for the new table in the AcpiDmTableData in source/common/dmtable.c If the new table is simple and there are no subtables and no variable-length data, the common dump routine can be used: Add the AcpiDmTableInfoXXXX name to the AcpiDmTableData structure as the first element of the data for the new table and the table will automatically be disassembled. The second element must be set to NULL. If there are subtables or variable-length data, a custom dump routine must be written: Add an AcpiDmDumpXXXX function to dmtbdump.c Note: code for another similar table can often be ported for the new table. Add an external for this function to acdisasm.h Add this function to the AcpiDmTableData entry for the new ACPI table, as the second element (first element must be set to NULL). Debug/Test: Either find an existing binary example of the new ACPI table, or create one using the "generic ACPI table support" included in the iASL data table compiler. Use the -G option to force a generic compile. Note: Any length fields within the table must be valid, or at least use labels to calculate length. Once the test file is compiled, the disassembler can be tested on the output binary file. It is often best to create the table from scratch, since this clearly exposes the dependencies (lengths, offsets, etc.) that the Table Compiler support will need to generate. iASL Table Compiler Support Simple flat tables do not require a compile routine. The definition of the table in common/dmtbinfo.c (created in the previous step for the disassembler) will suffice. Add flags as appropriate to the definition of the table in: source/common/dmtbinfo.c: DT_LENGTH This indicates to the compiler that this field is a length field that must be calculated and filled in by the compiler. NOTE: this value is the total length of the current subtable. If this is insufficient, it may be possible to restructure the subtables or it may be necessary to have a compile routine insert the length properly. DT_FLAGS This indicates to the compiler that this field is the beginning of the definition of a group of flags that must be encoded into a single value. DT_OPTIONAL This field is optional. DT_NON_ZERO This field must contain a non-zero value. Complex tables with subtables or variable data will require a compile routine with a name of the form DtCompileXXXX. Add the DtCompileXXXX function to this module: source/compiler/dttable.c Add an external for this function in the data table compiler header: source/include/dtcompiler.h Add this function to the AcpiDmTableData entry for the new ACPI table in this module: source/common/dmtable.c iASL Template Support (-T option) Now that the Table Compiler support is working for the new table, create an example of the new table in a file such as XXXX.asl. This example should contain an example of every supported subtable, and multiple instances of any variable length data. Compile the example file with the -sc option. This will create a hex C array that contains the table contents. The output file will be XXXX.hex. Add this array to this header: source/compiler/dttemplate.h The default name of the array/table is AmlCode. Rename the array TemplateXXXX, and insert it into dttemplate.h in alphabetical order. Ensure that the structure is declared as const unsigned char. Add an external for this array (TemplateXXXX) to the header named source/compiler/dtcompiler.h. Add this array name to the AcpiDmTableData entry for the new ACPI table in source/common/dmtable.c Debug/Test: Create the template file. Compile the file. Disassemble the file. Compile the disassembly file. Inspect all files: iasl T XXXX iasl XXXX.asl iasl d XXXX.aml Adding new ACPI Predefined Names There are four areas where ACPICA performs validation on predefined names (reserved names that start with an undrescore.): Input arguments: During compilation, the correct number of input arguments is checked. If defined to have zero arguments, the name can be implemented as either a control method or a static named object. If there are any required arguments, the name must be implemented as a control method. If the name is implemented as a static object, the object is checked for the proper number of data elements and the proper type of these elements. Runtime arguments: At runtime, the input arguments are checked for the proper number and type of the arguments. Runtime return value: At runtime, the return value is checked for the proper number of data elements and the proper type of these elements. There are only two places that require modification in order to add new predefined names, at least the simple ones that fit into existing types (return package types). Add the new names to the alphabetical table of predefined names and associated descriptions within the AcpiHelp utility (table is also used by the disassembler). See: source/tools/AcpiHelp/ahpredef.c Within the main ACPICA code, there is a single file that defines the names and their associated properties in alphabetical order: Required argument count, required argument data type(s), and the return value data type if applicable. This file is used by both the iASL compiler and the AML interpreter. See: source/include/acpredef.h Important Note: if any new typedefed struct definitions are added to the code, they must also be added to the AcpiSrc utility. This is so that the ACPICA source code can be properly converted to Linux format. Modify this file: source/tools/acpisrc/astable.c When a new predefined name (or names) has been completed, the modified file list should look something like this: modified: source/common/ahpredef.c modified: source/compiler/aslprepkg.c modified: source/components/namespace/nsprepkg.c modified: source/components/namespace/nsrepair.c modified: source/include/aclocal.h modified: source/include/acpredef.h modified: source/tools/acpihelp/ahdecode.c Return Value Package Types If the new predefined name returns a package, the type (and other information) of the package must be assigned to the name via the AcpiGbl_PredefinedMethods table in source/include/acpredef.h Example: The example below shows a name (_BCL) that is defined by the ACPI specification: There are no arguments, therefore the name can be implemented in ASL by either a control method or a simple static Name(). The name returns a variable-length package consisting of all integers. {{"_BCL", METHOD_0ARGS, METHOD_RETURNS (ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints) */ PACKAGE_INFO (ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0,0,0,0), The various package types (ACPI_PTYPE*) are described below. If the new name returns a package and does not fit into one of the existing types, a new one may need to be defined. PTYPE1 Return Package Objects These return packages do not contain subpackages. ACPI_PTYPE1_FIXED: Fixed-length length, 1 or 2 object types: object type count object type count ACPI_PTYPE1_VAR: Variable-length length. Zero-length package is allowed: object type (Int/Buf/Ref) ACPI_PTYPE1_OPTION: Package has some required and some optional elements (Used for _PRW) PTYPE2 Return Package Objects These return packages contain a Variable-length number of subpackages. Each of the different types describe the contents of each of the subpackages. ACPI_PTYPE2: Each subpackage contains 1 or 2 object types. Zero-length parent package is allowed: object type count object type count (Used for _ALR,_MLS,_PSS,_TRT,_TSS) ACPI_PTYPE2_COUNT: Each subpackage has a count as first element. A zero-length parent package is allowed: object type (Used for _CSD,_PSD,_TSD) ACPI_PTYPE2_PKG_COUNT: Count of subpackages at start, 1 or 2 object types: object type count object type count (Used for _CST) ACPI_PTYPE2_FIXED: Each subpackage is of Fixed-length. Zero-length parent package is allowed. (Used for _PRT) ACPI_PTYPE2_MIN: Each subpackage has a Variable-length but minimum length. Zero-length parent package is allowed: (Used for _HPX) ACPI_PTYPE2_REV_FIXED: Revision at start, each subpackage is Fixed-length (Used for _ART, _FPS) ACPI_PTYPE2_FIX_VAR: Each subpackage consists of some fixed-length elements followed by an optional element. Zero-length parent package is allowed. object type count object type count = 0 (optional) (Used for _DLM) ACPI_PTYPE2_VAR_VAR: Variable number of subpackages, each of either a constant or variable length. The subpackages are preceded by a constant number of objects. (Used for _LPI, _RDI) ACPI_PTYPE2_UUID_PAIR: Each subpackage is preceded by a UUID Buffer. The UUID defines the format of the package. Zero-length parent package is allowed. (Used for _DSD) Adding new AML Operators/Opcodes This section describes how to add a new AML operator to both the core/kernel ACPICA and the iASL compiler. Most new opcodes are defined by the ACPI specification itself, but there are a few internal opcodes that are used by ACPICA only. The integration process is basically the same for both. ACPICA Core and Interpreter Add a new #define for the opcode in the file source/include/amlcode.h The AML opcodes are at the start of the file. The name of the opcode should be of the form: AML__OP, where is the appropriate name of the opcode. Add a new entry for the opcode in the AcpiGbl_AmlOpInfo structure found in: source/components/parser/psopcode.c This new entry must be added at the end of the structure. Each entry in this structure contains the following data: A string containing the name of the opcode A macro that decribes the AML arguments for this opcode A macro that desribes the runtime data types for the opcode An entry that gives some object type information for the opcode. An entry that gives class information for the opcode. This is used to broadly group various opcodes to make differentiation easier. An entry that gives some type information for the opcode. Additional flags that simplifies execution of the opcode. Create a parser information macro that describes the opcode arguments in the file include/acopcode.h. This macro is essentially derived directly from the ASL grammar as described in the ACPI specification. The name of this macro should be ARGP_. Create a interpreter information macro that describes the resolved runtime arguments, also in the acopcode.h file. This macro is also derived from the ASL grammar, implementing the resolved data type for each argument of the new opcode. Example: Consider the following grammer for the ADD opcode. This is the actual definition of ADD in the ASL grammar described in the ACPI specification: AddTerm := Add ( Addend1, // TermArg => Integer Addend2, // TermArg => Integer Result // Target ) => Integer The following macros define the the ARGP input (parser) and the ARGI resolved (interpreter) arguments for the AML_ADD_OP: #define ARGP_ADD_OP \ ARGP_LIST3 (ARGP_TERMARG, ARGP_TERMARG, ARGP_TARGET) #define ARGI_ADD_OP \ ARGI_LIST3 (ARGI_INTEGER, ARGI_INTEGER, ARGI_TARGETREF) Note that since the return value is stored into the target, the targe is described as a reference to to the interpreter. OPCODE DISPATCH Add opcode information to the appropriate opcode dispatch table in the file components/parser/psopinfo.c AcpiGbl_ShortOpIndex AcpiGbl_LongOpIndex INTERPRETER DISPATCH source/interpreter/exoparg1: source/interpreter/exoparg2: source/interpreter/exoparg3: source/interpreter/exoparg6: iASL Compiler When the basic infrastructure for the new opcode has been completed as per the previous section, support for the iASL compiler can be added. Add an entry for the new opcode in the AslKeywordMapping structure within the file compiler/aslmap.c. Entries in this structure should be in alphabetical order. Each entry in the structure contains the following data: The actual AML opcode that will be emitted for this keyword. This may be either the actual AML opcode (for ASL operators) or any appropriate AML opcode (for other keywords). Flags Package Flag Btype If the opcode requires special processing such as additional parse tree transforms, a case for the AML opcode should be added to the file compiler/aslwalks.c Adding new iASL Preprocessor Directives Most new directives can be added to this file: source/compiler/prscan.c Near the beginning of the file, add an entry to the Gbl_DirectiveInfo struct that contains the actual name of the directive and the number of arguments required (if any). Add a new value to the Gbl_DirectiveIndexes enum that will be used during the directive decoding and dispatch. The value should be of the form: PR_DIRECTIVE_*. In the function PrDoDirective, add a new case (or cases) for the new directive, using the PR_DIRECTIVE_* from above. Usually, the case statement is used to dispatch the directive to the appropriate handler. Finally, write the handler that actually implements the directive. Building an ACPICA Release Instructions to create a full release of the ACPICA software and utilities. The build uses MS Visual Studio and Cygwin to accomplish the goal of releasing both Windows and Unix versions of the ACPICA code and utilities. For Windows, binary versions of the ACPICA utilities (including the iASL compiler) are created. Required Accounts 1) An account on github.com with full access rights to the acpica repository. 2) An account on the acpica bugzilla with write/change access. 3) An account on the acpica.org website with write/change access. Required Tools Documentation Tools The main ACPICA documents (ACPICA reference, iASL user guide) are written in MS word, then converted to PDF format. Both versions of each are released on the ACPICA website. MS Word Word to PDF conversion tool (such as PDF Create 8) Windows Tools The Windows binaries are built via Visual Studio. We must release the Windows binaries since Windows does not provide a compiler. See the following file acpica/generate/msvc9/readme.txt for Windows setup and ACPICA generation instructions. See acpica/source/compiler/readme.txt for flex/bison installation and iASL generation instructions. Microsoft Visual Studio 2008 Flex for Windows (http://gnuwin32.sourceforge.net/packages/flex.htm) Bison for Windows (http://gnuwin32.sourceforge.net/packages/bison.htm) PkWare pkzip25 (Available free from multiple sources). Here is a list of mirrors:  HYPERLINK "http://www.filewatcher.com/m/PKZIP25.EXE.339456-0.html" http://www.filewatcher.com/m/PKZIP25.EXE.339456-0.html Otherwise, Google "pkzip25.exe" to find the free executable. Install pkzip25 to /cygdrive/c/windows/pkzip25.exe Cygwin for Windows Cygwin is used to checkout the source code from the git tree, generate ACPICA from source, and to build the ACPICA release packages. Cygwin is available at (http://www.cygwin.com) These Cygwin packages are required for ACPICA generation: git (found in Devel) make (found in Devel) gcc C compiler (found in Devel) flex (found in Devel) bison (found in Devel) m4 (macro processor required by bison, found in Interpreters) dos2unix and unix2dos converters (found in Text) Additionally, to write to the git tree, these are needed: openSSH (found in Net) corkscrew (found in Net) Other Issues Windows/Unix line termination issues: a) Install Cygwin with the default setting of CR/LF line terminators b) Ensure that these lines are present in the git configuration file, .gitconfig in your home directory: [core] autocrlf = true git and ssh stuff To write to the git tree, you'll need to setup an ssh connection to github. The ssh clone path is: git clone ssh://git@ssh.github.com/acpica/acpica.git Generating the ACPICA Release Finish the Software and Documentation Cleanup any extraneous files in the local git tree Complete any updates to the ACPICA documentation (ACPICA ref, iASL ref) Create the .PDF versions of the MS Word .DOC files Checkin any changed documents Update the version number (hex in the format: 0xYYYYMMDD) in the file source/include/acpixf.h Build Windows debug versions of all software and utilities Build Windows nodebug versions of all software and utilities (generate/msvc9) Build Unix versions of all software and utilities: generate/unix/make clean generate/unix/make Write the Release Notes Generate sizes for the acpica library from generate/release/size.bat. Note: This step uses MS dumpbin(link) which is a part of the VC package. It might not work unless the environment variables are set correctly. Execute VC/vcvarsall.bat from the command line if necessary. Sizes appear in the files size_rel.txt and size_dbg.txt Integrate code/data and debug/nodebug sizes into the release notes. Add the release notes to the documents/changes.txt document via Word. Note: From Word, use "Save As", then check the "MS-DOS" and "Insert line breaks" boxes before saving. Checkin documents/changes.txt Checkin the new version number, source/include/acpixf.h Git push everything Tag the version file with a name of the form Rmm_dd_yy git tag -m"version yyyymmdd" Rmm_dd_yy git push --tags Build the Software Build the various tar/zip release files: Convert the generate/release/.sh files to unix format: dos2unix.sh On cygwin, execute generate/release/release.sh (sh release.sh) Updating the ACPICA Website Login to acpica.org (with update permission) ACPICA Version Number Create a new download node for the new ACPICA version: Goto: ContentManagement->CreateContent->Downloads Title: Use the new version number in the correct format (e.g., "Version 20140114") Body: Insert the release notes for this version Date: Must be the current date (should match ACPICA version) File Attachments: Attach all of the release zip/gz files (currently 6 files) (From the acpica/generate/release/current directory) Click "Save" at the bottom of the page Update the version number token. This will update the version number header on all pages where the token is used: Goto https://acpica.org/node/88, click edit, update version at body top Click "Save" at the bottom of the page File Pathnames Update file pathnames: Goto "Downloads", click edit Update paths to new file versions, update file sizes (3 files) Click "Save" at the bottom of the page Goto "Downloads/Windows Source Code", click edit Update paths to new file versions, update file sizes (2 files) Click "Save" at the bottom of the page Goto "Downloads/Windows Binary Tools", click edit Update paths to new file version, update file size (1 file) Click "Save" at the bottom of the page ACPICA Documents The documentation/changes.txt file must always be updated. Additional ACPICA documentation may require update (in doc/pdf pairs): acpica-reference.doc acpica-reference.pdf aslcompiler.doc aslcompiler.pdf Goto the "Documentation" page, click edit. Attach/upload all new versions of the document(s) Uncheck the "List" box for each new document Update pathnames (and file sizes) in body for each new filename (appears at bottom of each attach) Update "Last update" dates as needed Click save at bottom Update "news" if there are any major changes or major new features: Update front page news: Goto ContentManagement->CreateContent->News Add news item in the "Title" section and click save at bottom Release Notes Email separate copies of the notes (in plain text) to the following: AcpiCa (acpica.intel.com) devel@acpica.org acpi@linux.intel.com CaClients (undisclosed recipients/BCC: list) Update ACPICA bugzilla Close any problem reports that have been resolved. This page intentionally left blank.      McKinley Power Pod Design Guidelines, Rev. 0.0  5  PAGE 247 Intel Secret Ref No SC-3111 Ref No SC-3111 Intel Secret  PAGE 3    ACPI Component Architecture Internal Design  ACPI Component Architecture Programmer Reference  PAGE 6  ACPI Component Architecture Programmer Reference Ref No SC-3061  PAGE 247 Intel Secret  ACPI Component Architecture User Guide and Programmer Reference  PAGE 7  PAGE 247 ACPI Table Management Event Management ACPI Hardware Management Resource Management Namespace Management AML Interpreter '09:HIPst  ' ( , - 7 8 "#$%𱭩𝘑qhBXhE5CJOJQJaJ h1lCJjh1lCJU h1lh1l hi6h hi6hthhhUhWhV;hahEh&Ph~h}hfvhWCh.vB*CJ4aJ4phh.vCJ4aJ4h+hhih'whchnBP,:st] #$gd1l=@&gdw?@&gdw@&gdE F @&^gdE 7@&^gdwG@&gdw9@&gdw8d@&^gdw8d@&^gdw !"#$%&CD^_`abcde|}jqhEUjhEUjwhEUjhEUj}hEUhBXhECJOJQJaJhBXhE5CJOJQJaJhV+jhEUjhEUhE8$$cL<pF|$b=u  +,FGHJKLOPij6jhEUjehEUjhEUjkhEU%hBXhEB*CJOJQJaJphhV+jhEUhEhBXhECJOJQJaJjhEU9678:;<?@OPjklnopst   %&@ABDEѷѬѡіыjhEUjShEUjhEUjYhEUjhEUhBXhECJOJQJaJhE%hBXhEB*CJOJQJaJphhV+jhEUj_hEU6EFIJ[\vwxz{| "#$%&AB\]^`abefstjA hEUhBXhE5CJOJQJaJj hEUjG hEUjhEUhV+jMhEUjhEUhEhBXhECJOJQJaJ8 789;<=BCTUopqstuz{շլշաշՖշՋj/ hEUj hEUj5 hEUj hEU%hBXhEB*CJOJQJaJphj; hEUhEhBXhECJOJQJaJhV+jhEUj hEU6 !&'=>XYZ\]^cd  &jhEUj#hEUjhEUj)hEUhV+j hEUjhEUhBXhECJOJQJaJhE%hBXhEB*CJOJQJaJph8!^,}E~<p*`\P&'(*+,12\]wxy{|}   $%?@ACDEJK]^xyz|}ѻѬѡіыjhEUjhEUjhEUhBXhECJOJQJaJjhEUjhEUhE%hBXhEB*CJOJQJaJphhV+jhEUjhEU6}~  678:;<=>OPjklnopstjhEUjhEUhBXhE5CJOJQJaJjhEUhBXhECJOJQJaJjhEUhV+j hEUjhEUhE%hBXhEB*CJOJQJaJph4  $%&()*+,?@Z[\^_`cdz{%hBXhEB*CJOJQJaJphjphEUjhEUjvhEUjhEUhBXhE5CJOJQJaJhV+j|hEUjhEUhEhBXhECJOJQJaJ5;<VWXZ[\abyz  /0JhBXhE5CJOJQJaJjhEUjdhEUjhEUjjhEUhBXhECJOJQJaJ%hBXhEB*CJOJQJaJphhV+jhEUjhEUhE3JKLNOPSTkl   /01KLMOPQVWԺűԓԞԈ잱}잱jRhEUjhEUjXhEU%hBXhEB*CJOJQJaJphhDkhE^JjhEUhBXhECJOJQJaJhEhBXhE5CJOJQJaJhV+jhEUj^hEU1Q#e9|>t$ Z /!k!!!%"_""" $$@&gdHooWrst!"#()DE_`acdelmjhEUjFhEUjhEUhBXhECJOJQJaJjLhEU%hBXhEB*CJOJQJaJphhV+jhEUjhEUhEhDkhE^J7345789>?[\vwxz{|89:<=ѷѬѡіыj!hEUj4!hEUj hEUj: hEUjhEUhBXhECJOJQJaJhE%hBXhEB*CJOJQJaJphhV+jhEUj@hEU6=>CDSTnoprst{|    " # $ + , 9 : T U V X Y Z _ ` ~  j"$hEUj#hEUj(#hEUj"hEUhV+j."hEUjhEU%hBXhEB*CJOJQJaJphhEhBXhECJOJQJaJ8 !!)!*!+!-!.!/!6!7!J!K!e!f!g!i!j!k!p!q!!!!!!!!!!!!!!!!!!!!!"""ѻѰѥњj'hEUj&hEUj&hEUj%hEUj%hEUhE%hBXhEB*CJOJQJaJphhV+jhEUj$hEU<" "!"#"$"%","-">"?"Y"Z"["]"^"_"f"g"u"v""""""""""""""""### # #ѻլynyyj)h <Ujh <Uh < hi5jhi5UhiB*CJphhih]6GB*CJphjh1lB*CJUphj(hEUj (hEUhE%hBXhEB*CJOJQJaJphhV+jhEUj'hEU'"" # ##$$#$4$$$$%%M%j%k%l%%&@&gd](&d@&Pgdq^gdqgdqgd gd gdyAgdw >$$ @&gdI# >$$$@&a$gdI # # ##$$#$4$Q$q$$$$$$$% %% %!%"%$%L%M%N%e%g%h%i%j%k%l%|%%%%&&6'Ź|xtptieh| ht/h]h2h]hdhh hqhq hyAhqj)hqU hYchqhV+mHnHujhqUhE h h8kih8kihqhjh hyA hyAhyAh~hijhi5B*CJUph%hwh <B*CJOJQJaJph'6';'''a(b(p(((M)z))))**++E+Z+++++-,A,o,,,,--M-N----------ǫxtptlhx~hQh hRahRa$hRahRa5B*OJQJ^Jph41hRa5B*CJOJQJ^JaJmHnHph4u7hRahRa5B*CJOJQJ^JaJmHnHph4uhRah'w h \h \h \ hjhjh+hx#hjhbU h|h|h|hw)*&b(p())*++@+B+++),k,,,6-p-------gd d7$8$H$^gdRagdRagd'wgd \gdjgdbUgd|-...1.;...U/////00000011 1011121A1111111F2Z2s2w2r335556j6k6|66ٽ䮹覢zs h;h;,hWChIX'B*OJQJ^JmHnHphu hw\qhIX'B*mHnHphuhQhIX'h hU8hU8hU8hK% h'wh'wh'wCJOJQJ^JaJ hIX'h'wh'w h{.h{.h;h{.hbUh)5zhx~5hx~hy---..//0001 1011121A111F2Z2s2t2u2v2w2gdIX'gd'wgd'wgd gdIX'  & F@&gdW & Fgd)5zgdx~w222q3r333333 4m444%5&5555k6|6677(767gd{.gd;gdbUgd d7$8$H$^gdIX'6767G7777F8G8K8X888*9+9C9::4:~:::::;;';<8<<<v<z<<<<<<== =*=.=G=K=d=h=========hhx#5hhx#5B*ph4hh =5B*ph4hh4u15 hjhjhjhoU2 hhhhhhhh hI5hI5hI5h; h7xh7xh7xhK% h{.h{.hbUh{.hc567G777G8X8+9C9:4:K:Y:m:~:::::;;';<7<gdoU2gdjgdhgdh & Fgd"gdbUgdhgdI5gd7xgd{.gdbU7<8<v<<<<=*=G=d========">I>q>>>>>>?"?7?gd4u1Y^gdx#Y^gd4u1====">&>I>M>q>u>>>>>>>>>>>??"?&?7?;?=?I?7AEABB7CBCSCVCCCDDööt+hhD125B* CJaJmHnHphI}uhh\5B* phI}h\5B*ph4hfUh\5B*ph4h\hjhh |5B*ph4hh |5B*phhhx#5B*ph4hh =5B*ph4hh4u15B*ph4hh4u15'7?=?I?h???.@Y@@@@A6A7AEA]AAAA BBBcBBBB7CgdjY^gd |Y^gdx#7CVCCDKDDDDDE(EFEaErEE&GcIVJjJJJJgd7igdbUgdgdigdigdbU^gdx#gd]gdyFgdj YP^gd\DDJDKDDDDDDD(E6E7EPEQEaEqErEE(FSFG%GHHcIUJVJjJJJJJ»~~zvrnrnrnrjcz_XzThc h7ih7ih7i hihhf h&hih8C?hbU2 jh(hx#5B*CJOJQJ^JaJph4,h(hx#5B*CJOJQJ^JaJph4hx#h]hyF hjh\hD12hhD125B* phI}+hhD125B* CJaJmHnHphI}u+hhU!5B* CJaJmHnHphI}u J"K&K.K}KKKKLMM:NVNrNyNzN{NNNNOOPP6P7PQQ=QQQQQRRETFTUWVWmWpWWWBXDXXXXˬz3h#Ohr5B*CJOJQJaJmHnHph4u/hhr5B*OJQJ^JmHnHph4u'hrhrCJOJQJaJmHnHuhrhrB*ph hrhrhV hchwhoUhqJ hwhwh&hwhjhch ./JL1LMtMM{NNP7PQ=QnQ1RRSETFT[TaTgT|TTd7$8$H$gdrd7$8$H$^gdrgdrgdVgdwgdwgdwgdcTTTTTTTTTU UUDUEU`UaUUUUUUV0V1VBVCV^V_VVd7$8$H$gdrVVVVVVVWWDWUWVW2XXYZZZiZZZ^gdQpgd;Mgd0,gdyFgdwgdrd7$8$H$^gdrd7$8$H$gdrXXZZZ ZZ"Z)Z*ZtZZZZ[[[[\\q\r\\\7]W]z]{]]]^^1^B^H^Q^d^e^f^^^^^^^^^Ÿv!h0,h0,B* OJQJ^Jph h <hQph <h0,B* ph h <h0, hbUhQp hQphQphjOJQJ^Jh0,h0,OJQJ^J hwhQphA7\ hwh0, h;Mh;Mh;M h;Mh0,h < hrhwh}hwhr.^f^^^^%_p__aabccddddddgehe d7$8$H$gdRMC  ^gdRMC gdRMCgdgd;Md7$8$H$^gd0,gdQp^gd <^^^_"_#_%_n_p____``b`c````aOaPaaaaaaaaaaaa&b'brbsbbbbb/c0c|c}cccccccc4d5d~dͺƭƊh hbUhQp hQphQp!h0,h0,B* OJQJ^Jphh0,h0,OJQJ^Jh <h0,5h;M hhQp hh0, hwhQphj hwh0, hwh <#h0,h0,OJQJ^JmHnHu6~dddddddddddddeFeGeeegehe}eeeeeeeeee f5f6f7fIff㔭nW,h0,h0,B* OJQJ^JmHnHphu,hwh0,B*OJQJ^JmHnHphu hwh0,hwh0,5#h0,h0,OJQJ^JmHnHu hQphQph0,h0,OJQJ^J hbUhQp!h0,h0,B* OJQJ^JphhA7\OJQJ^J hk:hk: hk:hQp hk:h0,h <h0,5 hwhQp"heeeee6f7fffffggLgMggggggg8h9h  ^gdRMC gdRMC d7$8$H$gdRMC  `gdRMCffffffffff ggggg$gIgKgLgMg\gggggggggggggg6h8h9hBhjhkh~hڼڼڵ疏yhڵ疏y!h0,h0,B* OJQJ^JphhA7\OJQJ^Jhk:h0,mHnHu hk:h0,h <h0,5,h0,h0,B* OJQJ^JmHnHphu hbUhQp!h0,h0,B* OJQJ^Jphhwh0,OJQJ^Jh0,h0,OJQJ^J#h0,h0,OJQJ^JmHnHu hk:hQp(9hBhkhhhhhhi/i1i>ibiciiiiik d7$8$H$^gd < d7$8$H$^gdRMC  ^gdRMC gdRMC d7$8$H$gdRMC  ^gd <~hhhhhhhhhhhii.i/i0i1i5i;i=i>iBiDiEiaibicieiiiiiiijĺ||eĩee^ hwh0,,h0,h0,B* OJQJ^JmHnHphuhA7\B* OJQJ^Jph!h0,h0,B*OJQJ^JphhA7\B*OJQJ^Jph!h0,h0,B* OJQJ^JphhA7\OJQJ^Jh0,h0,OJQJ^J hk:hQp hk:h0,h <h0,5#h0,h0,OJQJ^JmHnHu hbUhQp"jj]j^jjjkkkk!k'kFkkkkkkAlMlNlllll9m:m~mmmmmmmmmmmmmmmmmmmmmmmmmnnnٺٺٺٺٳٜٺٳ hwhRMC hwh;Mhwh0,OJQJ^JhA7\OJQJ^J hbUhRMC!h0,h0,B* OJQJ^Jph hbUh;M h;Mh;Mh0,h0,OJQJ^Jhjhk:h hwh0, hwhQp6kFkmmmmmn+n-n.nvnwnnnnnnn oGodooogdA7\gdjgd;Md7$8$H$^gd0,^gdRMCgdQpgdn n nn)n+n,n-n.n5n6n7nunvnwnnnnnnnnnnnnnno o o oFoGoTo]ocodooooooooϨܐ܉܂ϡ܂qܐ܉ϡqܐ!h0,h0,B* OJQJ^Jph h;Mh;M hbUh;M!h0,h0,B* OJQJ^Jph hwh;M hwh0,#h0,h0,OJQJ^JmHnHu hbUhRMC hwhRMChwh0,OJQJ^Jh0,h0,OJQJ^JhA7\OJQJ^Jh0,h;MOJQJ^J,op pppplpmpzpppppppppqqqqqq$q?qAqBqqqqq r r)r*r4r8rWrXrYrZrrrrr'sKsSsTssstttt۽󽶤ۤhA7\ h;Mh;M hwhQp hwh0,#h0,h0,OJQJ^JmHnHu hwh;Mhwh0,OJQJ^J!h0,h0,B* OJQJ^Jph hbUh;M!h0,h0,B* OJQJ^Jphh0,h0,OJQJ^J6opmpppqqAqBq r*rYrZrrtuuuuu"vbvwgdhgdbUgdyFd7$8$H$^gd0,gdQpd7$8$H$^gdRMC^gdRMCtttQuRuuuuuuuuu"vw w?w@wbwwwwwwxxixjxxyyyym{n{|}LļӵӚkgchVYhq/hfUhh5>*B*CJOJQJ^JaJph4,hfUhh5B*CJOJQJ^JaJph4,hfUhio05B*CJOJQJ^JaJph4htP hhhhhhhh5hhhh5 hhhhhhhVhhbUhh hbUhbUhyF hhQp hh0,&w w?w@wbwwwxxixjx}xxyyyz+zFzxzzzz{ $ @ Hgdio0gdio0gdtPgdtPgdhgdhgdbUgdVgdyF{*{F{n{{{{|*|O|v||||}*}Q}t}}}}~$~S~|~~~~  $ @ Hgdio0 %H|9QRނ߂FG6YZ+BCY^gdEEgdtPgd%;&gdtPY^gd4+ngd4+ngdqgdq $ @ Hgdio0 7GMNOPR܂݂߂ԽԏԂ{`B`;j*h"h4+nB*OJQJU^JmHnHphu5jh"h4+nB*OJQJU^JmHnHphu h5h5h4+nh4+nOJQJ^J,h"h4$B*OJQJ^JmHnHphu,h"h B*OJQJ^JmHnHphu,h"h4+nB*OJQJ^JmHnHphu,h"h5B*OJQJ^JmHnHphuhtPh4+nOJQJ^Jh4+nhqDEG̃Ճ56Z*+B˅̅BsĆDEй|oeoeoToToeoeo!hfUhtPB*OJQJ^Jph4h;OJQJ^JhtPhtPOJQJ^J htPhEEhEEhtP,h"h4$B*OJQJ^JmHnHphu,h"hdB*OJQJ^JmHnHphu,h"h4+nB*OJQJ^JmHnHphu5jh"h4+nB*OJQJU^JmHnHphu'hEh4+n0J OJQJ^JmHnHuCABstĆņKLT]fpx‡Y^gdhY^gdEEY^gd;9G؈ۈ)*,?ȉɉBIŠϊЊ׊'(_`o{݋ދ !Ua{m{m{m{hRBhtP5OJQJ^JhRBhd(5OJQJ^Jh;OJQJ^Jh;htP5OJQJ^J!hfUhtPB*OJQJ^Jph4 hfUhh5B*CJaJph4 hfUhd(5B*CJaJph4hEEhtP5OJQJ^JhtPhtPOJQJ^J hfUhtP5B*CJaJph4* +789GHȈ*+,?@@ABIY^gd;Y^gdh Y$^gdRB Y$^gdRBY^gdEEIJŠnoTU34_`JKuvY^gd;Y^gdEEa֌׌4A_*+KVuOP'(ow"#bo}~&mn67ȶ hfUhEE5B*CJaJph4h;CJOJQJ^JaJ hEEhEECJOJQJ^JaJhhCJOJQJ^JaJh%;&hEEhRBhd(5OJQJ^Jh;OJQJ^JhtPhtPOJQJ^JhRBhtP5OJQJ^J4nob~&'klܓZ[Y^gdhgdEEY^gd;Y^gdEE7&H$%klӘԘPQex:;=^̛tct!hfUhtPB*OJQJ^Jph4 hfUhtP5B*CJaJph4hRBOJQJ^Jh;OJQJ^JhEEhtP5OJQJ^Jho<htPOJQJ^J htPhtPhtP h;hEECJOJQJ^JaJh;CJOJQJ^JaJ hfUhEE5B*CJaJph4 hEEhEECJOJQJ^JaJ#[ers%&HIBCUV^gd;gdtPY^gd;Y^gdhY^gdEEVsۗܗ{|z !;TUnox Y & F ^gdRBY^gd;Y & F gdRB&1;<=^_͛Λ%&23Y^gdRBY^gdd(Y^gd;̛͛YZ&2vw?@Ÿß=> +,?KL^Ǭ⢕}}}Ǭ}hd(OJQJ^JhEEhtP5OJQJ^Jho<hEEOJQJ^JhtPOJQJ^J!hfUhtPB*OJQJ^Jph4hRBOJQJ^J hfUhtP5B*CJaJph4h;OJQJ^Jho<htPOJQJ^J hfUhd(5B*CJaJph41-.wŸßZ[ɡʡ,LrsY^gdRBY^gd;գ֣WXȤ"?@r XYn !/47uzÿzlzlzhnQhnQ5OJQJ^JhnQOJQJ^JhnQhnQ5>*OJQJ^Jho<OJQJ^JhRBOJQJ^Jho<ho<OJQJ^JhuOJQJ^Jh^a htPhtP hfUhtP5B*CJaJph4hEEhtP5OJQJ^Jho<htPOJQJ^Jh;OJQJ^J&s78KLȤɤ QRܥݥ"?@[rƦ YP^gdWgd^agd^a^gd;Y^gdd(Y^gd;ƦǦoڧ !)*lmݩ4`EwϫgdYo Y(^gd YP^gdnQ YP^gdW )*HLUelmrݩEw~ǫϫ̸̮߫wndZG$hfUhD5B*OJQJ^Jph4h7sOJQJ^Jh@OJQJ^Jhuho<^JhuhYo^JhfUhf;5B*ph4hfUh`y5B*ph4hf;OJQJ^Jh`yOJQJ^Jho<OJQJ^JhviOJQJ^JhuOJQJ^Jho<ho<OJQJ^Jho<hnQOJQJ^JhfUhnQ5B*ph4hfUhm5B*ph4߫$;<yPQRЭ+ 2=> )EGH޺zzzph VOJQJ^JhHOJQJ^Jh OJQJ^JhOJQJ^Jhr3jOJQJ^Jhh.vOJQJ^JhviOJQJ^Jho<ho<OJQJ^Jh7s$hfUhD5B*OJQJ^Jph4h`yhfUhDB*ph4$hfUh`y5B*OJQJ^Jph4%ϫ$yQRЭ>XGH[\ YP^gd]iY & FP^`gd.vgd YP^gdvi YP^gdW  & FPgd7sH[\Ƴʳ$%+:YôĴ,-@EMT(ȻȻȻqgZhfUhf;5B*ph4hf;OJQJ^Jhh_(5OJQJ^JhkSuOJQJ^Jh_(OJQJ^Jho<OJQJ^Jh%;&OJQJ^Jh0A}OJQJ^Jh?FOJQJ^Jho<ho<OJQJ^Jh]iOJQJ^Jho<h]iOJQJ^Jho<hOJQJ^J&hh5>*CJOJQJ^JaJcٴ-(Bsз >?x ۺܺ4߻ YP^gdevY & F>P^`>gdevgdYo YP^gdW(BFHrs~DηϷз&07~ɼɥzpzfz\T\\h]ihE5hEOJQJ^Jha"%OJQJ^JhevOJQJ^Jho<hN]OJQJ^Jho<OJQJ^JhN]OJQJ^Jh }OJQJ^Jh4lOJQJ^JhfUh }5B*ph4hfUho<5B*ph4hfUh]i5B*ph4h]iOJQJ^Jh:OJQJ^Jho<ho<OJQJ^Jhuho<^J 3>?wx|ɹ 34Cںܺ ȻҎzpzfYLYhevha"%OJQJ^Jhevho<OJQJ^Jh0A}OJQJ^JhDOJQJ^JhWOJQJ^Jha"%OJQJ^JhfUho<B*ph4hfUh@9:5B*ph4hfUh@9:B*ph4h@9:OJQJ^Jho<ho<OJQJ^Jh4lOJQJ^JhfUho<5B*ph4hfUh]i5B*ph4h]iOJQJ^Jh@OJQJ^J234V]`hyzԻ޻$`bno():µ›mcYOYh"OJQJ^Jh0A}OJQJ^JhJOJQJ^J#h|h|5CJOJQJ^JaJ#h|ho<5CJOJQJ^JaJha"%OJQJ^Jho<ho<OJQJ^Jhevh0A}OJQJ^JhfUhW5B*ph4hfUho<5B*ph4hevOJQJ^JhevhevOJQJ^Jhevho<OJQJ^JhevhWOJQJ^J߻aboþkſ?@ YP^gdQY & FP^gd])gdYo YP^gdW YP^gdev:*+þɾξ (5[kÿĿյիաreXMhfUh]B*ph4hfUh]5B*ph4hfUh"*5B*ph4hfUhQ5B*ph4hfUh4l5B*ph4hfUh4lB*ph4h4lOJQJ^Jh])OJQJ^JhQOJQJ^JhfUho<5B*ph4huho<^Jh0A}OJQJ^Jho<ho<OJQJ^Jh@OJQJ^JhWOJQJ^JhOJQJ^JĿſοHIN%"FpqܹܯvlbbUHhfUho<5B*ph4hfUhQ5B*ph4hQOJQJ^Jh0A}OJQJ^JhWOJQJ^Jho<ho<OJQJ^Jho<h])OJQJ^Jh(MOJQJ^Jh(M5OJQJ^Jho<OJQJ^Jh])h"*5OJQJ^Jh[5OJQJ^Jh[OJQJ^Jh])OJQJ^Jh])h])5OJQJ^JhfUh])B*ph4#*2>?@248Sø|øsj``V`|h"OJQJ^Jh.OJQJ^Jhuho<^JhuhYo^Jh0A}OJQJ^JhfUho<B*ph4hfUho<5B*ph4hfUh]5B*ph4hfUhm5B*ph4hfUhQB*ph4hQOJQJ^JhmOJQJ^Jho<ho<OJQJ^Jh4lOJQJ^J!hfUho<B*OJQJ^Jph4^}fg34A}gdo<gd^a YTP^Tgd Y$TP^Tgd4l Y$P^gd4l YP^gd YP^gdW;]^}%efg"23Ȼȱէ鱐ȃvi^ȚShfUho<B*ph4hfUhmB*ph4ho<h*jOJQJ^Jh*jh*jOJQJ^JhfUh5B*ph4hOJQJ^JhfUh*j5B*ph4h*jOJQJ^Jh4lOJQJ^JhfUho<5B*ph4hfUhm5B*ph4hmOJQJ^Jh0A}OJQJ^Jho<ho<OJQJ^JhbOJQJ^J 34@A|}.gMv}~Żű~zvzzcPvc$hfUh5B*OJQJ^Jph4$hfUhd(5B*OJQJ^Jph4h-hK4!ho<hahhjWh|eh^ah@hfUh5B*ph4ho<OJQJ^JhOJQJ^Jh0A}OJQJ^Jho<ho<OJQJ^J#h(h(5CJOJQJ^JaJ#h(ho<5CJOJQJ^JaJh4lOJQJ^J}2.}e8e YP^gd /gd|e YP^gdnQp^pgdd( & Fgdgdo< & Fp^p`gdjW@Ee2j㸫zlW?/h@h45B*OJQJ^JmHnHphu)h@5B*OJQJ^JmHnHphuh@B*mHnHphuhX{B*mHnHphuh4B*mHnHphuh7shfUh /5B*ph4h|eho<hnQOJQJ^JhfUhnQ5B*ph4hnQhnQ5OJQJ^JhnQhnQ5>*OJQJ^JhnQOJQJ^J$hfUh5B*OJQJ^Jph43xy+Igd@dP7$8$H$^gd@d7$8$H$^gd4dP7$8$H$gd@ & FdP7$8$H$gd@dP7$8$H$^gd@gd7s}x+I` hijnr ! ۱ۭrdS h]LhX{B*mHnHphuh]B*mHnHphuh@B*mHnHphuhB*mHnHphu h]Lh]B*mHnHphuhX{B*mHnHphuh@7hfUh45B*CJOJQJ^JaJmHnHph4uh1hB*mHnHphuh4B*mHnHphu+h4h45B*CJaJmHnHphu IJ|}<[\ijgd@d7$8$H$^gdd7$8$H$^gd0A}d7$8$H$^gdX{-.%0ALabH]^Sdod7$8$H$^gdd7$8$H$^gd0A} gh7o[\*+,w̾Ặqmhdddh<2 hT25h4l$hfUhT25B*OJQJ^Jph4$hfUhfU5B*OJQJ^Jph4$hfUh@5B*OJQJ^Jph4ho<hZhT2h^ah@hX{B*mHnHphu(h"hX{B*CJaJmHnHphu h]Lh]B*mHnHphuhB*mHnHphu%gh7\xcLPgd@Pgd<2gdT2gdo<gd^ad7$8$H$^gdd7$8$H$^gdX{d7$8$H$^gd0A}Lw,$%! $$ (^$ gdfU $(^gdfU$(gdfU$Pgd2Pgd%Pgd<2  & FPgd<2w!@E\b+;<鶣t\\Xh/hfUh<25B*OJQJ^JmHnHph4uhfUh%B*ph4/hfUh%5B*OJQJ^JmHnHph4uh@h&hZ$hfUh25B*OJQJ^Jph4$hfUh%5B*OJQJ^Jph4h-h-h<25>*CJaJh-h%5OJQJ^Jh%h<2h-h<25OJQJ^J";<12G[\qPgd>O P^gd2d7$8$H$^gd2Pgd<2Pgd% (^gdfU/02[\q^_ '89hlm~t;<ҿҫңҫҫңҫңңңҟh=OJQJ^Jho<ho<OJQJ^Jh^ah@hQh5hQh5B*OJQJ^Jph4$hfUh5B*OJQJ^Jph4h hT2hT2hLhT2 hT2h"nhYh-h"nh<2h>O4_  &'9Sgd^aPgdgd & Fgd"ngdo<gdT2gdT2Pgd>OPgd"nQyz YP^gd4l YP^gd4l YP^gd@ YTP^Tgd"ngd4lgd_ YP^gd"n YP`gd"n34[\~./?@IJVӼ餲wmho<OJQJ^JhEh@0J OJQJ^J!j*h&OJQJU^Jho<h@OJQJ^Jjh@OJQJU^Jh@OJQJ^Jho<h4lOJQJ^Jh"nOJQJ^Jh4lh_hLfho<5OJQJ^Jho<ho<OJQJ^Jh=OJQJ^J'zMNk8KL@AZtD YP^gd4lgd4l Y & F Pgd"n YP^gd"n78KxyetLM"$lm,-  1&L渴檴洝h w^ho<5CJaJho<hrSOJQJ^Jho<OJQJ^JhrSh_hLfho<5OJQJ^Jhnho<5OJQJ^Jh=OJQJ^Jh4lho<ho<OJQJ^Jhd(ho<5CJaJ9DE3+,egd_YhP^`hgd"n YP^gd"nY & F P`gdngd4l YP^gd"n%Xvw^(l7o YP^gdngdrSB,-d%f A 4 YP^gdngd_ YP^gdngdrS4UGv 12q'(W-VogdrS YP^gdnoM4ef}~@&gdw$$@&^a$gdwgdrS YP^gdnef}78;<BCFGHTîwqwqwqwqwj hV+0J* hE0JjhE0JUhEB*phj7hEU hE6hEj+hEUhBXjhBXU)hp5B*CJ0OJQJmHnHphuhihi6CJaJhLfho<5OJQJ^Jh w^ho<5CJaJhrSOJQJ^Jho<ho<OJQJ^J%9:;de d$dN |dh^|gd20v $P2$dNdd H&dP      Q R X Y \ ] ^ m n                      ùØùùùÔ)hSM5B*CJOJQJ\^JaJphhBXj"OhSMUjhSM0JU* hV+0J* hSM0JjhSM0JUhSMjhSMUhE5B*CJphjhEU hE6jKBhEUhEjhE0JU*2   ? @ A ^ l m o p      d H F2d H2d$dN 2dd                 * + 5 @ A Q R S $d^a$gdq  Hd HF2 ) + ? A P R S T )hp5B*CJ0OJQJmHnHphuhBXhSM)hSM5B*CJOJQJ\^JaJphS T @&gdw< 0 0&P/R :pE/ =!"# $%% 9 0&P/R :p i/ =!"#$% 5 0/R :p i/ =!"#$% F q׽2~?JFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222Us" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( (C_!h^N ЅOP_ExbF> 5 e qXЪ>;k#}gFȔVcP^vKXJ{TM῎YhuxCA@E|/5\5}_B.dP=K@@mxsod[igh}He{EZP,Q >EPEeY]c'V'u|9 }*TA 6w x988c^u>kZ%+ok$QnivE v:j?W~2ҵ-΢B#;64/> xF +ga+>+ʍ-|ڊlqQq(USoli}ǑHy{v>?zxW?\{ekf1+ +=(z(3ߍ s}f__[s펵?& ZAkr 35.|(i:_=RO3]RKI=G?%@ ?o{⏁~5:Rs\~G_R[mu; |[đ#8ڇst}GIK˓$wEQi.i9acwgcQEWNo<[?ត;DɪNV A+{=WRdlv:6 Ƴ>5<z(VFe,t3&Ly.,H8$OYa0l:on.-kM̾qhǙ'#=JqEb>dH^]E`+>M$˭j})H[@i)c3D z0%"o>W|rҴolsi&el+{ {7?AIViЖCGMgo"Ҿj3kKX,oҹٶX3߰";3b4u_7ҭ8s ~ d{f-%k ؆[hccYOӥmEWRk*>vl< _E#h}2,,# HϧQ@\|@ aᵷ3^G$$1<{w5tP͚xGOI143Iç}*}+(^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX4 Dd 6VQ<  C A2 %H0'% [7p`!x %H0'% 3l"F xU eݖ6+҄DalQꭔRQo^-c 9֔},bb!c-("m*o~ss?}}=y|Y WI\tE^2%8 :|#"iuU)uZ2=ܵKz:5kպ-N;\sUek)06qMRrZgKȞLKKOʾlvfzVXj.ԬXf5<)1%vZ#$(BeߔP轤<ޏ*HVR|\GORLg?jjtQsq 3㻕gaM r4)ICM /f^([B_bnycAXj)q [L?oKm13!8n$%ִouϣ6gii|R64|X bK 暃\͊<yFaxy̻5ڐDNgιsi\ۆ>^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX Ddl  C :A"Intel logo print"`R q׽2~? BpF q׽2~?JFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222Us" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( (C_!h^N ЅOP_ExbF> 5 e qXЪ>;k#}gFȔVcP^vKXJ{TM῎YhuxCA@E|/5\5}_B.dP=K@@mxsod[igh}He{EZP,Q >EPEeY]c'V'u|9 }*TA 6w x988c^u>kZ%+ok$QnivE v:j?W~2ҵ-΢B#;64/> xF +ga+>+ʍ-|ڊlqQq(USoli}ǑHy{v>?zxW?\{ekf1+ +=(z(3ߍ s}f__[s펵?& ZAkr 35.|(i:_=RO3]RKI=G?%@ ?o{⏁~5:Rs\~G_R[mu; |[đ#8ڇst}GIK˓$wEQi.i9acwgcQEWNo<[?ត;DɪNV A+{=WRdlv:6 Ƴ>5<z(VFe,t3&Ly.,H8$OYa0l:on.-kM̾qhǙ'#=JqEb>dH^]E`+>M$˭j})H[@i)c3D z0%"o>W|rҴolsi&el+{ {7?AIViЖCGMgo"Ҿj3kKX,oҹٶX3߰";3b4u_7ҭ8s ~ d{f-%k ؆[hccYOӥmEWRk*>vl< _E#h}2,,# HϧQ@\|@ aᵷ3^G$$1<{w5tP͚xGOI143Iç}*}+(^ ?f,<˘h62K֧XyΡ}nx_b/_7 9=;Aq>TNWEwbbi-'nh-UZUie[Ug0D_'B'swйb+Ӓ  RH>!#:iܫC~~[ t룞:=^zuܪo.-^NE^VZRk *\+22TKh > /mX(ε#} ǫ=1`0cdG,/+os?yd3+e1LuQO \4rӁu _[{oTrJ> V0d} ޠ\ަws<&0{O")3s&q%y }}oa/ay=Or,H_Fi/+/B-Amb. j]SYuXO XEDlEڌ>[;"y|DL4|HLdO xU U5$U SuS#U *. a*ź>|raʆ.뚰FW] uEب&]6UevvtإRa<악}:qVA֯3_%߸K{}~{Or'\' r}B$u}Roq<#97Ci;}ۍ;3N:2nw IH|/kK?gS%?W5zw~ߦ{}O UW.PgkY[Xjͬ_&֭OUEF*5tUy꼼P9j@Y*6P{h'>WvVlQ_aSlToFzi] V/k V%GzhVGiYF(O$H>tԢH(隯4tмHFR4GHlEr/hVf3=5C xT {}K8NNo=S8a`/)i&wmA"5^:URUucUMxu?v/E &~̚ob-'{k3~ZXƒkK޿tcYr 컬Ϭmoa[m,/- sZ_UD[{/m7c~_>;@,}&LacuG5?d8n煓vA8eRWaϸrT>\˾Rzo*Ta^T=){m%ܮ[ÝVU34Q|hUucQ݁Fy0F~ûkU$%!zoKmjѶFax l8:{Cm +Vh16@ OڦHo+͑wX7,>tζ -FT1km_$˾d~ ,;a`ko?gK#yl𧵳8iIMH2hס,7 sQE*nQDRj+6hƯݩ4 Rݍ{ap2~4V=њa#h5cl#Aݭ9W?D!VCpf1R5cMqx6ޱt ej"&[`u Zfch[L+_9#xf,Ӫ3l[Ej6Z5m@![Ykc]VIˬ>AU` {صvfڕ.åyY\B\TrF)dlm$d2LL8`Sׇ54jo q5KR _l-K'V`H>VsϬ):>bg6bV6]*ysGx~}dX\sppppppppp0002 0@P`p2( 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p8XV~ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@ 0@_HmH nH sH tH J`J Normald$^_HmH sH tH @ Heading 1=$$$ & F d<@&^`5B*CJ0OJQJph|@|z"| Heading 27$ & F d<@&^`5B*CJ OJQJph~@~z"| Heading 3:$$ & F dh<@&^`5B*CJOJQJphz@z Heading 46$$ & F d,@&^`5B*CJOJQJphff Heading 5($$ & F ( d,d@&5B*CJOJQJbb Heading 6%$$ d,@&^5CJOJQJHH  Heading 7 & F<@&OJQJLL  Heading 8 & F<@& 6OJQJR R  Heading 9 & F<@&56CJOJQJDA`D Default Paragraph FontViV  Table Normal :V 44 la (k (0No List HOHBodyd$^B*mHnHu`"@` Caption)$$Xd$<1$^`X5B*OJQJ@Y@  Document Map-D OJQJ^@^!mpTOC 1+$$ p$BR`<^``5B*OJQJd@d1lpTOC 2+$ p$ p0^p`0OJQJmHnHuN@NpTOC 3! @ $@J@ 0^@ `0OJQJP@PpTOC 4$ @ $ "^"`OJQJNNpTOC 5! \% \P^\`POJQJH@rHHeader $F2^OJQJJ @JFooter $$d ^OJQJ.)@. Page Number4>4 Title$a$5CJ,dd Function Prototype $$ HH ^H` 5hBB Parameter Prototypeff Function Desc Header$$$,1$]a$5h^^ Parameter Description ^`FFCoded^CJOJQJh6U`6 Hyperlink >*B*ph>J> Subtitle !$@&a$5CJ$l"l Overview Heading."X$d!%d$&d 'd$-D ^X5h#@h0Table of Figures%# p$ p0^p`0OJQJbBb App_Level 1 $ d<`5B*CJ0OJQJ@AR@ App_Level 2 %dCJ TbT App_Level 3& `5B*CJOJQJTrT App_Level 4' `5B*CJOJQJbOb FigureSpace*($d$d%d&d'da$OJQJ00ArtID)$a$CJ @@Bullet*3x<^3`<< BulletPara+3<^3FF BulletSub, <^LL BulletSubPara- & F ^DDCaution. Xd`X CellBodyBullet0/ & F L<]^`LB*CJOJQJmH sH u\\ CellBodyBulletSub0 (^`(bb CellBodyLeft#1$d8((]^ CJOJQJ>">CellBodyCenter2$a$<2< CellBodyRight3$a$zBzCellHeadingCenter,4$$$((d`xx](^(a$5B*CJOJQJ@AR@CellHeadingLeft5$a$BAbBCellHeadingRight6$a$ROrRDocDate7d^56B*CJOJQJRORDocTitle8$./^5B*CJ0OJQJLOLDocType9dT&d5B*CJOJQJJJFigureSpace with Art ID:D& D Footnote ReferenceCJEHXX Footnote Text <]dL((^]`CJdOd Heading (TOC)=d&d^56B*CJ0OJQJfOfHeading (LOF & LOT)>d&d6CJ OJQJBOBLegal?P^ CJOJQJ@@Note@ p^`pBB Note TextA]^>">NotesB ^`L2L Notes TextC xx<^x`bBb Numbered_List$D dx^` htH uLRL Numbered_List TextE<^8Oqb8RefNumF 6POrPRevNum Gd5B*CJOJQJmHnHull Table Caption (Cont'd)H$hd<^h5B*OJQJZZ TableNotesId<@&^` CJOJQJnn TableNotesStep+J ppLd((@&^p`L CJOJQJFFWarningK ^`<< Code Level 2 L^@@ Code Level 3 M^B*<< Code Level 4 N ^ hh Parameter Descrip. BulletO ^`<C< Body Text IndentPHRH Body Text Indent 2 Q^@@ mpTOC 6Rd^CJaJ@@ mpTOC 7Sd^CJaJ@@ mpTOC 8Td^CJaJ@@ mpTOC 9Ud^CJaJ|c| / Table Grid7:VV0Vd$^r -kcode,Ex,CODE,PRE,CITEUW$$ 8h8p @ xHd^ CJOJQJFV F  0FollowedHyperlink >*B* phNZ@N Z(0 Plain TextYd^ OJQJ^JB/B Ys0Plain Text Char OJQJ^J@@ ] List Paragraph [^PK![Content_Types].xmlN0EH-J@%ǎǢ|ș$زULTB l,3;rØJB+$G]7O٭VvnB`2ǃ,!"E3p#9GQd; H xuv 0F[,F᚜K sO'3w #vfSVbsؠyX p5veuw 1z@ l,i!b I jZ2|9L$Z15xl.(zm${d:\@'23œln$^-@^i?D&|#td!6lġB"&63yy@t!HjpU*yeXry3~{s:FXI O5Y[Y!}S˪.7bd|n]671. tn/w/+[t6}PsںsL. J;̊iN $AI)t2 Lmx:(}\-i*xQCJuWl'QyI@ھ m2DBAR4 w¢naQ`ԲɁ W=0#xBdT/.3-F>bYL%׭˓KK 6HhfPQ=h)GBms]_Ԡ'CZѨys v@c])h7Jهic?FS.NP$ e&\Ӏ+I "'%QÕ@c![paAV.9Hd<ӮHVX*%A{Yr Aբ pxSL9":3U5U NC(p%u@;[d`4)]t#9M4W=P5*f̰lk<_X-C wT%Ժ}B% Y,] A̠&oʰŨ; \lc`|,bUvPK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 0_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!R%theme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] )CXnT/258;S)CXnT((>(y ?e&66k6E&}JW= " #6'-6=DJX^~df~hjnota7̛߫H(:Ŀ3 w T $"&-w2677<7?7CJTV^he9hkow{ CI[VsƦϫ߻}ILzD4o S T $ "C_a|+GJi 7 : O k n  % A D [ w z   " A ] ` s    8 ; T p s   = Y \ '*\x{ $@C]y|7:Okn %(?[^z;WZy /KNk 0LOs!D`c47[wz9<Sor"9UX~*-Jfi #>Z]u  !Mehz{D{IT T%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % _XXelp&-/{!!t!!t!t!t /T ,R$q׽2~? p0 www@2  (  ~  C :A"Intel logo print#" `?~  C :A"Intel logo print#" `?~  C :A"Intel logo print#" `?P   # #" ?z*S(   -z  +3  "0?` , c $X99?-z N2 - 3  =T2 . C  z=~ / 6/ { N2 0 3 QT2 1 C B~ 2 62V N2 3 3 T2 4 C  zF=~ 5 65  N2 6 3 F QT2 7 C   ~ 8 68 C N2 9 3 *\T2 : C z=~ ; 6; hZ c9d  < c9. HB = # c9+  > rB~CDEFF~vF @`W d hZ 9G  ? KY HB @ # @9@ A rBCDEFE @`G Z _  B  HB C # eYe D rBCDEFB @`#b E rBCDEFF @`_ hZ 9  F E98 HB GB # 9  H rBCDEF!V! @`S  hZ  _  I  HB J # E E  K rBCDEFF @` _ hZ  L HB MB # n N rBCDEFR @`=WhZ  O HB P # >r Q rBCDEFVjV @`Ar2 R 6))?f #0 ~ S 6S Q b  B S  ?fT+-z t St&$TTT[ _Toc498764105 _Toc37581258 _Toc37581736 _Toc483983684 _Toc483983685 _Toc483983686 _Toc498764110 _Toc37581263 _Toc37581741 _Toc483983687 _Toc478124672 _Toc483983688 _Toc483983689 _Toc483983690 _Toc483983691 _Toc483983692 _Toc483983693 _Toc483983694 _Toc483983695 _Toc483983696 _Toc483983697 _Toc483983698 _Toc483983699 _Toc483983700 _Toc483983701 _Toc483983702 _Toc483983703 _Toc483983704 _Toc483983705 _Toc483983706 _Toc483983707 _Toc483983708 _Toc483983709 _Toc483983710 _Toc483983711 _Toc483983712 _Toc483983713 _Toc483983714 _Toc483983715 _Toc483983716 _Toc483983717 _Toc483983718 _Toc483983719 _Toc483983720 _Toc483983721 _Toc483983722 _Toc483983723 _Toc483983724 _Toc483983725 _Toc483983726 _Toc483983727 _Toc483983728 _Toc483983729 _Toc483983730 _Toc483983731 _Toc483983732 _Toc483983733 _Toc483983734 _Toc483983735 _Toc483983736 _Toc483983737 _Toc483983738 _Toc483983739 _Toc483983740 _Toc483983741 _Toc483983742 _Toc483983743 _Toc483983744 _Toc483983745 _Toc483983746 _Toc483983747 _Toc483983748 _Toc483983749 _Toc483983750 _Toc483983751 _Toc483983752 _Toc483983753 _Toc483983754 _Toc483983755 _Toc483983756 _Toc483983757 _Toc483983758 _Toc483983759 _Toc483983760 _Toc483983761 _Toc483983762 _Toc483983763 _Toc483983764 _Toc483983765 _Toc483983766 _Toc483983767   #lb !"%'()2))F*-k.6//G0+12~223<a=r=VBBDtE{FHIPRRpW[cmmo o@ojp}p}wx6|+}b@[w(+\8e U234  !"#$%&'()*+,-./0156789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ"3Lo !#%(()@))Y*-{.F//W0B13222&3<q==iBB0DEF6Hoaojpjpjp|ppwxX|A}}ZqϥA¶ӻH6wJ+0U$ ; O o  % E [ {  # A a s   < T t = ] +\|$D]}@4C4E4H4J4P4o4u44444449#9::K;U;qqqqqq-r2r^u "    Q]mqU0Ps"Dd8[{=Ss#9Y~.Jj$>^u "mmUYe{ƿ@] g޿ER(>Ba</XTf)Z'8/3<ihC NoDTpbFW1iXBTyuZN$ v[6f]ݚ`__ ^agF+\d%  'm 3Yvz3n?6P Xq^`^`.^`..^`... ^` .... ^` ..... ^` ...... ^`....... ^`........h^`OJQJo(hHh ^ `OJQJ^Jo(hHoh ^ `OJQJo(hHhx^x`OJQJo(hHhH^H`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh ^ `OJQJ^Jo(hHoh\ ^\ `OJQJo(hHh,^,`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHhl^l`OJQJ^Jo(hHoh<^<`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHop^p`OJQJo(hH@ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoP^P`OJQJo(hHT^T`o() $ ^$ `hH.  L^ `LhH. ^`hH. ^`hH. dL^d`LhH. 4^4`hH. ^`hH. L^`LhH.^`o()  ^ `hH.  L^ `LhH. x^x`hH. H^H`hH. L^`LhH. ^`hH. ^`hH. L^`LhH.h^`OJQJo(hHh ^ `OJQJ^Jo(hHoh ^ `OJQJo(hHhP^P`OJQJo(hHh ^ `OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh`^``OJQJo(hHh^`OJQJo(hHh ^ `OJQJ^Jo(hHoh\ ^\ `OJQJo(hHh,^,`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHhl^l`OJQJ^Jo(hHoh<^<`OJQJo(hHx^x`o() H ^H `hH.  L^ `LhH. ^`hH. ^`hH. L^`LhH. X^X`hH. (^(`hH. L^`LhH.h T^T`hH.h $ ^$ `hH.h  L^ `LhH.h ^`hH.h ^`hH.h dL^d`LhH.h 4^4`hH.h ^`hH.h L^`LhH.h ^`hH.h  ^ `hH.h \ L^\ `LhH.h ,^,`hH.h ^`hH.h L^`LhH.h ^`hH.h l^l`hH.h <L^<`LhH.h b^b`hH.h 2 ^2 `hH.h  L^ `LhH.h ^`hH.h ^`hH.h rL^r`LhH.h B^B`hH.h ^`hH.h L^`LhH.^`OJQJo(hH^`OJQJ^Jo(hHop^p`OJQJo(hH@ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoP^P`OJQJo(hHT^T`o() $ ^$ `hH.  L^ `LhH. ^`hH. ^`hH. dL^d`LhH. 4^4`hH. ^`hH. L^`LhH.hT^T`OJQJo(hHh$ ^$ `OJQJ^Jo(hHoh ^ `OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohd^d`OJQJo(hHh4^4`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh ^`hH. ^ `o()4^4`OJPJQJ^Jo(nh P^P`hH.h  ^ `hH.h L^`LhH.h ^`hH.h ^`hH.h `L^``LhH.hb^b`OJQJo(hHh2 ^2 `OJQJ^Jo(hHoh ^ `OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohr^r`OJQJo(hHhB^B`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh ^ `OJQJ^Jo(hHoh ^ `OJQJo(hHhP^P`OJQJo(hHh ^ `OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh`^``OJQJo(hHP^`P@@^@`.0^`0..``^``... ^` .... ^` ..... ^` ...... `^``....... 00^0`........h ^`hH.h  ^ `hH.h  L^ `LhH.h P^P`hH.h  ^ `hH.h L^`LhH.h ^`hH.h ^`hH.h `L^``LhH.h ^`hH.h  ^ `hH.h \ L^\ `LhH.h ,^,`hH.h ^`hH.h L^`LhH.h ^`hH.h l^l`hH.h <L^<`LhH.hT^T`OJQJo(hHh$ ^$ `OJQJ^Jo(hHoh ^ `OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohd^d`OJQJo(hHh4^4`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hH\d)Z'`_ihCvz3niX/3<ERTyuZe{ g_]'m ^a/X>BabFW$ v[P XqoD                           >'        ƃ                          ې~                                            >'                  F*~{.                                                    +}/%=eaZ-*=cO$=eB2(M /642g7s>k@ HJE:LqYWd7]a/%j&c fg"_i:qnp{SvTzl@!08LZ7x %*tHK4`a=*$)"@]W_lnt@ E K xS Z a 1t n A-F%RT{hqv)3#V:Y7GV+67LiO4C],k;Nm"E^+gl 86>CoNSR]u@2VX7s  nt#_*Wl',35v7NkO-y},/K4FsHVYjYb($)^0@H>MZ^alz"-4Rfi{ I9gHP'Wa$4DEo_ _HNUl~[ 0!K4!@!f!"!"""%-"'>"a"ml"M#/9#[#x# $$$%$4$)5$w$K%a"%#%L%Z%z\%& & &3&%;&M&[&F_&}& 'Q$'f?'IX'D`'(((1(_(d(`p(8)6a6i6s6&v6A7G7zK7tR7\788;8 B8E8}\8Ua8e9)9>9M9@9:K:k:s ;;;+;^,;Q;y];Bi;l; <&<.<8C<`<a<a<t<K~< =9==D!=#=F*=TF=J=;z=j >!>y&>=>G> x>5?z&?8C?\?~~?L @@@@@K@k@]m@AEAAA>Ay_A>BABCBQBRBFmBqBCCCCn/C0CRMCWCHIaHII/IJ8JZJ K?K,K1K8KBKOCKJKgKjKkK{KL]LjLM1M!M(M7M;MC>MIjMN#N'N7N\NyN~N"O#OVOxOP&PnBP IP{gP9{PQQQnQ.R6RiRyR~RS.SBSrS.T-2T3TKTUQ-UVUbUgUVV V VV0VWW/W:`WjWuWvW XXXa0XnEXoXqX_ YY/YXYjYZkZ WZokZpZ|ZC,[G;[=[N[uS[\ \ \6\A7\=D\\\!]]/]N]z]^%^J'^4^h^4i^ w^k_2 _!_'_P_\_2^_ `/ ``S`ee`|``6aRaVa^abs&b,bf@bzbc"ccNcuScjcd<d'd3,d,d,dd3d?CdDdlsdZ!e:ef6fLfTfI g1g;&gbgmgUog@}g1hBhhh h,hGQh`hmh i-i4i4iPi]i8ki,jjjE)j*jr3jR;jx kk-kpskB|k|k4.l1l4lIlOl7Rl_Rl^lp|l~lm!m Dm$hmn4+nvn oo#)oYoHooporoppQp'%pLpWpqq;qYq_ qA-q;qw\q}gqr&rrZrX]r^rM}rs7ss%sb2sHMs-t0tf9tErts}t uuKukSuXu]vdvv v$v.v20vwQw'wm(w)w.Jwawcwlwytwwzw|wxYxAxLxWcxuxyi y`yaeygylyoy"zz)5zU{X{`{z"|I|`|d|Wx|u~| } }|}(>}?}0A}kP}Q}C~~Bp~x~6X<uEyC17WJ^K6'r(6%LT$'*'hr,A?J pff;.7K]dbfvx"(>HP4QS"qE1<$BgJJNfUoUVnqt$$8V;xDzp "_#o(N3BJpwny]SM`4{-*b7?Py "o-DO_zu89Z'o< DqV$i|%`Pim8}?&-..4K| $$-#J`R&{Ccdzj"<)}9|e0djWuLL$z-?Zq77<GJhh iiE\&f2U8(=Ds}*}/9/=Q =(chxU-KG!Ujnw".3: T=zt; =qyZ@4U [m[_v{| (+F,ICUpx'Y]v{I5Tte%O]`v!&AtV[<}PC*I 6N"wh^qp ,;Otx }A@I`bmQ } E.LBXhrw)r(.20GUmyt9CY @`Jcw=>>QXilw/1IFKMj"U&9q`0sD9T_-HYJOWg^b Op "#, 0:<<Y]EFZb>%h-DQZf0UEKnp}5a:@QVi"~Dele N*;?[,mnZ[1]u@sevGW?X^aar9BqJl^`aWe g"nqzIXZ+p0HNp<'T?tPZaceO&EH9/2fnkm~> x>?A^de#o4!-yA>OpwQ&T|G(yFT[ cch3<}6EUO[Q`w-">mTZp J)JTKWf:b|Z 556`kSu} F ''WyZi[[i!y7^|E,ZaB[h> ,Z69<cCFFQrzk:?.JWZMju (bQbgnm#{-{.v/<2FdbjVk~ .7r * =n :@PRsu^+K03`h}jww&'UEvR{YavW !])f;`5 #$8>DV>x?U!^9<#ky2+8HR|&h*&NV_p|| ;$4@[a)0=q"+~Sj[  c~/*t_cgni~Ywgt| ;]bk Qg(O>X]x m_hijvDMXS]^& (w)+gk~%+D@yE ).m.>VY0Zz<Avi#\Hm^7iu |}"`)>g"dPfilz@T@@Unknown G.Cx Times New Roman5Symbol3. *Cx Arial7.@Calibri?= *Cx Courier New;Wingdings71 Courier5. .[`)Tahoma;. *Cx HelveticaA$BCambria Math#1hcU.Ug.UgN/&./&.!4TT 2qXZ? 2! xx 0ACPI Component Architecture Programmer ReferenceACPI,CTPClassification=CTP_PUBLIC:VisualMarkings=Robert Moore;David Box Moore, Robertd                 Oh+'0<P ht    4ACPI Component Architecture Programmer ReferenceACPIRobert Moore;David Box0CTPClassification=CTP_PUBLIC:VisualMarkings= Normal.dotmMoore, Robert15Microsoft Office Word@T @?%@0T@?%./&՜.+,D՜.+,|8 px  Intel Corporation<T 1ACPI Component Architecture Programmer Reference Title PLlx _PID_HLINKS TitusGUIDCTP_TimeStampCTP_BU CTP_IDSID CTP_WWIDCTPClassificationA0 607http://www.filewatcher.com/m/PKZIP25.EXE.339456-0.htmlA )http://stackoverflow.com/a/1053662/41661(9f480be1-c79f-4a34-8fd8-b6767523e1b92017-05-12 19:53:06ZNANANA CTP_PUBLIC  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry Fp\%Data VZ1Table0WordDocument SummaryInformation(DocumentSummaryInformation8MsoDataStorep\%p\%O3YYEZQ==2p\%p\%Item  PropertiesUCompObj r   F Microsoft Word 97-2003 Document MSWordDocWord.Document.89q