CN116627429B

CN116627429B - Assembly code generation method and device, electronic equipment and storage medium

Info

Publication number: CN116627429B
Application number: CN202310890640.3A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Wuxi Muchuang Integrated Circuit Design Co ltd
Current assignee: Wuxi Muchuang Integrated Circuit Design Co ltd
Priority date: 2023-07-20
Filing date: 2023-07-20
Publication date: 2023-10-20
Anticipated expiration: 2043-07-20
Also published as: CN116627429A

Abstract

The application discloses an assembly code generation method, an assembly code generation device, electronic equipment and a storage medium, wherein the assembly code generation method comprises the following steps: generating a corresponding macro definition for a constant and a register to be used, and generating a macro definition of an objective function according to a required function; storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file; and generating main assembly codes based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, wherein the main assembly codes are used for realizing the function. According to the assembly code generation method provided by the application, macro definition is carried out on the constant, the register and the target function to be used in the header file, the main assembly code is generated based on the macro definition of the constant, the macro definition of the register and the macro definition of the target function, multiplexing of the macro definition of the target function is realized, and the code generation efficiency of the assembly language is improved.

Description

Assembly code generation method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer technology, and more particularly, to an assembly code generating method and apparatus, an electronic device, and a computer readable storage medium.

Background

RISC-V is a widely focused open source instruction set, with a large number of related tools being issued in practice. However, in practical use, since RISC-V is an assembly language, the language itself cannot support multiplexing of modules and code. Therefore, in the related art, code generation efficiency of assembly language is low. How to improve the code generation efficiency of assembly language is a technical problem that needs to be solved by those skilled in the art.

Disclosure of Invention

The application aims to provide an assembly code generation method and device, electronic equipment and a computer readable storage medium, and the efficiency of code generation of assembly language is improved.

In order to achieve the above object, the present application provides a method for generating assembly code, including:

generating a corresponding macro definition for a constant and a register to be used, and generating a macro definition of an objective function according to a required function;

storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file;

and generating main assembly codes based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, wherein the main assembly codes are used for realizing the function.

If the macro definition of the objective function includes a jump mark, the method further includes:

splicing calling identifiers corresponding to the objective function after jump marks in the macro definition of the objective function so as to update the macro definition of the objective function; the input of the updated target function when the macro definition is called comprises the value of the calling identifier, and the main assembly code inputs different values of the calling identifier each time the updated target function macro definition is called.

The main assembly code sequentially uses the registers from the register with the smallest number according to the increasing direction of the number, the global register sequentially uses the registers from the register with the largest number to the register with the number n according to the decreasing direction of the number, and the registers from the register with the number n-1 in the macro definition of the function sequentially use the registers according to the decreasing direction of the number;

and when the idle register does not exist, generating a plurality of macro definitions for the target register, wherein the action ranges of the macro definitions corresponding to the target register are not overlapped.

The macro definition of the objective function comprises a first assembly code, a second assembly code and a third assembly code which are sequentially arranged, wherein the first assembly code is used for storing a value of a register to be used to a preset position of a memory, the second assembly code is used for realizing a required function, and the third assembly code is used for recovering the value of the register in the preset position to the register.

Wherein the generating a macro definition of the objective function according to the required function includes:

generating macro definition of the objective function according to the required function through the head file guard;

correspondingly, saving the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file comprises the following steps:

and storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a plurality of header files.

Wherein, still include:

extracting macro definition names from files except for intermediate files in the compiling process; the macro definition names comprise macro definition names of constants, macro definition names of registers and macro definition names of functions;

generating a corresponding tag file based on the macro definition name, and configuring a catalog of the tag file in a configuration file of a text editor;

in the code browsing process, skipping of a code tag is carried out based on the tag file in the catalog;

and in the code writing process, code completion is carried out based on the tag files in the catalog.

Wherein the extracting macro definition names from the files except the intermediate files in the compiling process comprises:

When a save command of the assembly code is received, the step of extracting macro definition names from files except for intermediate files in the compiling process is triggered to be executed.

In order to achieve the above object, the present application provides an assembly code generating apparatus, comprising:

the generation module is used for generating corresponding macro definitions for constants and registers to be used and generating macro definitions of the objective function according to the required function;

the storage module is used for storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file;

and the execution module is used for generating main assembly code based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, wherein the main assembly code is used for realizing the function.

To achieve the above object, the present application provides an electronic device including:

a memory for storing a computer program;

and a processor for implementing the steps of the assembly code generation method as described above when executing the computer program.

To achieve the above object, the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the assembly code generation method as described above.

According to the scheme, the method for generating the assembly code provided by the application comprises the following steps: generating a corresponding macro definition for a constant and a register to be used, and generating a macro definition of an objective function according to a required function; storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file; and generating main assembly codes based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, wherein the main assembly codes are used for realizing the function.

According to the assembly code generation method provided by the application, macro definition is carried out on the constant, the register and the target function to be used in the header file, the main assembly code is generated based on the macro definition of the constant, the macro definition of the register and the macro definition of the target function, multiplexing of the macro definition of the target function is realized, and the code generation efficiency of the assembly language is improved. The application also discloses an assembly code generating device, electronic equipment and a computer readable storage medium, and the technical effects can be realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art. The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of this specification, illustrate the disclosure and together with the description serve to explain, but do not limit the disclosure. In the drawings:

FIG. 1 is a flowchart illustrating a method of assembly code generation, according to an example embodiment;

FIG. 2 is a schematic diagram illustrating a common header file being expanded multiple times in a source file according to an example embodiment;

FIG. 3 is a block diagram illustrating an assembly code generation apparatus according to an example embodiment;

fig. 4 is a block diagram of an electronic device, according to an example embodiment.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application. In addition, in the embodiments of the present application, "first", "second", etc. are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence.

In the related art, RISC-V code is written, often lacking in readability and maintainability. By way of example, the following two operations need to be completed: the maximum length of a packet (1518) is loaded into the x1 register and the location in memory (0 x 1000) of the packet is loaded into the x2 register. This is the operation of loading two immediate data into a given register, which has practical implications. Each immediate load requires two instructions to implement, the specific code is as follows:

_start:

lui x1, %hi(1518)

lui x2, %hi(0x1000)

addi x1, x1, %lo(1518)

addi x2, x2, %lo(0x1000)；

the macro definition is not used for the constants (1518, 0x 1000) and the numbers (x 1, x 2) of the registers in the code, and the effect of 'seeing the name' is difficult to achieve. Not only is the actual reading readability poor. Moreover, it is also difficult to uniformly modify the relative constant and register numbers. The codes are not subjected to modularization processing (an lui instruction is matched with an addi instruction to complete the loading of an immediate number), so that the cohesion degree between adjacent codes is low, and the coupling degree between non-adjacent codes is high, thus the code reading, multiplexing and maintenance are difficult. Because the code is not packaged in the form of a code library, if it is to be multiplexed, it can only be implemented by copying the code, modifying constants, register numbers, etc. This is extremely inconvenient for multiplexing codes. Meanwhile, the codes multiplexed in the mode are difficult to uniformly modify and maintain.

As can be seen, in the related art, the code generation efficiency of assembly language is low. Based on the method, macro definition is carried out on constants, registers and objective functions to be used in the header file, main assembly codes are generated based on macro definition of the constants, macro definition of the registers and macro definition of the objective functions, multiplexing of macro definition of the objective functions is achieved, and code generation efficiency of assembly languages is improved.

The embodiment of the application discloses an assembly code generation method, which improves the code generation efficiency of assembly language.

Referring to fig. 1, a flowchart of an assembly code generating method according to an exemplary embodiment is shown, as shown in fig. 1, including:

s101: generating a corresponding macro definition for a constant and a register to be used, and generating a macro definition of an objective function according to a required function;

the execution body of the embodiment may be an assembly code generator, and the assembly code may be automatically generated based on the assembly code generation method provided in the embodiment.

In a specific implementation, a corresponding macro definition is generated for the constants and registers that need to be used, and the macro definition can be performed by a #definition statement.

Registers other than x0 can generate macro definitions in the header file, typically without directly using x1-x31. The macro definition names of the registers may all be capital letters, segmented using underlining, ending with REG, for example:

#define INPUT_PKT_MAX_LEN_REG x1。

The macro definition names of the global registers may all start with g_e.g.:

#define G_STORE_REG_BASE_ADDR_REG x31

#define G_PKT_BASE_ADDR_REG x30

#define G_PKT_LEN_REG x29。

the CSR (Control and Status Register, control status register) may start with csr_s. For example:

#define CSR_RECV_STATUS_REG (0x290)。

if registers between different functions are renamed, words before the first underline of the function may be taken before the registers to show differentiation.

The constant may include a numeric constant, such as an immediate, and the macro-defined name of the constant may be named with large letters, and the different words may be separated by an underline, but the end is not added with a REG, which is distinguished from the macro-defined name of the register. For example: input_pkt_max_len_reg, input_pkt_max_len.

Further, corresponding macro definitions are generated for the objective function according to the required function, and the macro definitions of the function are completed by using the. Macro and the. Endm.

In the macro definition of a function, position numbers may be named in lowercase letters, beginning with underlined separation between words, for example: the position marks are generally named and can be distinguished from each other. For definitions that exist in multiple functions, the name of the macro where_of_exists can be added to the end to distinguish, for example: start_of_macro_01, end_of_macro_02. The instructions may all take the form of small letters, such as: lui, addi, etc. In the macro definition of the function, macro, & endm, and form parameters may be named in full lowercase and underlined form, and function names may be named in full uppercase form, e.g., function header: macro load_imme_to_reg dst_reg, IMME.

S102: storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a header file;

in this step, the macro definition of the generated constant, the macro definition of the register, and the macro definition of the objective function are saved to the header file (.h or.s file).

As a preferred embodiment, the macro definition of the generated constant, the macro definition of the register, the macro definition of the objective function may be saved to a plurality of header files. When compiling the assembly code specifically, the compiler will perform precompiled (precompilation) first, and perform text replacement according to the macro definition to form the assembly source code to be compiled. The macro definition of the function is stored in a plurality of header files (h or S files), and thus a problem is also brought about, namely, a problem of repeated inclusion. The most common cause of duplicate inclusion is "diamond inclusion". Diamond containment may lead to compilation errors because the common header file may be extended multiple times in the source file. As shown in fig. 2, the "header file 2.h" and the "header file 3.h" both need to refer to the "header file 1.H", and the main program needs to refer to the "header file 2.h" and the "header file 3.h", and codes in the common header file, that is, the "header file 1.H", may be repeated in the source file of the main program.

The header guard (Header File Safeguard) is needed to avoid redefinition errors, and the main purpose of the header guard is to protect nested macro definitions from redefinition, i.e. the generation of macro definitions of objective functions according to the required function functions includes: and generating macro definition of the target function according to the required function through the head file guard.

Examples are as follows:

for documents a.h and b.h:

//a.h

# ifndef_A_H// head file guard

# define _A_H

Internally defined macros for// completion

.macro macro_001

.endm

Head file guard end of the# endif// a.h file

//b.h

# ifndef_b_h// head file guard

# define _B_H

# include "a.h"

Internally defined macros for// completion

.macro macro_002

.endm

Head file guard end of the# endif// b.h file

For file main.S, the call to two macro definition functions is accomplished simultaneously by referencing two header files a.h, b.h

#include "a.h"

#include "b.h"

_start:

In main program code, call two macro functions

macro_001

macro_002。

S103: generating main assembly code based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, and executing the main assembly code to realize the function.

In particular implementations, in the main assembly code, the function functions are implemented by calling constants, registers, and objective functions defined by macros in the header file.

In this embodiment, all immediate and internal registers (x 0-x 31) are defined as a macro string by using the # define command provided by the gcc (GNU Compiler Collection) compiler. And for the reusable code segments, the macro and the endm pre-compiling commands provided by the gcc compiler are defined into macro code segments, the reusability of the code segments is improved in a parameter transmission mode, and the parameters of the macro code segments are acquired in the macro through a parameter_name mode. When the main assembly code is actually generated, the main assembly code is realized by calling the defined macro code segment as much as possible, so that the copy use of the code segment is realized.

By way of example, the maximum length of a packet is written to the x1 register and the location value of the packet is written to the x2 register. Definition of registers, macro definition of immediate in header file:

the register number of the maximum length of the INPUT packet is # defined INPUT_PKT_MAX_LEN_REGx1// stored

Register number of #define input_pkt_addr_regx2// register number storing INPUT packet address

# define INPUT_PKT_ADDR (0 x 1000)// INPUT packet Address value

The value of the maximum length of the INPUT packet is # defined INPUT_PKT_MAX_LEN (1518)// INPUT packet.

Macro definition of defining function in header file:

.macro LOAD_IMME_TO_REG dst_reg , imme

lui \dst_reg, %hi(\imme)

addi \dst_reg, \dst_reg , %lo(\imme)

.endm。

Writing the maximum length of the data packet into an x1 register and writing the position value of the data packet into an x2 register are realized in main assembly code:

_start:

load_IMME_TO_REG INPUT_PKT_MAX_LEN_REG, INPUT_PKT_MAX_LEN// LOAD packet maximum length value TO the corresponding register;

load_imme_to_reg input_pkt_addr_reg, input_pkt_addr// LOAD packet base address value TO the corresponding register.

In addition, a new immediate loading interface can be provided according to the characteristic of loading the immediate. A generic immediate load interface requires two RV32I assembly statements. And the optimized loading of an immediate function can be completed by only one statement. The specific codes are as follows:

.macro LOAD_IMME_TO_REG_UPPER dst_reg , imme

lui \dst_reg, %hi(\imme)

.endm

the// defines a macro code segment for loading a register. The immediate low 12 bits must all be 0;

.macro LOAD_IMME_TO_REG_SMALL dst_reg , imme

addi \dst_reg, x0, %hi(\imme)

.endm

the// defines a macro code segment for loading a register. The size of the immediate value must be within the range of-2048 to 2047.

When the code needs TO be optimized, the characteristics of the two immediate values can be analyzed, the address value of the data packet is 0x1000, the calling condition of the first function LOAD_IMME_TO_REG_UPPER is met, namely, the lower 12 bits of the immediate value must be all 0, the maximum value of the data packet is 1518, and the calling condition of the second function LOAD_IMME_TO_REG_SMALL is met, namely, the size range of the immediate value must be-2048-2047 (namely, -0x 800-0 x7 FF).

Therefore, the optimized main assembly code is:

_start:

LOAD_IMME_TO_REG_UPPER INPUT_PKT_ADDR_REG, INPUT_PKT_ADDR

LOAD_IMME_TO_REG_SMALL INPUT_PKT_MAX_LEN_REG , INPUT_PKT_MAX_LEN。

in addition, three library functions are available for multiplexing, namely:

.macro LOAD_IMME_TO_REG dst_reg , imme

.macro LOAD_IMME_TO_REG_UPPER dst_reg , imme

.macro LOAD_IMME_TO_REG_SMALL dst_reg , imme。

according to the assembly code generation method provided by the embodiment of the application, macro definition is carried out on the constant, the register and the target function to be used in the header file, the main assembly code is generated based on the macro definition of the constant, the macro definition of the register and the macro definition of the target function, multiplexing of the macro definition of the target function is realized, and the code generation efficiency of the assembly language is improved.

On the basis of the foregoing embodiment, as a preferred implementation manner, if the macro definition of the objective function includes a jump mark, after the macro definition of the objective function is generated according to the function as needed, the method further includes: splicing calling identifiers corresponding to the objective function after jump marks in the macro definition of the objective function so as to update the macro definition of the objective function; the input of the updated target function when the macro definition is called comprises the value of the calling identifier, and the main assembly code inputs different values of the calling identifier each time the updated target function macro definition is called.

Since the code is implemented using macro definition, the code is simply copied and expanded, and when the code segments with defined jump marks are multiplexed, an error of "mark repetition definition" is reported. For example:

#define CSR_RECV_STATUS_REG (0x290)

.macro RECV_PKT

csrrwi x0, CSR_RECV_STATUS_REG, 0x2// cycle waiting, packet receipt CSR flag register set

' wait_data_in:// note that a position index is defined herein, repeated references may cause conflicts

csrr x1, CSR_RECV_STATUS_REG

bne x1, x0, _wait_data_in

.endm

_start:

Recv_pkt// receive first packet

Recv_pkt// receives the second packet where the compilation would report error_wait_data_in label is repeatedly defined.

In view of the above, in this embodiment, when calling, a call identifier for distinguishing is transferred to the macro definition. The specific process is as follows: firstly, adding a parameter call_id (call identifier) to the macro to be called, secondly, transferring the call_id value (call identifier) which is input on the tail splicing in the places related to all jump labels in the macro to be called, and finally, transferring a different call_id character string (call identifier) each time the macro is called.

The modified code is as follows:

the macro RECV_PKT call_id// macro definition function is added with a parameter call_id, and a call number character string is transferred

csrrwi x0, CSR_RECV_STATUS_REG, 0x2

The value of_wait_data_in_call_id:// position index is followed by concatenation of the value of call_id

csrr x1, CSR_RECV_STATUS_REG

The value of position index followed by splice call_id is also used when bnex 1, x0, _wait_data_in_call_id// jump

.endm

_start:

Recv_pkt call_id_01// receive first packet

Recv_pkt call_id_02// receives the second packet, here by passing only a different call number string

The code defined in this way, after precompiled, generates the code:

/(correlation code)

//...

The serial number generated by calling RECV_PKT for the first time is:// the serial number generated by calling RECV_PKT for the first time

/(correlation code)

//...

The_wait_data_in_call_id_02:// the number generated by the RECV_PKT is called for the second time

//...。

For slightly larger macro segments, registers are used internally, except for the registers passed in as parameters. Therefore, to implement code segment multiplexing, register management work in and out of macro must be done to prevent conflicts from occurring with them. The application provides two schemes for register management, and the two schemes can be independently used or mixed.

As a possible implementation manner, the master assembly code sequentially uses the registers from the register with the smallest number according to the increasing direction of the number, the global registers sequentially use the registers from the register with the largest number to the register with the number n according to the decreasing direction of the number, and the registers from the register with the number n-1 in the macro definition of the function sequentially use the registers according to the decreasing direction of the number; and when the idle register does not exist, generating a plurality of macro definitions for the target register, wherein the action ranges of the macro definitions corresponding to the target register are not overlapped.

The scheme is suitable for the condition that the whole code scale is smaller, and the use of the registers is allocated by the pre-agreed scheme, so that the use conflict of the registers is effectively prevented. The following is an example scenario:

1. registers used by the main assembly code are arranged from x1, x2 and … … from x1 from small to large in positive sequence;

2. a small number of global registers, which may be arranged in reverse order from large to small, from x31, x30, … …, to xn, with fewer variations;

3. for temporarily used registers in the macro program segment, the registers are arranged from xn-1, xn-2 and … … in reverse order from large to small;

4. when the number of registers is insufficient, especially the macro definitions of the global register and the current used registers are more, the action ranges of the registers can be analyzed, different macro definition names can be used for two or more registers with the effective action ranges which are not overlapped certainly, and the defined real register numbers can be consistent. For example:

#define G_RECV_BASE_REG x31

#define G_SEND_BASE_REG x31。

the g_recv_base_reg and g_send_base_reg are global registers, but their active ranges do not overlap. The g_recv_base_reg is used when receiving packets, and the g_send_base_reg is used when transmitting packets. Therefore, the same register numbers can be used.

When the register is used according to the scheme, the register cannot collide.

By way of example, the following codes are shown:

#define STORE_REG_BASE_ADDR (0x900)

the following are global registers, named G_head

#define G_STORE_REG_BASE_ADDR_REG x31

#define G_PKT_BASE_ADDR_REG x30

#define G_PKT_LEN_REG x29

Register for MACRO_DEMO_01 internal temporary use is defined below

#define MACRO_DEMO_01_01_REG x28

#define MACRO_DEMO_01_02_REG x27

#define MACRO_DEMO_01_03_REG x26

Example MACRO ro dema_01// first internal use to register

USE_REG_01 MACRO_DEMO_01_01_REG

USE_REG_02 MACRO_DEMO_01_02_REG

USE_REG_03 MACRO_DEMO_01_03_REG

.endm

The register for temporary use inside MACRO_DEMO_02 is defined below, rearranged from x28 from big to small, and is not affected by MACRO_DEMO_01

#define MACRO_DEMO_02_01_REG x28

#define MACRO_DEMO_02_02_REG x27

#define MACRO_DEMO_02_03_REG x26

#define MACRO_DEMO_02_04_REG x25

Example MACRO ro dema 02// second internal use to register

USE_REG_01 MACRO_DEMO_02_01_REG

USE_REG_02 MACRO_DEMO_02_02_REG

USE_REG_03 MACRO_DEMO_02_03_REG

USE_REG_04 MACRO_DEMO_02_04_REG

.endm

Start/Main program, call example macros in turn

MACRO_DEMO_01

MACRO_DEMO_02。

As another possible implementation manner, the macro definition of the objective function includes a first assembly code, a second assembly code and a third assembly code, which are sequentially arranged, where the first assembly code is used for storing a value of a register to be used in a preset location of a memory, the second assembly code is used for implementing a required function, and the third assembly code is used for restoring the value of the register in the preset location into the register.

In a specific implementation, each time a macro code segment is entered, a register to be temporarily used in the code segment may be saved to a fixed location in a memory RAM (random access memory ), and in the macro code, the macro code segment processing is finished using the register, and then the value in the memory RAM is read back into the register.

The following are relevant support codes:

the region of #define STORE_REG_BASE_ADDR (0 x 900)// 0x900 onward is dedicated to storing and restoring register values and cannot be corrupted by other uses

The following are global registers, named G_head

#define G_STORE_REG_BASE_ADDR_REG x31

#define G_PKT_BASE_ADDR_REG x30

#define G_PKT_LEN_REG x29

The following code is to write the contents of the register into the memory RAM

.macro STORE_x1 base_addr_reg

sw x1, (1 * 0x04)(\base_addr_reg)

.endm

.macro STORE_x2 base_addr_reg

sw x2, (2 * 0x04)(\base_addr_reg)

.endm

//.......

.macro STORE_x31 base_addr_reg

sw x31, (31* 0x04)(\base_addr_reg)

.endm

The following code is to restore registers from memory RAM

.macro LOAD_x1 base_addr_reg

lw x1, (1 * 0x04)(\base_addr_reg)

.endm

.macro LOAD_x2 base_addr_reg

lw x2, (2 * 0x04)(\base_addr_reg)

.endm

//.......

.macro LOAD_x31 base_addr_reg

lw x31, (31* 0x04)(\base_addr_reg)

.endm。

By using the above support code, a macro definition function that does not call before and after, and does not affect the x1-x31 registers can be conveniently implemented. Specific examples are as follows:

a macro is defined below, where x1, x3, x8 are used internally, but without adverse effects, i.e., the values of the registers of x1-x32 do not change before and after invocation

.macro MACRO_DEMO_03

LOAD _ IMME _ TO _ REG _ STORE _ REG _ BASE _ ADDR _ REG, STORE _ REG _ BASE _ ADDR// memory area ready for storing register values, this area is dedicated TO storing and restoring register values and cannot be destroyed by other uses

STORE_x1 STORE_REG_BASE_ADDR_REG

STORE_x3 STORE_REG_BASE_ADDR_REG

STORE_x8 STORE_REG_BASE_ADDR_REG

Intermediate code, which can operate on x1, x3, x8

LOAD_x1 STORE_REG_BASE_ADDR_REG

LOAD_x3 STORE_REG_BASE_ADDR_REG

LOAD_x8 STORE_REG_BASE_ADDR_REG

.endm

Start/Main program, call example macros in turn

First, assign values to the x1, x3, x8 registers

LOAD_IMME_TO_REG x1, 0x12345

LOAD_IMME_TO_REG x3, 0x34567

LOAD_IMME_TO_REG x8, 0x89012

The MACRO_DEMO_03// call will use a macrofunction that uses three registers, x1, x3, x8

After the// call is completed, the values of x1, x3, x8 are unchanged.

In specific implementation, the functions of the sub-functions of the macro definitions should be divided into smaller and independent functions, so that the use of registers in each macro definition can be effectively reduced. In addition, the method is used strictly according to the above register allocation specification, so that not only can the conflict of register use be prevented, but also the readability can be increased, and the code maintainability can be improved. If indeed a macro uses too many registers, out of range, a combination of the two schemes described above may be used: firstly, planning a register according to a scope, and if the planning is completed, the register is still not used enough. The macro function with the most registers is selected, and the registers are saved before use and restored after use.

On the basis of the above embodiment, as a preferred implementation manner, the method further includes: extracting macro definition names from files except for intermediate files in the compiling process; the macro definition names comprise macro definition names of constants, macro definition names of registers and macro definition names of functions; generating a corresponding tag file based on the macro definition name, and configuring a catalog of the tag file in a configuration file of a text editor; in the code browsing process, skipping of a code tag is carried out based on the tag file in the catalog; and in the code writing process, code completion is carried out based on the tag files in the catalog.

Vim is a text editor developed from vi, and code label jumping and code completion can be achieved by combining label (tags) files conforming to the Vim standard format. For assembly language, the tags file needs to be generated by writing a script.

The specific process is as follows:

shell script is written, ctags command is called, and tags file is generated.

Wherein, the firmware_tags.sh script content is as follows:

echo "!_TAG_FILE_SORTED 0"

grep macro * |grep -v "*\.map" | awk -F '[: \t,]+' '{ print $3 "\t./" $1 "\t/"$2,$3"\\>" }'

grep define * |grep -v "\#include" | awk -F '[: \t,]+' '{ print $3 "\t./" $1 "\t/"$2,$3"\\>" }'；

where grep is the meaning of looking up a line containing the specified text, say grep macro is the meaning of looking up a line containing the text of macro, grep-v is the meaning of looking up in the opposite direction, say grep-v ". Map" is the meaning of looking up a line not containing the map field. The first grep header command above is to extract the macro name defined by macro as a tag (tag). grep macro searches all the current catalogues for lines containing macro definition, grep-v "\map" excludes related lines extracted from map files, map files are intermediate files generated during compiling, the internal of the map files are also text formats, the generation and the use of tags files can be influenced, awk-F're ' { action } ', for the text lines from the previous pipeline, F ' is used for [ \t + ' designating separators, namely space is designated, and three separators of tab and number are designated. Then, some characters are extracted, the format is rearranged, and the output is carried out. The second grep header command above is used to extract the macro name defined by #definition, and the command structure is similar to the extraction above as tag.

the tags file format is as follows:

{tagname} {TAB} {tagfile} {TAB} {tagaddress}；

{ tagname } is an identifier name, such as a function name, class name, structure name, macro, etc., and cannot contain a tab, and { tagfile } is a file containing { tagname }, and cannot contain a tab. { tagadd } is an Ex command that can be positioned to the cursor position, and typically contains only a line number or search command. Between { tagname }, { tagface }, and { tagadd }, tab separation is employed, that is, tab cannot be included in the contents of { tagname }, { tagface }, and { tagadd }.

For example, a row in the tags file is generated:

LOAD_IMME_TO_REG ./bit_byte_proc.S /.macro LOAD_IMME_TO_REG\>；

the LOAD_IMME_TO_REG represents a { tagname }, which is a name defined by a macro,/bit_byte_proc.S, which is a { tagfile }, which represents a file and path where the macro defines the LOAD_IMME_TO_REG, and/(macro LOAD_IMME_TO_REG >, which is an { tagaddress }, which is an Ex command that can be positioned TO a cursor position.

The beginning of the Tag file may contain a row beginning with "|_tag_", to add other information to the Tag file. Two such markers are recognized by Vim, frequently used are "_tag_file_sent" markers, for example:

!_TAG_FILE_SORTED<Tab>1<Tab>{anything}；

a value of 1 indicates that the tag files are ordered, and the case is distinguished during ordering, and the ordered tags are searched by a dichotomy Vim, so that the searching speed is increased; if the value is 0, the tag file is not ordered; if the value is 2, it indicates that the tag file is in the ignore case ordering. The retrieval is faster for the ordered tag files. However, the amount of code assembled is generally not so large, so the value can be set to 0, i.e., using a non-ordered format.

The final tags file content is as follows:

the flag at the beginning of | TAG_FILE_SORTED 0# indicates that the current FILE is unordered

# below are some of the macro functions defined by macro extracted from the S file

LOAD_IMME_TO_REG ./bit_byte_proc.S /.macro LOAD_IMME_TO_REG\>

CLEAR_REG_HIGH_N_BITS ./bit_byte_proc.S /.macro CLEAR_REG_HIGH_N_BITS\>

RESERVE_REG_LOW_N_BITS ./bit_byte_proc.S /.macro RESERVE_REG_LOW_N_BITS\>

CLEAR_REG_16_31_BITS ./bit_byte_proc.S /.macro CLEAR_REG_16_31_BITS\>

GET_AND_MASK_RESULT_REG ./bit_byte_proc.S /.macro GET_AND_MASK_RESULT_REG\>

GET_AND_MASK_RESULT ./bit_byte_proc.S /.macro GET_AND_MASK_RESULT\>

#...

The following are some macros extracted from the define. H file defined by: register number and number constant

Register number defined by definition #

SPI2_VALUE_REG ./define.h /#define SPI2_VALUE_REG\>

SPI2_SRC_IP_REG ./define.h /#define SPI2_SRC_IP_REG\>

SPI2_DST_IP_REG ./define.h /#define SPI2_DST_IP_REG\>

SPI2_SUM_IP_REG ./define.h /#define SPI2_SUM_IP_REG\>

# numerical constant defined by definition

SPI2_LEN ./define.h /#define SPI2_LEN\>

IPV4_HEADER_VAL ./define.h /#define IPV4_HEADER_VAL\>

IPV4_HEADER_VAL_OFFSET_BY_IP_HDR ./define.h /#define IPV4_HEADER_VAL_OFFSET_BY_IP_HDR\>

UDP_HEADER_LEN ./define.h /#define UDP_HEADER_LEN\>

ETH_HEADER_LEN ./define.h /#define ETH_HEADER_LEN\>

IP_HEADER_LEN ./define.h /#define IP_HEADER_LEN\>

ESP_HEADER_LEN ./define.h /#define ESP_HEADER_LEN\>

PAD_ETH_IP_HEADER_LEN ./define.h /#define PAD_ETH_IP_HEADER_LEN\>

#...。

After the tags file is generated, the simple configuration can perform code jumping and code complement work in the Vim. In the vimrc, a tags option is set, and the directory of the tags file is specified. The method comprises the following steps: set tags=/tags,/firmware_dir/tags, where firmware_dir is the directory where the specific tags file is located, so that flexible configuration can be implemented according to specific situations.

On the basis of the above embodiment, as a preferred implementation manner, the extracting the macro definition name from the files except for the intermediate file in the compiling process includes: when a save command of the assembly code is received, the step of extracting macro definition names from files except for intermediate files in the compiling process is triggered to be executed.

In specific implementation, a setting can be added in a configuration file of the Vim, and after each time of modifying and saving the assembly code, a script is called to regenerate a tags file, wherein the specific code is as follows:

:autocmd BufWritePost *.S,define.h silent! call system("./firmware_tags.sh>tags&")；

autocmd BufWritePost filelist call system ("run. Sh") indicates that each time a file of S or defined. H is saved, a shell script run. Sh is called, and sillent | indicates that the entire script command is quietly executed without popping up a dialog box.

With the above described basis for preparation and configuration, the jump function of Vim can be used as follows. When browsing codes, the jump can be performed according to the content of the tags file. When in specific use, there are two modes:

1. TAG jumps are implemented using a shortcut key:

(1) the cursor is moved to the function calling position, and the combination key ctrl+ is used for jumping to the function definition position;

(2) ctrl+o jumps back to function call;

(3) g Ctrl+ can cross the catalogue, can be prompted when there are multiple definitions, and use the digital mark, enter the carriage return can jump to the corresponding definition place after inputting the number;

(4) the use of ctrl+t may be returned to the previous file;

2. TAG jumps are implemented using Ex commands:

(1) the tag { keyword } is equivalent to ctrl+ ], only the keyword is needed to be manually input, and the completion can be carried out by pressing the < TAB > key in the input process;

(2) Tjump { keyword } is equivalent to gctrl+ ], if there are multiple tags that can match the key where the current cursor is located, the user is prompted to specify a place to jump. If only one position is matched, the prompt is not given, and the jump is directly carried out;

(3) pop is equivalent to ctrl+t, traversing the tag history in reverse;

(4) the tag forward traverses the tag history;

(5) t next jumps to the next matched tag;

(6) tprev jumps to the last matched tag;

(7) tfirst jumps to the first matched tag;

(8) the tlast jumps to the last matched tag;

(9) tselect prompts the user to select an item from the tag match list to jump.

The automatic complement function eliminates the trouble of entering the entire word, and only the first few letters of the word need to be given, and Vim creates a list containing suggested content based on this information to select the appropriate complement. Automatic completion in Vim will scan the following three file contents:

1. all files in the current editing session;

2. all include files (included files);

3. tag files (tag files): i.e. the tags file described earlier.

A completion list is created accordingly.

By means of the two combination keys ctrl+p and ctrl+n, not only the autocompletion of Vim can be triggered in the insertion mode, but also they can be used for the selection in reverse or forward direction in the complement list.

(1) ctrl+p, ctrl+n will only call the auto-completion of the normal key. In addition to this, there are several other methods of autocompletion, all of which operate with the combination key ctrl+x as the start.

(2) ctrl+x ctrl+n: current buffer key;

(3) ctrl+x ctrl+i: contains file keywords;

(4) ctrl+x ctrl+ ]: tag file keywords (keywords in tags files that are particularly suitable for generation);

(5) ctrl+x ctrl+k: dictionary searching;

(6) ctrl+x ctrl+l: full row complement;

(7) ctrl+x ctrl+f: the file name is completed.

An assembly code generating device provided in the embodiment of the present application is described below, and an assembly code generating device described below and an assembly code generating method described above may be referred to each other.

Referring to fig. 3, a block diagram of an assembly code generating apparatus according to an exemplary embodiment is shown, as shown in fig. 3, including:

the generating module 301 is configured to generate a corresponding macro definition for a constant and a register to be used, and generate a macro definition of an objective function according to a required function;

a saving module 302, configured to save the macro definition of the constant, the macro definition of the register, and the macro definition of the objective function to a header file;

And the execution module 303 is configured to generate a master assembly code based on the macro definition of the constant, the macro definition of the register, and the macro definition of the objective function in the header file, where the master assembly code is used to implement the function.

According to the assembly code generation device provided by the embodiment of the application, macro definition is carried out on the constant, the register and the target function to be used in the header file, and the main assembly code is generated based on the macro definition of the constant, the macro definition of the register and the macro definition of the target function, so that multiplexing of the macro definition of the target function is realized, and the code generation efficiency of the assembly language is improved.

On the basis of the foregoing embodiment, as a preferred implementation manner, if the macro definition of the objective function includes a jump mark, the method further includes:

the splicing module is used for splicing the call identifier corresponding to the objective function after the jump mark in the macro definition of the objective function so as to update the macro definition of the objective function; the input of the updated target function when the macro definition is called comprises the value of the calling identifier, and the main assembly code inputs different values of the calling identifier each time the updated target function macro definition is called.

On the basis of the above embodiment, as a preferred implementation manner, the master assembly code sequentially uses the registers from the register with the smallest number according to the increasing direction of the number, the global registers sequentially use the registers from the register with the largest number to the register with the number n according to the decreasing direction of the number, and the registers are sequentially used from the register with the number n-1 according to the decreasing direction of the number in the macro definition of the function; and when the idle register does not exist, generating a plurality of macro definitions for the target register, wherein the action ranges of the macro definitions corresponding to the target register are not overlapped.

On the basis of the above embodiment, as a preferred implementation manner, the macro definition of the objective function includes a first assembly code, a second assembly code and a third assembly code, which are sequentially arranged, where the first assembly code is used for storing the value of the register to be used in a preset location in the memory, the second assembly code is used for implementing the required function, and the third assembly code is used for restoring the value of the register in the preset location into the register.

On the basis of the above embodiment, as a preferred implementation manner, the generating module 301 is specifically configured to: generating a corresponding macro definition for the constant and the register to be used, and generating a macro definition of the objective function according to the function required by the head file guard;

Accordingly, the saving module 302 is specifically configured to: and storing the macro definition of the constant, the macro definition of the register and the macro definition of the objective function into a plurality of header files.

On the basis of the above embodiment, as a preferred implementation manner, the method further includes:

the extraction module is used for extracting macro definition names from files except for intermediate files in the compiling process; the macro definition names comprise macro definition names of constants, macro definition names of registers and macro definition names of functions;

the third generation module is used for generating a corresponding tag file based on the macro definition name and configuring a catalog of the tag file in a configuration file of the text editor;

the jump module is used for jumping the code labels based on the label files in the catalogue in the code browsing process;

and the completion module is used for carrying out code completion based on the tag file in the catalog in the code writing process.

On the basis of the above embodiment, as a preferred implementation manner, the extraction module is specifically configured to: when a save command of the assembly code is received, the step of extracting macro definition names from files except for intermediate files in the compiling process is triggered to be executed.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

Based on the hardware implementation of the program modules, and in order to implement the method according to the embodiment of the present application, the embodiment of the present application further provides an electronic device, and fig. 4 is a block diagram of an electronic device according to an exemplary embodiment, and as shown in fig. 4, the electronic device includes:

a communication interface 1 capable of information interaction with other devices such as network devices and the like;

and the processor 2 is connected with the communication interface 1 to realize information interaction with other devices and is used for executing the assembly code generation method provided by one or more technical schemes when running the computer program. And the computer program is stored on the memory 3.

Of course, in practice, the various components in the electronic device are coupled together by a bus system 4. It will be appreciated that the bus system 4 is used to enable connected communications between these components. The bus system 4 comprises, in addition to a data bus, a power bus, a control bus and a status signal bus. But for clarity of illustration the various buses are labeled as bus system 4 in fig. 4.

The memory 3 in the embodiment of the present application is used to store various types of data to support the operation of the electronic device. Examples of such data include: any computer program for operating on an electronic device.

It will be appreciated that the memory 3 may be either volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. Wherein the nonvolatile Memory may be Read Only Memory (ROM), programmable Read Only Memory (PROM, programmable Read-Only Memory), erasable programmable Read Only Memory (EPROM, erasable Programmable Read-Only Memory), electrically erasable programmable Read Only Memory (EEPROM, electrically Erasable Programmable Read-Only Memory), magnetic random access Memory (FRAM, ferromagnetic random access Memory), flash Memory (Flash Memory), magnetic surface Memory, optical disk, or compact disk Read Only Memory (CD-ROM, compact Disc Read-Only Memory); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be random access memory (RAM, random Access Memory), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (SRAM, static Random Access Memory), synchronous static random access memory (SSRAM, synchronous Static Random Access Memory), dynamic random access memory (DRAM, dynamic Random Access Memory), synchronous dynamic random access memory (SDRAM, synchronous Dynamic Random Access Memory), double data rate synchronous dynamic random access memory (ddr SDRAM, double Data Rate Synchronous Dynamic Random Access Memory), enhanced synchronous dynamic random access memory (ESDRAM, enhanced Synchronous Dynamic Random Access Memory), synchronous link dynamic random access memory (SLDRAM, syncLink Dynamic Random Access Memory), direct memory bus random access memory (DRRAM, direct Rambus Random Access Memory). The memory 3 described in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the above embodiment of the present application may be applied to the processor 2 or implemented by the processor 2. The processor 2 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 2 or by instructions in the form of software. The processor 2 described above may be a general purpose processor, DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 2 may implement or perform the methods, steps and logic blocks disclosed in embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiment of the application can be directly embodied in the hardware of the decoding processor or can be implemented by combining hardware and software modules in the decoding processor. The software modules may be located in a storage medium in the memory 3 and the processor 2 reads the program in the memory 3 to perform the steps of the method described above in connection with its hardware.

The corresponding flow in each method of the embodiments of the present application is implemented when the processor 2 executes the program, and for brevity, will not be described in detail herein.

In an exemplary embodiment, the present application also provides a storage medium, i.e. a computer storage medium, in particular a computer readable storage medium, for example comprising a memory 3 storing a computer program executable by the processor 2 for performing the steps of the method described above. The computer readable storage medium may be FRAM, ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, CD-ROM, etc.

Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware associated with program instructions, where the foregoing program may be stored in a computer readable storage medium, and when executed, the program performs steps including the above method embodiments; and the aforementioned storage medium includes: a removable storage device, ROM, RAM, magnetic or optical disk, or other medium capable of storing program code.

Alternatively, the above-described integrated units of the present application may be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as separate products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied essentially or in part in the form of a software product stored in a storage medium, including instructions for causing an electronic device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, ROM, RAM, magnetic or optical disk, or other medium capable of storing program code.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An assembly code generation method, comprising:

generating a corresponding macro definition for constants and registers to be used by using RISC-V assembly codes in an assembly code generator, and generating a macro definition of an objective function according to a required function by using the RISC-V assembly codes; macro definition is carried out on the constant and the register through a # definition statement in RISC-V assembly code, and macro definition is carried out on the objective function by using a. Macro and a. Endm in RISC-V assembly code;

generating main assembly code based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file by using RISC-V assembly code, wherein the main assembly code is used for realizing the function;

And precompiled the main assembly code by a compiler, performing text replacement according to the macro definition to form assembly source code, and compiling the assembly source code.

2. The assembly code generating method according to claim 1, wherein if the macro definition of the objective function includes a jump mark, the generating the macro definition of the objective function according to the required function using RISC-V assembly code further comprises:

3. The assembly code generating method according to claim 1, wherein the master assembly code sequentially uses registers from a register with a smallest number in a direction of increasing the number, the global register sequentially uses registers from a register with a largest number to a register with a number n in a direction of decreasing the number, and the registers are sequentially used from a register with a number n-1 in a macro definition of the function in a direction of decreasing the number;

4. The method of generating assembly code according to claim 1, wherein the macro definition of the objective function includes a first assembly code, a second assembly code and a third assembly code, which are sequentially arranged, the first assembly code is used for storing a value of a register to be used to a preset location of a memory, the second assembly code is used for implementing a required function, and the third assembly code is used for restoring the value of the register in the preset location to the register.

5. The assembly code generation method according to claim 1, wherein the generating a macro definition of an objective function according to a desired function using RISC-V assembly code comprises:

generating macro definition of the objective function according to the required function by using RISC-V assembly code through the head file guard;

6. The assembly code generation method of claim 1, further comprising:

7. The assembly code generation method according to claim 6, wherein extracting macro definition names from files other than intermediate files in the compiling process includes:

8. An assembly code generation apparatus, comprising:

the generating module is used for generating corresponding macro definitions for constants and registers to be used by using RISC-V assembly codes in the assembly code generator, and generating macro definitions of the objective function according to the required function by using the RISC-V assembly codes; macro definition is carried out on the constant and the register through a # definition statement in RISC-V assembly code, and macro definition is carried out on the objective function by using a. Macro and a. Endm in RISC-V assembly code;

the generating module is used for generating main assembly codes by using RISC-V assembly codes based on the macro definition of the constant, the macro definition of the register and the macro definition of the objective function in the header file, wherein the main assembly codes are used for realizing the function;

and the compiling module is used for precompiling the main assembly code by utilizing a compiler, replacing texts according to macro definitions to form assembly source code, and compiling the assembly source code.

9. An electronic device, comprising:

a memory for storing a computer program;

a processor for implementing the steps of the assembly code generation method according to any one of claims 1 to 7 when executing the computer program.

10. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the assembly code generation method according to any of claims 1 to 7.