WO2011024554A1 - アセンブル装置、構文解析方法、及びアセンブラプログラム - Google Patents

アセンブル装置、構文解析方法、及びアセンブラプログラム Download PDF

Info

Publication number
WO2011024554A1
WO2011024554A1 PCT/JP2010/061219 JP2010061219W WO2011024554A1 WO 2011024554 A1 WO2011024554 A1 WO 2011024554A1 JP 2010061219 W JP2010061219 W JP 2010061219W WO 2011024554 A1 WO2011024554 A1 WO 2011024554A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
character
operand
tokens
instruction
Prior art date
Application number
PCT/JP2010/061219
Other languages
English (en)
French (fr)
Inventor
孝寛 久村
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2011528694A priority Critical patent/JP5413623B2/ja
Publication of WO2011024554A1 publication Critical patent/WO2011024554A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing

Definitions

  • the present invention relates to an assembler for translating a program for a processor into a machine language, and more particularly to a general-purpose assembler that can handle various instruction description styles, a lexical analysis method, and a syntax analysis method.
  • the assembler is software for translating a processor program such as a CPU (CENTRAL PROCESSING UNIT) and a DSP (DIGITAL SIGNAL PROCESSOR) into a machine language.
  • the program is described in a language called assembly language.
  • the assembly language is a language that can directly describe instructions of the processor.
  • processor instruction description styles for each CPU and DSP, but they can generally be classified into the following three formats. Mnemonic format: “mnemonic operating 0, operand 1,...
  • the mnemonic format is a description style in which an instruction is expressed using a character string representing the name of an instruction called mnemonic and a plurality of operands.
  • the function format is a description style in which instructions are expressed in a format like a C function call.
  • the arithmetic format is a description style in which instructions are expressed in a format such as C language operations (four arithmetic operations, logical operations, etc.).
  • an operand for storing the operation result is specified, and the operation of the instruction is easier to understand than in the mnemonic format.
  • an instruction description style (grammar) is generally determined, and then an assembler is developed in accordance with the description style. In other words, if the processor description style is changed or modified, the assembler needs to be developed again.
  • the programmer can create a parser that matches the grammar using, for example, a manual work or a tool called yacc / lex.
  • Related techniques related to the assembler are described in Japanese Patent Application Laid-Open No.
  • Patent Document 1 8-286927
  • Patent Document 2 Japanese Patent Application Laid-Open No. 6-259261
  • the assembler described in Patent Document 1 uses instructions related to syntax and fields of instructions stored in a database, and a processor assembles instructions. Since this method stores information related to instructions in a database, it can cope with various instructions only by changing the instruction information in the database.
  • the assembler mnemonic syntax analysis method described in Patent Document 2 reads a source program including instructions described in an arithmetic form, decomposes and analyzes the instruction character string into tokens, and generates a code.
  • the assembler of Patent Document 1 supports only a mnemonic description style, and does not support other description styles.
  • the mnemonic parsing processing method disclosed in Patent Document 2 supports only arithmetic style description styles and does not support other description styles. That is, the assemblers of Patent Document 1 and Patent Document 2 are not versatile with respect to the instruction description style. Therefore, in these methods, it is necessary to recreate a parser for each description style.
  • One of the challenges in the assembler is to support various instruction writing styles with a single parser. With such a parser, a single parser can be used in common regardless of the instruction description style.
  • the present invention provides an assembling apparatus and a syntax analysis method having a syntax analyzer that can correspond to an instruction description format of a mnemonic format, a function format, and an arithmetic format.
  • the assembling apparatus includes a token information table that represents a configuration pattern of words (tokens) and operand variables that constitute a description format (syntax) of each instruction, and operand information that represents the meaning of operand variables and candidate tokens.
  • a parsing unit that searches the token information table.
  • an assembler a syntax analysis method, a storage medium, and an assembler program for realizing a syntax analyzer that can handle a mnemonic format, a function format, and an arithmetic instruction description format.
  • FIG. 1 is a functional block diagram illustrating configurations of an assembler 100 and a parsing unit 110 in an exemplary embodiment of the invention.
  • FIG. 2 is a flowchart showing the processing of the assembler 100.
  • FIG. 3 is a flowchart showing the processing of step S3 “token decomposition”.
  • FIG. 4 is an explanatory diagram showing the process of acquiring one character from the input character string in step S32.
  • FIG. 5 is an explanatory diagram showing the relationship between the character extracted from the input character string and the character type in step S33 “character type determination”.
  • FIG. 6 is an explanatory diagram showing the state transition of token boundary determination in step S34 “token boundary determination”.
  • FIG. 7 is an explanatory diagram showing the processing content of “start position shift” in FIG.
  • FIG. 8A and 8B are explanatory diagrams showing the processing content of “token extraction” in FIG.
  • FIG. 9 is an explanatory diagram showing the processing contents of the “character return” in FIG.
  • FIG. 10 is a flowchart showing the processing of step S4 “token information matching”.
  • FIG. 11 is an explanatory diagram showing the processing content of step S45 “character string match check”.
  • FIG. 12 is an explanatory diagram showing the processing content of step S46 “semantic match check”.
  • FIG. 13 is an explanatory diagram illustrating an example of the source file 200 of FIG. 14A and 14B are explanatory diagrams illustrating examples of instruction syntax.
  • 15A and 15B are explanatory diagrams illustrating examples of the token information table 130.
  • FIG. FIG. 16 is an explanatory diagram illustrating an example of the operand information table 140.
  • FIG. 17 is an explanatory diagram illustrating an example of the operation code table 150.
  • FIG. 18 is a block diagram illustrating a configuration example of
  • an assembler 100 that is an exemplary embodiment of the present invention includes a line decomposition unit 111, a parsing unit 110, an instruction encoder 120, a token information table 130, an operand information table 140, and an opcode. And a table 150.
  • the assembler 100 is configured as a program that operates on a personal computer (PC: PERSONAL COMPUTER) (not shown), and each component of the assembler 100 may be part of the program.
  • PC personal computer
  • the assembler 100 and the source file 200 are stored in a storage unit (not shown) of the PC, and the PC CPU takes the assembler 100 and the source file 200 as a trigger in response to a predetermined instruction from the user.
  • the data is read from the storage unit, the assembler 100 is executed, the object file 300 is generated from the source file 200, and the object file 300 is stored in the storage unit.
  • the assembler 100 according to the present invention is expanded in the storage unit of the information processing apparatus, and operates the CPU as each unit according to the present invention on the basis of the assemble execution operation on the input unit of the operator.
  • the lexical analysis and syntax analysis are performed on the object file, and the object file 300 can be output by assembling.
  • the converted object file 300 is recorded as a code in a microcomputer, displayed on a screen as necessary, printed on paper using a printer, or stored in an external storage device.
  • the line decomposition unit 111 extracts a character string 112 for one line from the source file 200 and supplies it to the parsing unit 110.
  • the parsing unit 110 examines the instruction ID and operand value of the instruction included in the character string 112 for one line, and provides them to the instruction encoder 120.
  • the parsing unit 110 includes a token decomposition unit 113 and a matching unit 115.
  • the token decomposing unit 113 decomposes the character string 112 for one line into a plurality of tokens, and provides the matching unit 115 with information on the plurality of tokens (token information 114).
  • the matching unit 115 searches the token information table 130 for a match with the token information 114, obtains the instruction ID of the token information, and from the operand information table 140, the operand included in the token information 114 Get the value (operand value) of.
  • the instruction encoder 120 calculates an instruction code by referring to the operation code table 150 from the instruction ID and the operand value, and adds the instruction code to the object file 300.
  • the assembler 100 extracts the character string 112 for one line from the source file 200 and adds the instruction code of the instruction included in the character string 112 for one line to the object file 300. Repeat until the instruction is processed.
  • processing operations based on the assembler 100 operating on the personal computer will be described.
  • description is simplified or abbreviate
  • the operation of the CPU based on the assembler 100 is described as being performed by the assembler 100.
  • ⁇ Processing flow of assembler 100> The processing flow of the assembler 100 in the first embodiment will be described with reference to FIG.
  • the assembler 100 repeats the five steps from step S1 to step S5.
  • step S1 the assembler 100 checks whether or not an unprocessed character string (line) remains in the source file 200 (see FIG. 1) that is an input file. The assembler 100 proceeds to step S2 if an unprocessed character string remains in the source file 200, and ends the process otherwise.
  • step S ⁇ b> 2 the assembler 100 acquires a character string for one line including an instruction from the head position of an unprocessed character string in the source file 200. If the character string for one line at the head position of the unprocessed character string is a comment or a blank line, the assembler 100 reads the comment or blank line until it can obtain the character string for one line including the instruction. Fly.
  • FIG. 13 is an example of the source file 200. In FIG.
  • a line starting from # is a comment
  • a line other than the comment line and the blank line is a line including an instruction
  • the line including the instruction is a character string acquired in step S ⁇ b> 2.
  • the assembler 100 decomposes the character string for one line into a plurality of tokens. These multiple tokens are called unknown instruction tokens.
  • a token is a word constituting an instruction character string. The token will be described in detail later.
  • step S ⁇ b> 4 the assembler 100 compares the token of the unknown instruction with reference to various tables related to the known instruction, compares the token with the known instruction, and obtains the instruction ID of the unknown instruction and the value of the operand. This comparison procedure will be described in detail later.
  • step S5 the assembler 100 calculates the instruction code of the unknown instruction from the instruction ID of the unknown instruction and the operand value, and adds the instruction code to the object file 300 (see FIG. 1).
  • the instruction code includes an operation code that is uniquely defined by the instruction ID and an operand value that varies depending on the character string of the operand.
  • the instruction encoder 120 in charge of instruction encoding acquires an operation code corresponding to the instruction ID of the unknown instruction from the operation code table 150. Based on this opcode and the value of the operand obtained in step S4, the instruction encoder 120 calculates the instruction code of the unknown instruction.
  • the assembler 100 moves to step S1 to process an unknown instruction in the next unprocessed line of the source file 200.
  • FIG. 17 is an example of the operation code table 150.
  • the instruction ID, instruction word length (number of bits), operation code, number of operands, bit length and bit position of each operand are recorded for each instruction.
  • an instruction with an instruction ID of ADD has an instruction word length of 32 bits, an operation code of “0x10100000”, three operands, each operand having a length of 4 bits, It can be seen that the operand is arranged in 12 bits from bit 0 to bit 11.
  • the instruction encoder 120 encodes the instruction using information of a list of known operation codes as illustrated in FIG.
  • FIG. 14A shows the instruction ID, syntax, and description of each instruction.
  • the instruction ID is like the name of each instruction, and each instruction is distinguished using the instruction ID.
  • the instruction syntax is a character string representing the instruction description format.
  • the instruction syntax is composed of character strings such as operand variables and symbols.
  • the operand variable is a variable representing an instruction operand (register, numeric value, etc.), and represents the position where the operand should be described in the instruction syntax and the meaning of the operand.
  • the assembler 100 uses a token information table 130 and an operand information table 140 to parse and parse instructions such as those in FIGS. 14A and 14B.
  • the token information table 130 is a table that stores information about tokens included in the syntax of instructions.
  • a token is a word that is a component of the syntax of an instruction.
  • the syntax of the instruction is composed of a plurality of tokens.
  • FIG. 15B there are four types of instruction syntax tokens: operand variables, symbols, numerical values, and symbols.
  • An operand variable is a token that represents an operand.
  • Operand variables have names (character strings) starting with “%”.
  • FIG. 15A is an example of the token information table 130.
  • the example shown in FIG. 15A is information on tokens that form the syntax of each instruction shown in FIGS. 14A and 14B.
  • FIG. 16 shows an example of the operand information table 140.
  • the type of operand variable represents the type of operand.
  • the type of the operand variable indicates whether the operand applicable to the operand variable is a register or an immediate value.
  • the token candidate represents a token candidate applicable to the operand variable. For example, if the type of the operand variable is a register, a symbol token representing the name of a register that applies to the operand variable is a candidate token.
  • Step S3 Token decomposition>
  • the “token decomposition” process in step S3 (see FIG. 2) will be described in detail with reference to FIG. Step S3 includes four steps of steps S31 to S34.
  • the token decomposing unit 113 (see FIG. 1) checks whether or not an unprocessed character remains in the character string (input character string) for one line, and if it remains, moves to step S32. If not, step S3 is terminated.
  • step S32 the token decomposition unit 113 acquires one character from the input character string.
  • the process for acquiring characters is illustrated in FIG. FIG. 4 shows input character strings and auxiliary information before and after the first character is acquired.
  • the auxiliary information is a character string acquisition position and a token head position.
  • the character string acquisition position represents a position where the token decomposition unit 113 acquires characters.
  • the token head position represents the head position of the current token.
  • the token decomposition unit 113 acquires one character from the character string acquisition position, and then moves the character acquisition position by one character in the line end direction. In the example of FIG.
  • step S33 the token decomposition unit 113 determines the character type of the acquired character.
  • the character types are shown in FIG.
  • the token decomposing unit 113 determines the character type based on the state of the token boundary determination in the next step S34.
  • the state of token boundary determination will be described in detail later.
  • FIG. 5 shows which character type the acquired character is classified based on the token boundary determination state. There are the following five types of characters.
  • Symbol head character A character that represents the head of a symbol (character string composed of alphabets, numbers, and underscores)
  • Symbol character Character other than the beginning of the symbol
  • Number Characters representing numerical values
  • Space characters Characters representing spaces and tabs
  • Symbol characters Characters other than alphabets, numbers, underscores, spaces, etc.
  • the token decomposing unit 113 determines whether or not the acquired character string is a part of a new token based on the current token boundary determination state and the acquired character type.
  • the token decomposition unit 113 has the following three states called token boundary determination states.
  • -Null state Initial state. State that the token of the character string starting from the token start position is unknown
  • Numeric state A state that indicates that the character string starting from the token start position is a numeric token.
  • Symbol state State that indicates that the character string starting from the token start position is a symbol token
  • the token boundary determination state is “null state”.
  • step S34 the token decomposing unit 113 determines whether the acquired character is part of a new token, and then changes the token boundary determination state.
  • the transition of the token boundary determination state is shown in FIG.
  • the state indicated by a circle indicates the state
  • the process indicated by the square indicates processing executed by the token decomposition unit 113.
  • the token decomposition unit 113 transitions the state to the symbol state in accordance with the arrow extending from above the null state in FIG.
  • the token decomposing unit 113 executes the square processing in the state where the arrow starts. For example, when the character acquired in the null state is a blank character, the token disassembly unit 113 selects an arrow extending from the top of the null state in FIG. Then, it returns to the null state again. For other states (symbol state and numerical state), the token disassembling unit 113 operates similarly.
  • FIG. 6 there are three types of processing represented by square boxes. The contents of this processing will be described. ⁇ Start position movement ⁇ Token extraction ⁇ Character return FIG. 7 shows the processing content of “start position shift”.
  • the token disassembly unit 113 moves the token start position to the character acquisition position.
  • the token head position at the beginning of the line has been moved from the beginning of the line to the right by two characters. This process is called in one of the following three cases. -When a blank character is acquired in the null state ⁇ When the symbol character is acquired in the null state ⁇ After the “character return” process from the symbol state or numerical state When a blank character is acquired in the null state, the token decomposition unit 113 moves the token head position without extracting a new token. This is to ignore white space characters. In the other two cases, the token decomposition unit 113 extracts a new token and then moves the token head position.
  • the processing content of “token extraction” is shown in FIG. 8A.
  • the token decomposing unit 113 performs a process of regarding a character string from the token start position to one character before the character acquisition position as one token. Based on the state of the token boundary determination at this time, the token decomposing unit 113 determines the type of this new token.
  • the relationship between the token boundary determination state and the token type is as shown in the table of FIG. 8B. That is, if the token boundary determination state is null, the new token is a symbol token. Similarly, if it is a numerical state, the new token is a numerical token, and if it is a symbol state, it is a symbol token.
  • FIG. 8A The processing content of “token extraction” is shown in FIG. 8A.
  • the token decomposing unit 113 performs a process of regarding a character string from the token start position to one character before the character acquisition position as one token. Based on the state of the token boundary determination at this time, the token decomposing unit 113 determines the type
  • Step S4 Token information matching>
  • “token information matching” in step S4 (see FIG. 2) will be described in detail with reference to FIG. Step S4 includes eight steps S41 to S48.
  • the token information matching process is a process of searching for an instruction that matches a configuration pattern of tokens that constitute an unknown instruction from among known instructions while referring to the token information table 130.
  • An instruction consists of one or more tokens.
  • the token information table 130 is a table having token configuration patterns and instruction IDs of all known instructions. If a known instruction having the same token configuration pattern as the token configuration pattern of the unknown instruction is found from the token information table 130, the instruction ID of the unknown instruction can be known.
  • the matching unit 115 checks whether there are any uninspected known instruction IDs. If such a known instruction ID remains, the process proceeds to step S42.
  • step S4 is terminated.
  • the matching unit 115 selects one uninspected known instruction ID and acquires token information of the known instruction from the token information table 130 (see FIG. 1).
  • the token information of the known instruction acquired at this time includes a plurality of tokens.
  • the matching unit 115 acquires one token each from the token information of the known instruction and the token information of the unknown instruction. In each of the token information of both the known instruction and the unknown instruction, numbers starting from 0 are assigned in order from the token at the head position to the end token. When acquiring tokens of a known instruction and an unknown instruction in step S43, tokens having the same number are acquired.
  • step S44 the matching unit 115 checks whether or not the token of the known instruction is a token indicating an operand variable. If it is not an operand variable, the process proceeds to step S45. If it is an operand variable, the process proceeds to step S46. To do.
  • step S45 the matching unit 115 checks whether or not the character strings of the token of the known instruction and the token of the unknown instruction exactly match, and gives the result to step S47. This “character string match inspection” in step S45 will be described in detail later.
  • step S46 the matching unit 115 checks whether the tokens of the known instruction and the unknown instruction match, and gives the result to step S47.
  • the “semantic match check” in step S46 will be described in detail later.
  • step S47 the matching unit 115 confirms the inspection result in step S45 or step S46, and if it is “match”, the process proceeds to step S48, and if it is “mismatch”, the process proceeds to step S42. Transition.
  • the transition to step S42 means that the currently selected known instruction is not an unknown instruction, and the matching unit 115 will try another known instruction.
  • step S48 the matching unit 115 confirms whether or not all tokens included in the token information of the known instruction have been checked.
  • the matching unit 115 proceeds to step S43, and the rest Check token. If not, the matching unit 115 determines that the tokens of both the known instruction and the unknown instruction all match, and sets the instruction ID of the known instruction as the instruction ID of the unknown instruction. In addition, the matching unit 115 acquires the value of the operand obtained by the “semantic match check” in step S46, and provides the instruction ID and operand value of the unknown instruction to step S5 (see FIG. 2). In the token information table 130, the number of tokens constituting each known instruction is recorded. Using the number of tokens, the matching unit 115 determines whether all tokens have been examined.
  • step S4 the matching unit 115 performs the “character string match check” in step S45 or the “semantic match check” in step S46 on all tokens, and determines the instruction ID of the unknown instruction. Extract the operand value. By doing in this way, an instruction having the same configuration pattern as the token configuration pattern constituting the unknown instruction can be found from the known instructions.
  • step S4 no precondition is used for the token configuration pattern. For example, the precondition that a character string representing a mnemonic should appear at the beginning is not used. Therefore, the matching unit 115 can specify an unknown instruction as long as the token configuration patterns match in mnemonic format, functional format, or arithmetic format.
  • the character string match check is a process for checking whether or not tokens at positions corresponding to a known instruction and an unknown instruction match as a character string.
  • the matching unit 115 performs a character string match check when the token of the known instruction does not indicate an operand variable.
  • FIG. 11 shows a process in which the matching unit 115 performs a character string matching check on the rightmost token (closer to the end of the line) of each of the known instruction and the unknown instruction. In the example shown in FIG. 11, each of the known instruction and the unknown instruction has 6 tokens.
  • the matching unit 115 performs a string match check. In FIG. 11, since the tokens on the rightmost side (closer to the end of the line) of the known instruction and the unknown instruction are both “)”, the matching unit 115 determines that the character strings of both tokens match. ⁇ Meaning check> Next, the “semantic match check” in step S46 (see FIG. 10) will be described in detail with reference to FIG.
  • the semantic matching check is a process for checking whether or not the meanings of tokens at positions corresponding to a known instruction and an unknown instruction match.
  • the matching unit 115 performs a semantic matching check when the token of the known instruction represents an operand variable.
  • meaning matches means that a token of an unknown instruction is included in a set of symbol tokens and numerical tokens (token candidates) that can be expressed by operand variables.
  • FIG. 12 shows a process in which the matching unit 115 performs a semantic matching check on the leftmost token (closer to the beginning of the line) of each of the known instruction and the unknown instruction.
  • “% op0” and “% op1” are tokens representing operand variables.
  • the matching unit 115 For each of these two tokens representing operand variables, the matching unit 115 performs a semantic match check. In FIG. 12, the matching unit 115 compares the leftmost token (% op0) of the known instruction with the leftmost symbol token “R5” of the unknown instruction, and compares it with the token that is the operand variable. It is determined whether or not the symbol token “R5” of the unknown instruction is included in the set of tokens represented by “% op0”. The matching unit 115 retrieves information related to operand variables of known instructions from the operand information table 140.
  • the operand information table 140 is a table that holds information (operand information) regarding operand variables included in the token information of each known instruction. Operand information is the following five pieces of information. 1. Instruction ID of a known instruction 2.
  • the matching unit 115 acquires the operand information of the operand variable “% op0” from the operand information table 140. Based on the operand information, it can be seen that “% op0” is an operand variable representing the R register, and the token candidates of “% op0” are symbol tokens representing the registers from “R0” to “R15”. Accordingly, the matching unit 115 determines that the leftmost symbol token “R5” of the unknown instruction is included in the set of tokens represented by the leftmost token (% op0) of the known instruction. As described above, by using the present invention, it is possible to provide one general-purpose parser that can cope with various description styles.
  • a general-purpose assembler and assembler having the parser can be provided. Since the assembling apparatus recognizes an instruction included in the input character string using the token pattern, for example, it is possible to cope with a description style in which there is no character string (token) representing the instruction at the head of the input character string. . Further, the assembling apparatus can provide an assembling function with high convenience that is not limited by changes in the processor specifications. In other words, according to the present invention, it is possible to provide an assembler, a syntax analysis method, and an assembler program having a syntax analyzer that can correspond to an instruction description format of a mnemonic format, a function format, and an arithmetic format.
  • the assembler is recorded and held on a recording medium such as an optical disc, and is read from the recording medium into a computer via the input unit, thereby operating the CPU to convert the source file into an object code and outputting it from the output unit. You may make it do.
  • the assembler may be operably recorded on a recording medium on the server, and assembly processing may be performed using the CPU or storage unit of the server.
  • the assembler is a development tool indispensable for program development for a processor such as a CPU or DSP.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

　多種の記述形式に対応可能なアセンブラ装置を提供するため、アセンブリ言語で記述されたプログラムを含む入力ファイルを読み込んで、そのプログラムのオブジェクトコードを出力するアセンブル装置に対して、各命令のシンタックスを構成するトークンやオペランド変数の構成パターンを表すトークン情報テーブルと、オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルと、入力ファイルの入力文字列を複数のトークンに分解し、オペランド情報テーブルを参照しながら、得られたトークンの構成パターンに合致するトークンの構成パターンをもつ命令をトークン情報テーブルから探索する構文解析ユニットと、を設けた。

Description

アセンブル装置、構文解析方法、及びアセンブラプログラム
　本発明は、プロセッサへのプログラムを機械語に翻訳するためのアセンブラに関し、特に、様々な命令記述スタイルに対応可能な汎用アセンブラおよび、その字句解析方法、構文解析方法に関する。
　アセンブラとは、ＣＰＵ（ＣＥＮＴＲＡＬ　ＰＲＯＣＥＳＳＩＮＧ　ＵＮＩＴ）やＤＳＰ（ＤＩＧＩＴＡＬ　ＳＩＧＮＡＬ　ＰＲＯＣＥＳＳＯＲ）などのプロセッサ用プログラムを機械語へ翻訳するためのソフトウェアである。当該プログラムはアセンブリ言語と呼ばれる言語で記述される。アセンブリ言語は、プロセッサの命令を直接記述可能な言語である。プロセッサの命令の記述スタイルは、ＣＰＵやＤＳＰ毎に様々であるが、一般的には、以下の三つの形式に分類できる。
　・ニモニック形式：“ｍｎｅｍｏｎｉｃ　ｏｐｅｒａｎｄ０，ｏｐｅｒａｎｄ１，…”
　・関数形式：“ｄｓｔ＝ｍｎｅｍｏｎｉｃ（ｓｒｃ０、ｓｒｃ１，…）”
　・算術形式：“ｄｓｔ＝ｓｒｃ０＋ｓｒｃ１”
　ニモニック形式は、ニモニック（ｍｎｅｍｏｎｉｃ）と呼ばれる命令の名前を表す文字列と、複数のオペランドを使って、命令を表記する記述スタイルである。
　関数形式は、Ｃ言語の関数呼び出しのような形式で命令を表記する記述スタイルである。
　算術形式は、Ｃ言語の演算（四則演算や論理演算など）のような形式で命令を表記する記述スタイルである。
　関数形式と算術形式では、演算結果を格納するオペランドが明記されており、ニモニック形式に比べて、命令の動作を理解し易い。
　プロセッサ毎のアセンブラの開発方法は、一般に、命令の記述スタイル（文法）を決めてから、その記述スタイルに合わせたアセンブラを開発する。換言すれば、プロセッサの記述スタイルを変更したり修正したりすると、アセンブラを再度開発する必要が生ずる。
　命令の文法が定まれば、プログラマは、例えば、手作業やｙａｃｃ／ｌｅｘというツールを使って、その文法に合わせた構文解析器を作成できる。
　アセンブラに関する関連技術は、特開平８−２８６９２７号公報（特許文献１）及び特開平６−２５９２６１号公報（特許文献２）に記載されている。
　特許文献１で説明されているアセンブラは、データベースに格納された命令のシンタックスやフィールドに関する情報をもちいて、プロセッサが命令をアセンブルする。この方式は、命令に関する情報をデータベースに格納しているため、データベースの命令情報を変更するだけで、さまざまな命令に対応可能である。
　特許文献２で説明されているアセンブラのニモニック構文解析処理方法は、算術形式で記述された命令を含むソースプログラムを読み込み、命令文字列をトークンに分解及び解析してコードを生成する。
　特許文献１のアセンブラは、ニモニック形式の記述スタイルだけに対応しており、その他の記述スタイルには対応していない。
　特許文献２のニモニック構文解析処理方法は、算術形式の記述スタイルだけに対応しており、その他の記述スタイルには対応していない。
　即ち、特許文献１及び特許文献２のアセンブラは、命令の記述スタイルに関して汎用性がない。そのため、これらの方式では、記述スタイルごとに、構文解析器を作り直す必要がある。
　ひとつの構文解析器で様々な命令の記述スタイルに対応することが、アセンブラにおける課題のひとつになっている。そのような構文解析器があれば、命令の記述スタイルに関係なく、ひとつの構文解析器を共通して使用することができる。
　本発明は、ニモニック形式と関数形式と算術形式の命令記述形式に対応できる構文解析器を有するアセンブル装置、構文解析方法を提供する。
　本発明に係るアセンブル装置は、各命令の記述形式（シンタックス）を構成する単語（トークン）やオペランド変数の構成パターンを表すトークン情報テーブルと、オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルと、アセンブル装置への入力ファイルから取り出された入力文字列を複数のトークンに分解し、オペランド情報テーブルを参照しながら、得られた前記トークンの構成パターンに合致するトークンの構成パターンをもつ命令をトークン情報テーブルから探索する構文解析ユニットと、を有することを特徴とする。
　本発明によれば、ニモニック形式と関数形式と算術形式の命令記述形式に対応できる構文解析器を実現するアセンブル装置、構文解析方法、記憶媒体およびアセンブラプログラムを提供できる。
　図１は、本発明の模範的な実施形態におけるアセンブラ１００および構文解析ユニット１１０の構成を示す機能ブロック図である。
　図２は、アセンブラ１００の処理を示すフローチャートである。
　図３は、ステップＳ３「トークン分解」の処理を示すフローチャートである。
　図４は、ステップＳ３２における、入力文字列から１文字を取得する処理を表す説明図である。
　図５は、ステップＳ３３「文字種別判定」における、入力文字列から取り出した文字と文字種別の関係を示す説明図である。
　図６は、ステップＳ３４「トークン境界判定」における、トークン境界判定の状態遷移を表す説明図である。
　図７は、図６の「先頭位置移動」の処理内容を示す説明図である。
　図８Ａ及び図８Ｂは、図６の「トークン抽出」の処理内容を示す説明図である。
　図９は、図６の「文字差し戻し」の処理内容を示す説明図である。
　図１０は、ステップＳ４「トークン情報マッチング」の処理を示すフローチャートである。
　図１１は、ステップＳ４５「文字列一致検査」の処理内容を示す説明図である。
　図１２は、ステップＳ４６「意味一致検査」の処理内容を示す説明図である。
　図１３は、図１のソースファイル２００の例を表す説明図である。
　図１４Ａ及び図１４Ｂは、命令のシンタックスの例を表す説明図である。
　図１５Ａ及び図１５Ｂは、トークン情報テーブル１３０の例を表す説明図である。
　図１６は、オペランド情報テーブル１４０の例を表す説明図である。
　図１７は、オペコードテーブル１５０の例を表す説明図である。
　図１８は、アセンブル装置の構成例を示すブロック図である。
　本発明の実施の形態について図面を参照して説明する。
　図１を参照すると、本発明の模範的な実施形態であるアセンブラ１００は、行分解ユニット１１１と、構文解析ユニット１１０と、命令エンコーダ１２０と、トークン情報テーブル１３０と、オペランド情報テーブル１４０と、オペコードテーブル１５０とを備える。
　アセンブラ１００は、パーソナルコンピュータ（ＰＣ：ＰＥＲＳＯＮＡＬ　ＣＯＭＰＵＴＥＲ）（図示せず）の上で動作するプログラムとして構成され、そして、アセンブラ１００の各構成要素はそのプログラムの一部であってもよい。その場合には、ＰＣの記憶ユニット（図示せず）に、アセンブラ１００、ソースファイル２００が格納されており、ユーザの所定の指示をきっかけとして、ＰＣのＣＰＵは、アセンブラ１００とソースファイル２００とを記憶ユニットから読み出して、アセンブラ１００を実行し、ソースファイル２００からオブジェクトファイル３００を生成し、オブジェクトファイル３００を記憶ユニットへ格納する。
　換言すれば、本発明に係るアセンブラ１００は、情報処理装置の記憶部に展開され、操作者の入力部に対するアセンブル実行操作に基づき、ＣＰＵを本発明に係る各ユニットとして動作させ、ソースファイル２００に対して字句解析および構文解析を実施し、アセンブルしてオブジェクトファイル３００を出力可能とする。変換されたオブジェクトファイル３００は、コードとしてマイコンに記録されたり、必要に応じて、画面上に表示されたり、プリンタを用いて用紙に印刷されたり、外部記憶装置に格納される。
　次に、アセンブラ１００の各構成要素について説明する。
　行分解ユニット１１１は、ソースファイル２００から一行分の文字列１１２を取り出し、それを構文解析ユニット１１０へ与える。
　構文解析ユニット１１０は、一行分の文字列１１２に含まれる命令の命令ＩＤとオペランド値を調査し、それらを命令エンコーダ１２０へ与える。構文解析ユニット１１０は、トークン分解ユニット１１３とマッチングユニット１１５を備えている。トークン分解ユニット１１３は、一行分の文字列１１２を複数のトークンに分解し、複数のトークンの情報（トークン情報１１４）をマッチングユニット１１５へ与える。マッチングユニット１１５は、トークン情報テーブル１３０の中から、トークン情報１１４に一致するものを探索し、そのトークン情報の命令ＩＤを取得すると共に、オペランド情報テーブル１４０の中から、トークン情報１１４に含まれるオペランドの値（オペランド値）を取得する。
　命令エンコーダ１２０は、命令ＩＤとオペランド値から、オペコードテーブル１５０を参照して命令コードを算出し、その命令コードをオブジェクトファイル３００に追加する。
　アセンブラ１００は、ソースファイル２００から一行分の文字列１１２を取り出して、一行分の文字列１１２に含まれる命令の命令コードをオブジェクトファイル３００へ追加するという処理を、ソースファイル２００に含まれる全ての命令を処理するまで繰り返す。
　次に、パーソナルコンピュータ上で動作するアセンブラ１００に基づく処理動作を説明する。なお、本発明と関係の薄い内容については、記載を簡略化又は省略する。なお、以下の説明では、アセンブラ１００に基づくＣＰＵの動作をアセンブラ１００が行なうこととして記載する。
＜アセンブラ１００の処理の流れ＞
　図２を参照しながら、第一の実施形態におけるアセンブラ１００の処理の流れを説明する。アセンブラ１００は、ステップＳ１からＳ５までの五つのステップを繰り返す。
　ステップＳ１において、アセンブラ１００は、入力ファイルであるソースファイル２００（図１参照）に、未処理の文字列（行）が残っているか否かを検査する。アセンブラ１００は、もしソースファイル２００に未処理の文字列が残っているならばステップＳ２へ、そうでなければ処理を終了する。
　ステップＳ２において、アセンブラ１００は、ソースファイル２００の未処理の文字列の先頭位置から、命令を含む一行分の文字列を取得する。もし、未処理の文字列の先頭位置にある一行分の文字列がコメントや空白行であるならば、アセンブラ１００は、命令を含む一行分の文字列を取得できるまで、コメントや空白行を読み飛ばす。図１３は、ソースファイル２００の例である。図１３において、＃から始まる行はコメントであり、コメント行と空白行以外の行は命令を含む行であり、命令を含む行がステップＳ２で取得される文字列である。
　ステップＳ３において、アセンブラ１００は、一行分の文字列を複数のトークンに分解する。この複数のトークンを未知命令のトークンと呼ぶことにする。トークンとは命令文字列を構成する単語である。トークンについては後で詳しく説明する。
　ステップＳ４において、アセンブラ１００は、未知命令のトークンを、既知の命令に関する各種テーブルを参照して、既知の命令のトークンと比較し、未知命令の命令ＩＤとオペランドの値とを求める。この比較の手順については後で詳しく説明する。
　ステップＳ５において、アセンブラ１００は、未知命令の命令ＩＤとオペランド値から未知命令の命令コードを計算し、その命令コードをオブジェクトファイル３００（図１参照）に追加する。
　命令コードは、命令ＩＤによって一意に定義されるオペコードと、オペランドの文字列によって変わるオペランド値とを含む。
　アセンブラ１００において、命令のエンコードを担当する命令エンコーダ１２０は、オペコードテーブル１５０から未知命令の命令ＩＤに対応するオペコードを取得する。このオペコードとステップＳ４で得られたオペランドの値に基づいて、命令エンコーダ１２０は、未知命令の命令コードを計算する。
　ステップＳ５の後に、アセンブラ１００は、ステップＳ１へ移動し、ソースファイル２００の次の未処理の行にある未知命令を処理する。
　図１７は、オペコードテーブル１５０の例である。図１７に示すオペコードテーブル１５０には、各命令について、命令ＩＤ、命令語長（ｂｉｔ数）、オペコード、オペランドの個数、各オペランドのビット長とビット位置が記録されている。図１７を参照すると、例えば、ＡＤＤという命令ＩＤの命令は、命令語長が３２ビットで、オペコードが“０ｘ１０１０００００”で、オペランドを３個有し、各オペランドが４ビットの長さで、三つのオペランドがビット０から１１までの１２ビットに配置される、ということがわかる。命令エンコーダ１２０は、図１７に例示したような既知であるオペコードの一覧の情報を使用して、命令をエンコードする。
　以降では、命令のシンタックスとトークンについて説明してから、アセンブラ１００の重要な処理であるステップＳ３とステップＳ４について詳しく説明する。
＜命令のシンタックスとトークン＞
　つづいて、命令のシンタックスとトークンについて説明する。
　図１４Ａ及び図１４Ｂは、命令のシンタックスの例である。図１４Ａには、各命令の命令ＩＤとシンタックスと説明が示されている。命令ＩＤは各命令の名前のようなものであり、命令ＩＤを使って各命令は区別される。
　命令のシンタックスは、命令の記述形式を表す文字列である。命令のシンタックスは、オペランド変数や記号などの文字列で構成される。オペランド変数は、命令のオペランド（レジスタや数値など）を表す変数であり、命令のシンタックスの中でオペランドを記述すべき位置とオペランドの意味とを表す。図１４Ｂには、図１４Ａで使われているオペランド変数の説明が示されている。
　図１４Ａ及び図１４Ｂにあるような命令を字句解析して構文解析するために、アセンブラ１００は、トークン情報テーブル１３０とオペランド情報テーブル１４０を使用する。トークン情報テーブル１３０は、命令のシンタックスに含まれるトークンに関する情報を格納したテーブルである。トークンとは、命令のシンタックスの構成要素となる単語である。命令のシンタックスは、複数のトークンで構成されている。
　命令のシンタックスのトークンは、図１５Ｂに示すように、オペランド変数、シンボル、数値、記号、の四種類がある。オペランド変数は、オペランドを表すトークンである。オペランド変数は“％”から始まる名前（文字列）をもつ。シンボルは、アルファベットや数字やアンダースコアで構成される１文字以上のトークンである。数値は、数値を示すトークンである。記号は、非アルファベットかつ非数字の１文字で構成されるトークンである。
　図１５Ａは、トークン情報テーブル１３０の例である。図１５Ａに示されている例は、図１４Ａ及び図１４Ｂに示した各命令のシンタックスを構成するトークンの情報である。図１５Ａには、各命令について、命令ＩＤ、トークンの個数、各トークンのタイプと文字列が示されている。図１５Ａを参照すると、例えば、ＡＤＤという命令ＩＤの命令のシンタックスは、５個のトークンをもち、最初のトークンは“％ｏｐ０”というオペランド変数のトークンであり、その次のトークンは“＝”という記号のトークンであり、といったことがわかる。
　オペランド変数で表現可能なトークンに関する情報は、オペランド情報テーブル１４０に格納されている。図１６はオペランド情報テーブル１４０の例である。オペランド情報テーブル１４０には、各オペランド変数について、命令ＩＤ、オペランド変数の名前、オペランド変数のタイプ、トークンの候補、オペランドの値が記されている。
　オペランド変数のタイプは、オペランドの種類を表す。オペランド変数のタイプは、そのオペランド変数に当てはまるオペランドがレジスタなのか即値なのかといったことを表す。トークンの候補は、オペランド変数に当てはまるトークンの候補を表す。例えば、もしオペランド変数の種類がレジスタであるならば、オペランド変数に当てはまるレジスタの名前を表すシンボルトークンが、トークンの候補である。
　図１６によると、例えば、ＡＤＤという命令ＩＤのオペランド変数“％ｏｐ０”は、Ｒレジスタを示すオペランド変数であって、そのトークン候補は“Ｒ０”から“Ｒ１５”までのＲレジスタの名前を表すシンボルトークンである、ということがわかる。
＜ステップＳ３：トークン分解＞
　つづいて、図３を参照しながら、ステップＳ３（図２参照）の「トークン分解」処理について詳しく説明する。ステップＳ３は、ステップＳ３１からＳ３４の四つのステップを含む。
　ステップＳ３１において、トークン分解ユニット１１３（図１参照）は、一行分の文字列（入力文字列）の中に未処理の文字が残っているかを検査し、もし残っているならばステップＳ３２へ移動し、残っていなければステップＳ３を終了する。
　ステップＳ３２において、トークン分解ユニット１１３は、入力文字列から１文字を取得する。
　文字を取得する処理を図４に例示する。図４には、１字目の文字を取得する前と後の入力文字列と補助情報が示されている。補助情報とは、文字列取得位置とトークン先頭位置である。文字列取得位置は、トークン分解ユニット１１３が文字を取得する位置を表す。トークン先頭位置は、現在のトークンの先頭の位置を表す。ステップＳ３２において、トークン分解ユニット１１３は、文字列取得位置から文字をひとつ取得し、その後に、文字取得位置を行末方向へ１字分移動する。図４の例では、文字を取得する以前の文字取得位置は入力文字列の行頭（“Ｒ”の位置）で、文字を取得した後の文字取得位置は入力文字列の行頭の右ひとつ隣（“５”の位置）である。
　つづいて、ステップＳ３３の「文字種別判定」について詳しく説明する。ステップＳ３３において、トークン分解ユニット１１３は、取得した文字の文字種別を判定する。文字の種別を図５に示す。
　トークン分解ユニット１１３は、文字の種別を、次のステップＳ３４のトークン境界判定の状態に基づいて決定する。トークン境界判定の状態については後で詳しく説明する。図５には、取得した文字がトークン境界判定の状態に基づいて、どの文字種別に分類されるかが示されている。文字の種別は、以下の五種類である。
　・シンボル先頭文字：シンボル（アルファベット、数字、アンダースコアで構成される文字列）の先頭を表す文字
　・シンボル文字：シンボルの先頭以外を表す文字
　・数字：数値を表す文字
　・空白文字：空白やタブを表す文字
　・記号文字：アルファベット、数字、アンダースコア、空白、など以外の文字
　例えば、取得した文字が０から９までのいずれかであって、トークン境界判定の状態が「シンボル状態」であれば、トークン分解ユニット１１３は、取得した文字の種別を「シンボル文字」と識別する。
　つづいて、ステップＳ３４の「トークン境界判定」について詳しく説明する。ステップＳ３４において、トークン分解ユニット１１３は、現在のトークン境界判定の状態と、取得した文字の種別とに基づいて、取得した文字列が新たなトークンの一部であるか否かを判定する。トークン分解ユニット１１３は、トークン境界判定の状態と呼ばれる以下の三つの状態をもつ。
　・ヌル状態：初期状態。トークン先頭位置から始まる文字列のトークンが不明であることを示す状態
　・数値状態：トークン先頭位置から始まる文字列が数値トークンであることを示す状態
・シンボル状態：トークン先頭位置から始まる文字列がシンボルトークンであることを示す状態
　ステップＳ３の「トークン分解」を開始する時点では、トークン境界判定の状態は「ヌル状態」である。そして、ステップＳ３４において、トークン分解ユニット１１３は、取得した文字が新たなトークンの一部であるか否かを判定した後で、トークン境界判定の状態を変更する。
　トークン境界判定の状態の遷移を図６に示す。図６において、丸で示されているのが状態を、そこから伸びている矢印が取得した文字の種別による状態遷移を、四角で示されているのがトークン分解ユニット１１３で実行される処理を、それぞれ表す。例えば、ヌル状態において取得した文字がシンボル先頭文字である場合には、図６のヌル状態の上から伸びる矢印にしたがって、トークン分解ユニット１１３は状態をシンボル状態に遷移させる。このとき、もし矢印が四角の箱につながるならば、矢印の開始元の状態において、トークン分解ユニット１１３はその四角の処理を実行する。例えば、ヌル状態において取得した文字が空白文字である場合には、トークン分解ユニット１１３は図６のヌル状態の上から伸びる矢印を選択し、この矢印の先の「先頭位置移動」という処理を実行し、そして再びヌル状態に戻る。他の状態（シンボル状態や数値状態）についても、トークン分解ユニット１１３は同様にふるまい動作する。
　図６には、四角の箱で表された処理が三種類ある。これの処理の内容について説明する。
　・先頭位置移動
　・トークン抽出
　・文字差し戻し
　「先頭位置移動」の処理内容を図７に示す。先頭位置移動において、トークン分解ユニット１１３は、トークン先頭位置を文字取得位置に移動する。図７の例では、行頭にあったトークン先頭位置は、行頭から右へ二文字分移動されている。この処理が呼び出されるのは、以下３つの場合のいずれかである。
　・ヌル状態で空白文字を取得したとき
　・ヌル状態で記号文字を取得したとき
　・シンボル状態あるいは数値状態から「文字差し戻し」処理を経た後
　ヌル状態で空白文字を取得したときには、トークン分解ユニット１１３は、新たなトークンを抽出せずに、トークン先頭位置を移動する。これは、空白文字を無視するためである。他の二つの場合では、トークン分解ユニット１１３は、新たなトークンを抽出してから、トークン先頭位置を移動する。トークンを抽出する処理については次に詳しく説明する。
　「トークン抽出」の処理内容を図８Ａに示す。トークン抽出において、トークン分解ユニット１１３は、トークン先頭位置から文字取得位置のひとつ手前までの文字列をひとつのトークンとみなす処理を行う。このときのトークン境界判定の状態に基づいて、トークン分解ユニット１１３は、この新たなトークンの種類を決定する。トークン境界判定の状態とトークンの種類の関係は図８Ｂの表のとおりである。つまり、もしトークン境界判定の状態がヌル状態ならば、新たなトークンは記号トークンとなる。同様にして、もし数値状態ならば、新たなトークンは数値トークンとなり、もしシンボル状態ならば、シンボルトークンとなる。
　「文字差し戻し」の処理内容を図９に示す。文字差し戻しにおいて、トークン分解ユニット１１３は、文字取得位置を行頭方向に１文字分戻し、次処理に移行する。これは、文字の取得をやり直すためである。文字差し戻しを実行するときは、トークン境界判定の状態が数値状態であって数字以外の文字を取得したときか、もしくはシンボル状態であってシンボル文字以外の文字を取得したときのいずれかである。いずれの場合も、トークン分解ユニット１１３は、現在の状態で処理すべきではない文字を取得しているため、その文字の取得をキャンセルする必要がある。
＜ステップＳ４：トークン情報マッチング＞
　つづいて、図１０を参照しながら、ステップＳ４（図２参照）の「トークン情報マッチング」について詳しく説明する。ステップＳ４は、ステップＳ４１からＳ４８の八つのステップを含む。
　トークン情報マッチング処理は、トークン情報テーブル１３０を参照しながら、未知命令を構成するトークンの構成パターンに合致する命令を、既知の命令の中から探し出す処理である。命令というものは、ひとつ以上のトークンで構成されている。ここでは、各トークンの文字列や種類、そしてトークンの並び方を、トークンの構成パターンと呼んでいる。トークン情報テーブル１３０は、全ての既知命令のトークンの構成パターンと命令ＩＤとを持つテーブルである。トークン情報テーブル１３０の中から、未知命令のトークンの構成パターンと同じトークンの構成パターンをもつ既知命令を探し出せば、未知命令の命令ＩＤを知ることができる。
　ステップＳ４１において、マッチングユニット１１５（図１参照）は、既知の命令ＩＤの中で未検査なものが残っているか否かを確認し、もしそのような既知命令ＩＤが残っていればステップＳ４２へ移動し、もし残っていなければステップＳ４を終了する。
　ステップＳ４２において、マッチングユニット１１５は、未検査な既知命令ＩＤをひとつ選択し、その既知命令のトークン情報をトークン情報テーブル１３０（図１参照）から取得する。このとき取得する既知命令のトークン情報には、複数のトークンが含まれる。また、既知命令のシンボルトークンには、オペランド変数を示すものとそうでないものとが存在する。
　ステップＳ４３において、マッチングユニット１１５は、既知命令のトークン情報と未知命令のトークン情報からそれぞれひとつずつトークンを取得する。既知命令と未知命令の両方のそれぞれのトークン情報において、先頭の位置にあるトークンから末尾のトークンに向かって順番に０から始まる番号をつけておく。ステップＳ４３において既知命令と未知命令のトークンを取得する際には、同じ番号をもつトークンを取得する。例えば、既知命令と未知命令のそれぞれの先頭のトークンを取得する、それぞれの先頭から２番目のトークンを取得する、それぞれの先頭から３番目のトークンを取得する、といったようにする。
　ステップＳ４４において、マッチングユニット１１５は、既知命令のトークンがオペランド変数を示すトークンであるか否かを確認し、もしオペランド変数でなければステップＳ４５へ移行し、もしオペランド変数であればステップＳ４６へ移行する。
　ステップＳ４５において、マッチングユニット１１５は、既知命令のトークンと未知命令のトークンの文字列が正確に一致するか否かを検査し、その結果をステップＳ４７へ与える。このステップＳ４５の「文字列一致検査」については後で詳しく説明する。
　ステップＳ４６において、マッチングユニット１１５は、既知命令のトークンと未知命令のトークンの意味が一致するか否かを検査し、その結果をステップＳ４７へ与える。このステップＳ４６の「意味一致検査」については後で詳しく説明する。
　ステップＳ４７において、マッチングユニット１１５は、ステップＳ４５あるいはステップＳ４６の検査結果を確認し、もしそれが「一致」であるならばステップＳ４８に移行し、もしそれが「不一致」であるならばステップＳ４２に移行する。ステップＳ４２への移行は、現在選択している既知命令が未知命令でなかったことを意味し、マッチングユニット１１５は、別の既知命令を試すことになる。
　ステップＳ４８において、マッチングユニット１１５は、既知命令のトークン情報に含まれる全てのトークンについて検査を行なったか否かを確認し、もし検査を行なっていないトークンがあるならばステップＳ４３に移行し、残りのトークンを検査する。もしそうでなければ、マッチングユニット１１５は、既知命令と未知命令の両者のトークンが全て一致したと判断し、その既知命令の命令ＩＤを未知命令の命令ＩＤとする。加えて、マッチングユニット１１５は、ステップＳ４６の「意味一致検査」で得られたオペランドの値を取得し、未知命令の命令ＩＤとオペランド値とを、ステップＳ５（図２参照）へ与える。
　トークン情報テーブル１３０には、各既知命令を構成するトークンの数が記録されている。そのトークンの数を使用して、マッチングユニット１１５は、全てのトークンの検査を行ったか否かを確認する。
　以上説明したように、ステップＳ４において、マッチングユニット１１５は、全てのトークンに対して、ステップＳ４５の「文字列一致検査」あるいはステップＳ４６の「意味一致検査」を実施し、未知命令の命令ＩＤとオペランド値を抽出する。このようにすることによって、未知命令を構成するトークンの構成パターンと同じ構成パターンをもつ命令を、既知命令の中から探し出すことができる。ステップＳ４では、トークンの構成パターンに関して前提条件を使用していない。例えば、先頭にニモニックを表す文字列が出現するはず、といった前提条件を使用していない。したがって、ニモニック形式でも関数形式でも算術形式でも、トークンの構成パターンが一致しさえすれば、マッチングユニット１１５は未知命令を特定することが可能である。
＜文字列一致検査＞
　つづいて、図１１を参照しながら、ステップＳ４５（図１０参照）の「文字列一致検査」について詳しく説明する。
　文字列一致検査とは、既知命令と未知命令のそれぞれ対応する位置にあるトークンが、文字列として一致するか否かを検査する処理である。マッチングユニット１１５は、既知命令のトークンがオペランド変数を示していない場合に、文字列一致検査を行なう。
　図１１は、既知命令と未知命令のそれぞれの最も右側（行末に近い方）のトークンについて、マッチングユニット１１５が文字列一致検査を行なう処理を示す。図１１に示す例では、既知命令と未知命令はそれぞれ６個のトークンを有している。既知命令のトークンのなかで、“％ｏｐ０”、“％ｏｐ１”、はオペランド変数を表すトークンであり、それ以外のトークン、“＝”、“ＡＢＳ”、“（”、“）”はオペランド変数ではないトークンである。オペランド変数ではないこれらの４個のトークンについて、マッチングユニット１１５は文字列一致検査を行なう。図１１において、既知命令と未知命令の最も右側（行末に近い方）のトークンは、どちらも“）”であるので、マッチングユニット１１５は、両方のトークンの文字列が一致すると判断する。
＜意味一致検査＞
　つづいて、図１２を参照しながら、ステップＳ４６（図１０参照）の「意味一致検査」について詳しく説明する。
　意味一致検査とは、既知命令と未知命令のそれぞれ対応する位置にあるトークンの意味が一致するか否かを検査する処理である。マッチングユニット１１５は、既知命令のトークンがオペランド変数を表す場合に、意味一致検査を行なう。
　ここで、「意味が一致する」とは、オペランド変数が表現可能なシンボルトークンや数値トークンの集合（トークンの候補）に未知命令のトークンが含まれていることを意味する。図１２は、既知命令と未知命令のそれぞれの最も左側（行頭に近い方）のトークンについて、マッチングユニット１１５が意味一致検査を行なう処理を示す。
　図１２に示す例では、既知命令のトークンのなかで、“％ｏｐ０”、“％ｏｐ１”、はオペランド変数を表すトークンである。オペランド変数を表すこれらの２個のトークンのそれぞれについて、マッチングユニット１１５は意味一致検査を行なう。図１２において、マッチングユニット１１５は、既知命令の最も左側（行頭に近い方）のトークン“％ｏｐ０”と、未知命令の同じく最も左側のシンボルトークン“Ｒ５”とを比較し、オペランド変数であるトークン“％ｏｐ０”が表すトークンの集合に未知命令のシンボルトークン“Ｒ５”が含まれるか否かを判定する。
　マッチングユニット１１５は、既知命令のオペランド変数に関する情報を、オペランド情報テーブル１４０から取り出す。オペランド情報テーブル１４０は、各既知命令のトークン情報の中に含まれるオペランド変数に関する情報（オペランド情報）を保持するテーブルである。オペランド情報とは、以下の五つの情報である。
　１．既知命令の命令ＩＤ
　２．オペランド変数の名前
　３．オペランド変数のタイプ
　４．トークンの候補
　５．オペランドの値
　図１２において、マッチングユニット１１５は、オペランド変数“％ｏｐ０”のオペランド情報をオペランド情報テーブル１４０から取得する。そのオペランド情報に基づくと、“％ｏｐ０”はＲレジスタを表すオペランド変数であり、“％ｏｐ０”のトークン候補は“Ｒ０”から“Ｒ１５”までのレジスタを表すシンボルトークンであることがわかる。したがって、未知命令の同じく最も左側のシンボルトークン“Ｒ５”は、既知命令の最も左側（行頭に近い方）のトークン“％ｏｐ０”が表すトークンの集合に含まれる、とマッチングユニット１１５は判断する。
　以上説明したように、本発明を使用すれば、さまざまな記述スタイルに対応できたひとつの汎用な構文解析器を提供できる。また、当該構文解析器を有する汎用アセンブラおよびアセンブル装置を提供できる。
　上記アセンブル装置は、トークンの構成パターンを用いて入力文字列に含まれる命令を認識するため、例えば、入力文字列の先頭に命令を現す文字列（トークン）が無い記述スタイルにも対応可能である。また、上記アセンブル装置は、プロセッサの仕様変更等に囚われない利便性の高いアセンブル機能を提供できる。
　即ち、本発明によれば、ニモニック形式と関数形式と算術形式の命令記述形式に対応できる構文解析器を有するアセンブル装置、構文解析方法、およびアセンブラプログラムを提供できる。
　なお、本発明の具体的な構成は前述の実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の変更があってもこの発明に含まれる。
　例えば、上記アセンブラは、オプティカルディスクなどの記録媒体に記録保持され、記録媒体から入力部を介してコンピュータに読み込まれることによって、ＣＰＵを動作させてソースファイルをオブジェクトコードに変換し、出力部から出力するようにしてもよい。
　また、図１８に例示すように、サーバ上の記録媒体にアセンブラを動作可能に記録保持し、サーバのＣＰＵや記憶部を使用して、アセンブル処理を行なってもよい。
　アセンブラは、ＣＰＵやＤＳＰなどのプロセッサのためのプログラム開発に欠かせない開発ツールである。携帯電話、音楽プレーヤ、自動車向けナビシステムなどの組み込み用途に向けてさまざまなＣＰＵやＤＳＰが開発されている。本発明はそうした組み込み向けプロセッサのためのアセンブラに使用できる。
　この出願は、２００９年８月２５日に出願された日本出願特願２００９−１９４５７４号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１００　アセンブラ
　１１０　構文解析ユニット
　１１１　行分解ユニット
　１１３　トークン分解ユニット
　１１５　マッチングユニット
　１２０　命令エンコーダ
　１３０　トークン情報テーブル
　１４０　オペランド情報テーブル
　１５０　オペコードテーブル
　２００　ソースファイル
　３００　オブジェクトファイル

Claims (20)

  1. 　各命令のシンタックスを構成するトークンやオペランド変数の構成パターンを表すトークン情報テーブルと、
    　オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルと、
    　入力ファイルの入力文字列を複数のトークンに分解し、前記オペランド情報テーブルを参照しながら、得られた前記トークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索する構文解析ユニットと、
    を備えることを特徴とするソースファイルからオブジェクトコードを出力するアセンブル装置。
  2. 　請求項１に記載のアセンブル装置であって、
    　前記構文解析ユニットは、１行分の入力文字列毎に、１字ずつ取得した文字とその前の文字の判定結果に基づき当該１字の文字種別を判定し、
    　もし前記文字種別が記号文字であれば、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別がシンボル先頭文字であれば、シンボル文字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別が数字であれば、数字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　入力ファイルの入力文字列を複数のトークンに分解する
    ことを特徴とするアセンブル装置。
  3. 　請求項１又は２に記載のアセンブル装置であって、
    　前記構文解析ユニットは、前記入力文字列のトークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索する際に、
    　前記入力文字列から第１のトークンを取り出し、
    　前記トークン情報テーブルのひとつの既知命令を構成する複数のトークンの中から前記第１のトークンに対応する位置にある第２のトークンを取り出し、
    　取り出した第２のトークンがオペランドを表す変数であるか否かを識別して、その結果に基づき、意味一致検査もしくは文字列一致検査を行い、
    　前記入力文字列の全てのトークンについて意味一致検査もしくは文字列一致検査に適合するような既知命令を前記トークン情報テーブルから探し出す、
    ことを特徴とするアセンブル装置。
  4. 　請求項３記載のアセンブル装置であって、
    　前記構文解析ユニットは、第２のトークンがオペランド変数ではない場合に、
    　第１および第２のトークンが文字列として一致するか否かを検査する文字一致検査を行う、
    ことを特徴とするアセンブル装置。
  5. 　請求項３又は４に記載のアセンブル装置であって、
    　前記構文解析ユニットは、第２のトークンがオペランド変数の場合に、
    　前記オペランド情報テーブルを参照しながら、前記オペランド変数が表すトークン候補の中に第１のトークンが含まれているときに一致と判定する意味一致検査を行う、
    ことを特徴とするアセンブル装置。
  6. 　各命令のシンタックスを構成するトークンやオペランド変数の構成パターンを表すトークン情報テーブルと、オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルと、を記憶保持し、
    　入力ファイルの入力文字列を複数のトークンに分解し、
    　前記オペランド情報テーブルを参照しながら、得られた前記トークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索するような構文解析を行う、
    ことを特徴とするアセンブラの命令の構文解析方法。
  7. 　請求項６に記載のアセンブラの構文解析方法であって、
    　１行分の入力文字列毎に、１字ずつ取得した文字とその前の文字の判定結果に基づき当該１字の文字種別を判定し、
    　もし前記文字種別が記号文字であれば、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別がシンボル先頭文字であれば、シンボル文字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別が数字であれば、数字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　入力ファイルの入力文字列を複数のトークンに分解する
    ことを特徴とする構文解析方法。
  8. 　請求項６又は７に記載の構文解析方法であって、
    　前記構文解析は、前記入力文字列のトークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索する際に、
    　前記入力文字列から第１のトークンを取り出し、
    　前記トークン情報テーブルのひとつの既知命令を構成する複数のトークンの中から前記第１のトークンに対応する位置にある第２のトークンを取り出し、
    　取り出した第２のトークンがオペランドを表す変数であるか否かを識別して、その結果に基づき、意味一致検査もしくは文字列一致検査を行い、
    　前記入力文字列の全てのトークンについて意味一致検査もしくは文字列一致検査に適合するような既知命令を前記トークン情報テーブルから探し出す、
    ことを特徴とする構文解析方法。
  9. 　請求項８記載の構文解析方法であって、
    　第２のトークンがオペランド変数でない場合に、
    　第１および第２のトークンが文字列として一致するか否かを検査する文字一致検査を行う、
    ことを特徴とする構文解析方法。
  10. 　請求項８又は９に記載の構文解析方法であって、
    　第２のトークンがオペランド変数の場合に、
    　前記オペランド情報テーブルを参照しながら、前記オペランド変数のトークン候補の中に第１のトークンが含まれるときに一致と判定する意味一致検査を行う、
    ことを特徴とする構文解析方法。
  11. 　コンピュータのＣＰＵを、
    　入力ファイルの入力文字列を複数のトークンに分解すると共に、オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルを参照しながら、得られた前記トークンの構成パターンに合致するトークンの構成パターンをもつ命令を、各命令のシンタックスを構成するトークンやオペランド変数の構成パターンを表すトークン情報テーブルから探索する構文解析ユニット、
    として動作させることを特徴とするアセンブラプログラムを記録した記録媒体。
  12. 　請求項１１に記載のアセンブラプログラムを記録した記録媒体であって、
    　入力ファイルの入力文字列を複数のトークンに分解する処理において、
    　前記構文解析ユニットは、
    　１行分の入力文字列毎に、１字ずつ取得した文字とその前の文字の判定結果に基づき当該１字の文字種別を判定し、
    　もし前記文字種別が記号文字であれば、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別がシンボル先頭文字であれば、シンボル文字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別が数字であれば、数字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　入力ファイルの入力文字列を複数のトークンに分解する、
    ことを特徴とするアセンブラプログラムを記録した記録媒体。
  13. 　請求項１１又は１２に記載のアセンブラプログラムを記録した記録媒体であって、
    　前記マッチングユニットは、前記入力文字列のトークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索する際に、
    　前記入力文字列から第１のトークンを取り出し、
    　前記トークン情報テーブルのひとつの既知命令を構成する複数のトークンの中から前記第１のトークンに対応する位置にある第２のトークンを取り出し、
    　取り出した第２のトークンがオペランドを表す変数であるか否かを識別して、その結果に基づき、意味一致検査もしくは文字列一致検査を行い、
    　前記入力文字列の全てのトークンについて意味一致検査もしくは文字列一致検査に適合するような既知命令を前記トークン情報テーブルから探し出す、
    ことを特徴とするアセンブラプログラムを記録した記録媒体。
  14. 　請求項１３記載のアセンブラプログラムを記録した記録媒体であって、
    　第２のトークンがオペランド変数でない場合に、
    　第１および第２のトークンが文字列として一致するか否かを検査する文字一致検査を行う、
    ことを特徴とするアセンブラプログラムを記録した記録媒体。
  15. 　請求項１３又は１４に記載のアセンブラプログラムを記録した記録媒体であって、
    　第２のトークンがオペランド変数の場合に、
    　前記オペランド情報テーブルを参照しながら、前記オペランド変数のトークン候補の中に第１のトークンが含まれるときに一致と判定する意味一致検査を行う、
    ことを特徴とするアセンブラプログラムを記録した記録媒体。
  16. 　コンピュータのＣＰＵを、
    　入力ファイルの入力文字列を複数のトークンに分解すると共に、オペランド変数の意味や候補となるトークンを表すオペランド情報テーブルを参照しながら、得られた前記トークンの構成パターンに合致するトークンの構成パターンをもつ命令を、各命令のシンタックスを構成するトークンやオペランド変数の構成パターンを表すトークン情報テーブルから探索する構文解析ユニット、
    として動作させることを特徴とするアセンブラプログラム。
  17. 　請求項１６に記載のアセンブラプログラムであって、
    　入力ファイルの入力文字列を複数のトークンに分解する処理において、
    　前記構文解析ユニットは、
    　１行分の入力文字列毎に、１字ずつ取得した文字とその前の文字の判定結果に基づき当該１字の文字種別を判定し、
    　もし前記文字種別が記号文字であれば、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別がシンボル先頭文字であれば、シンボル文字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　もし前記文字種別が数字であれば、数字と異なる文字の検出時に、当該１字をトークンの境界を識別してトークンを抽出し、
    　入力ファイルの入力文字列を複数のトークンに分解する、
    ことを特徴とするアセンブラプログラム。
  18. 　請求項１６又は１７に記載のアセンブラプログラムであって、
    　前記マッチングユニットは、前記入力文字列のトークンの構成パターンに合致するトークンの構成パターンをもつ命令を前記トークン情報テーブルから探索する際に、
    　前記入力文字列から第１のトークンを取り出し、
    　前記トークン情報テーブルのひとつの既知命令を構成する複数のトークンの中から前記第１のトークンに対応する位置にある第２のトークンを取り出し、
    　取り出した第２のトークンがオペランドを表す変数であるか否かを識別して、その結果に基づき、意味一致検査もしくは文字列一致検査を行い、
    　前記入力文字列の全てのトークンについて意味一致検査もしくは文字列一致検査に適合するような既知命令を前記トークン情報テーブルから探し出す、
    ことを特徴とするアセンブラプログラム。
  19. 　請求項１８記載のアセンブラプログラムであって、
    　第２のトークンがオペランド変数でない場合に、
    　第１および第２のトークンが文字列として一致するか否かを検査する文字一致検査を行う、
    ことを特徴とするアセンブラプログラム。
  20. 　請求項１８又は１９に記載のアセンブラプログラムであって、
    　第２のトークンがオペランド変数の場合に、
    　前記オペランド情報テーブルを参照しながら、前記オペランド変数のトークン候補の中に第１のトークンが含まれるときに一致と判定する意味一致検査を行う、
    ことを特徴とするアセンブラプログラム。
PCT/JP2010/061219 2009-08-25 2010-06-24 アセンブル装置、構文解析方法、及びアセンブラプログラム WO2011024554A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011528694A JP5413623B2 (ja) 2009-08-25 2010-06-24 アセンブル装置、構文解析方法、及びアセンブラプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-194574 2009-08-25
JP2009194574 2009-08-25

Publications (1)

Publication Number Publication Date
WO2011024554A1 true WO2011024554A1 (ja) 2011-03-03

Family

ID=43627665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061219 WO2011024554A1 (ja) 2009-08-25 2010-06-24 アセンブル装置、構文解析方法、及びアセンブラプログラム

Country Status (2)

Country Link
JP (1) JP5413623B2 (ja)
WO (1) WO2011024554A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109379403A (zh) * 2018-09-12 2019-02-22 珠海德百祺科技有限公司 物联网设备的控制方法、装置、服务器和终端设备
JP2019125062A (ja) * 2018-01-12 2019-07-25 カシオ計算機株式会社 プログラミング支援装置、プログラミング支援方法、およびプログラム
CN112634357A (zh) * 2020-12-30 2021-04-09 哈尔滨工业大学芜湖机器人产业技术研究院 用于机器人二维视觉系统的通讯数据处理方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04309125A (ja) * 1991-04-08 1992-10-30 Matsushita Electric Ind Co Ltd アセンブリ言語のフィルタ装置
JPH08286927A (ja) * 1995-04-18 1996-11-01 Hitachi Ltd アセンブラ処理方式
JPH11249903A (ja) * 1998-02-26 1999-09-17 Agency Of Ind Science & Technol 抽象構文木処理方法、抽象構文木処理プログラムを記録したコンピュータ読み取り可能な記録媒体、抽象構文木データを記録したコンピュータ読み取り可能な記録媒体、及び、抽象構文木処理装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04309125A (ja) * 1991-04-08 1992-10-30 Matsushita Electric Ind Co Ltd アセンブリ言語のフィルタ装置
JPH08286927A (ja) * 1995-04-18 1996-11-01 Hitachi Ltd アセンブラ処理方式
JPH11249903A (ja) * 1998-02-26 1999-09-17 Agency Of Ind Science & Technol 抽象構文木処理方法、抽象構文木処理プログラムを記録したコンピュータ読み取り可能な記録媒体、抽象構文木データを記録したコンピュータ読み取り可能な記録媒体、及び、抽象構文木処理装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019125062A (ja) * 2018-01-12 2019-07-25 カシオ計算機株式会社 プログラミング支援装置、プログラミング支援方法、およびプログラム
JP7020127B2 (ja) 2018-01-12 2022-02-16 カシオ計算機株式会社 プログラミング支援装置、プログラミング支援方法、およびプログラム
CN109379403A (zh) * 2018-09-12 2019-02-22 珠海德百祺科技有限公司 物联网设备的控制方法、装置、服务器和终端设备
CN109379403B (zh) * 2018-09-12 2021-04-06 珠海德百祺科技有限公司 物联网设备的控制方法、装置、服务器和终端设备
CN112634357A (zh) * 2020-12-30 2021-04-09 哈尔滨工业大学芜湖机器人产业技术研究院 用于机器人二维视觉系统的通讯数据处理方法及系统
CN112634357B (zh) * 2020-12-30 2022-12-23 哈尔滨工业大学芜湖机器人产业技术研究院 用于机器人二维视觉系统的通讯数据处理方法及系统

Also Published As

Publication number Publication date
JPWO2011024554A1 (ja) 2013-01-24
JP5413623B2 (ja) 2014-02-12

Similar Documents

Publication Publication Date Title
JP4148527B2 (ja) 機能テスト・スクリプト生成装置
JPS6375835A (ja) 目的コ−ド、プログラム・リスト及び設計文書を生成する装置
JP2004295398A (ja) コンパイラ、コンパイル方法、及びプログラム開発ツール
US20090049431A1 (en) Method and compiler of compiling a program
CN112596739B (zh) 一种数据的处理方法和装置
JP5413623B2 (ja) アセンブル装置、構文解析方法、及びアセンブラプログラム
JP6440895B2 (ja) ソフトウェア分析装置及びソフトウェア分析方法
WO2010050128A1 (ja) コンパイル方法及びコンパイルプログラム
US20090125873A1 (en) Using compiler commentary for configuring an integrated development environment
US20070169054A1 (en) Process of automatically translating a high level programming language into an extended activity diagram
CN116360794A (zh) 数据库语言解析方法、装置、计算机设备及存储介质
KR102614967B1 (ko) 자바스크립트의 중간 언어 기반 의미론 추출 자동화 시스템 및 방법
CN116257245A (zh) 一种基于flex与bison语法分析的多输出编译方法及系统
CN114327614A (zh) 参考模型数据流记录和分析的方法及应用
CN112965909A (zh) 测试数据、测试用例生成方法及系统、存储介质
JP4102897B2 (ja) 特許明細書デバッグツールおよび特許明細書デバッグツールプログラム
JP2011204069A (ja) テスト方法およびテスト仕様書テストデータ自動生成装置
JP2007257397A (ja) 競合状態検出処理追加プログラム、競合状態検出処理追加装置、競合状態検出処理追加方法
TW200417924A (en) WIN F-language interpreter
JP2015197821A (ja) アセンブリコード変換装置およびその変換方法
CN116880826B (zh) 一种可视化代码生成方法
JP2004178011A (ja) 文書変換装置及び文書変換方法
CN117592478A (zh) 基于上下文语义的跨平台二进制函数命名预测方法
JP2009252170A (ja) コンバータ及びプログラム変換方法
JP2024008473A (ja) プログラム変換支援装置、プログラム変換支援方法、およびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10811605

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011528694

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10811605

Country of ref document: EP

Kind code of ref document: A1