Abstract. Programs written in languages of the Oberon family usually. contain runtime tests on the dynamic type of variables.

Transcription

1 Type Test Elimination using Typeow Analysis Diane Corney and John Gough Queensland University of Technology, Brisbane, Australia Abstract. Programs written in languages of the Oberon family usually contain runtime tests on the dynamic type of variables. In some cases it may be desirable to reduce the number of such tests. Typeow analysis is a static method of determining bounds on the types that objects may possess at runtime. We show that this analysis is able to reduce the number of tests in certain plausible circumstances. Furthermore, the same analysis is able to detect certain program errors at compile time, which would normally only be detected at program execution. This paper introduces the concepts of typeow analysis and details its use in the reduction of runtime overhead in Oberon-2. 1 Introduction Implementations of object-oriented languages based on type extension[1] such as Oberon[2] and Oberon-2 [3] must perform tests on the dynamic type of objects. These type tests are comparable in runtime cost to the index bounds checks of Pascal-like languages[4]. Just as it is possible to eliminate much of the overhead of index bounds checking by careful static analysis of programs (see [5], for example, for a recent review), so it is possible to eliminate some of the runtime cost of type testing. In this paper we introduce the concept of typeow analysis, which has some similarities to dataow analysis, and explain how these concepts have been implemented to achieve this objective in an Oberon-2 compiler. Section 2 discusses type extension as a form of inheritance and introduces a notation for type extension and explains its use. Section 3 shows how conventional common subexpression elimination may be used to eliminate some type tests. However, we show that this method falls short of detecting some obvious redundancies, demonstrating the need for a more careful analysis. A discussion is given in Section 4 of the concepts of typeow analysis and its relation to control ow. The notion of a manifest type is introduced and its use in tracking variable types during this form of static analysis is explained. For dierent control ow constructs, the manner in which the manifest type may be updated is discussed, and examples given. Section 5 discusses the testing of an implementation of typeow analysis limited to some simple cases. Consideration is given as to how typeow analysis might be fully implemented and utilised. This work is supported by the Cooperative Research Centre for Distributed Systems Technology

2 2 Inheritance and Type Extension Type extension is a data structuring mechanism introduced by Niklaus Wirth in the language Oberon. It allows record types to be declared which extend previously declared record types by the addition of extra elds. This mechanism is a form of single inheritance and allows a type hierarchy to be constructed. 2.1 Notation If there is a type T 0, which we shall call a base type, and T 1 is an extension of T 0, then we denote this T 1 > T 0. We say that T 1 is a direct extension of T 0. However, T 1 could then be further extended, so that T 2 > T 1, and so on. The reexive transitive closure of the extends relation is denoted >. For example, T n > T m states that T n is a (possibly indirect) extension of T m, or else T n = T m. The language semantics provide that references to objects may be assigned bound objects of any type which is an extension of the statically declared bound type of the reference. When a program makes an access to a selected component belonging only to certain extensions of a type, the designator of the selector component contains a type guard. This type guard is an assertion that the dynamic type of the object will be in the `extends' relation of the nominated type, and causes a runtime test to be generated. Syntactically the type guard is denoted by a type name, appearing in parenthesis, following the denoter of the referenced object. For example, the designator exp(binop).op asserts that the object referenced by exp is dynamically of a type which is in the > relation with the type BinOp. It should be noted that the word \type" in this connection has its conventional meaning in strongly typed languages. This is in constrast to the use of the word to refer to a nite set of classes, as discussed in [8], for example. In our notation, all types are distinct, and an object has a unique type at every epoch of its lifetime. 3 The Limitations of Common Subexpression Elimination Some type tests may be eliminated by conventional common subexpression elimination. Consider a situation where a type Expr has several extensions including a BinOp type, and the BinOp type has extensions Plus and Star. The relevant part of the type hierarchy is shown in Figure 1. A typical fragment of code might be -... exp(binop).leftexp...;... exp(binop).rightexp...; It is clear that if the type guard is treated as a unary operator on the object designator, the second of the two runtime tests may be eliminated. In eect, the tested value becomes a common subexpression.

3 Q Q Q Q Q Q R@ Unary Expr Plus Binop Star Fig. 1. Fragment of type hierarchy Unfortunately, this mechanism is insucient to eliminate all unnecessary tests. Consider the fragment -... exp(plus).field1...;... exp(binop).field2...; In this case the second test is redundant (since if an object is an extension of type Plus it is necessarily an extension of type BinOp), although there is no common subexpression. exp:=starvar exp:=plusvar Q Qs + exp(binop).leftexp Fig. 2. Merging control ow Global ow of type information must also be taken into account. Consider the control ow graph fragment in Figure 2, where the variables have static types as indicated by their names. In this case, understanding the semantics of the type system, we can deduce that the type guard in the successor block is redundant, since all paths leading to that block set the type to an extension of the BinOp type. 4 Typeow Analysis If a particular reference object is declared as being of some static type S, then the static semantic checks of Oberon-2 ensure that the dynamic type D is always such that D > S. However, we wish to place some tighter bound on the type

4 by computing a manifest type M for the object so that, at every point in the program D > M > S For any given variable S is constant, while D and M may vary from place to place in the program. If we use the manifest type as a bound on the dynamic type of a variable, then the manifest type can be used to decide if a type guard is redundant. At any point in the program a type assertion D > t is redundant if the statically computed manifest type M > t, since we know that D > M. For technical reasons which become clear later we lift the domain of types to include two additional, extremal values. The special type value is an error type, and is an extension of every type. All types in a program are considered to be an extension of the other special value >. Formally, for every type T, > T > >. It is not dicult to see that every \object oriented language" which admits (a possibly limited form of) polymorphic assignment could be subjected to static analysis to compute the set of possible types which an object might take at runtime. In general, such a computation requires the nding of a least xed point of a set of set-valued equations[9]. In this general case the computations are over vectors of elements which are members of the powerset of program types. It is the major contribution of this paper to show that for Oberon-2 the computation may be carried out in terms of vectors of elements of a denumerable type, of cardinality equal to the number of types in the program. Furthermore, the equations have a formal correspondence to the familiar equations of dataow analysis, although the meaning of the symbols is somewhat dierent. 4.1 Control Flow Typeow analysis involves the tracking of the type of variables across the control ow graph. At entry to the control ow graph the manifest type of each reference object is set equal to its static type, that is, M = S. The static type does not change, but the manifest type is updated as the eect of each statement in the block is computed. The manifest type of a variable into a particular block is denoted M in. At the end of the block the new manifest type, that is, the manifest type out of the block, is denoted M out. In straight line control ow the M in of one block is equal to the M out for the predecessor block. However, in more complex control ow the M in of a block requires more computation. For a merge block, that is, a block with several predecessor blocks, M in is the lowest common ancestor of the set of M out values of all the predecessor blocks. The lowest common ancestor (LCA) of a set of types is the most extended type in the type hierarchy which includes all of the types in the set. For example, using the type hierarchy fragment in Figure 1, the LCA of the set fplus,starg is BinOp. The LCA of the set funary,plus,starg is Expr, and the LCA of the set fbinop,plus,starg is BinOp. In a companion paper[6], we develop the formal theory of typeow based on an algebra of clades, a term borrowed from evolutionary biology to denote a

5 species and all the species evolved from that species. For any type T we dene the corresponding clade as the set Clade(T ) = ft j t > T g In the companion paper we show that the manifest type into each single input, single output region is given by the following equations Mstart in = S _ Mi in = j2pred(i) A j _ (B j ^ M in j ) (1) In these equations, pred(i) is the set of blocks which are control ow predecessors of block i, and _ denotes the LCA operation. ^ denotes the more extended of its two operands if one is an extension of the other, and the special value if the two are incommensurate. The value denotes an error value, the root of the empty clade. The local information from each region appears in the coecients A i ; B i. These encapsulate the eect of downwardly visible Assignments and type Bounding tests respectively for each region. For a basic block i, if j is an index over program objects, and a ij ; b ij are the j-th elements of the vectors A i ; B i, then one of a ij ; b ij will be an extremal value for every index j. Blocks with assignments to a particular variable with index j will have the corresponding element, b ij equal to, while blocks with no assignments to variable j will have the corresponding element, a ij equal to >. The equations 1 must be solved in the forward control ow direction, so as to obtain a least (most constrained) value for M. In dataow terms this is a forward ow, all paths problem. However, it should be noted that the meaning of the ^; _ are quite distinct to the bitwise, Boolean and and or of conventional dataow analysis. Strict analysis would show that at every point in a program the strongest possible assertion regarding the dynamic type of an object would constrain the type to be a member of some set of types. However, there are no operations in Oberon-2 which test membership in such an arbitrary set of types. Instead, all explicit and implicit tests are based on the > relation. Suppose that D is the type of an object at some point in a program, and it is known that D 2 S, where S is some set of types. In this case, the condition that a test D > T is redundant is S Clade(T ). What we have called the manifest type M is simply the smallest clade covering S, and the redundancy condition is M > T. The approximation which we make is to compute the smallest covering clades (that is, the manifest types) directly and test the > predicate, rather than compute the exact sets and test the subset predicate. It is this mechanism of representing arbitrary sets by their smallest covering clade which results in the reduction of cardinality in the entities which we compute. In a program with N types there are 2 N sets of types, but there are only N + 2 clades. In common with the formally similar dataow equations, the system of equations (1) possess a \loop breaking rule". The practical consequence of this rule is

6 ) A UA / ) that loops need only be traversed twice to determine the manifest type at each point in the body. 4.2 Manifest Types and the Control Flow Graph Any reducible control ow graph can be derived from a small number of constructs. They are straight line control ow, merging control ow, and control ow with back edges. The following describes how the equations are solved for each case. Straight Line Control Flow. This is a trivial case for typeow. This structure is produced by simple sequential code. The M out of a block becomes the M in to the following block, see Figure M1 in M2 in = M1 out M2 out Fig. 3. A sequence construct Merging Control Flow. Merging control ow is produced by WITH, IF and CASE statements in Oberon-2. Figure 4 shows a control ow graph fragment which contains merging control ow 2. In this situation the M out of block 1 is the M in for blocks 2{5. The M in to block 6 is the LCA of the manifest types out of blocks 2{5. The equations are also shown in Figure 4. 2 P P P P Pq P P P P Pq S ws 4 5 M2 in = M1 out M3 in = M1 out M4 in = M1 out M5 in = M1 out M6 in = LCA(M2 out, M3 out, M4 out, M5 out ) Fig. 4. Example of merging control ow 2 This diagram strictly applies only to those cases where the ow of control is not predicated on the result of type tests. The modications required to handle such predicates are dealt with in a later section.

7 Q Control Flow With Back Edges. The control ow graph fragment in Figure 5 contains a back edge. This may require the traversal of the block more than once. As can be seen, the M in to block 2 is the LCA of the manifest types out of block 1 and block 2. To calculate the M out of block 2 it is rst traversed with an 1 2 M2 in = LCA(M1 out, M2 out ) M3 in = M2 out 3 Fig. 5. Fragment with a back edge initial M in equal to the M out of block 1. Then the block is traversed a second time with M in equal to the LCA of the M out of block 1 and the M out of block 2 which was calculated on the rst traversal. The M out of block 2 is the M in for block 3 in the usual way. The Oberon-2 statements which produce this type of control ow are the WHILE, FOR and REPEAT loops. The LOOP statement produces the slightly dierent control ow, shown in Figure 6. The fragment shown is for a loop with two exits. The M in into block 2 is calculated by the same method as for other loops, that is, blocks 2, 3 and 4 are traversed with the M in to block 2 being the M out of block 1. Once the M out of block 4 is calculated, blocks 2, 3 and 4 are traversed again using the LCA of the manifest types out of blocks 1 and 4 as the M in for block 2. The M in to block 5 is then calculated as the LCA of the manifest types out of blocks 2 and Q Qs Fig. 6. Loop with multiple exits LOOP......EXIT;......EXIT;... END;

8 4.3 Local Typeow In order to compute the relationship between M in and M out in any particular block, we must take account of the eect of the statements of the block. Three constructs aect the manifest type of variables within a block. These are assignment statements, procedure calls and type guards. Assignment Statement. The Oberon-2 language semantics allow for variables of a particular type to be assigned expressions which are extensions of that type. For reference objects the dynamic type then becomes equal to the dynamic type of the expression. With this is mind, consider the assignment statement var := exp; where the static type of exp is T e. The static semantic rules of Oberon demand that T e must be in the extends relations with T v, the static (declared) type of the variable. After this assignment statement has been executed it can be asserted that the type of the variable is equal to the type of the expression. During typeow analysis this means that the manifest type of the variable becomes the manifest type of the expression. Procedure Call. When a reference object is sent as a variable parameter of a procedure call, the called procedure may change the type of that parameter. Without inter-procedural type tracking, the only assertion that can be made about the type of the variable after the procedure call is that it is an extension of the static type of the formal parameter. The manifest type of the actual is changed to reect this. Type Guards. As mentioned previously, a type guard is an assertion that the dynamic type of a variable is in the extends relation of the guard type. A type guard produces a runtime test for this. Since the goal of typeow analysis is to remove redundant type tests, each type guard must be compared to the manifest type of the variable it is guarding. The type guard var(t ).eld has dierent eects depending on the manifest type of the variable var. First, suppose that the manifest type of var is M, and this is an extension of T. In this case the type guard may be removed. We know that the dynamic type of var will be at least as extended as M, so if M is an extension of T, the test is bound to evaluate to true. In this case, the manifest type of var is unchanged by the test, as M is already more extended than T. On the other hand, if the guard type is an extension of the manifest type of var, T > M, then the test cannot be removed. However, following the test it is known that the type of var is at least as extended as T, and so the manifest type of var is thus updated to equal T. 4.4 Type Predicates There are two constructs in Oberon-2 in which the ow of control is explicitly mediated by the dynamic type of objects. These are IS expressions and WITH statements, also called regional type guards.

9 IS Expression. In Oberon the IS expression is a boolean expression of the form var IS T, which gives the result of the runtime type test D > T where D is the dynamic type of var. When this expression is used as the condition for a loop or an if statement, then the manifest type of var can be updated to be the more extended of M and T, where M is the existing manifest type of var. Note that the manifest type of var should not be simply set to T, as the existing manifest type may already be more extended than T. For example, again referring to the type hierarchy in Figure 1, for the if statement - IF exp IS BinOp THEN StatementSequence ELSE StatementSequence END; If exp is statically of the type Expr, and its existing manifest type is also Expr then the manifest type of exp should be changed to BinOp before the thenpart statement sequence is traversed. However, if the existing manifest type of exp is Plus, say, which is an extension of BinOp, then the manifest type is unchanged for the traversal. In either case, the manifest type entering the elsepart statement sequence is the same as the manifest type on entry to the if statement. WITH Statement. Syntactically, a WITH statement in Oberon-2 has the form{ WITH var : T1 DO StatementSequence; var : T2 DO StatementSequence; var : T3 DO StatementSequence; ELSE StatementSequence; END; The WITH statement is equivalent to an IF statement containing multiple ELSIF s with a number of IS expressions as the condition on each. It sequentially tests each option for the var > T n relation, where T n is the type in the option, until it nds a test which succeeds. If none of the tests succeed, then the statements in the ELSE clause are executed. The ELSE clause is optional and, if it is not present and no other test succeeds, then the program aborts. Each option in the WITH statement is treated as an IS expression. Before traversal of each statement sequence the manifest type of the variable is changed to be the lower of the existing manifest type of var and T n. This WITH statement produces the control ow found in Figure 7. The manifest type of var after the WITH statement, that is, M in for the merge block

10 Fig. 7. A WITH statement fragment (block 8), is changed to the LCA of the manifest type of var after traversal of each of the options of the WITH. 4.5 A Bonus Detection of Incorrect Programs We have described how typeow analysis can be used to detect type tests which will always evaluate true at runtime. At the same time, and at no extra cost, type tests which are bound to fail at runtime may be detected. Incorrect programs can be found when carrying out the tests for type guards. As suggested previously in Section 4.3, the manifest type following a type test for Typeof(var) > T is the lower of M and T. If M > T the test is redundant and may be removed, otherwise the test must remain. If T and M are incommensurate, then the new manifest type is, the error type dened in section 4.1. In this case the program is in error, and will certainly fail at runtime if control ever reaches the test. As an example, consider the following fragment of code, referring to the type hierarchy in Figure 1, where exp is of type Expr and unary is of type Unary{... exp := unary; exp(binop).leftexp;... This code is statically correct. In the rst statement exp is assigned a variable which has a type which is an extension of the static type of exp. The second statement contains a type guard which tests that exp is of some type which is an extension of its static type. However, it is obvious that the type guard in the second statement will fail at runtime, as exp is dynamically of type Unary, and Binop and Unary are roots of non-overlapping clades 3. Runtime errors also occur in Oberon-2 if the dynamic type of a record on the left of an assignment is not equal to its static type. This is automatically 3 If we set the initial manifest type of unallocated (NIL) objects to > rather than to the static type, then the same computation will detect programs where the object is not allocated along every path leading to the type guard.

11 the case for record variables, since their type cannot change. For references to records an implicit runtime test must be generated. If it is found during typeow analysis that the manifest type of the record being referenced is not equal to its static type, then a warning can be issued that the program will fail at runtime. Dead code can also be detected in WITH statement options. If the same two comparisons of the manifest type and the option type are carried out as for type guards, for example, M > T n and T n > M, and both fail, then code for that option of the WITH statement will never be executed. Of course, if all the options of a WITH statement are found to be dead code and there is no ELSE clause, then the program is incorrect and must fail at runtime. For example, consider the WITH statement: WITH var : Plus DO... var : BinOp DO... END; If the manifest type of var is Star then the code in the Plus option is dead, whereas if the manifest type of var is Plus then the code in the BinOp option is dead code. If var has the manifest type Unary then the code for both options is dead, and the program will give a runtime error. An ELSE clause added to this WITH statement would prevent the runtime error, if the manifest type were Unary, but the code in the Plus and BinOp options would still be dead. WHILE loops and IF statement branches which are never executed can be found by the same method. This only applies for those statements where the condition is an IS expression. The same tests used for the WITH options are applied to the IS expression to determine if the conditional code will ever be executed. 5 An Implementation of Typeow Analysis We have described the computation of manifest types in terms of manipulation of the control ow graph. However, typeow analysis can be carried out without the need for constructing the control ow graph. Since Oberon-2 is a structured language and only produces a limited number of control ow constructs, it is not necessary to solve the manifest type equations for arbitrary control ow. In fact, the equations may be solved \on the y" during a traversal of the abstract syntax tree of the program. This method is similar to that described by Mossenbock for computing static single assignment form[7]. It is probably possible to carry out typeow analysis during the same traversal which checks static semantic rules. However, our initial implementation of typeow analysis is done during a separate traversal, after the static semantic checks have been completed. To achieve this, each variable descriptor contains a manifest type attribute as well as the expected static type attribute. This attribute is updated during

12 the traversal for assignments, type guards and so on. When a statement is encountered which has diverging control ow (see Figure 4) then as variables are encountered in each of these blocks, a record is kept of the manifest type emerging from the predecessor block. As each divergent path is traversed the M in of modied variables are reset before the traversal of the next path. Referring to Figure 4, this means that before traversing each of blocks 2, 3, 4 and 5 the manifest type is reset to the M out of block 1. At the end of each block the M out of the variable is `collected' so as to be able to compute M in for the successor block. After traversing the rst block with an in edge to the merge block (block 2) the M in is initialised. For subsequent blocks M in is replaced by the lowest common ancestor of the previous M in and the M out on the new in edge. After all predecessor blocks have been traversed, the nal value for M in is known. 5.1 Implementation Details In the analysis so far, it has been assumed that the manifest type out of each block is the same along each edge. However, this is not strictly correct for either WITH statements, or other conditional forms which include an explicit type test. In our formal analysis[6] we introduce type assertions in synthetic blocks placed on edges to regularise the analysis. Here however we may take this information directly into account. The WITH statement serves as a good example of this 4. Figure 7 shows the control ow graph representing the WITH statement in Section 4.4 which has three options and an ELSE clause. Blocks 1, 3 and 5 are the tests for executions of the dierent options and blocks 2,4 and 6 respectively, contain the corresponding statements for each option. Block 7 is the ELSE statements. Because of the semantics of the WITH statement the manifest types along the two out edges from block 1 are not the same. The statements in block 2 are only executed if the test in block 1 evaluates true, that is, WITH var : T 1 DO... Thus on this path we assert that M is T 1. On the path from block 1 to block 3, the manifest type of var is unchanged from M in to block 1. In detail, the steps of the typeow analysis for the WITH statement structure in Figure 7 for a particular variable are as follows{ { block 1 is traversed. This sets the manifest type of Mvar to the type of the rst WITH option { block 2 is traversed. M in for block 8 is set to the current manifest type of the variable Mvar (i.e. M out for block 2) { block 3 is traversed, which sets Mvar to the type of the second WITH option { block 4 is traversed. M in for block 8 is adjusted to the LCA of the interim M in and the M out of block 4 { block 5 is traversed, which sets Mvar to the type of the third WITH option { block 6 is traversed. M in for block 8 is adjusted to the LCA of the interim M in and the M out of block 6 4 For simplicity of exposition, we shall assume that neither dead code nor errors are discovered during typeow analysis in out example.

13 { Mvar is reset to M in for block 1. Block 7, which is the block for the ELSE clause is then traversed. Again, M in for block 8 is updated to the LCA of the interim M in and the M out of block 7 { all of the blocks of the WITH statement have now been traversed. The M in of block 8 is now the LCA of its predecessor blocks and analysis may proceed with block 8 Because the control ow produced by each statement is known, the required information about types can be stored as state variables of the recursive traversal procedures. All structures produced by Oberon-2 statements are traversed in a similar manner. An extra step must be included when traversing loop structures. As mentioned earlier, the block(s) in a loop must be traversed twice so that the correct M in to the loop can be computed using the M out of the loop block(s). It is a consequence of the \loop breaking rule" that the types out of a loop can be correctly computed without knowing the manifest types on the back edge. Once the M out values are known, the correct M in may be computed and the necessity of any type tests evaluated. A rst traversal is performed, without removing any apparently redundant type tests. The M out value obtained is then used to calculate the nal M in value for a second traversal of the loop. Since the correct M in value is known during the second traversal, redundant type tests may be removed on this pass. In the case of nested loops, the same reasoning shows that the statements of the innermost loop may be traversed a number of times equal to the loop nesting-level plus one. 5.2 Future Work Our initial implementation of typeow analysis computes manifest types on a procedure basis. There is no inter-procedural analysis. It also deals only with entire variables, and does not track elds of objects. For example, for the designator{ exp(binop).leftexp(unaryop).op the variable exp is tracked, and the BinOp type guard will be checked for redundancy and thus might be removed. However, the eld leftexp, which also is a record, is not tracked and the Unary type guard is not redundancy checked. This represents a limitation of our current descriptor structure. The implementation is currently being extended to track elds of records. Inter-procedural typeow analysis should be able to be carried out, at least for procedures local to the module being compiled. This can be done by type traversing a procedure before traversing any code which calls that procedure. The manifest type of formal parameters at procedure exit can then be used to rene manifest type information in the caller. For each called procedure an attribute indicates if the formal is modied within the procedure. If a formal parameter is agged as type modied, the manifest type of the corresponding

14 actual parameter can be updated to the manifest type already calculated for the formal at exit. If the formal parameter is not so agged, then the manifest type of the actual will be the lower of the previous value and the manifest type of the formal at exit. 6 Summary The typeow analysis outlined in this paper has been implemented and incorporated into an Oberon-2 compiler. Some preliminary testing has been carried out, and removal of redundant type tests as well as the incorrect program detection have been achieved. References 1. N. Wirth: Type Extension, ACM Trans. on Prog. Lang. and Systems Vol 10, No 2 pp 204{214, April N. Wirth: The Programming Language Oberon, Software Practice and Experience, Vol 18, No 7, pp 671{690, July H. Mossenbock and N. Wirth: The Programming Language Oberon-2, Computer Science Report 160, ETH Zurich, May N. H. Cohen: Type-Extension Type Tests Can Be Performed in Constant Time, (Technical Correspondence), ACM Trans. on Prog. Lang. and Systems, Vol 13, No 4, pp 626{629, October J. Asuru: Optimisation of Array Subscript Range Checks, ACM Letters on Prog. Lang. and Systems, Vol 1, No 2, June J. Gough and D. Corney: Typeow Analysis by Clade Algebra, Information Technology Report 9/93, QUT Brisbane, July 1993, (preprint) 7. H. Mossenbock: private communication March J. Palsberg and M. Schwartzbach: Static Typing for Object-Oriented Programming, To appear in Science of Computer Programming. 9. N. Oxhj, J. Palsberg and M. Schwartzbach: Making Type Inference Practical, ECOOP '92, Lecture Notes in Computer Science, Vol 615, Springer Verlag, This article was processed using the LaT E X macro package with LLNCS style