· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
CUP Manual

CUP User's Manual

Scott E. Hudson

Graphics Visualization and Usability Center

Georgia Institute of Technology

Modified by Frank Flannery, C. Scott Ananian, Dan Wang with advice from Andrew W. Appel

Last updated July 1999 (v0.10j)

번역시작;; : 이철기 (lacovnk@freechal.com) 원문 : [http]http://www.cs.princeton.edu/~appel/modern/java/CUP/manual.html

Chapter 1 번역 : 조성재 (jachin@hanafos.com) - 애매한 문장이 있다면 메일보내주세요. (졸릴때 해놔서...)


2. i. About CUP Version 0.10

CUP Version 0.10는 Ver. 0.9 보다 여러가지 많은 시도와 요소들을 추가했습니다. 이번 버전은 YACC에 좀 더 가깝도록 만들었습니다. 그 때문에 0.9 버전의 CUP 파서를 이용한 specification과는 호환되지 않습니다. 새로운 specification을 작성하기 위해서는 새 메뉴얼의 Appendix C를 읽으셔야 합니다. 하지만 새 버전은 사용자에게 더 강력한 성능과 옵션을 제공하며, 더 쉽게 parser specification을 작성하실 수 있습니다.

3. 1. Introduction and Example

이 메뉴얼은 자바에 기초한 유용한 Parser인 CUP에 대한 기본적인 작동과 사용방법을 기술합니다. CUP는 간단한 specification으로부터 LALR 파서를 생성하는 시스템입니다. 이 시스템은 널리 쓰이고 있는 YACC와 같은 규칙을 제공하며, 실제로 YACC의 대부분의 요소들을 제공합니다.하지만 CUP는 자바로 작성되었으며, 자바 코드를 포함한 specification을 사용하며, 자바로 합성한 파서를 생성합니다.

비록 이 메뉴얼이 CUP 시스템의 모든 면을 다룬다고 해도, 그것은 상대적인 것이며, LR Parsing에 대한 최소한의 지식을 당신이 갖고 있다고 가정합니다. YACC의 사용 경험은 어떻게 CUP specification을 운영하는지에 대해 매우 도움이 됩니다. 많은 수의 compiler 구조 교제는 이 부분을 다루고 있으며, 간단한 예제로서 (CUP와 매우 흡사한) YACC에 대해 논의하곤 합니다.

CUP를 사용한다는 것은 구문분석기(Scanner)가 인식할 수 있는 작은 단위의 토큰들(keywords나 숫자, 특수한 기호들)과 함께, 토큰에 대한 파서의 문법에 기초한 간단한 specification을 만드는 것을 포함합니다.

간단한 예를 들어, 정수를 다루는 간단한 수학적 표현을 시험하기 위한 시스템을 생각해봅시다. 이 시스템은 (각각 세미콜론으로 끝나는) 표준입력으로부터 표현들을 읽어들이고 그것들을 시험하며, 표준출력으로 결과를 출력할 것입니다. 이런 시스템에 대한 입력의 문법은 다음과 같을 것입니다.

  expr_list ::= expr_list expr_part | expr_part
  expr_part ::= expr ';'
  expr      ::= expr '+' expr | expr '-' expr | expr '*' expr
              | expr '/' expr | expr '%' expr | '(' expr ')'
              | '-' expr | number


이 문법에 기초한 파서를 구체화하기 위해, 우리의 첫번째 목표는 입력에 나타날 terminal symbol의 묶음과 non-terminal symbol의 묶음을 분별하고, 이름짓는 것입니다.이 예에서 non-terminal symbol이라는 것들은 다음과 같습니다.

  expr_list, expr_part  and  expr .


우리가 선택할 terminal 이름들에 대해서는 다음과 같습니다.:

  SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD, NUMBER, LPAREN,
and RPAREN


경험을 갖춘 사용자는 문법상에 있는 문제를 주의할 것입니다. 그 문제란 애매모호함입니다. 모호한 문법은 한 입력에 대해 두 가지 출력결과를 얻을 수 있는 두 가지 해석방법이 공존하는 문법입니다. 예를 들어, 다음의 문법을 갖고 주어진 입력을 전달해 보십시오.

3 + 4 * 6


위의 문법은 3 + 4 를 먼저 시도하여 7 * 6 의 연산을 할 수도 있고, 4 * 6 을 먼저 연산하여 3을 더할 수도 있습니다. CUP의 예전버전은 사용자가 모호하지 않은 문법을 쓰도록 강요했지만, 지금은 terminal들에 대해 우선순위와 조합을 명세하도록 사용자에게 허용하는 개념입니다. 즉, 모호한 문법을 사용할 수 있으며, 후에 그것에 대한 우선순위와 조합을 기술함을 뜻합니다. 이것에 대해선 후에 더 자세히 설명하겠습니다. 이러한 법칙으로부터 우리는 다음과 같은 CUP specification을 구성할 수 있습니다.

// CUP specification for a simple expression evaluator (no actions)

import java_cup.runtime.*;

/* Preliminaries to set up and use the scanner.  */
init with {: scanner.init();              :};
scan with {: return scanner.next_token(); :};

/* Terminals (tokens returned by the scanner). */
terminal            SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD;
terminal            UMINUS, LPAREN, RPAREN;
terminal Integer    NUMBER;

/* Non terminals */
non terminal            expr_list, expr_part;
non terminal Integer    expr, term, factor;

/* Precedences */
precedence left PLUS, MINUS;
precedence left TIMES, DIVIDE, MOD;
precedence left UMINUS;

/* The grammar */
expr_list ::= expr_list expr_part |
              expr_part;
expr_part ::= expr SEMI;
expr      ::= expr PLUS expr
            | expr MINUS expr
            | expr TIMES expr
            | expr DIVIDE expr
            | expr MOD expr
            | MINUS expr %prec UMINUS
            | LPAREN expr RPAREN
            | NUMBER
            ;


나중에 각 문법에 대해 자세히 볼 것입니다만, 지금 여기서 specification이 4개의 주요 부분으로 구성되어 있는 것을 바로 볼 수 있습니다. 첫번째 부분은 어떻게 파서가 생성될 것인지, 런타임 코드 부분을 어떻게 제공할 것인지 우선적인 여러가지의 선언을 제공합니다. 이 경우에는 java_cup.runtime 클래스들이 포함될 것이며, 스캐너 초기화와 스캐너의 다음 입력 토큰을 출력할 것을 서술하고 있습니다. Specification의 두번째 부분은 terminal들과 non-terminal들, 각각에 결합될 object 클래스를 정의합니다. 이 경우 terminal들은 type이 없거나, 정수형으로 선언되어 있습니다. Terminal이나 non-terminal의 정의된 타입은 이들 terminal과 non-terminal의 값의 타입입니다. 만약 타입이 없다고 정의될 경우, terminal이나 non-terminal은 아무런 값을 갖지 않습니다. 여기 타입이 없는 terminal과 non-terminal들은 아무 값도 갖지 않습니다. 세번째 부분은 terminal들의 우선순위와 조합에 대해 명세합니다. 마지막 우선순위 선언은 선언된 터미널에게 최고의 우선순위를 부여합니다. Specification의 마지막 부분은 문법을 포함합니다.

이 specification으로부터 파서를 생성하기 위해 우리는 CUP 생성기를 사용합니다. 만약 이 specification이 parser.cup에 저장되어 있던 것이면, (적어도 유닉스 시스템에서) 우리는 다음 명령어로 CUP을 호출할 것입니다.

 java java_cup.Main < parser.cup


이 예에서, 시스템은 두 개의 자바 소스 파일(생성된 파서인 sym.java와 parser.java 파일)을 생성할 것입니다. 당신이 예상한 것처럼 이 두 파일은 sym 클래스와 parser 클래스에 대한 선언을 포함하고 있습니다. sym 클래스는 각각 terminal 심볼에 대한 상수 선언의 나열을 포함합니다. 이것은 symbol을 참조하는 스캐너에 의해 대부분 사용됩니다(예를들어 "return new Symbol(sym.SEMI);"와 같은 코드처럼). parser 클래스는 parser 자신을 합성합니다.

Parser 전체를 형성하는 동안의 specification은 내용에 관련한 어떠한 작업(Action)도 생성하지 않습니다. 단지 parse의 성공과 실패를 나타낼 뿐입니다. 각각의 표현을 계산(처리)하고 출력하기 위해, 여러 곳에 작업(Action)을 위한 자바코드를 내장시켜야 합니다. CUP에서 작업(Action)들은 {:과 :} 형태의 구분자에 의해 둘러싸여진 코드 문장으로 포함됩니다. (이 부분에 대해서 괄호에 둘러싸여진 init와 scan의 예제를 볼 수 있습니다.) 보통 시스템은 구분자 안에 있는 모든 문자를 기록하지만, 안에 들어있는 내용이 사용 가능한 자바 코드인지는 체크하지 않습니다.

우리의 (문법 안에서 여러 지점에 내장된 작업들이 같이 들어간) 예제 시스템에 대해 더욱 완성적인 specification을 다음에 보여줍니다.

// CUP specification for a simple expression evaluator (w/ actions)

import java_cup.runtime.*;

/* Preliminaries to set up and use the scanner.  */
init with {: scanner.init();              :};
scan with {: return scanner.next_token(); :};

/* Terminals (tokens returned by the scanner). */
terminal           SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD;
terminal           UMINUS, LPAREN, RPAREN;
terminal Integer   NUMBER;

/* Non-terminals */
non terminal            expr_list, expr_part;
non terminal Integer    expr;

/* Precedences */
precedence left PLUS, MINUS;
precedence left TIMES, DIVIDE, MOD;
precedence left UMINUS;

/* The grammar */
expr_list ::= expr_list expr_part
              |
              expr_part;

expr_part ::= expr:e
              {: System.out.println("= " + e); :}
              SEMI
              ;

expr      ::= expr:e1 PLUS expr:e2
              {: RESULT = new Integer(e1.intValue() + e2.intValue()); :}
              |
              expr:e1 MINUS expr:e2
              {: RESULT = new Integer(e1.intValue() - e2.intValue()); :}
              |
              expr:e1 TIMES expr:e2
              {: RESULT = new Integer(e1.intValue() * e2.intValue()); :}
              |
              expr:e1 DIVIDE expr:e2
              {: RESULT = new Integer(e1.intValue() / e2.intValue()); :}
              |
              expr:e1 MOD expr:e2
              {: RESULT = new Integer(e1.intValue() % e2.intValue()); :}
              |
              NUMBER:n
              {: RESULT = n; :}
              |
              MINUS expr:e
              {: RESULT = new Integer(0 - e.intValue()); :}
              %prec UMINUS
              |
              LPAREN expr:e RPAREN
              {: RESULT = e; :}
              ;


여기서 우리는 몇가지 바뀐점을 볼 수 있습니다. 가장 중요한 부분은 파서의 여러곳에서 실행될 코드가 {: 와 :}에 의해 구분된 코드 안에 포함되어 있다는 것입니다. 게다가, 레이블(label)들이 결과물의 우변에 있는 다양한 symbol들에 위치하고 있습니다. 예를 들어,

  expr:e1 PLUS expr:e2
        {: RESULT = new Integer(e1.intValue() + e2.intValue()); :}


첫번째 non-terminal 인 expr은 e1으로 레이블 표기 되었으며, 두번째는 e2로 되었습니다. 각 출력물의 좌변을 암묵적으로 항상 RESULT라고 레이블 표기합니다.

생성물에 나타난 각각의 심볼은 parse 스택에서 실행시에 심볼타입의 객체(object)에 의해 나타납니다. 레이블은 이 객체(object)들에서 Instance 변수 값을 참조합니다. 위의 소스표현 expr:e1 PLUS expr:e2 에서, e2와 e1은 정수형 객체를 참조합니다. 이 객체들은 parse 스택에서 이들의 non-terminal로 보이는 심볼형(Symbol type)의 값 영역에 있습니다. RESULT는 non-terminal expr이 정수형으로 선언되면서부터 정수형입니다. 이 객체는 새로운 심볼객체의 Instance 변수값이 됩니다.

각각의 레이블에 대해, 사용자가 접근 가능한 두 개 이상의 변수를 선언합니다. 그 좌우값 레이블은 코드 문자열로 전달되어서, 사용자가 입력 스트림에 있는 각각의 terminal 과 non-terminal의 좌우변이 어디 있는지 찾을 수 있습니다. 이 변수들의 이름은 레이블 이름에 leftright를 붙입니다. 예를 들어, 생성물의 우변에 있는 expr:e1 PLUS expr:e2는 사용자가 e1과 e2로 접근할 뿐만 아니라, e1left, e1right, e2left, e2ritght로도 접근이 가능합니다. 이 변수들의 타입은 정수형입니다.

파서 성생의 마지막 단계는 (잘 아시다시피 lexical analyzer 또는 간단히 lexer라고 하는) 스캐너를 제작하는 것입니다. 이 루틴은 개별 문자를 읽어들이고 공백이나 주석을 제거하고, 각 문자들의 집합이 나타내는 문법으로부터 terminal symbol을 인식하여, 파서에게 이러한 심볼들을 나타내는 심볼객체들(Symbol Objects)을 되돌려줘야 합니다. 그 terminal들은 스캐너 함수를 호출하기 위해 반환됩니다. 예를 들어, 파서가 scanner.next_token()을 호출할 것입니다. 스캐너는 java_cup.runtime.Symbol 형의 객체를 되돌려줘야 합니다. 이 자료형은 이전의 CUP에서 java_cup.runtime.symbol과는 아주 다릅니다. 이 심볼 객체는 문법분석기에 의해 설정될 객체형의 변수값 인스턴스를 포함하고 있습니다. 이 변수는 terminal과 non terminal 선언에서 선언된 같은 자료형의 값으로 심볼값과 객체형이 적용됩니다. 다음의 예제에서 만약 문법분석기가 NUMBER 토큰은 넘어가도록 원한다면, 정수형의 객체로 채워진 인스턴스 변수값을 갖는 심볼을 만들어야 합니다. terminal과 값을 갖지 않는 non-terminal들에 대한 심볼 객체들은 널 값 영역을 갖습니다.

The code contained in the init with clause of the specification will be executed before any tokens are requested. Each token will be requested using whatever code is found in the scan with clause. Beyond this, the exact form the scanner takes is up to you; however note that each call to the scanner function should return a new instance of java_cup.runtime.Symbol (or a subclass). These symbol objects are annotated with parser information and pushed onto a stack; reusing objects will result in the parser annotations being scrambled. As of CUP 0.10j, Symbol reuse should be detected if it occurs; the parser will throw an Error telling you to fix your scanner.

In the next section a more detailed and formal explanation of all parts of a CUP specification will be given. Section 3 describes options for running the CUP system. Section 4 discusses the details of how to customize a CUP parser, while section 5 discusses the scanner interface added in CUP 0.10j. Section 6 considers error recovery. Finally, Section 7 provides a conclusion.

4. 2. Specification Syntax

Now that we have seen a small example, we present a complete description of all parts of a CUP specification. A specification has four sections with a total of eight specific parts (however, most of these are optional). A specification consists of:

  • package and import specifications,
  • user code components,
  • symbol (terminal and non-terminal) lists,
  • precedence declarations, and
  • the grammar.

Each of these parts must appear in the order presented here. (A complete grammar for the specification language is given in Appendix A.) The particulars of each part of the specification are described in the subsections below.

5. Package and Import Specifications

A specification begins with optional package and import declarations. These have the same syntax, and play the same role, as the package and import declarations found in a normal Java program. A package declaration is of the form:

    package name;


where name name is a Java package identifier, possibly in several parts separated by ".". In general, CUP employs Java lexical conventions. So for example, both styles of Java comments are supported, and identifiers are constructed beginning with a letter, dollar sign ($), or underscore (_), which can then be followed by zero or more letters, numbers, dollar signs, and underscores.

After an optional package declaration, there can be zero or more import declarations. As in a Java program these have the form:

    import package_name.class_name;


or

    import package_name.*;


The package declaration indicates what package the sym and parser classes that are generated by the system will be in. Any import declarations that appear in the specification will also appear in the source file for the parser class allowing various names from that package to be used directly in user supplied action code. User Code Components Following the optional package and import declarations are a series of optional declarations that allow user code to be included as part of the generated parser (see Section 4 for a full description of how the parser uses this code). As a part of the parser file, a separate non-public class to contain all embedded user actions is produced. The first action code declaration section allows code to be included in this class. Routines and variables for use by the code embedded in the grammar would normally be placed in this section (a typical example might be symbol table manipulation routines). This declaration takes the form:

    action code {: ... :};


where {: ... :} is a code string whose contents will be placed directly within the action class class declaration.

After the action code declaration is an optional parser code declaration. This declaration allows methods and variable to be placed directly within the generated parser class. Although this is less common, it can be helpful when customizing the parser &emdash; it is possible for example, to include scanning methods inside the parser and/or override the default error reporting routines. This declaration is very similar to the action code declaration and takes the form:

    parser code {: ... :};


Again, code from the code string is placed directly into the generated parser class definition.

Next in the specification is the optional init declaration which has the form:

    init with {: ... :};


This declaration provides code that will be executed by the parser before it asks for the first token. Typically, this is used to initialize the scanner as well as various tables and other data structures that might be needed by semantic actions. In this case, the code given in the code string forms the body of a void method inside the parser class.

The final (optional) user code section of the specification indicates how the parser should ask for the next token from the scanner. This has the form:

    scan with {: ... :};


As with the init clause, the contents of the code string forms the body of a method in the generated parser. However, in this case the method returns an object of type java_cup.runtime.Symbol. Consequently the code found in the scan with clause should return such a value. See section 5 for information on the default behavior if the scan with section is omitted.

As of CUP 0.10j the action code, parser code, init code, and scan with sections may appear in any order. They must, however, precede the symbol lists.

6. Symbol Lists

Following user supplied code comes the first required part of the specification: the symbol lists. These declarations are responsible for naming and supplying a type for each terminal and non-terminal symbol that appears in the grammar. As indicated above, each terminal and non-terminal symbol is represented at runtime with a Symbol object. In the case of terminals, these are returned by the scanner and placed on the parse stack. The lexer should put the value of the terminal in the value instance variable. In the case of non-terminals these replace a series of Symbol objects on the parse stack whenever the right hand side of some production is recognized. In order to tell the parser which object types should be used for which symbol, terminal and non terminal declarations are used. These take the forms:

    terminal classname name1, name2, ...;
    non terminal classname name1, name2, ...;
    terminal name1, name2, ...;


and

    non terminal name1, name2, ...;


where classname can be a multiple part name separated with "."s. The classname specified represents the type of the value of that terminal or non-terminal. When accessing these values through labels, the users uses the type declared. the classname can be of any type. If no classname is given, then the terminal or non-terminal holds no value. a label referring to such a symbol with have a null value. As of CUP 0.10j, you may specify non-terminals the declaration "nonterminal" (note, no space) as well as the original "non terminal" spelling.

Names of terminals and non-terminals cannot be CUP reserved words; these include "code", "action", "parser", "terminal", "non", "nonterminal", "init", "scan", "with", "start", "precedence", "left", "right", "nonassoc", "import", and "package".

Precedence and Associativity declarations The third section, which is optional, specifies the precedences and associativity of terminals. This is useful for parsing with ambiguous grammars, as done in the example above. There are three type of precedence/associativity declarations:

        precedence left     terminal[, terminal...];
        precedence right    terminal[, terminal...];
        precedence nonassoc terminal[, terminal...];


The comma separated list indicates that those terminals should have the associativity specified at that precedence level and the precedence of that declaration. The order of precedence, from highest to lowest, is bottom to top. Hence, this declares that multiplication and division have higher precedence than addition and subtraction:

        precedence left  ADD, SUBTRACT;
        precedence left  TIMES, DIVIDE;


Precedence resolves shift reduce problems. For example, given the input to the above example parser 3 + 4 * 8, the parser doesn't know whether to reduce 3 + 4 or shift the '*' onto the stack. However, since '*' has a higher precedence than '+', it will be shifted and the multiplication will be performed before the addition.

CUP assigns each one of its terminals a precedence according to these declarations. Any terminals not in this declaration have lowest precedence. CUP also assigns each of its productions a precedence. That precedence is equal to the precedence of the last terminal in that production. If the production has no terminals, then it has lowest precedence. For example, expr ::= expr TIMES expr would have the same precedence as TIMES. When there is a shift/reduce conflict, the parser determines whether the terminal to be shifted has a higher precedence, or if the production to reduce by does. If the terminal has higher precedence, it it shifted, if the production has higher precedence, a reduce is performed. If they have equal precedence, associativity of the terminal determine what happens.

An associativity is assigned to each terminal used in the precedence/associativity declarations. The three associativities are left, right and nonassoc Associativities are also used to resolve shift/reduce conflicts, but only in the case of equal precedences. If the associativity of the terminal that can be shifted is left, then a reduce is performed. This means, if the input is a string of additions, like 3 + 4 + 5 + 6 + 7, the parser will always reduce them from left to right, in this case, starting with 3 + 4. If the associativity of the terminal is right, it is shifted onto the stack. hence, the reductions will take place from right to left. So, if PLUS were declared with associativity of right, the 6 + 7 would be reduced first in the above string. If a terminal is declared as nonassoc, then two consecutive occurrences of equal precedence non-associative terminals generates an error. This is useful for comparison operations. For example, if the input string is 6 == 7 == 8 == 9, the parser should generate an error. If '==' is declared as nonassoc then an error will be generated.

All terminals not used in the precedence/associativity declarations are treated as lowest precedence. If a shift/reduce error results, involving two such terminals, it cannot be resolved, as the above conflicts are, so it will be reported.

7. The Grammar

The final section of a CUP declaration provides the grammar. This section optionally starts with a declaration of the form:

    start with non-terminal;


이것은 어떤 non-terminal이 파싱의 시작이나 혹은 종결하는 non-terminal인지 가리킨다. 만약 시작하는 non-terminal이 explicitly하게 선언되지 않으면, 척번째 production의 좌변의 non-terminal이 사용될 것이다. 파싱을 성공적으로 끝낸 후에, CUP는 java_cup.runtime.Symbol을 리턴한다. 이 Symbol의 value instance variable은 마지막 reduction result를 갖는다

The grammar itself follows the optional start declaration. 문법의 각각의 production은 좌변에 non-terminal이, 그리고 "::="가 붙고, zero or more개의 actions, terminal, or non-terminal symbols, followed by an optional contextual precedence assignment, and terminated with a semicolon (;).. 들이 온다.

우변의 각각의 symbol은 이름을 붙여 labeled 될 수 있다. label name은 symbol name 뒤에 colon (:) 다음에 붙인다. label name은 그 production에서 유일해야하며, action code에서 symbol의 value를 참조하는데 쓰일 수 있다. Along with the label, two more variables are created, which are the label plus left and the label plus right. These are int values that contain the right and left locations of what the terminal or non-terminal covers in the input file. These values must be properly initialized in the terminals by the lexer. The left and right values then propagate to non-terminals to which productions reduce.

만약 같은 non-terminal에 대해 여러개의 production이 있으면 함께 선언할 수 있다. 이 경우, production은 non-terminal과 ::= 로 시작된다. 그리고 여러개의 우변들이, 각각 bar (|) 로 나뉘어 딸린다. production의 full set은 semicolon에 의해 끝난다.

action은 code strings (e.g., Java code inside {: ... :} delimiters) 로 나타난다. 이것들은 the portion of the production to the left of the action이 인식 되는 시점에 실행된다. (Note that the scanner will have returned the token one past the point of the action since the parser needs this extra lookahead token for recognition.)

Contextual precedence assignments follow all the symbols and actions of the right hand side of the production whose precedence it is assigning. Contextual precedence assignment allows a production to be assigned a precedence not based on the last terminal in it. A good example is shown in the above sample parser specification:

        precedence left PLUS, MINUS;
        precedence left TIMES, DIVIDE, MOD;
        precedence left UMINUS;

        expr ::=  MINUS expr:e
                  {: RESULT = new Integer(0 - e.intValue()); :}
                  %prec UMINUS


Here, there production is declared as having the precedence of UMINUS. Hence, the parser can give the MINUS sign two different precedences, depending on whether it is a unary minus or a subtraction operation.

8. 3. Running CUP

As mentioned above, CUP is written in Java. To invoke it, one needs to use the Java interpreter to invoke the static method java_cup.Main(), passing an array of strings containing options. Assuming a Unix machine, the simplest way to do this is typically to invoke it directly from the command line with a command such as:

    java java_cup.Main options < inputfile


Once running, CUP expects to find a specification file on standard input and produces two Java source files as output.

In addition to the specification file, CUP's behavior can also be changed by passing various options to it. Legal options are documented in Main.java and include:

  • -package name

Specify that the parser and sym classes are to be placed in the named package. By default, no package specification is put in the generated code (hence the classes default to the special "unnamed" package).
  • -parser name

parser와 action code를 주어진 이름의 파일(클래스이기도 한)에 출력한다. 기본값은 "parser"
  • -symbols name

symbol constant code를 주어진 이름의 클래스에 내보낸다. 기본값은 "sym"
  • -interface

symbol constant code를 class로 하지 않고 interface로 내보낸다.
  • -nonterms

Place constants for non-terminals into the symbol constant class. The parser does not need these symbol constants, so they are not normally output. However, it can be very helpful to refer to these constants when debugging a generated parser.
  • -expect number

During parser construction the system may detect that an ambiguous situation would occur at runtime. This is called a conflict. In general, the parser may be unable to decide whether to shift (read another symbol) or reduce (replace the recognized right hand side of a production with its left hand side). This is called a shift/reduce conflict. Similarly, the parser may not be able to decide between reduction with two different productions. This is called a reduce/reduce conflict. Normally, if one or more of these conflicts occur, parser generation is aborted. However, in certain carefully considered cases it may be advantageous to arbitrarily break such a conflict. In this case CUP uses YACC convention and resolves shift/reduce conflicts by shifting, and reduce/reduce conflicts using the "highest priority" production (the one declared first in the specification). In order to enable automatic breaking of conflicts the -expect option must be given indicating exactly how many conflicts are expected. Conflicts resolved by precedences and associativities are not reported.
  • -compact_red

Including this option enables a table compaction optimization involving reductions. In particular, it allows the most common reduce entry in each row of the parse action table to be used as the default for that row. This typically saves considerable room in the tables, which can grow to be very large. This optimization has the effect of replacing all error entries in a row with the default reduce entry. While this may sound dangerous, if not down right incorrect, it turns out that this does not affect the correctness of the parser. In particular, some changes of this type are inherent in LALR parsers (when compared to canonical LR parsers), and the resulting parsers will still never read past the first token at which the error could be detected. The parser can, however, make extra erroneous reduces before detecting the error, so this can degrade the parser's ability to do error recovery. (Refer to reference 2 pp. 244-247 or reference 3 pp. 190-194 for a complete explanation of this compaction technique.)

This option is typically used to work-around the java bytecode limitations on table initialization code sizes. However, CUP 0.10h introduced a string-encoding for the parser tables which is not subject to the standard method-size limitations. Consequently, use of this option should no longer be required for large grammars.
  • -nowarn

This options causes all warning messages (as opposed to error messages) produced by the system to be suppressed.
  • -nosummary

Normally, the system prints a summary listing such things as the number of terminals, non-terminals, parse states, etc. at the end of its run. This option suppresses that summary.
  • -progress

This option causes the system to print short messages indicating its progress through various parts of the parser generation process.
  • -dump_grammar
  • -dump_states
  • -dump_tables
  • -dump

These options cause the system to produce a human readable dump of the grammar, the constructed parse states (often needed to resolve parse conflicts), and the parse tables (rarely needed), respectively. The -dump option can be used to produce all of these dumps.
  • -time

This option adds detailed timing statistics to the normal summary of results. This is normally of great interest only to maintainers of the system itself.
  • -debug

This option produces voluminous internal debugging information about the system as it runs. This is normally of interest only to maintainers of the system itself.
  • -nopositions

This option keeps CUP from generating code to propagate the left and right hand values of terminals to non-terminals, and then from non-terminals to other terminals. If the left and right values aren't going to be used by the parser, then it will save some runtime computation to not generate these position propagations. This option also keeps the left and right label variables from being generated, so any reference to these will cause an error.
  • -noscanner

CUP 0.10j introduced improved scanner integration and a new interface, java_cup.runtime.Scanner. By default, the generated parser refers to this interface, which means you cannot use these parsers with CUP runtimes older than 0.10j. If your parser does not use the new scanner integration features, then you may specify the -noscanner option to suppress the java_cup.runtime.Scanner references and allow compatibility with old runtimes. Not many people should have reason to do this.
  • -version

Invoking CUP with the -version flag will cause it to print out the working version of CUP and halt. This allows automated CUP version checking for Makefiles, install scripts and other applications which may require it.

9. 4. Customizing the Parser

Each generated parser consists of three generated classes. The sym class (which can be renamed using the -symbols option) simply contains a series of int constants, one for each terminal. Non-terminals are also included if the -nonterms option is given. The source file for the parser class (which can be renamed using the -parser option) actually contains two class definitions, the public parser class that implements the actual parser, and another non-public class (called CUP$action) which encapsulates all user actions contained in the grammar, as well as code from the action code declaration. In addition to user supplied code, this class contains one method: CUP$do_action which consists of a large switch statement for selecting and executing various fragments of user supplied action code. In general, all names beginning with the prefix of CUP$ are reserved for internal uses by CUP generated code.

The parser class contains the actual generated parser. It is a subclass of java_cup.runtime.lr_parser which implements a general table driven framework for an LR parser. The generated parser class provides a series of tables for use by the general framework. Three tables are provided:

  • the production table

provides the symbol number of the left hand side non-terminal, along with the length of the right hand side, for each production in the grammar,
  • the action table

indicates what action (shift, reduce, or error) is to be taken on each lookahead symbol when encountered in each state, and
  • the reduce-goto table

indicates which state to shift to after reduces (under each non-terminal from each state).

(Note that the action and reduce-goto tables are not stored as simple arrays, but use a compacted "list" structure to save a significant amount of space. See comments the runtime system source code for details.)

Beyond the parse tables, generated (or inherited) code provides a series of methods that can be used to customize the generated parser. Some of these methods are supplied by code found in part of the specification and can be customized directly in that fashion. The others are provided by the lr_parser base class and can be overridden with new versions (via the parser code declaration) to customize the system. Methods available for customization include:

  • public void user_init()

이 method는 parser가 scanner에게서 token을 처음으로 요청하기 전에 호출된다. 이 method의 body는 specification의 init with 구문의 내용이다.
  • public java_cup.runtime.Symbol scan()

이 method는 scanner를 캡슐화하고, 새로운 terminal이 필요할 때마다 parser에 의해 호출된다. 이 method의 body는 scan with 구문의 내용이다. 만약 없을 경우 이는 getScanner().next_token()을 리턴한다.
  • public java_cup.runtime.Scanner getScanner()

default scanner를 리턴한다. See section 5.
  • public void setScanner(java_cup.runtime.Scanner s)

default scanner를 지정한다. See section 5.
  • public void report_error(String message, Object info)

이 method는 error message가 필요 할 때마다 호출된다. 이 method의 기본구현은, 첫번째 parameter는 System.err에 출력될 message이고, 두번째 parameter는 무시돤다. 더 복잡한 error reporting mechanism을 위해 이 method를 흔히 override한다.
  • public void report_fatal_error(String message, Object info)

이 method는 non-recoverable error가 발생할 때 마다 호출된다. 이는 report_error()를 호출하며 반응하고, 그리고 parser method done_parsing()을 호출하여 parsing을 중단시키고, exception을 throw한다. (보통, done_parsing()은 parsing이 더 일찍 끝날 필요가 있을때 호출된다)
  • public void syntax_error(Symbol cur_token)

이 method는 syntax error가 감지되었을 때 parser가 호출한다. (단, error recovery가 시도되기 전에) 기본 구현은 report_error("Syntax error", null); 이다
  • public void unrecovered_syntax_error(Symbol cur_token)

이 method는 syntax error를 recover하지 못할 때 parser가 호출한다. 기본 구현은 report_fatal_error("Couldn't repair and continue parse", null); 이다
  • protected int error_sync_size()

This method is called by the parser to determine how many tokens it must successfully parse in order to consider an error recovery successful. 기본 구현은 3을 return 한다. 2이하의 값은 추천하지 않는다. See the section on error recovery for details.

parsing 자체는 method public Symbol parse()에 의해 수행된다. 이 method는 각각 parse table에서 각각의 reference를 찾으며 시작하고, CUP$action object를 초기화한다 (protected void init_actions()를 부른다). 그다음 이는 user_init()를 호출하고, scan()을 호출하여 fetches the first lookahead한다. Finally, it begins parsing. Parsing은 done_parsing()이 호출될 때까지 계속 된다. (이것은 자동으로 불린다. 예를 들어 parser가 accepts할 때) 그러면 start production의 RESULT를 포함하는 value instance variable을 가지는 Symbol 혹은 그 value가 없을 경우 null 을 리턴한다.

normal parser에 덧붙여서, runtime system은 debugging version의 parser를 제공한다. 이는 normal parser와 정확히 동일하게 동작하고, 다만 기본적으로는 System.err에 출력되는 debugging messages를 출력한다. (void debug_message(String mess)를 호출한다)

Based on these routines, invocation of a CUP parser is typically done with code such as:

      /* create a parsing object */
      parser parser_obj = new parser();

      /* open input files, etc. here */
      Symbol parse_tree = null;

      try {
        if (do_debug_parse)
          parse_tree = parser_obj.debug_parse();
        else
          parse_tree = parser_obj.parse();
      } catch (Exception e) {
        /* do cleanup here - - possibly rethrow e */
      } finally {
        /* do close out here */
      }


10. 5. Scanner Interface

In CUP 0.10j, scanner integration was improved according to suggestions made by David MacMahon. The changes make it easier to incorporate JLex and other automatically-generated scanners into CUP parsers.

To use the new code, your scanner should implement the java_cup.runtime.Scanner interface, defined as:

package java_cup.runtime;

public interface Scanner {
    public Symbol next_token() throws java.lang.Exception;
}


In addition to the methods described in section 4, the java_cup.runtime.lr_parser class has two new accessor methods, setScanner() and getScanner(). The default implementation of scan() is:

  public Symbol scan() throws java.lang.Exception {
    return getScanner().next_token();
  }


The generated parser also contains a constructor which takes a Scanner and calls setScanner() with it. In most cases, then, the init with and scan with directives may be omitted. You can simply create the parser with a reference to the desired scanner:

      /* create a parsing object */
      parser parser_obj = new parser(new my_scanner());


or set the scanner after the parser is created:

      /* create a parsing object */
      parser parser_obj = new parser();
      /* set the default scanner */
      parser_obj.setScanner(new my_scanner());


Note that because the parser uses look-ahead, resetting the scanner in the middle of a parse is not recommended. If you attempt to use the default implementation of scan() without first calling setScanner(), a NullPointerException will be thrown.

As an example of scanner integration, the following three lines in the lexer-generator input are all that is required to use a JLex scanner with CUP:

%implements java_cup.runtime.Scanner
%function next_token
%type java_cup.runtime.Symbol


It is anticipated that the JLex directive %cup will abbreviate the above three directive in the next version of JLex. Invoking the parser with the JLex scanner is then simply:

parser parser_obj = new parser( new Yylex( some_InputStream_or_Reader));


Note that you still have to handle EOF correctly; the JLex code to do so is something like:

%eofval{
  return sym.EOF;
%eofval}


where sym is the name of the symbol class for your generated parser.

The simple_calc example in the CUP distribution illustrates the use of the scanner integration features with a hand-coded scanner.

11. 6. Error Recovery

CUP으로 parsers를 만들때 가장 중요한 점은, syntactic error의 복구를 지원한다는 점이다. CUP은 YACC과 같은 error recovery mechanism을 사용한다. In particular, CUP은 특별한 error symbol을 지원한다. (간단히 error이다) This symbol plays the role of a special non-terminal which, instead of being defined by productions, instead matches an erroneous input sequence.

이 error symbol은 syntax error가 감지되었을 때에만 적용된다. 만약 syntax error가 감지되면 parser는 input token stream의 부분을 error로 replace하고, parsing을 계속한다. 예를 들어서 우리는 다음과 같은 production을 가진다고 하자 :

    stmt ::= expr SEMI | while_stmt SEMI | if_stmt SEMI | <b>..</b>. |
             error SEMI
             ;


이것은 input에 의해서 stmt의 어떠한 normal과도 일치하지 않을때, syntax error가 선언되고, recovery should be made by skipping erroneous tokens (equivalent to matching and replacing them with error) up to a point at which the parse can be continued with a semicolon (and additional context that legally follows a statement). An error is considered to be recovered from if and only if a sufficient number of tokens past the error symbol can be successfully parsed. (The number of tokens required is determined by the error_sync_size() method of the parser and defaults to 3).

Specifically, the parser first looks for the closest state to the top of the parse stack that has an outgoing transition under error. This generally corresponds to working from productions that represent more detailed constructs (such as a specific kind of statement) up to productions that represent more general or enclosing constructs (such as the general production for all statements or a production representing a whole section of declarations) until we get to a place where an error recovery production has been provided for. Once the parser is placed into a configuration that has an immediate error recovery (by popping the stack to the first such state), the parser begins skipping tokens to find a point at which the parse can be continued. After discarding each token, the parser attempts to parse ahead in the input (without executing any embedded semantic actions). If the parser can successfully parse past the required number of tokens, then the input is backed up to the point of recovery and the parse is resumed normally (executing all actions). If the parse cannot be continued far enough, then another token is discarded and the parser again tries to parse ahead. If the end of input is reached without making a successful recovery (or there was no suitable error recovery state found on the parse stack to begin with) then error recovery fails.

12. 7. Conclusion

이 manual은 CUP LALR parser generation system을 간단히 서술하였다. CUP은 유명한 YACC parser와 비슷한 역할을 하지만, C나 C++이 아닌 JAVA code로 쓰여졌고, 동작한다. system의 operation의 세부적인 사항은 parser generator와 runtime의 source code에서 알 수 있다. See the CUP home page below for access to the API documentation for the system and its runtime.

This document covers version 0.10j of the system. Check the CUP home page: [http]http://www.cs.princeton.edu/~appel/modern/java/CUP/ for the latest release information, instructions for downloading the system, and additional news about CUP. Bug reports and other comments for the developers should be sent to the CUP maintainer, C. Scott Ananian, at cananian@alumni.princeton.edu

CUP was originally written by Scott Hudson, in August of 1995.

It was extended to support precedence by Frank Flannery, in July of 1996.

On-going improvements have been done by C. Scott Ananian, the CUP maintainer, from December of 1997 to the present.

13. References


1

S. C. Johnson, "YACC &emdash; Yet Another Compiler Compiler", CS Technical Report #32, Bell Telephone Laboratories, Murray Hill, NJ, 1975.

2
  • Aho, R. Sethi, and J. Ullman, Compilers: Principles, Techniques, and Tools, Addison-Wesley Publishing, Reading, MA, 1986.
3

C. Fischer, and R. LeBlanc, Crafting a Compiler with C, Benjamin/Cummings Publishing, Redwood City, CA, 1991.

14. Appendix A. Grammar for CUP Specification Files (0.10j)


java_cup_spec      ::= package_spec import_list code_parts
                       symbol_list precedence_list start_spec
                       production_list
package_spec       ::= PACKAGE multipart_id SEMI | empty
import_list        ::= import_list import_spec | empty
import_spec        ::= IMPORT import_id SEMI
code_part          ::= action_code_part | parser_code_part |
                       init_code | scan_code
code_parts         ::= code_parts code_part | empty
action_code_part   ::= ACTION CODE CODE_STRING opt_semi
parser_code_part   ::= PARSER CODE CODE_STRING opt_semi
init_code          ::= INIT WITH CODE_STRING opt_semi
scan_code          ::= SCAN WITH CODE_STRING opt_semi
symbol_list        ::= symbol_list symbol | symbol
symbol             ::= TERMINAL type_id declares_term |
                       NON TERMINAL type_id declares_non_term |
                       NONTERMINAL type_id declares_non_term |
                       TERMINAL declares_term |
                       NON TERMINAL declares_non_term |
                       NONTERMIANL declared_non_term
term_name_list     ::= term_name_list COMMA new_term_id | new_term_id
non_term_name_list ::= non_term_name_list COMMA new_non_term_id |
                       new_non_term_id
declares_term      ::= term_name_list SEMI
declares_non_term  ::= non_term_name_list SEMI
precedence_list    ::= precedence_l | empty
precedence_l       ::= precedence_l preced + preced;
preced             ::= PRECEDENCE LEFT terminal_list SEMI
                       | PRECEDENCE RIGHT terminal_list SEMI
                       | PRECEDENCE NONASSOC terminal_list SEMI
terminal_list      ::= terminal_list COMMA terminal_id | terminal_id
start_spec         ::= START WITH nt_id SEMI | empty
production_list    ::= production_list production | production
production         ::= nt_id COLON_COLON_EQUALS rhs_list SEMI
rhs_list           ::= rhs_list BAR rhs | rhs
rhs                ::= prod_part_list PERCENT_PREC term_id |
                       prod_part_list
prod_part_list     ::= prod_part_list prod_part | empty
prod_part          ::= symbol_id opt_label | CODE_STRING
opt_label          ::= COLON label_id | empty
multipart_id       ::= multipart_id DOT ID | ID
import_id          ::= multipart_id DOT STAR | multipart_id
type_id            ::= multipart_id
terminal_id        ::= term_id
term_id            ::= symbol_id
new_term_id        ::= ID
new_non_term_id    ::= ID
nt_id              ::= ID
symbol_id          ::= ID
label_id           ::= ID
opt_semi           ::= SEMI | empty


15. Appendix B. A Very Simple Example Scanner


// Simple Example Scanner Class

import java_cup.runtime.*;
import sym;

public class scanner {
  /* single lookahead character */
  protected static int next_char;

  /* advance input by one character */
  protected static void advance()
    throws java.io.IOException
    { next_char = System.in.read(); }

  /* initialize the scanner */
  public static void init()
    throws java.io.IOException
    { advance(); }

  /* recognize and return the next complete token */
  public static Symbol next_token()
    throws java.io.IOException
    {
      for (;;)
        switch (next_char)
          {
            case '0': case '1': case '2': case '3': case '4':
            case '5': case '6': case '7': case '8': case '9':
              /* parse a decimal integer */
              int i_val = 0;
              do {
                i_val = i_val * 10 + (next_char - '0');
                advance();
              } while (next_char >= '0' && next_char <= '9');
            return new Symbol(sym.NUMBER, new Integer(i_val));

            case ';': advance(); return new Symbol(sym.SEMI);
            case '+': advance(); return new Symbol(sym.PLUS);
            case '-': advance(); return new Symbol(sym.MINUS);
            case '*': advance(); return new Symbol(sym.TIMES);
            case '/': advance(); return new Symbol(sym.DIVIDE);
            case '%': advance(); return new Symbol(sym.MOD);
            case '(': advance(); return new Symbol(sym.LPAREN);
            case ')': advance(); return new Symbol(sym.RPAREN);

            case -1: return new Symbol(sym.EOF);

            default:
              /* in this simple scanner we just ignore everything else */
              advance();
            break;
          }
    }
};


16. Appendix C: Incompatibilites between CUP 0.9 and CUP 0.10

CUP version 0.10a is a major overhaul of CUP. The changes are severe, meaning no backwards compatibility to older versions. The changes consist of:

  • A different lexical interface,
  • New terminal/non-terminal declarations,
  • Different label references,
  • A different way of passing RESULT,
  • New position values and propagation,
  • Parser now returns a value,
  • Terminal precedence declarations and
  • Rule contextual precedence assignment

17. Lexical Interface

CUP now interfaces with the lexer in a completely different manner. In the previous releases, a new class was used for every distinct type of terminal. This release, however, uses only one class: The Symbol class. The Symbol class has three instance variables which are significant to the parser when passing information from the lexer. The first is the value instance variable. This variable contains the value of that terminal. It is of the type declared as the terminal type in the parser specification file. The second two are the instance variables left and right. They should be filled with the int value of where in the input file, character-wise, that terminal was found.

For more information, refer to the manual on scanners.

18. Terminal/Non-Terminal Declarations

Terminal and non-terminal declarations now can be declared in two different ways to indicate the values of the terminals or non-terminals. The previous declarations of the form

terminal classname terminal [, terminal ...];


still works. The classname, however indicates the type of the value of the terminal or non-terminal, and does not indicate the type of object placed on the parse stack. A declaration, such as:

terminal terminal [, terminal ...];


indicates the terminals in the list hold no value.

For more information, refer to the manual on declarations.

19. Label References

Label references do not refer to the object on the parse stack, as in the old CUP, but rather to the value of the value instance variable of the Symbol that represents that terminal or non-terminal. Hence, references to terminal and non-terminal values is direct, as opposed to the old CUP, where the labels referred to objects containing the value of the terminal or non-terminal.

For more information, refer to the manual on labels.

20. RESULT Value

The RESULT variable refers directly to the value of the non-terminal to which a rule reduces, rather than to the object on the parse stack. Hence, RESULT is of the same type the non-terminal to which it reduces, as declared in the non-terminal declaration. Again, the reference is direct, rather than to something that will contain the data.

For more information, refer to the manual on RESULT.

21. Position Propagation

For every label, two more variables are declared, which are the label plus left or the label plus right. These correspond to the left and right locations in the input stream to which that terminal or non-terminal came from. These values are propagated from the input terminals, so that the starting non-terminal should have a left value of 0 and a right value of the location of the last character read.

For more information, refer to the manual on positions.

22. Return Value

A call to parse() or debug_parse() returns a Symbol. This Symbol is the start non-terminal, so the value instance variable contains the final RESULT assignment.

23. Precedence

CUP now has precedenced terminals. a new declaration section, occurring between the terminal and non-terminal declarations and the grammar specifies the precedence and associativity of rules. The declarations are of the form:

precedence {left| right | nonassoc} terminal[, terminal ...];
<b>..</b>.


The terminals are assigned a precedence, where terminals on the same line have equal precedences, and the precedence declarations farther down the list of precedence declarations have higher precedence. left, right and nonassoc specify the associativity of these terminals. left associativity corresponds to a reduce on conflict, right to a shift on conflict, and nonassoc to an error on conflict. Hence, ambiguous grammars may now be used.

For more information, refer to the manual on precedence.

24. Contextual Precedence

Finally the new CUP adds contextual precedence. A production may be declare as followed:

lhs ::= {right hand side list of terminals, non-terminals and actions}
        %prec {terminal};


this production would then have a precedence equal to the terminal specified after the %prec. Hence, shift/reduce conflicts can be contextually resolved. Note that the %prec terminal part comes after all actions strings. It does not come before the last action string.

For more information, refer to the manual on contextual precedence. These changes implemented by: Frank Flannery Department of Computer Science Princeton University

25. Appendix D: Bugs

In this version of CUP it's difficult for the semantic action phrases (Java code attached to productions) to access the report_error method and other similar methods and objects defined in the parser code directive.

This is because the parsing tables (and parsing engine) are in one object (belonging to class parser or whatever name is specified by the -parser directive), and the semantic actions are in another object (of class CUP$actions).

However, there is a way to do it, though it's a bit inelegant. The action object has a private final field named parser that points to the parsing object. Thus, methods and instance variables of the parser can be accessed within semantic actions as:

parser.report_error(message,info);
x = parser.mydata;

Perhaps this will not be necessary in a future release, and that such methods and variables as report_error and mydata will be available directly from the semantic actions; we will achieve this by combining the "parser" object and the "actions" object together.

For a list of any other currently known bugs in CUP, see [http]http://www.cs.princeton.edu/~appel/modern/java/CUP/bugs.html.

26. Appendix E: Change log


0.9e

March 1996, Scott Hudson's original version.

0.10a

August 1996, several major changes to the interface.

0.10b

November 1996, fixes a few minor bugs.

0.10c

July 1997, fixes a bug related to precedence declarations.

0.10e

September 1997, fixes a bug introduced in 0.10c relating to nonassoc precedence. Thanks to Tony Hosking for reporting the bug and providing the fix. Also recognizes carriage-return character as white space and fixes a number of other small bugs.

0.10f

December 1997, was a maintenance release. The CUP source was cleaned up for JDK 1.1.

0.10g

March 1998, adds new features and fixes old bugs. The behavior of RESULT assignments was normalized, and a problem with implicit start productions was fixed. The CUP grammar was extended to allow array types for terminals and non-terminals, and a command-line flag was added to allow the generation of a symbol interface, rather than class. Bugs associated with multiple invocations of a single parser object and multiple CUP classes in one package have been stomped on. Documentation was updated, as well.

0.10h-0.10i

February 1999, are maintenance releases.

0.10j

July 1999, broadened the CUP input grammar to allow more flexibility and improved scanner integration via the java_cup.runtime.Scanner interface.

Java and HotJava are trademarks of Sun Microsystems, Inc., and refer to Sun's Java programming language and HotJava browser technologies. CUP is not sponsored by or affiliated with Sun Microsystems, Inc.



ID
Password
Join
"It seems strange to meet computer geeks who're still primarily running Windows... as if they were still cooking on a wood stove or something." - mbp


sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2005-01-07 03:56:47
Processing time 0.1802 sec