Compiling implementation method and device for ARM processor supporting posit floating point format

Abstract

The application discloses a kind of compiling implementation method and device for ARM processor supporting POSIT floating point format, the method includes: in compiling front end, the extension of POSIT type is carried out to lexical and syntax analysis, semantic analysis extension and intermediate representation generation extension, lexical and syntax analysis extension includes the keyword of newly added POSIT type, semantic analysis extension includes the semantic checking rule of increasing for POSIT type, intermediate representation generation extension includes the corresponding LLVM IR instruction of generating for the various operation operations of POSIT type;In compiling middle end, the IR type system extension of POSIT type is carried out, IR instruction set extension and optimization channel extension;In compiling back end, instruction selection and mapping, register allocation and call convention and instruction scheduling and emission are configured for POSIT type.The application can significantly improve the comprehensiveness, usability and compiler performance of compiling.

Description

Technical Field

[0001] This invention relates to the field of high-performance computing technology, and in particular to a compilation implementation method and apparatus for supporting POSIT floating-point format for ARM processors. Background Technology

[0002] Floating-point format is a specification for computer hardware and software to process floating-point data. It standardizes how computer hardware and software calculate, transmit, and store floating-point data. Floating-point format has a significant impact on the design and implementation of computer hardware and software. The hardware layer needs to design corresponding execution and storage components based on the floating-point format and provide corresponding floating-point instructions as the calling interface for the software layer. At the same time, the software layer needs to provide programming interfaces, compilers, and high-performance mathematical libraries to fully utilize hardware performance and improve application efficiency.

[0003] Currently, floating-point formats follow the IEEE 754 standard. However, with the rise of data-intensive fields such as artificial intelligence and big data, the demand for high-precision, high-dynamic-range numerical calculations is increasing, placing new requirements on data representation formats. The POSIT floating-point format has attracted attention because it offers higher precision and a wider dynamic range than the traditional IEEE 754 format at the same bit width. The POSIT floating-point format can provide more possibilities for further improving application computing efficiency. However, current general-purpose programming languages ​​and compilers do not yet provide adequate support for the POSIT floating-point data format. This lack of language support results in a lack of effective descriptive tools for algorithms based on the new floating-point format, and the lack of compiler support makes it difficult to conduct hardware-level research on the performance and characteristics of the new floating-point format. In other words, the practical application of the POSIT format will face the problem of a lack of complete software toolchain support.

[0004] Specifically, current mainstream open-source compilers (such as those based on GCC or LLVM) do not provide native support for the POSIT data type, which leads to the following problems: 1. Compatibility issues: Developers cannot directly use the POSIT data type in high-level programming languages ​​(such as C / C++) and must rely on cumbersome software library function calls for calculations, which seriously reduces development efficiency and prevents them from taking advantage of the compiler's automatic optimization capabilities.

[0005] 2. Performance bottleneck: Simulating POSIT operations through software library functions is far less efficient than instructions directly supported by hardware, and it cannot utilize the vectorized instruction sets of modern processors (such as ARM NEON) for parallel acceleration, thus failing to realize the performance advantages of the POSIT format.

[0006] 3. Ecosystem Barrier: The lack of compiler support creates a huge software and hardware gap between upper-layer applications and lower-layer hardware (especially ARM processors or FPGA hardware accelerators that support the POSIT instruction set), making it impossible to form a collaborative optimization technology ecosystem and seriously hindering the transition of the POSIT format from theoretical research to practical engineering applications.

[0007] Supporting the POSIT data type on top of existing mainstream open-source compilers (GCC / LLVM) presents the following challenges: 1. Incompatibility between high-level language syntax and type systems. Existing compilers' syntax parsing and type rules are based on traditional integer and IEEE 754 floating-point types. Adding the POSIT type presents two problems: first, the compiler cannot recognize POSIT-related keywords and cannot parse the declaration code of POSIT variables; second, the type hierarchy rules for POSIT are completely different from those of traditional types, and directly applying existing rules will lead to calculation errors, such as the inability to determine whether posit32_2 and posit32_3 can be calculated together. 2. Incompatibility between compiler intermediate layer functionality and optimization. The compiler intermediate representation (IR) is the core link between code parsing and hardware instructions. Existing IRs only support instructions and optimization logic for traditional data types and cannot directly support POSIT. On the one hand, it is impossible to generate valid POSIT operation IR instructions, and there are no dedicated instructions to implement the conversion between POSIT and other types; on the other hand, existing optimization logic is not suitable for POSIT, and direct use will lead to loss of precision or performance degradation, or even failure to trigger optimization. 3. The compiler backend is incompatible with the hardware instructions. While ARM processors / FPGAs can support POSIT, their instructions and registers differ from traditional hardware. Because current compiler backends lack rules to translate the IR instructions for POSIT operations into hardware-recognizable POSIT-specific instructions, multiple traditional instructions may be needed for simulation, resulting in wasted performance. Furthermore, current compiler backends lack specific allocation registers adapted for POSIT and clear rules for passing POSIT parameters during function calls, leading to code execution errors. Summary of the Invention

[0008] The technical problem to be solved by this invention is: in view of the technical problems existing in the prior art, this invention provides a compilation implementation method and apparatus for ARM processors to support POSIT floating-point format, which can significantly improve the comprehensiveness, usability and compiler performance of compilation.

[0009] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows: A compilation implementation method for supporting POSIT floating-point format on ARM processors includes: The compiler front end performs lexical and syntactic analysis extensions, semantic analysis extensions, and intermediate representation generation extensions for the POSIT type. The lexical and syntactic analysis extensions include adding keywords for the POSIT type and constructing an AST tree to enable parsing code containing the POSIT type. The semantic analysis extensions include adding semantic rules to define the POSIT type to clarify the type hierarchy and implicit conversion logic. The intermediate representation generation extensions include mapping various operations of the POSIT type in the AST to corresponding LLVM IR instructions to provide for mid-end optimization and back-end code. During compilation, IR type system extensions, IR instruction set extensions, and optimization channel extensions are performed for the POSIT type. The IR type system extensions include adding basic data types corresponding to the front-end POSIT type in LLVM IR. The IR instruction set extensions include modifying the core arithmetic instructions of LLVM IR to support the POSIT data type and extending the type conversion instruction set to support mutual conversion between the POSIT type and other types. The optimization channel extensions include configuring optimization channels suitable for the POSIT data type to perform machine-independent optimizations on IR code containing POSIT operations. In the compilation backend, instruction selection and mapping, register allocation and calling conventions, and instruction scheduling and issuance are configured for POSIT types. The instruction selection and mapping includes mapping LLVM IR instructions containing POSIT operations to POSIT hardware instructions of the target hardware platform. The register allocation and calling conventions include defining register classes and function calling rules for POSIT data types. The instruction scheduling and issuance includes scheduling and optimizing the generated POSIT instruction sequence according to the characteristics of the target processor.

[0010] Furthermore, in the compiler front-end, the lexical and syntax analysis extensions include: Keyword addition: A new POSIT type keyword is added to the keyword enumeration of the compiler's lexical analysis module, and a corresponding type identifier is added to the type specifier enumeration, so that the compiler can recognize the new POSIT type keyword as a valid type specifier; AST data structure extension: In the abstract syntax tree context class, a new member variable is added to store the POSIT basic data type. The POSIT subclass is extended in the built-in type class, and the type identifier retrieval method is reconfigured so that the AST can carry POSIT type information. Syntax analysis logic supplement: Modify the syntax parsing function so that when a POSIT type keyword is detected, the corresponding processing logic is triggered to generate the corresponding POSIT type AST node.

[0011] Furthermore, in the compilation frontend, the semantic analysis extension includes: Type rank rule definition: A new POSIT type rule is added to the type rank determination function of semantic analysis, including: POSIT type rank is higher than IEEE 754 floating point type under the same bit width; under different bit width, the corresponding rank is determined according to the width of POSIT type; for POSIT types with the same bit width but different exponent bit lengths (es), the corresponding rank is determined according to the exponent bit lengths (es). Static constants and semantic mapping: Define static constants that store the bit width and es parameter of the POSIT type. During AST context initialization, bind the corresponding type to the POSIT type member variables and map the POSIT floating-point semantics. Semantic check supplement: In the semantic check function for binary operations, POSIT type logic is added, including: POSIT types with the same bit width but different exponent bit lengths (es) are prohibited from direct operation, and POSIT is implicitly converted to other types according to the rank rule when operating on them.

[0012] Furthermore, the intermediate representation generation extension includes: Type mapping logic: Modify the conversion function from AST type to IR type. When the input type is POSIT type, return the corresponding POSIT basic type in IR. Arithmetic IR Generation: Modify the scalar expression emission function to generate corresponding IR core arithmetic instructions for addition, subtraction, multiplication, and division operations of type POSIT; and generate IR comparison instructions that support type POSIT for comparison operations. Type Conversion IR Generation: Modify the type conversion expression emission function to generate IR conversion instructions or call LLVM internal functions for conversions between POSIT and other types.

[0013] Furthermore, in the compilation process, the IR type system extension includes: Basic type definition: Define POSIT scalar and vector types through template files, and generate corresponding IR type enumeration and processing code; Memory layout adaptation: Modify the alignment and bit width retrieval functions of the IR data layout class to return the correct parameters for the POSIT type; Serialization / deserialization support: Modify the bitcode write and read functions of the IR module to assign encodings to POSIT types in the type table.

[0014] Furthermore, in the compilation stage, the IR instruction set extension includes: Core arithmetic instructions extended: Modified the operand validity check function for the IR binary arithmetic instruction class to allow operands of type POSIT for add, sub, mul, and div instructions; also modified the instruction creation function to support the generation of arithmetic instructions of type POSIT. Type conversion internal function definition: Define the internal functions for POSIT and other type conversions through the IR internal function template, and generate the corresponding function declarations and recognition logic. IR implements type conversion by calling the corresponding functions; The optimized channel expansion includes: Vectorization optimization and adaptation: Modify the type validity judgment function of the loop vectorizer to allow the POSIT type as a valid vectorization type; in the vector type generation function, generate the corresponding vector type for the POSIT type; in the loop vectorization logic, generate vector IR instructions for operations on the POSIT type. Optimize channel integration: Add the POSIT optimization channel to the compiler optimization pipeline and set it to be automatically enabled at a specified optimization level; at the same time, modify the type discrimination logic of the optimization pass to add support for the POSIT type.

[0015] Furthermore, in the compilation backend, the instruction selection and mapping includes: Instruction format definition: Define the instruction format according to the encoding rules of ARM POSIT instructions to specify parameters including operand type and instruction length; Instruction mapping rule definition: For ARM POSIT hardware instructions, define the mapping rules from IR instructions to hardware instructions to map POSIT type IR arithmetic instructions to the corresponding ARM hardware instructions; Instruction selection logic supplement: Modify the backend DAG to DAG instruction selection function. When encountering a POSIT type IR operation node, call the corresponding matching logic and select the corresponding ARM POSIT hardware instruction to generate a machine instruction node.

[0016] Furthermore, in the compilation backend, register allocation and calling conventions include: POSIT Register Class Definition: In the back-end register information definition, a new POSIT dedicated register class is added, and it is specified that a certain subset of the ARM processor's general-purpose registers are used to store POSIT data, so as to clarify the register bit width and the supported POSIT types; Calling convention configuration: In the ARM calling convention definition, a new rule for passing POSIT type parameters is added to clarify how POSIT parameters are passed during function calls and where the return value is stored; The command scheduling and launch include: Hardware characteristic modeling: Add information about execution latency and functional unit occupancy to the backend target machine description of the POSIT instruction; Instruction scheduling logic optimization: Modify the backend instruction scheduling function to adjust the instruction execution order for the POSIT instruction sequence, taking into account hardware characteristics and instruction dependencies, to reduce pipeline stalls; at the same time, optimize the instruction issue logic to ensure that the POSIT instruction can efficiently utilize hardware functional units and improve overall execution efficiency.

[0017] A compiler device for ARM processors supporting the POSIT floating-point format includes a processor and a memory for storing computer programs, and the processor for executing the computer programs to perform the methods described above.

[0018] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention constructs a systematic compilation scheme by extending the entire compiler chain from front-end to back-end. The front-end implements POSIT extensions to identify and process POSIT type-related syntax and semantics; the middle-end extends POSIT based on LLVM IR to improve the type system, instruction set, and optimization capabilities; and the back-end configures POSIT-related instruction mapping and scheduling logic for ARM chips. Ultimately, it achieves full-stack support for the POSIT format on the LLVM compiler framework, from language extensions and compilation optimization to hardware code generation, forming a complete solution. This solves the problem that current general-purpose compilers cannot provide complete support for the POSIT floating-point format, making it difficult to implement in practical applications. It achieves comprehensive support for the POSIT format on the ARM processor platform from the front-end to the back-end, thus bridging the entire technology chain from application development and compilation optimization to hardware execution, eliminating the software-hardware gap between upper-layer applications and lower-layer ARM hardware.

[0020] 2. This invention, with the deep native support of the compiler, directly compiles POSIT operations into hardware instructions for the ARM processor, completely avoiding the huge performance overhead caused by software simulation. At the same time, the compiler can automatically optimize the POSIT-related code and fully utilize the hardware computing resources of the ARM processor to maximize its computing potential, thus demonstrating the performance advantages of the POSIT format and effectively solving the problems of performance bottlenecks and failure to realize hardware potential in traditional POSIT operation simulation through software library functions.

[0021] 3. This invention further extends the basic type system of the C / C++ language by adding a native POSIT data type. Developers can directly use the POSIT type in C / C++ source code for programming, with a user experience consistent with the standard float and double types. It eliminates the need for cumbersome software library function calls, greatly reducing the development threshold for POSIT format-related applications. It solves the compatibility problem of traditional developers being unable to directly use the POSIT type in high-level programming languages ​​and experiencing low development efficiency, which is conducive to promoting the application and popularization of the POSIT format in fields such as high-performance computing and machine learning. Attached Figure Description

[0022] Figure 1 This is a schematic diagram illustrating the compilation process for supporting the POSIT floating-point format on ARM processors in this embodiment.

[0023] Figure 2 This is a schematic diagram illustrating the principle of LLVM IR type system extension in this embodiment.

[0024] Figure 3 This is a schematic diagram of the compilation front-end processing flow in this embodiment.

[0025] Figure 4 This is a schematic diagram illustrating the principle of compiler backend instruction selection and mapping in this embodiment.

[0026] Figure 5 This is a comparative diagram of test results obtained in a specific application embodiment. Detailed Implementation

[0027] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0028] The compiler frontend is responsible for converting high-level language source code into a hardware-independent intermediate representation (LLVM IR). To support POSIT data types, this invention extends the LLVM Clang frontend with lexical and syntactic analysis, semantic analysis, and intermediate representation generation. The compiler middleware is responsible for architecture-independent optimizations at the LLVM IR level. This invention extends the LLVM IR itself and its optimizer with IR type system extensions, IR type system extensions, and optimization pass extensions. The compiler backend is responsible for converting the optimized LLVM IR into machine code for the target hardware platform. This invention targets ARM processors or FPGA hardware verification platforms that support the POSIT instruction set, achieving deep adaptation of the LLVM backend through instruction selection and mapping, register allocation and calling conventions, and instruction scheduling and issuance configuration. This invention provides a compilation implementation method for supporting the POSIT floating-point format on ARM processors. By implementing a compiler front-end that supports POSIT extensions, LLVM IR-based POSIT extensions, and a compiler back-end for ARM chips that supports POSIT, a systematic compilation implementation method is achieved. This solves the problem of comprehensive support for the POSIT format from the compilation front-end to the back-end on the ARM processor platform, thereby establishing a complete technology chain from application and compilation optimization to hardware execution.

[0029] like Figure 1 As shown, the compilation implementation method for supporting POSIT floating-point format on ARM processors in this embodiment includes: The compiler front end performs lexical and syntax analysis extensions, semantic analysis extensions, and intermediate representation generation extensions for POSIT types. The lexical and syntax analysis extensions include adding keywords for POSIT types and building AST trees to enable parsing code containing POSIT types. The semantic analysis extensions include adding semantic rules for defining POSIT types to clarify type levels and implicit conversion logic. The intermediate representation generation extensions include mapping various operations of POSIT types in the AST to corresponding LLVM IR instructions to provide for mid-end optimization and back-end code. During compilation, IR type system extensions, IR instruction set extensions, and optimization channel extensions are performed for POSIT types. IR type system extensions include adding basic data types corresponding to the front-end POSIT type in LLVM IR. IR instruction set extensions include modifying the core arithmetic instructions of LLVM IR to support POSIT data types and extending the type conversion instruction set to support mutual conversion between POSIT types and other types. Optimization channel extensions include configuring optimization channels suitable for POSIT data types to perform machine-independent optimizations on IR code containing POSIT operations. In the compilation backend, instruction selection and mapping, register allocation and calling conventions, and instruction scheduling and issuance are configured for POSIT types. Instruction selection and mapping includes mapping LLVM IR instructions containing POSIT operations to POSIT hardware instructions of the target hardware platform. Register allocation and calling conventions include defining register classes and function calling rules for POSIT data types. Instruction scheduling and issuance includes scheduling and optimizing the generated POSIT instruction sequence according to the characteristics of the target processor.

[0030] This embodiment is based on the open-source LLVM compiler framework. By systematically extending it in a full-stack manner (front-end, middle-end, back-end), the extended compiler front-end is used to identify and process POSIT types in the source code, the extended compiler middle-end is used to optimize POSIT-related intermediate representations, and the compiler back-end can be used to generate efficient POSIT instruction sequences for specific hardware (such as ARM processors or FPGA prototype systems), thereby achieving full support for the POSIT floating-point format.

[0031] In specific application embodiments, such as Figure 1 As shown, each module is configured as follows: Input layer: The code is labeled "C / C++ source code" and the code examples are labeled with the three POSIT types posit16_1, posit32_2, and posit32_3 to intuitively demonstrate the native support of high-level languages ​​for POSIT. Compile the front-end module: block annotations for "lexical / syntactic analysis (extended Clang)", "semantic analysis", and "IR generation", with the core output annotated next to each submodule. Compile the intermediate module: annotate "Vectorization (optimizer)" and "Other optimizations (constant folding, sparse conditional propagation)", add "POSIT dedicated optimization channel enabled" as a side note, and annotate the output as "Optimized LLVM IR" with a comparison of IR instructions before and after optimization. The compilation backend module is labeled "Instruction Selection (for domestic ARM processors)" and "Register Allocation". The instruction selection module is labeled "ARM POSIT Hardware Instruction Mapping Rules", and the register allocation module is labeled "POSIT Dedicated Register Class". The final output is labeled "ARM machine code containing PADD / PMUL instructions". The input layer, front-end, middle layer, and back-end are connected by solid lines with arrows to form a link association, achieving end-to-end support for the POSIT type across the entire link.

[0032] In this embodiment, the lexical and syntax analysis extensions in the compiler front-end include: Keyword addition: A new POSIT type keyword is added to the keyword enumeration of the compiler's lexical analysis module, and a corresponding type identifier is added to the type specifier enumeration, so that the compiler can recognize the new POSIT type keyword as a valid type specifier; AST data structure extension: In the abstract syntax tree context class, a new member variable is added to store the POSIT basic data type. The POSIT subclass is extended in the built-in type class, and the type identifier retrieval method is reconfigured so that the AST can carry POSIT type information. Syntax analysis logic supplement: Modify the syntax parsing function so that when a POSIT type keyword is detected, the corresponding processing logic is triggered to generate the corresponding POSIT type AST node, enabling the parsing of legal code such as "posit32_2 x =3.14;" without syntax errors.

[0033] This embodiment extends lexical and syntactic analysis in the compiler front-end as described above. Without disrupting the existing C / C++ syntax parsing logic, it adds the ability to identify POSIT type keywords and construct syntax trees (ASTs). This ensures that the compiler can correctly parse code containing POSIT types, solves the problem of the compiler being unable to recognize POSIT type code, avoids conflicts between the new keywords and the existing syntax, and ensures that the extended syntax analysis logic can generate valid POSIT type AST nodes without affecting the parsing process of other types of code.

[0034] In a specific application embodiment, the lexical and syntax analysis extensions are implemented by adding the keywords posit16_1, posit32, and posit32_3 of type POSIT to the preprocessing module, and by expanding the relevant data structures of the AST in the syntax analysis module, and adding syntax analysis logic for posit-based expression computation. By adding the ability to recognize POSIT type keywords (such as posit16_1, posit32_2, and posit32_3) in the preprocessing and syntax analysis modules, the system can correctly parse and generate an Abstract Syntax Tree (AST) containing these new types.

[0035] In this embodiment, the lexical and syntax analysis extension adds posit16_1, posit32, and posit32_3 to the preprocessing keyword whitelist and marks them as "built-in type keywords," setting their priority above user macros. The identifier classification function is modified so that when matching POSIT keywords, they are directly classified as "built-in type identifiers," skipping macro queries. When a conditional compilation block contains a POSIT declaration, keyword syntax information is retained, only the on / off state is marked. A new log entry records keyword position, classification, and conflict results. This embodiment's lexical and syntax analysis extension is implemented collaboratively by preprocessing and syntax analysis modules, overcoming the limitations of traditional compilers that rely on a single module to process type keywords. It solves the problem that AST cannot fully carry POSIT type attributes and addresses the difficulties of cross-module type recognition collaboration and accurate transmission of AST semantic information. The POSIT keyword pre-identification and macro definition protection in the preprocessing module can overcome the limitations of "relying solely on lexical analysis to identify type keywords," solving the problems of keyword mis-replacement, information loss, and macro conflicts during the preprocessing stage, preventing preprocessing from treating POSIT keywords as ordinary identifiers, while not affecting user macro functionality.

[0036] In this embodiment, the semantic analysis extension in the compiler frontend includes: Type rank rule definition: A new POSIT type rule is added to the type rank determination function of semantic analysis, including: POSIT types with the same bit width have a higher rank than IEEE 754 floating-point types; for different bit widths, the rank is determined by the width of the POSIT type; for POSIT types with the same bit width but different exponent lengths (es), the rank is determined by the exponent length (es). For example, for different bit widths, a wider POSIT type has a higher rank; for POSIT types with the same bit width but different exponent lengths (es), the type with the larger exponent length (es) has a higher rank.

[0037] Static constants and semantic mapping: Define static constants that store the bit width and es parameter of the POSIT type. During AST context initialization, bind the corresponding type to the POSIT type member variables and map the POSIT floating-point semantics. Semantic check supplement: In the semantic check function for binary operations, POSIT type logic is added, including: POSIT types with the same bit width but different exponent bit lengths (es) are prohibited from direct operation, and POSIT is implicitly converted to other types according to the rank rule when operating on them.

[0038] In this embodiment, semantic analysis is extended in the manner described above to define semantic rules specific to the POSIT type, clarify the type rank and implicit conversion logic, ensure the semantic correctness of code containing the POSIT type, and achieve semantic rules that are compatible with existing floating-point types and conform to the characteristics of POSIT, especially the operation constraints of POSIT types with different bit widths and different exponents (es), to avoid precision errors or type conflicts and solve the problem of judging the legality of operations / conversions between the POSIT type and other types.

[0039] Specifically, in this embodiment, the AST data structure of the syntax analysis module is extended by adding bit width and es parameter members to the type node structure, adding judgment and retrieval macros; modifying the type node creation function to determine the bit width and es according to the POSIT keyword suffix, setting a dedicated type identifier, and modifying the AST serialization / deserialization function to additionally read and write bit width and es parameters. This enables "customized carrying of POSIT dedicated attributes", solving the problem that traditional ASTs cannot store POSIT bit width and es parameters, resulting in semantic analysis being unable to distinguish between different specifications of POSIT. Moreover, the AST field extension does not break compatibility and ensures that cross-module attributes are not lost.

[0040] Specifically, in this embodiment, the POSIT calculation expression parsing logic of the syntax analysis module is improved by adding POSIT basic expressions (identifying variables and "p + bit width_es" suffix literals) and binary operation expressions (supporting addition, subtraction, multiplication, and division; generating corresponding nodes if the operands are all POSIT) to the syntax rule file; adding result type members to the expression nodes; modifying the creation function to ensure that the POSIT operation result type is consistent with the operand (nodes are not generated for different POSIT specifications); adding dedicated error codes; and outputting specific prompts when there are no conversion rules for mixed operations. This achieves "support for POSIT-specific operation syntax," solving the problem that traditional syntax analysis cannot identify POSIT variable operations, and does not conflict with existing logic when expanding rules.

[0041] In this embodiment, the semantic analysis extension, by combining a customized POSIT type semantic carrying, mapping and judgment system, can overcome the limitation of traditional semantic analysis that only supports basic floating-point types, solve the problems of incomplete POSIT type attribute transmission and inability to determine the legality of operations, and enable the implementation of POSIT-specific semantic logic while being compatible with the existing semantic system, thereby providing correct semantics for subsequent IR generation and optimization. Specifically, addressing the issue of POSIT type attributes lacking a dedicated storage carrier and being disconnected from the AST semantic system, this embodiment employs a combined approach of "POSIT-specific static constants + ASTContext class extension + member variable initialization and floating-point semantic mapping." This involves using static constants to solidify core parameters, extending the ASTContext to carry type information, and using initialization and mapping to bind semantics, thus forming a complete POSIT type semantic transmission chain. Specifically, in the core header file of the semantic analysis module, static constants corresponding one-to-one with each POSIT type are defined to store the bit width and es parameter for each type, ensuring that each module can directly call these fixed parameters during compilation. Simultaneously, several CanQualType member variables are added to the ASTContext class, corresponding to the aforementioned POSIT basic data types, to explicitly annotate and carry POSIT type information in the abstract syntax tree context, enabling the rapid acquisition of type-related data through the ASTContext during semantic analysis. Building upon this, in the constructor or initialization function of the ASTContext class, the internal type creation interface is called to generate the corresponding type object based on the POSIT bit width and es parameter stored in the static constant, and to assign a value to the newly added CanQualType member variable, ensuring that each member is bound to a clear POSIT semantic after initialization. At the same time, the floating-point semantic configuration interface of ASTContext is called to set the corresponding floating-point semantic rules such as dynamic range and precision distribution according to the parameter characteristics of different POSIT types, so that the semantic analysis module can accurately identify the floating-point attributes of POSIT to provide subsequent calculation validity checks. To address the lack of clear criteria for judging POSIT type operations and conversions, and the absence of dedicated semantic checking logic, this embodiment adopts a method of "pre-defined POSIT type rank logic rules + supplemented by full-dimensional semantic checking rules." The rank rules clarify the type hierarchy, and combined with targeted semantic checks, ensure the legality of POSIT type operations, conversions, and declarations. Specifically, POSIT-specific rank logic rules are first embedded in the type hierarchy judgment function of the semantic analysis module: in cross-type comparisons, POSIT types with the same bit width have a higher rank than traditional IEEE 754 floating-point types, but lower than traditional floating-point types with wider bit widths; in comparisons of different specifications within the same type, for POSIT types with the same bit width, a larger es parameter results in a higher rank; for POSIT types with different bit widths, a larger bit width results in a higher rank. Meanwhile, a new entry related to POSIT was added to the BuiltinTypes.def file, supplementing the definition of the POSIT type in the built-in type hierarchy and ensuring that the compiler can distinguish the POSIT type from other built-in types. In the POSIT variable declaration processing logic, a dedicated declaration statement processing module was added. When a keyword representing the POSIT type is detected, the AST type object creation interface is automatically called to set the corresponding POSIT type AST object, avoiding type identification errors during declaration. Furthermore, the semantic analysis module was supplemented with full-dimensional POSIT semantic checking rules: in the type inference stage, the inference direction is determined according to the rank rule when different types are mixed in operations; in the operator overload resolution stage, arithmetic operations such as +, -, *, / and comparison operations such as >, >=, <, <=, ==, != for POSIT types are explicitly supported, while unsupported operators (such as bitwise operations) are rejected; in the type conversion stage, the legality of the conversion is checked to ensure the semantic correctness of the program.

[0042] Specifically, the logical rules for defining rank include: 1. The rank of the posit type is higher than that of other floating-point types of the same bit width, and the rank of the posit type is lower than that of a floating-point type with a wider bit width. 2. For posit types with the same bit width, the posit type with more index bits has a higher rank; 3. Add a posit-related entry to the BuiltinTypes.def file, add a declaration statement to handle posit type variables in the Posit variable declaration, and set the corresponding AST type object when a keyword representing the posit type is detected.

[0043] In this embodiment, the compilation front-end and middle section represent the generation of extensions, including: Type mapping logic: Modify the conversion function from AST type to IR type. When the input type is POSIT type, return the corresponding POSIT base type in IR (extend the POSIT type in advance in the IR type system). Arithmetic IR Generation: Modify the scalar expression emission function to generate corresponding IR core arithmetic instructions for addition, subtraction, multiplication, and division operations of POSIT type; generate IR comparison instructions that support POSIT type for comparison operations (such as x>y). Type Conversion IR Generation: Modify the type conversion expression emission function to generate IR conversion instructions or call LLVM internal functions for conversions between POSIT and other types.

[0044] In this embodiment, by performing intermediate representation generation extension at the compilation front end in the manner described above, the POSIT type operations and conversion logic in the AST are correctly mapped to LLVM IR instructions. This achieves accurate mapping of the POSIT type from AST to IR, ensuring that the semantics of the POSIT type in the AST are not lost, and that the generated IR instructions are legal and can be recognized by subsequent processes. This avoids optimization or code generation failures due to type incompatibility, thus laying the foundation for mid-end optimization and back-end code generation.

[0045] In this embodiment, during the intermediate representation generation extension, corresponding LLVM IR instructions are generated for various operations of the POSIT type in the IR generation module to facilitate subsequent optimization and code generation. In the POSIT type mapping process, the type objects in the AST are mapped to the type objects in the IR, and the type conversion expression of the POSIT number is configured in the AST to add the corresponding intermediate representation generation logic and generate the IR representation of the POSIT type conversion operation.

[0046] In this embodiment, the intermediate representation generation extension serves as a core link connecting the semantic analysis of the compilation front-end and the mid-end IR optimization. By employing precise generation of POSIT operation IR instructions combined with AST-IR type mapping adaptation and customized IR logic for transformation operations, it can overcome the limitation of traditional IR generation only supporting basic types, solve the problem of lossless semantic transfer of POSIT types from AST to LLVM IR, be compatible with existing IR generation processes, ensure the legality of IR representations for POSIT operations and transformations, and lay the foundation for subsequent optimization and code generation. Specifically, addressing the issue that POSIT operations lack corresponding LLVM IR instructions, hindering subsequent processes, this embodiment employs a POSIT-specific IR instruction generation mechanism to generate corresponding IR instructions based on the characteristics of POSIT operations. Specifically, in the scalar expression processing logic of the IR generation module, when a new POSIT-specific branch is parsed to a POSIT operation node in the AST, the operand is first confirmed to be of POSIT type. Then, the IR instruction creation interface is called to generate the corresponding instruction. A comparison operation is performed to generate an fcmp instruction that supports POSIT, ensuring the completeness of the operation semantics. To address the issue of mismatched POSIT types between AST and IR, leading to information transmission gaps, this embodiment employs a precise AST-IR POSIT type mapping scheme to establish a one-to-one correspondence and ensure no attribute loss. Specifically, in the type conversion function of the IR generation module, a new POSIT mapping logic is added—reading the POSIT attribute from the CanQualType member of ASTContext and calling the IR type creation interface to generate the corresponding IR basic type; type identifier verification (comparing AST and IR type enumerations) ensures correct mapping, preventing posit32_2 from being mismatched as float, and ensuring the validity of operand types in subsequent IR instructions. To address the issue of incorrect conversion due to the lack of a dedicated IR representation for POSIT type conversion, this embodiment employs a customized IR generation logic for POSIT conversion operations. It generates a suitable IR representation through the AST conversion expression. Specifically, in the type conversion expression processing logic of the IR generation module, a dedicated POSIT conversion branch is added. When a POSIT conversion node is detected in the AST, the conversion validity is first checked, and then IR instructions are generated according to the type: POSIT and traditional floating-point / integer conversions call preset internal functions; different POSIT conversion specifications generate instruction sequences including bit-width extensions and ES adaptation; after IR generation, semantic verification confirms that the instructions are consistent with the conversion requirements, avoiding runtime anomalies and providing a foundation for mid-range optimization.

[0047] In this embodiment, the aforementioned compilation front-end can overcome the barrier of high-level languages ​​lacking native POSIT types, be compatible with the existing syntax system, and ensure the correctness of type semantics, thus enabling full-link parsing of POSIT types.

[0048] In this embodiment, the extension of LLVM IR itself and its optimizer specifically includes: IR Type System Extension: A new basic data type corresponding to the front-end POSIT type was introduced in LLVM IR, improving the IR type system.

[0049] IR Instruction Set Extension: The definitions of core LLVM IR arithmetic instructions (such as add, sub, mul, div) have been modified to enable their operands to support the newly added POSIT data type. Simultaneously, the type conversion instruction set has been extended to support conversions between POSIT types and other types (such as integers and traditional floating-point numbers).

[0050] Optimized Pass Extensions: Optimized passes have been developed or adapted for POSIT data types. These passes can be integrated into LLVM's optimized pipeline to perform machine-independent optimizations such as vectorization on IR code containing POSIT operations, further improving the performance of generated code.

[0051] In this embodiment, LLVM IR itself and its optimizer extension serve as the core components of the compilation process. They inherit the front-end POSIT semantics and support back-end hardware adaptation. Innovation is achieved through "customized extension of IR type system + adaptation of core instruction set and conversion logic + integration of dedicated optimization channel". This breaks through the limitations of traditional IR, which only supports basic types and does not cover POSIT operations. It solves the problems of POSIT having no carrier, missing instructions, and ineffective optimization at the IR level. The core challenge is to ensure compatibility with the existing LLVM IR ecosystem, guaranteeing the complete POSIT type IR representation, valid instructions, and efficient optimization, thus laying the foundation for back-end instruction generation and performance improvement.

[0052] In this embodiment, the IR type system extension during compilation includes: Basic type definition: Define POSIT scalar and vector types through template files, and generate corresponding IR type enumeration and processing code; Memory layout adaptation: Modify the alignment and bit width retrieval functions of the IR data layout class to return the correct parameters for the POSIT type; Serialization / deserialization support: Modify the bitcode write and read functions of the IR module, assign encoding to the POSIT type in the type table, and ensure that the IR file can correctly store and load POSIT type information.

[0053] This embodiment implements the IR type system extension in the compilation stage as described above, adds the POSIT basic type and vector type to LLVM IR, improves the IR type system, ensures that IR can correctly store and transmit POSIT type data, and is compatible with IR's memory layout and serialization / deserialization logic, without breaking the existing IR toolchain, and solves the problem that IR cannot carry POSIT type data.

[0054] In this embodiment, the IR instruction set extension during compilation includes: Core arithmetic instructions extended: Modified the operand validity check function for the IR binary arithmetic instruction class to allow operands of type POSIT for add, sub, mul, and div instructions; also modified the instruction creation function to support the generation of arithmetic instructions of type POSIT. Type conversion internal function definition: Define the internal functions for POSIT and other type conversions through the IR internal function template, and generate the corresponding function declarations and recognition logic. IR implements type conversion by calling the corresponding functions; In this embodiment, the above method is used in the compilation stage to extend the IR instruction set. By extending the core IR arithmetic instructions and type conversion instructions, it can be ensured that the operation and conversion logic of POSIT type has legal IR instruction support and semantic integrity. The operand constraints of IR instructions are modified to make them compatible with the conversion instructions of existing optimization logic, avoid instruction conflicts or optimization failures, and solve the problem that there are no corresponding IR instructions for POSIT type operations and conversions.

[0055] In this embodiment, the optimization of channel expansion during compilation includes: Vectorization optimization and adaptation: Modify the type validity judgment function of the loop vectorizer to allow the POSIT type as a valid vectorization type; in the vector type generation function, generate the corresponding vector type for the POSIT type; in the loop vectorization logic, generate vector IR instructions for operations on the POSIT type. Optimize channel integration: Add the POSIT optimization channel to the compiler optimization pipeline and set it to be automatically enabled at a specified optimization level; at the same time, modify the type discrimination logic of the optimization pass to add POSIT type support, ensuring that IR code containing POSIT operations can enter the optimization process.

[0056] This embodiment achieves optimization channel expansion in the compilation stage by adopting the above method, configuring a dedicated optimization channel for POSIT, and customizing optimization strategies for the dynamic range and precision characteristics of POSIT. It fully leverages the compiler's automatic optimization capabilities and avoids precision loss or performance degradation after optimization. In particular, vectorization optimization needs to be adapted to the characteristics of the POSIT type to ensure the optimization effect and solve the problem that the existing optimization pass cannot handle POSIT type IR code.

[0057] Specifically, addressing the issue that the IR type system lacks a dedicated POSIT type and cannot support front-end POSIT attributes, this embodiment employs an extension method that precisely aligns IR and front-end POSIT types. Corresponding types are constructed through template definitions and modifications to core classes. Specifically, the LLVM type definition template file is modified to add POSIT scalar and vector types, annotating the bit width of each type. The TableGen tool is used to generate corresponding MVT::SimpleValueType enumerations, enabling the IR core module to recognize these new types. Relevant functions in the DataLayout class are modified to configure dedicated memory layout parameters for POSIT types. The Type class is extended, adding a POSIT type item to the type identifier enumeration, adding POSIT type discrimination and retrieval methods, and modifying the bitcode read / write logic to assign dedicated encoding to POSIT types, ensuring that IR files can correctly store and load POSIT type information.

[0058] To address the issues of IR core arithmetic instructions not supporting POSIT operands and lacking dedicated logic for conversion, this embodiment adopts a method of relaxing core instruction set constraints and customizing conversion instruction sets for adaptation. Legality is achieved by modifying instruction rules and adding internal functions. Specifically, the definition of binary arithmetic instruction classes is modified, and the operand validity judgment function is expanded to allow operand types to be the newly added POSIT type. A dedicated branch for the POSIT type is added to the instruction creation function to generate legal arithmetic instructions such as "%result = add posit32_2 % op1, % op2". A dedicated internal function for POSIT type conversion is defined in the internal function definition template file, clearly specifying the function's input / output types and the absence of memory access attributes. The TableGen tool is used to generate corresponding function declarations and internal instruction class extensions, ensuring that the IR layer can achieve secure conversion between POSIT and other types by calling these internal functions, avoiding conflicts with the existing IR ecosystem.

[0059] To address the issue that existing optimization channels are not compatible with POSIT and cannot optimize IRs containing POSIT operations, this embodiment adopts a POSIT-specific optimization channel development and optimization pipeline integration approach, customizing optimization logic and integrating it into existing processes. Specifically, a vectorized optimization channel suitable for the POSIT type is developed, and the type validity judgment function of the loop vectorization module is modified to include the POSIT type within the scope of valid vectorized types. In the vector type generation function, the corresponding vector type is generated based on the POSIT scalar type, and vector operation IRs are generated for POSIT arithmetic instructions in the core loop vectorization logic. Existing optimization channels are adapted by adding POSIT type judgment to the type discrimination logic of these channels to ensure that IRs containing POSIT operations can be optimized normally. In the optimization pipeline configuration module, the POSIT-specific optimization channel is added to O2 and higher optimization level processes to ensure that IR code containing POSIT operations can automatically trigger vectorization and other optimizations during compilation, improving the execution efficiency of subsequent machine code generation.

[0060] In this embodiment, the aforementioned compiler can achieve full capability extension of LLVM IR, breaking through the limitation of existing IR lacking POSIT support, and can be compatible with the IR ecosystem, achieving POSIT-specific optimizations.

[0061] In this embodiment, instruction selection and mapping includes rewriting or extending the backend instruction selection template (e.g., LLVM's TableGen file) to explicitly map LLVM IR instructions containing POSIT operations to target hardware platform-specific POSIT instructions (such as padd, pmul, etc.) or instruction sequences. Register allocation and calling conventions include defining register classes for POSIT data types and configuring parameter passing and return value rules (calling conventions) during function calls to ensure the correctness of system-level calls. Instruction scheduling and issuance include scheduling and optimizing the generated POSIT instruction sequences according to the characteristics of the target processor (such as pipelines and functional units) to fully utilize hardware performance.

[0062] In this embodiment, the compilation backend serves as a crucial link between the optimized LLVM IR and the ARM processor hardware instructions. Its core objective is to accurately convert IR containing POSIT operations into hardware-executable POSIT instructions, ensuring correct function calls and execution efficiency. This addresses the problems of traditional backends, such as "mismatch between IR and POSIT hardware instructions, lack of dedicated registers and calling rules, and instruction sequences not adapted to the hardware." The key challenge lies in ensuring compatibility with the ARM architecture specification, achieving accurate mapping, secure storage, and efficient scheduling of POSIT instructions, and maximizing hardware performance.

[0063] In this embodiment, instruction selection and mapping in the compilation backend include: Instruction format definition: Define the instruction format according to the encoding rules of ARM POSIT instructions to specify parameters including operand type and instruction length; Instruction mapping rule definition: For ARM POSIT hardware instructions, define the mapping rules from IR instructions to hardware instructions to map POSIT type IR arithmetic instructions to the corresponding ARM hardware instructions; Instruction selection logic supplement: Modify the backend DAG to DAG instruction selection function. When encountering a POSIT type IR operation node, call the corresponding matching logic and select the corresponding ARM POSIT hardware instruction to generate a machine instruction node.

[0064] In this embodiment, instruction selection and mapping are implemented in the compilation backend using the above method. The POSIT operation IR instructions are accurately mapped to ARM processor-specific POSIT hardware instructions, avoiding software simulation overhead and fully utilizing hardware performance. The precise instruction matching rules are designed according to the ARM POSIT instruction set specification, which also ensures that the IR semantics are consistent with the hardware instruction semantics, thereby solving the problem that IR instructions cannot generate ARM hardware executable code.

[0065] In this embodiment, the register allocation and calling conventions in the compilation backend include: POSIT Register Class Definition: In the back-end register information definition, a new POSIT dedicated register class is added, and it is specified that a certain subset of the ARM processor's general-purpose registers are used to store POSIT data, so as to clarify the register bit width and the supported POSIT types; Call convention configuration: In the ARM call convention definition, a new rule for passing POSIT type parameters is added to clarify the way POSIT parameters are passed during function calls and the storage location of return values, ensuring that POSIT data is passed correctly when crossing function calls.

[0066] This embodiment uses the above method in the compilation backend to implement register allocation and calling convention. By defining dedicated registers and function calling rules for the POSIT type, it ensures the security of POSIT data storage and the correct passing of function call parameters. At the same time, it is compatible with the register architecture and calling convention specifications of the ARM processor, reasonably allocates register resources, avoids register conflicts or abnormal parameter passing, and thus solves the problems of POSIT type having no dedicated register storage and incorrect function call parameter passing.

[0067] In this embodiment, command scheduling and transmission include: Hardware characteristic modeling: Add information such as execution latency and functional unit occupancy to the backend target machine description to provide hardware data support for scheduling; Instruction scheduling logic optimization: Modify the backend instruction scheduling function to adjust the instruction execution order for the POSIT instruction sequence, taking into account hardware characteristics and instruction dependencies, to reduce pipeline stalls; at the same time, optimize the instruction issue logic to ensure that the POSIT instruction can efficiently utilize hardware functional units and improve overall execution efficiency.

[0068] In this embodiment, the above-described method is used in the compilation backend to implement instruction scheduling and issuance. Based on the hardware characteristics of the ARM processor, the scheduling of the POSIT instruction sequence is optimized to improve the parallelism and efficiency of instruction execution. It can also balance the dependencies of POSIT instructions and hardware resource constraints, avoid pipeline blockage due to improper scheduling, and thus solve the problem of low execution efficiency of the POSIT instruction sequence.

[0069] Specifically, this embodiment innovates in the instruction selection and mapping stage by rewriting or extending the backend instruction selection template to ensure that the POSIT operation IR is accurately mapped to the ARM hardware POSIT instruction or sequence, avoiding analog loss. The specific implementation is as follows: First, a POSIT-specific format (such as a three-operand scalar format) is added to the backend instruction format file to clarify the operand type and instruction length; then, mapping rules are defined in the instruction information file using TableGen—for example, the IR addition instruction “%result = add posit32_2 % op1, % op2” is mapped to the PADD instruction through pattern matching [(set GPR64:Rd,(addposit322:Rn, posit32_2:$Rm))], and the multiplication instruction is mapped to PMUL; the instruction selection logic is modified to call the specific matching logic when detecting the POSIT IR node, ensuring no semantic loss.

[0070] This embodiment addresses the issues of "lack of dedicated storage and cross-function passing errors" by defining a dedicated POSIT register class and configuring calling rules in the register allocation and calling convention phase, ensuring correct system-level calls. Specifically, a dedicated POSIT register class is added to the register information file, specifying a subset of ARM-specific general-purpose registers and clearly defining the supported POSIT types and bit widths. Rules are added to the calling convention file: the first four POSIT parameters are passed using dedicated registers, and any excess is stored in a stack frame aligned to 4 bytes; the return value is returned using X0. The register allocation logic is modified to prioritize allocating dedicated registers for POSIT variables, avoiding resource preemption.

[0071] This embodiment optimizes the POSIT instruction sequence based on ARM processor characteristics (pipeline, functional unit latency) during instruction scheduling and issuance, resolving the issues of "pipeline blocking and underperformance." Specifically, it involves: adding POSIT instruction hardware data to the target machine description file; modifying the scheduling logic to adjust the order according to hardware data and instruction dependencies: non-dependent instructions are scheduled in parallel, while dependent instructions are inserted with NOPs or filled with irrelevant instructions; and optimizing the issuance logic to ensure efficient use of hardware units by POSIT instructions, avoiding idle time and improving execution efficiency.

[0072] In this embodiment, the above-mentioned compilation backend can achieve deep adaptation to ARM hardware, establish the mapping link from IR to ARM POSIT instructions, and achieve accurate instruction matching while being compatible with ARM calling conventions.

[0073] like Figure 2 As shown, in a specific application embodiment, when implementing the LLVM IR type system extension, the core input file is labeled "Type Definition Template File," with the definitions of POSIT scalar and vector types clearly marked in the file content fragments, specifying the bit width parameters for each type. In the tool generation stage, the tool is labeled "TableGen Tool," with the input end associated with the "Type Definition Template File," and the output end labeled "MVT::SimpleValueType Enumeration," with the newly added POSIT type enumeration item marked in the enumeration list. The core class extension is labeled "DataLayout Memory Layout Class," with a function list attached (getAlignment(), getTypeSizeInBits()), and the parameter configuration for the POSIT type is marked. The core type class is labeled "Type," with the newly added POSIT type identifier (TypeID::PositTy) marked in the class member list, and the newly added discrimination method (isPositTy()) and retrieval methods (getPosit16_1Ty(), getPosit32_2Ty()) marked in the method list. Compatibility Guarantee: The code is labeled "Bitcode Reader / Writer," and the read / write process is marked with "POSIT type-specific encoding (e.g., posit32_2 encoding 0x1A)," along with an example of a bitcode file storing binary data fragments of the POSIT type, demonstrating no compatibility breaches. Dependencies: A dotted line with the "Dependency" label connects "Type Definition Template File → TableGen Tool → MVT Enumeration → DataLayout Class / Type Class → Bitcode Reader / Writer" to clearly present the dependency logic of each module and demonstrate the systematic nature of type extension.

[0074] like Figure 3As shown, when performing front-end processing during compilation in a specific application embodiment: Lexical analysis stage: The preprocessing module is labeled, and the processing logic is labeled with "POSIT keyword whitelist (posit16_1, posit32_2, posit32_3)" and "macro conflict detection rules". The output is labeled with "POSIT keyword recognition result (no macro replacement error)" and error examples are provided for comparison. Syntax analysis stage: Mark "AST building module", mark "ASTContext class extension" and "BuiltinType class extension" within the module, and mark the POSIT type variable declaration node in the output AST structure diagram. Semantic analysis stage: The "Semantic Inspection and Rank Rule Module" is labeled, the POSIT type rank judgment criteria are labeled in the rule list, and the inspection results are labeled with "Legal operation example (posit32_2+posit32_2)" and "Illegal operation example (posit32_2+posit32_3, error message)". IR generation stage: Mark “AST→IR mapping module”, mark “ASTPositBuiltinType→IR posit type” in the mapping rules, and mark the POSIT operation instruction in the output IR instruction fragment. Output connection: The output end is marked "LLVM IR with POSIT extension type" and an arrow points to "compile mid-stage optimization stage", which clearly shows the data flow connection between the front end and the mid-stage, without any information gaps.

[0075] like Figure 4 As shown, in a specific application embodiment, when selecting and mapping compilation backend instructions: Input IR commands: Label “LLVM IR command input”. In the command example, label “% result = addposit32_2 % a, % b” and add a note “Operation type: POSIT32_2 addition, operand type: posit32_2”. Instruction selection (ISel) stage: labeled “SelectionDAG building block”, labeled “IR instruction node (add:posit32_2)” and “transformed node (AArch64ISD::PADD)” in the DAG diagram, with “pattern matching rule (based on TableGen definition)” as a side note. Instruction mapping stage: label "ARM POSIT instruction definition module", label "PADD" and "PMUL" in the instruction list, and annotate "instruction format", "operand constraints" and "hardware functional unit" next to each instruction. Output hardware instructions: labeled "ARM machine code output", the instruction example is labeled "PADD X0, X1, X2", and the side note is "corresponding IR instruction: % result = add posit32_2 % a, % b" "execution unit: ARM floating point unit" "no software simulation overhead". Accuracy Guarantee: Mark "Semantic Consistency Verification Rules", and mark "IR Operation Accuracy → Hardware Instruction Accuracy" and "Operand Type Matching (IR posit32_2 → Hardware POSIT32 Register)" in the verification items to ensure no precision loss or logical errors.

[0076] The detailed steps for implementing the compilation of POSIT floating-point format for ARM processors using the above-described method of the present invention in a specific application embodiment are as follows: Step 1: C / C++ language extension: The standard C / C++ basic type system is extended to include a new native POSIT data type. The POSIT format consists of a tuple.<n, es> Defined as follows, where n is the bit width and es is the upper limit of the exponent in bits. This embodiment mainly supports the following three data types natively supported by the FPGA prototype system: posit16_1: indicates POSIT<16,1> posit32_2: represents POSIT<32,2> posit32_3: represents POSIT<32,3> Meanwhile, in contrast, this embodiment can also support the bfloat16 format, and the specific language extensions are summarized in Table 1.

[0077] Table 1: Posit extension in C language

[0078] POSIT numbers of the same type support all basic arithmetic and comparison operations. The key rule is that POSIT numbers with the same bit width but different `es` parameters are considered completely different types and direct operations are prohibited. Explicit type casting is required for any necessary operations. For example, the statements `posit32_2 x = 0; posit32_3 y = 1; x += y;` will trigger a type error at compile time.

[0079] Step 2: LLVM IR intermediate representation extension Step 2.1: Type System Extension Add basic data types and modify several core modules in LLVM IR, including: Modify the ValueTypes.td template file: add definitions for scalar types (such as posit16_1) and vector types. The TableGen tool then generates corresponding C++ code (such as the MVT enumeration type) based on this, enabling the compiler to recognize the new types.

[0080] Improve memory layout support: Modify the DataLayout::getAlignment and DataLayout::getTypeSizeInBits functions to return the correct alignment requirements and bit width for POSIT types.

[0081] Extend the core Type class: Add a POSIT type enumeration value to the Type::TypeID enumeration, and add corresponding discrimination methods (such as isPositTy) and retrieval methods (such as getPosit32_2Ty).

[0082] Support serialization / deserialization: Modify related functions such as ModuleBitcodeWriter::writeTypeTable and BitcodeReader::parseTypeTableBody to ensure that the POSIT type in IR can be read and written correctly.

[0083] Step 2.2: Expansion of Operation Instructions and Intrinsic Functions Extend arithmetic instructions and type conversion: Arithmetic instructions: Directly modify the definitions of the LLVM IR core instructions add, sub, mul, and div, relax their operand constraints, and allow them to accept POSIT type operands.

[0084] Type conversion: To avoid modifying the core instruction set, complex conversions are implemented by adding new Intrinsic functions. For example: The functions int_convert_from_posit32 and int_convert_to_posit32 are defined in Intrinsics.td.

[0085] Add a new enumeration value to enum IITDescriptorKind to describe the POSIT parameter type constraint.

[0086] Step 3: Optimize the compilation backend configuration for ARM processors This embodiment specifically adapts to ARM processors based on the ARM AArch64 extension, including: Step 3.1: Define subtargets and characteristics In the AArch64.td template file, the processor is defined as a subtarget of AArch64, and a new Posit feature is added as an optional architecture extension.

[0087] Step 3.2: Instruction Set Definition and Pattern Matching Define the instruction format and specific instructions: Define instruction formats: In AArch64InstrFormats.td, define new instruction formats according to the processor's instruction manual, such as three-operand scalar instruction format, vector instruction format, etc.

[0088] Define specific instructions: In AArch64InstrInfo.td, define all specific POSIT instructions (such as PADD, PMUL), including their encoding, operands and corresponding instruction selection patterns, to map IR operations to machine instructions.

[0089] Step 3.3: Registers and Calling Conventions Define registers and calling conventions: Define registers: Define a dedicated register class in AArch64RegisterInfo.td to store POSIT data.

[0090] Define calling convention: The AArch64CallingConvention.td explicitly specifies how POSIT type parameters are passed during function calls (either through registers or the stack).

[0091] Step 4: Compile the front-end extension Step 4.1: Lexical Analysis (Preprocessing) Extension Modify TokenKinds.def: Add a definition for the POSIT type keyword (such as posit16_1) in this file.

[0092] Extend the enum TypeSpecifierType: Add enumeration values ​​such as TST_posit16_1 so that the compiler can recognize these keywords as type specifiers.

[0093] Step 4.2: Syntax Analysis and AST Construction Extend the ASTContext class: Add a CanQualType member variable (such as Posit16_1Ty) to represent the POSIT type in the AST.

[0094] Define type rank: To implement the implicit type conversion rules of the C language, define an explicit rank for the POSIT type. The rule is: POSIT types with higher bit width or larger es for the same bit width have a higher rank.

[0095] Modify Parser::ParseDeclarationSpecifiers: This enables the parser to correctly construct the AST node for variable declarations when it encounters the POSIT keyword.

[0096] Step 4.3: Intermediate Representation (IR) Generation Type mapping: Modify functions such as getTypeForFormat to establish a mapping relationship between POSIT types in AST and newly added types in LLVM IR.

[0097] Transformation operation generation: Modify the ScalarExprEmitter::EmitScalarCast function to generate the correct IR instructions for type conversion expressions in the AST (possibly calling Intrinsic functions).

[0098] The compiler described above in this embodiment can serve as a key bridge connecting processors that support the POSIT hardware instruction set with upper-layer application software, providing core toolchain support for building a complete software and hardware collaborative ecosystem based on the new floating-point format.

[0099] In summary, this invention enables compilation supporting the POSIT floating-point format for ARM processors, achieving end-to-end support for the POSIT format from programming languages ​​and compilation optimization to hardware instruction generation. It bridges the gap between upper-layer applications and lower-layer hardware, providing core compilation technology support for building a software and hardware ecosystem based on the new floating-point format. This solves the problem of existing compilers (such as GCC and LLVM) lacking native support for new floating-point formats like POSIT. Specifically, it can achieve the following effects: Comprehensiveness: By implementing full-stack support for the POSIT format on the LLVM compiler framework, from language extensions and compilation optimizations to hardware code generation, a complete solution is formed, rather than fragmented library function support.

[0100] High performance: With deep native support from the compiler, POSIT operations can be directly compiled into efficient hardware instructions, avoiding the huge performance overhead caused by software simulation. At the same time, it can take advantage of the compiler's automatic optimization capabilities (such as vectorization) to fully unleash the computing potential of the ARM processor hardware.

[0101] High availability: The POSIT type can be used directly in C / C++ source code, providing the same experience as using the standard float and double types, which greatly reduces the development threshold and facilitates the application and promotion of the POSIT format.

[0102] To verify the effectiveness of this invention, specific application embodiments were implemented using this invention to compile for a certain type of ARM processor, supporting the POSIT floating-point format, and compared with mainstream compilers in the prior art. This invention systematically implements complete, native-level support for multiple POSIT formats (such as POSIT<16,1>, POSIT<32,2>, POSIT<32,3>) on the LLVM compiler framework, which is not supported by mainstream compilers in the prior art. A comparison of the support levels between this invention and existing open-source compilers is shown in Table 2.

[0103] Table 2: Comparison of the functions of the compiler of this invention (llvm-posit) with those of compilers in the prior art

[0104] Through comprehensive testing with the C_nfp_test set, this invention successfully supports all target formats' four basic arithmetic operations (addition, subtraction, multiplication, and division) and six comparison operations (>, >=, <, <=, ==, !=), achieving a 100% compilation success rate. The generated programs ran correctly on the FPGA hardware verification platform, demonstrating the completeness and reliability of the invention's technical solution. This invention not only supports syntax testing but is also applicable to mainstream applications in the two key areas of high-performance computing (HPC) and machine learning (ML), showcasing its strong engineering practical value. In the field of high-performance computing, it successfully replaced the floating-point format of eight core programs (BT, FT, SP, LU, MG, CG, IS, EP) in the NPB benchmark test set and compiled them. All programs compiled successfully on the first attempt, and the generated executable files ran on the FPGA hardware verification platform. The calculation results were completely consistent with the soft simulation results on the Phytium 2000+ platform, proving the correctness and stability of this invention in complex scientific computing scenarios. In the field of machine learning, the classic machine learning model LeNet-5 was successfully compiled, and its recognition accuracy was tested. Test results show that the code compiled using this invention maintains extremely high model accuracy across various new formats: BF16 format accuracy is 97.96%, POSIT<16,1> format accuracy is 98.73%, POSIT<32,2> format accuracy is 96.93%, and POSIT<32,3> format accuracy is 95.80%. As can be seen, all accuracies exceed 95% and are consistent with the soft simulation results. This demonstrates that this invention fully meets the stringent requirements of machine learning applications for computational accuracy and stability.

[0105] This invention, through a deeply adapted compilation backend, can efficiently map POSIT operations in high-level languages ​​to specific instructions on ARM processors, thereby maximizing hardware performance. Performance tests of the core computational kernel, matrix multiplication (GEMM), show that computational efficiency can approach the theoretical peak. Figure 5As shown, the basic test information includes: "Test Core: Matrix Multiplication (GEMM)" below the chart title, "Hardware Platform: ARM processor / FPGA verification platform supporting POSIT instructions," and "Test Data Scale: 1024×1024 matrix," to ensure the test conditions are clear and reproducible. Comparison dimensions: The X-axis of the chart is labeled "Test Scheme," divided into "Compilation and Implementation of this Invention" and "Existing Software Simulation"; the Y-axis is labeled "Computational Efficiency," with a scale range of 0-100%, and a "Hardware Theoretical Peak Line" is also marked. Test results: In the bar / line chart, the corresponding bars / data points for "Compilation and Implementation of this Invention" are labeled "≥90%," and the corresponding bars / data points for "Existing Software Simulation" are labeled "≤20%," with specific test data attached next to the bars, making the differences visually apparent. Result analysis: The "Reasons for Performance Advantage" are labeled below the chart, with list items including "Direct Generation of Hardware POSIT Instructions," "POSIT-Specific Vectorization Optimization," and "Register-Specific Allocation," explaining the technical support for the performance advantage. Furthermore, the "applicable scenarios" can be labeled, with list items including "high-performance computing," "machine learning," and "embedded devices," reflecting the practical application significance of the test results.

[0106] The above results verify that the present invention achieves deep optimization, resulting in extremely efficient generated code. It completely avoids the huge performance overhead caused by simulating POSIT operations through software libraries, provides performance assurance for the practical application of the new format, effectively solves the problem of the lack of compiler support for the POSIT format, and can further improve compatibility, calculation accuracy, and running efficiency.

[0107] This embodiment further provides a compiler device for ARM processors that supports the POSIT floating-point format, including a processor and a memory, wherein the memory is used to store computer programs and the processor is used to execute the computer programs to perform the methods described above.

[0108] It is understood that the method described in this embodiment can be executed by a single device, such as a computer or server, or it can be applied to a distributed scenario where multiple devices cooperate to complete the task. In a distributed scenario, one of the multiple devices may execute only one or more steps of the method described in this embodiment, and the multiple devices interact to complete the method. The processor can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit, or one or more integrated circuits, and is used to execute relevant programs to implement the method described in this embodiment. The memory can be implemented using read-only memory (ROM), random access memory (RAM), static storage devices, and dynamic storage devices. The memory can store the operating system and other applications. When the method described in this embodiment is implemented through software or firmware, the relevant program code is stored in the memory and called and executed by the processor.

[0109] This embodiment further provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0110] Those skilled in the art will understand that the above embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce implementations of the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0111] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

Claims

1. A compilation implementation method for supporting POSIT floating-point format on ARM processors, characterized in that, include: The compiler front end performs lexical and syntactic analysis extensions, semantic analysis extensions, and intermediate representation generation extensions for the POSIT type. The lexical and syntactic analysis extensions include adding keywords for the POSIT type and constructing an AST tree to enable parsing code containing the POSIT type. The semantic analysis extensions include adding semantic rules to define the POSIT type to clarify the type hierarchy and implicit conversion logic. The intermediate representation generation extensions include mapping various operations of the POSIT type in the AST to corresponding LLVM IR instructions to provide for mid-end optimization and back-end code. During compilation, IR type system extensions, IR instruction set extensions, and optimization channel extensions are performed for the POSIT type. The IR type system extensions include adding basic data types corresponding to the front-end POSIT type in LLVM IR. The IR instruction set extensions include modifying the core arithmetic instructions of LLVM IR to support the POSIT data type and extending the type conversion instruction set to support mutual conversion between the POSIT type and other types. The optimization channel extensions include configuring optimization channels suitable for the POSIT data type to perform machine-independent optimizations on IR code containing POSIT operations. In the compilation backend, instruction selection and mapping, register allocation and calling conventions, and instruction scheduling and issuance are configured for POSIT types. The instruction selection and mapping includes mapping LLVM IR instructions containing POSIT operations to POSIT hardware instructions of the target hardware platform. The register allocation and calling conventions include defining register classes and function calling rules for POSIT data types. The instruction scheduling and issuance includes scheduling and optimizing the generated POSIT instruction sequence according to the characteristics of the target processor.

2. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to claim 1, characterized in that, In the compiler frontend, the lexical and syntax analysis extensions include: Keyword addition: A new POSIT type keyword is added to the keyword enumeration of the compiler's lexical analysis module, and a corresponding type identifier is added to the type specifier enumeration, so that the compiler can recognize the new POSIT type keyword as a valid type specifier; AST data structure extension: In the abstract syntax tree context class, a new member variable is added to store the POSIT basic data type. The POSIT subclass is extended in the built-in type class, and the type identifier retrieval method is reconfigured so that the AST can carry POSIT type information. Syntax analysis logic supplement: Modify the syntax parsing function so that when a POSIT type keyword is detected, the corresponding processing logic is triggered to generate the corresponding POSIT type AST node.

3. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to claim 1, characterized in that, In the compiler frontend, the semantic analysis extension includes: Type rank rule definition: A new POSIT type rule is added to the type rank determination function of semantic analysis, including: POSIT type rank is higher than IEEE 754 floating point type under the same bit width; under different bit width, the corresponding rank is determined according to the width of POSIT type; for POSIT types with the same bit width but different exponent bit lengths (es), the corresponding rank is determined according to the exponent bit lengths (es). Static constants and semantic mapping: Define static constants that store the bit width and es parameter of the POSIT type. During AST context initialization, bind the corresponding type to the POSIT type member variables and map the POSIT floating-point semantics. Semantic check supplement: In the semantic check function for binary operations, POSIT type logic is added, including: POSIT types with the same bit width but different exponent bit lengths (es) are prohibited from direct operation, and POSIT is implicitly converted to other types according to the rank rule when operating on them.

4. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to claim 1, characterized in that, The intermediate representation generation extension includes: Type mapping logic: Modify the conversion function from AST type to IR type. When the input type is POSIT type, return the corresponding POSIT basic type in IR. Arithmetic IR Generation: Modify the scalar expression emission function to generate corresponding IR core arithmetic instructions for addition, subtraction, multiplication, and division operations of type POSIT; and generate IR comparison instructions that support type POSIT for comparison operations. Type Conversion IR Generation: Modify the type conversion expression emission function to generate IR conversion instructions or call LLVM internal functions for conversions between POSIT and other types.

5. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to claim 1, characterized in that, In the compilation stage, the IR type system extension includes: Basic type definition: Define POSIT scalar and vector types through template files, and generate corresponding IR type enumeration and processing code; Memory layout adaptation: Modify the alignment and bit width retrieval functions of the IR data layout class to return the correct parameters for the POSIT type; Serialization / deserialization support: Modify the bitcode write and read functions of the IR module to assign encodings to the POSIT type in the type table.

6. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to claim 1, characterized in that, In the compilation stage, the IR instruction set extension includes: Core arithmetic instructions extended: Modified the operand validity check function for the IR binary arithmetic instruction class to allow operands of type POSIT for add, sub, mul, and div instructions; also modified the instruction creation function to support the generation of arithmetic instructions of type POSIT. Type conversion internal function definition: Define the internal functions for POSIT and other type conversions through the IR internal function template, and generate the corresponding function declarations and recognition logic. IR implements type conversion by calling the corresponding functions; The optimized channel expansion includes: Vectorization optimization and adaptation: Modify the type validity judgment function of the loop vectorizer to allow the POSIT type as a valid vectorization type; generate the corresponding vector type for the POSIT type in the vector type generation function; generate vector IR instructions for operations on the POSIT type in the loop vectorization logic; Optimize channel integration: Add the POSIT optimization channel to the compiler optimization pipeline and set it to be automatically enabled at a specified optimization level; at the same time, modify the type discrimination logic of the optimization pass to add support for the POSIT type.

7. The compilation implementation method for supporting POSIT floating-point format on ARM processors according to any one of claims 1 to 6, characterized in that, In the compilation backend, the instruction selection and mapping includes: Instruction format definition: Define the instruction format according to the encoding rules of ARM POSIT instructions to specify parameters including operand type and instruction length; Instruction mapping rule definition: For ARM POSIT hardware instructions, define the mapping rules from IR instructions to hardware instructions to map POSIT type IR arithmetic instructions to the corresponding ARM hardware instructions; Instruction selection logic supplement: Modify the backend DAG to DAG instruction selection function. When encountering a POSIT type IR operation node, call the corresponding matching logic and select the corresponding ARM POSIT hardware instruction to generate a machine instruction node.

8. The compilation implementation method for supporting POSIT floating-point format for ARM processors according to any one of claims 1 to 6, characterized in that, In the compilation backend, register allocation and calling conventions include: POSIT Register Class Definition: In the back-end register information definition, a new POSIT dedicated register class is added, and it is specified that a certain subset of the ARM processor's general-purpose registers are used to store POSIT data, so as to clarify the register bit width and the supported POSIT types; Calling convention configuration: In the ARM calling convention definition, a new rule for passing POSIT type parameters is added to clarify how POSIT parameters are passed during function calls and where the return value is stored; The command scheduling and launch include: Hardware characteristic modeling: Add information about execution latency and functional unit occupancy to the backend target machine description of the POSIT instruction; Instruction scheduling logic optimization: Modify the backend instruction scheduling function to adjust the instruction execution order for the POSIT instruction sequence, taking into account hardware characteristics and instruction dependencies, to reduce pipeline stalls; at the same time, optimize the instruction issue logic to ensure that POSIT instructions can efficiently utilize hardware functional units and improve overall execution efficiency.

9. A compiler device for ARM processors supporting POSIT floating-point format, comprising a processor and a memory, wherein the memory is used to store computer programs, characterized in that, The processor is used to execute the computer program to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images