KR101225577B1 - Apparatus and method for analyzing assembly language code - Google Patents

Abstract

An apparatus for analyzing assembly language code, the apparatus comprising: a storage module for storing dependency protocol information on a processing means of assembly language; An input module to which assembly language code including one or more instructions is input; And an analysis module for analyzing the input assembly language code according to the dependency agreement information to determine a portion corresponding to an error or a performance degradation factor in the assembly language code. By using the analysis device of the assembly language code, a developer can easily write a high performance assembly language code optimized for a corresponding processing means.

Description

Apparatus and method for analyzing assembly language code {APPARATUS AND METHOD FOR ANALYZING ASSEMBLY LANGUAGE CODE}

Embodiments relate to an apparatus and method for analyzing assembly language code.

Assembly language programming is used to write programs that are system-sensitive or performance sensitive. For example, operating system (OS) programs require the setting of caches and virtual memory addresses, which cannot be expressed in higher-level languages such as C or C ++ and are not centralized. Controllable only through assembly instructions provided by the Processing Unit (CPU). Therefore, these functions are programmed using the assembly language provided by the CPU. In addition, when the CPU does not provide a large amount of operations such as multiplication or division as an instruction, a library function that provides these operations is used to create a related program. When programming these library functions, developers are programming in assembly language optimized for the CPU for better performance.

However, existing assembly language programming tools only provide the ability to examine the grammatical parts of written assembly language code. Because of this, if you are programming in assembly language as described above, writing a program optimized for that CPU is error-prone and time-consuming unless you are skilled at the instructions and architecture of that CPU. It is a difficult task to become a reality.

According to an aspect of the present invention, when writing a program in an assembly language (assembly) to analyze the problems that may be impaired the performance of the assembly language code written to provide a developer to enable assembly programming for better performance An apparatus and method for analyzing assembly language code can be provided.

According to an embodiment, an apparatus for analyzing assembly language code may include: a storage module configured to store dependency protocol information on a processing means of assembly language; An input module to which assembly language code including one or more instructions is input; And an analysis module for analyzing the input assembly language code according to the dependency agreement information to determine a portion corresponding to an error or a performance degradation factor in the assembly language code.

According to an embodiment, a method of analyzing assembly language code may include: receiving assembly language code including one or more instructions; Analyzing the received assembly language code according to dependency agreement information on a processing means of pre-stored assembly language; And determining a part corresponding to an error or a performance degradation factor in the assembly language code.

Using an apparatus and method for analyzing assembly language codes according to an aspect of the present invention, inputted assembly language codes may be added to dependency protocol information of a central processing unit (CPU) initially input. Based on the analysis results, errors or performance degradation factors can be identified and reported to the developer. Therefore, the developer can easily write high performance assembly language code optimized for the CPU.

1 is a block diagram of an apparatus for analyzing assembly language code, according to an exemplary embodiment.
2 is a schematic diagram illustrating an output screen of an apparatus for analyzing assembly language code, according to an exemplary embodiment.
3 is a flowchart illustrating a method of analyzing assembly language code, according to an exemplary embodiment.
4 is a schematic diagram illustrating a graph generated during an analysis of assembly language code, according to an exemplary embodiment.

Hereinafter, with reference to the drawings will be described in detail an embodiment of the present invention. However, the present invention is not limited by the following examples.

Embodiments described herein may have aspects that are wholly hardware, partly hardware and partly software, or wholly software. As used herein, "unit", "module", "device" or "system" and the like refer to hardware, a combination of hardware and software, or a computer related entity such as software. For example, parts, modules, devices, or systems herein refer to running processes, processors, objects, executables, threads of execution, programs, and / or computers. computer, but is not limited thereto. For example, both an application running on a computer and a computer may correspond to a part, module, device, system, or the like herein.

1 is a block diagram of an apparatus for analyzing assembly language code, according to an exemplary embodiment.

Referring to FIG. 1, an apparatus for analyzing assembly language code may include an input module 10, a storage module 20, and an analysis module 30. Further, in one embodiment, the apparatus for analyzing assembly language code may further include an output module 40. Each of the above modules 10, 20, 30, and 40 may be connected to each other by wire and / or wirelessly.

The input module 10 is a part into which assembly language code written by a developer is input. For example, input module 10 may include a keyboard or other suitable input device capable of entering assembly language code. In addition, dependency protocol information on processing means of the assembly language may be input through the input module 10 as described below.

The storage module 20 is a part in which dependency agreement information on processing means of the assembly language is stored for analysis of assembly language code input to the input module 10. Processing means may refer to a central processing unit (CPU) or other suitable processor of a computer. The dependency protocol information may be stored in the form of a file in which a type of a register, information on factors that may cause an error, or a performance degradation may be recorded. The dependency agreement information may be generated in advance and stored in the storage module 20, or / or input through the input module 10 and stored in the storage module 20.

The analysis module 30 is a part for analyzing the assembly language code input to the input module 10 using the dependency protocol information stored in the storage module 20. Through this analysis, it is possible to find out which parts of the input assembly language code correspond to errors or performance degradation factors. In one embodiment, the analysis module 30 may include a graph generator 31 and a graph analyzer 32.

The graph generator 31 is a part that generates a graph corresponding to the assembly language code input to the input module 10. The graph generator 31 may record the instructions described in each line of the assembly language code by dividing them into an operator (opcode) indicating an operation of the instruction and an operand which is an operand used for the operation. In addition, the graph generator 31 may convert each analyzed command into a node on the graph, and a node may be added to the graph whenever a line of assembly language code is input. The graph will be described later in detail.

The graph analyzer 32 may analyze a graph generated by the graph generator 31 to determine a part corresponding to an error or a performance degradation factor in the assembly language code. That is, the graph analyzer 32 may find an instruction corresponding to an error or a performance deterioration factor by analyzing a dependency between previously input assembly language codes and currently input assembly language codes using the graph. .

The output module 40 may output a command determined as a part corresponding to an error or a performance degradation factor of the assembly language code by the analysis module 30. For example, when an error or a performance degradation is expected in the assembly language code input as a result of the analysis by the analysis module 30, the output module 40 may output information of an instruction related to the error or performance degradation on the screen. The developer can immediately identify an error or performance deterioration part in the assembly language code being written through the output module 40 and improve the problem part.

2 is a schematic diagram illustrating an output screen of an apparatus for analyzing assembly language code, according to an exemplary embodiment. Referring to FIG. 2, the output screen of the apparatus for analyzing the assembly language code may include a first screen 210 and a second screen 220. The assembly screen code input by the developer may be displayed on the first screen 210. The second screen 220 may display a cause that may cause an error or a performance degradation and an assembly language code related to the cause, which are obtained by analyzing the assembly language code produced to date.

For example, the following message may be displayed on the second screen 220: "warning: line 20-> expected pipeline stall". The above message indicates that a pipeline stall may occur due to the instruction written on line 20 of the assembly language code written so far. However, the above output screens and messages are merely exemplary, and the output form of the analysis result in the analysis device of the assembly language code is not limited to the above, and may be output in various other forms in which the developer can easily check the analysis result. .

3 is a flowchart illustrating each step of a method of analyzing assembly language code, according to an exemplary embodiment.

Referring to FIG. 3, dependency agreement information on a processing means (eg, a CPU) of an assembly language to be written first may be input (S1). For example, the dependency agreement information may be input through an input means such as a keyboard and stored in a separate storage means. However, in another embodiment, the dependency agreement information may be stored in advance instead of being input, in which case the above-described step of inputting the dependency agreement information S1 may be omitted.

The dependency protocol information may describe the characteristics of each instruction in assembly language code. For example, the dependency protocol information may include attributes of each instruction such as an integer arithmetic instruction, a decimal arithmetic instruction, a bit arithmetic instruction, a memory access instruction, or a branch related instruction. The dependency protocol information may include the time taken for each instruction to be executed (for example, a cycle of a CPU). In addition, the dependency protocol information may include dependency information related to attributes of each instruction. For example, information about how many cycles to wait when a branch instruction comes after a memory access instruction is included. In addition, the dependency agreement information may include a CPU register set.

The dependency agreement information described above is merely exemplary, and the information included in the dependency agreement information is not limited to the above. In addition, some of the dependency protocol information may be common to all kinds of CPU, while some other information may be specific to the specific type of CPU.

Next, the assembly language code to be analyzed may be input (S2). For example, a developer can write assembly language code via a keyboard or other suitable input means. The input assembly language code includes one or more instructions, and each line of assembly language code corresponds to one instruction. Unlike high-level languages such as C or C ++, assembly language code specifies a corresponding action for each line, that is, each instruction, so that assembly language code can be analyzed on a line-by-line basis as described below.

Next, each instruction of the input assembly language code is analyzed into an operator (opcode) representing the operation of the instruction and an operand which is an operand used in the operation (S3), and each analyzed instruction is a node on the graph. Can be converted to (S4). The above processes S3 and S4 may be performed in units of instructions in the assembly language code, that is, in units of lines of the assembly language code. Therefore, whenever a line of assembly language code is input, a node corresponding to the line may be added to the graph.

Specifically, first, after dividing an instruction into an operator and an address unit, it is possible to find out what attribute each separated instruction has through the above-described dependency protocol information. Next, a command separated in the current step may be added to the graph of previously input commands by characteristics. In this case, the added instruction may be appropriately disposed on the graph in consideration of the control flow corresponding to the order in which the instructions are executed, the data flow corresponding to the dependence of the operands, and the dependency between the instruction attributes. .

4 is a schematic diagram illustrating a graph generated during an analysis of assembly language code, according to an exemplary embodiment. 4 illustrates a graph generated corresponding to the assembly language code as shown in Table 1 below.

1: _dvisi3: 2: add r1, r5, # 0 3: eor ip, r0, r1 4: cmp r3, r1 5: bls L111

Referring to FIG. 4, the graph includes nodes 401, 402, 403, 404, 405 corresponding to each line (ie, each instruction) of the assembly language code described in Table 1. The edges 411 to 414 and 421 to 422 displayed between the nodes represent the dependencies between the respective commands according to the dependency agreement input in step S1 described above. Solid edges 411, 412, 413, 414 represent control flow dependence, and dotted lines 421, 422 represent data flow dependence.

Next, by analyzing the graph generated by the above process can analyze the error or performance degradation factor (S5). That is, by using the solid and dashed edges between the nodes of the graph generated in the above-described steps S3 and S4, the dependency between previously written assembly language codes and the currently input assembly language code is analyzed in advance. An instruction corresponding to an error or a performance degradation factor may be detected based on the stored dependency protocol information. An example of a process of detecting an error or a performance degradation factor using edge and dependency protocol information of a graph will be described as follows.

For ARM CPUs, the dependency protocol may include the time it takes to complete the execution of the ldr instruction, which reads a value from a memory address into a register. For example, if the dependency protocol defines that the time is four cycles, instructions that use the register containing the result of the ldr instruction as an operand must use the result of the ldr instruction after four cycles to prevent stalling of the pipeline. It becomes possible. In this case, it is assumed that the assembly language code shown in Table 2 below is input.

1: Ldr r0, label 2: Add r1, r0, r2

The first line of the assembly language code shown in Table 2 reads the contents of the label memory address into the r0 register. The second line adds the contents of the r0 and r2 registers to the r1 register. Each line command is added as a node on the graph, and the node corresponding to the ldr command and the node corresponding to the add command are connected by a solid edge indicating the execution order. In addition, since the register r0 read by the ldr command is used in the add command, the node corresponding to the ldr command and the node corresponding to the add command are also connected to the dotted edge indicating the data flow. Each instruction is executed sequentially in units of one cycle. If you write assembly language code to use r0, the result of the ldr instruction, directly in the next instruction, add, as shown in Table 2, r0, the result of the ldr instruction, is used when the add instruction is executed when the assembly language code is executed by the real CPU. This prevents the pipeline from stalling, or stalling, in the CPU until r0 is available to the add instruction.

In order to prevent this, a command corresponding to an error or a performance deterioration factor may be detected using the dependency between each node of the graph (S5). For example, if you analyze the node corresponding to the add instruction, the node is connected by the edge to the node corresponding to the ldr instruction, so that the assembly language code that causes the add instruction following the ldr instruction to use the result of the ldr instruction is entered. It can be seen through the solid and dashed edges between the nodes. Next, the factor of performance degradation may be determined by referring to the time taken to complete the execution of the ldr command in the dependency protocol information. That is, in the case of the assembly language code shown in Table 2, the add instruction described in the second line corresponds to the performance degradation factor.

Next, when there is a node that is determined to have an error or a performance deterioration factor as a result of graph analysis using the dependency protocol information, information of an instruction related to the error or performance deterioration factor may be output (S6). For example, information on the cause of error or performance degradation and the assembly language code in which the cause is located may be displayed on a screen so that a developer may know. When the next line of assembly language code is input by the developer, the process returns to step S2, and the above-described processes S2 to S6 may be repeated for the newly input assembly language code.

By doing the above while the assembly language code is being written by the developer, you can immediately report any errors or performance degradations to the developer when the assembly language code is written. Therefore, the developer can easily write high performance assembly language code optimized for the CPU. In addition, the dependencies between each instruction are analyzed using graphs generated by considering the characteristics of each instruction (for example, control flow and data flow), so that all instructions are checked to see whether a specific instruction corresponds to an error or a performance degradation factor. It is possible to analyze only the commands associated with each characteristic without having to analyze it, thereby reducing the time required for analysis.

Apparatus and method of analyzing assembly language code described herein, or any aspect or portion thereof, may be any tangible medium, such as a floppy diskette, CD-ROM, DVD, hard disk drive, or any other computer readable recording medium. It may be implemented in the form of program code (ie, instructions) included in. The program code is loaded and executed in a device such as a computer, wherein the device corresponds to an apparatus for implementing the present invention.

Although the present invention described above has been described with reference to the embodiments illustrated in the drawings, this is merely exemplary, and it will be understood by those skilled in the art that various modifications and variations may be made therefrom. However, such modifications should be considered to be within the technical protection scope of the present invention. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

Claims (12)

A storage module for storing dependency protocol information on the processing means of the assembly language;
An input module to which assembly language code including one or more instructions is input; And
And an analysis module for analyzing the input assembly language code according to the dependency agreement information to determine a portion corresponding to an error or a performance degradation factor in the assembly language code.
The method of claim 1,
The analysis module,
A graph generator configured to generate a graph having at least one node corresponding to each of the at least one command by using the dependency protocol information; And
And a graph analyzer configured to analyze the dependencies between the nodes to determine a command corresponding to an error or a performance deterioration factor.
The method of claim 2,
And the graph generator divides each of the one or more instructions into an operator and an address unit.
The method of claim 1,
And the dependency protocol information is input to the input module and stored in the storage module.
The method of claim 1,
And an output module for displaying a portion corresponding to an error or a performance degradation factor in the assembly language code.
The method of claim 1,
The dependency protocol information may include at least one of an attribute of each instruction of an assembly language, a time taken for each instruction to be executed, dependency information related to an attribute of each instruction, and register set information of a processing means. Analysis device.
Receiving an assembly language code comprising one or more instructions;
Analyzing the received assembly language code according to dependency agreement information on a processing means of pre-stored assembly language; And
And determining a part corresponding to an error or a performance degradation factor in the assembly language code.
8. The method of claim 7,
Analyzing according to the dependency protocol information,
Generating a graph having one or more nodes corresponding to each of the one or more instructions using the dependency protocol information; And
Analyzing the dependencies between the nodes to determine an instruction corresponding to an error or a performance deterioration factor.
The method of claim 8,
The generating of the graph may include dividing each of the one or more instructions into an operator and an address unit.
8. The method of claim 7,
And before receiving the assembly language code, receiving the dependency protocol information.
8. The method of claim 7,
And outputting a portion corresponding to an error or a performance deterioration factor in the assembly language code.
8. The method of claim 7,
The dependency protocol information may include at least one of an attribute of each instruction of an assembly language, a time taken for each instruction to be executed, dependency information related to an attribute of each instruction, and register set information of a processing means. Analytical Method.

Images