| The parser generating system PGS, E. Klein, M. Martin, Software Practice and Experience, Vol. 19(11), p. 1015-1028, November 1989 |
....amount of research devoted to seeking ways to automate the production of programming language compilers, based on declarative specifications. The production of high quality scanners and parsers has been commonplace for many years, with results rivalling the very best hand crafted programs[15]. Other phases of compilation have proved much more resistant to automation, and it is only recently that static semantic analysers based on attribute grammars have become competitive with hand written analysers[14] Code selection has had a somewhat chequered history. Code selection is the phase ....
William MWaite. The cost of lexical analysis. Software Practice and Experience, Volume 16, Number 5, pages 473--488, 1986.
.... and virtual machines for such devices; for example, Windows CE [11] for a number of PDAs currently in the market, and Java for PalmPilot VII [12] In addition, the foreseen increase of bandwidth in wireless communication makes the connection of these infoappliances to the Internet a reality [10]. We envisage a general scenario in which a user will want to access data using a PC in his oce, using a laptop while in the airport or in the hotel, using a PDA in a taxi, etc. The user wants to live in this data ubiquitous world with no other concern besides doing his own work and, as much as ....
Malcom W. Oliphant. The mobile phone meets the internet. Software Practice and Experience, 36(8):20-28, August 1999.
....of space. In fact, Heu86] suggests that nearly all lexical analysers for production compilers are written by hand. A formal design methodology for writing scanners is discussed in [DGM80] A practical design outline for a hand crafted parser that is roughly the base for my design is found in [Wai86] The major difference of my implementation is that his mkint, and mkfpt routines are implemented with inline code. Heu86] gives the basic rules to follow for creating a fast scanner: touch characters as few times as possible, avoid procedure calls. Both of these rules have been followed ....
W. M. Waite. The cost of lexical analysis. Software---Practice and Experience, 16(5):473--488, May 1986.
....encountered, have been addressed at the implementation of various by modern standards baroque languages. A way to handle operators with varying syntactic rules of the APL language is given in [Str77] The use of a two level grammar to handle the complexity of the language PL I can be found in [Mar84] This scheme, described in section 2.3.5, is used to handle a shift reduce conflict in the HASKELL grammar associated with the parsing of list comprehension qualifiers. HASKELL features infix operators with user defined precedence and associativity. Handling them in a yacc based grammar is very ....
B. L. Marks. Taming the PL/1 syntax. Software---Practice and Experience, 14(8):775--789, August 1984.
....intermediate language can be found in [KKM80] 33 The approach elected was a modification of the classical environment based eval apply interpreter following the tradition started by [McC60] The implementation of such an interpreter in Hope is described in [FH88, pp. 193 213] and in Lisp in [Lic86] A more general implementation for abstract equations can be found in[HOS85] A meta circular version of the interpreter (with one additional procedure EVLIS which evaluates a list calling EVAL) is given in [JSXX, p. 631] The interpreter is based on the SCHEME language and is thus lexically ....
Zavdi L. Lichtman. The function of T and NIL in LISP. Software--- Practice and Experience, 16(1):1--3, January 1986. 86
....interpreter is based on the SCHEME language and is thus lexically scoped, exactly as required for HASKELL . That interpreter is then transformed into a statement oriented language presented in [JSXX, p. 637] suitable for VLSI implementation. Another description of a Lisp interpreter is given by [Bai85b] I argue that my imperative implementation of the eval apply interpreter resembles the SECD machine first presented in [Lan63] In section 4.5 I describe a special compiler written to compile primitives from a HASKELL C hybrid language into C Examples of development and uses of such little ....
D. Bailey. The university of salford Lisp/Prolog system. Software--- Practice and Experience, 15(6):595--609, June 1985.
....the area of compiler construction, sets of lists of natural numbers have been implemented by ordered son brother trees. The algorithm to insert a new list into a tree is specified as implementation of (f Deltag [ Delta) It is used to construct comb vectors for parse table compression, see e.g. [10]. Virtually all features of the sort discipline are used in this application: a constraint formula restricts the sort of all son brother trees to the ordered ones, the set constructors are not free but obey to non trivial equations 5 , and computation of the range sorts of the representation ....
The parser generating system PGS, E. Klein, M. Martin, Software Practice and Experience, Vol. 19(11), p. 1015-1028, November 1989
....for the two compilers on this input. Closer analysis of Icont reveals that most of the lexical analysis time (32 of the total execution time) is spent in a routine to get the next character from the input. Previous research has shown that this is an area which deserves to be handled carefully [28]. As a result, Eli includes a support module that provides efficient access to input characters without any special effort on the part of the compiler writer. 4.2 Efficiency Lessons To Be Learned On the other side of the coin are programs for which EliIcont performs poorly compared to Icont. By ....
WAITE, W. M. The cost of lexical analysis. Software---Practice and Experience 16, 5 (May 1986), 473--488.
....into compilers. Compiler syntax analyzers build and examine parse trees and determine the presence or absence of syntactic faults. More ambitious compilers, and similar standalone analysis tools, determine the presence or absence of certain semantic faults (e.g. the PFORT Fortran Analyzer [Ryd74] and the Lint C analyzer) More powerful static analyzers build increasingly sophisticated program models, and employ increasingly powerful mathematics to demonstrate the absence of wider classes of faults. Thus dataflow analyzers [OF76, DC94] construct annotated flowgraphs to represent program ....
B.G. Ryder. The PFORT Verifier. Software --- Practice and Experience, 4:359--378, 1974.
....Haskell includes type classes for the systematic expression of ad hoc polymorphism, array types whose values are aggregated collections of indexed values, and an I O scheme requiring every program to be a function whose result is a list of requests and whose argument is a list of responses. TIP [8] is a software package for use in interactive terminal based programs; it is an important part of a commercially successful tool kit for the rapid construction of UNIX applications. TIP enables the application programmer to work with a Author s address: Department of Computer Science, University ....
H. W. Thimbleby. The design of a terminal independent package. Software --- Practice and Experience, 17(5):351--67, 1987.
....software is written almost exclusively in FORTRAN, so that the portability effort in this context concerns itself only with the incompatibilities that arise out of the use of various language dialects and the particularities of different target environments. Tools such as the PFort verifier [Ryd74], which checks a FORTRAN program for adherence to a portable subset of the language, are useful in detecting these potential impediments to portability. Several existing numerical software libraries have been designed to be 64 portable. The central idea of a portable library is to maintain only ....
B.G. Ryder; The PFORT Verifier; Software-Practice and Experience, 4:4, 359-377; 1974. {6}
....of which contributes to lcc s efficiency as described below. Lexical Analysis The design of the input module and of the lexical analyzer and judicious code tuning of the lexical analyzer contribute to lcc s speed. Input and lexical analysis use variations of the design described in Reference [20]. Since the lexical analyzer is the only module that inspects every input character, the design avoids extraneous per character processing and minimizes character movement by scanning tokens directly out of a large input buffer. Input is read directly from the operating system into a ....
....across white space. The important consequence of this design is that most of the input characters are accessed by cp and many are never moved. Only identifiers (excluding keywords) and string literals that appear in executable code are copied out of the buffer into permanent storage. Reference [20] s algorithm moves partial lines instead of partial tokens and does so after scanning the first newline in the buffer. But this operation overwrites storage before the buffer when a partial line is longer than a fixed maximum. The algorithm above avoids this problem, but at the per token cost of ....
[Article contains additional citation context not shown here]
W. M. Waite. The cost of lexical analysis. Software---Practice and Experience, 16(5):473--488, May 1986.
....of intermediate level have been studied and applied: i) Abstract Machine Languages which provide a form of machine code instruction set for some abstract machine architecture more suited to the implementation of some specific small class of languages. Examples date back to the O Code for BCPL [Ric71] and more recently WAM [War83] for Prolog, and the G Machine [Aug84,Joh84] for lazy functional languages. In general an abstract machine will provide for efficient implementations, since the low level abstract machine instructions are easily compiled to simple sequences of conventional machine ....
....which directly produce instruction codes for a particular machine we will be mixing the general issues of compiling a language with the specific issues of implementation on a machine. It was to avoid this confusion that the concept of an abstract machine was introduced, the first being O Code [Ric71] for the BCPL language, more recent examples being the Page 40 Chapter G Machine [Aug84,Joh84] for lazy ML and the WAM [War83] for Prolog. An abstract machine for a particular language provides an architecture and instruction set in the style of Von Neumann architecture, but includes specific ....
<F1.149e+04> The Portability of the BCPL Compiler,<F1.176e+04> Martin Richards, Software - Practice and Experience, Vol. 1, No. 2, pp.135-146.
....we find that techniques in some prototype systems work only for programs with restricted structure and solve only limited problems. An efficient debugging paradigm that deals with a broader scope of faults is needed. 18 3. ANALYSIS OF A NEW DEBUGGING APPROACH Most studies of fault analysis [Knu89, BP84, OW84, Bow80, Lip79, AC73, JSCD83, SPL 85] classify faults collected from long term projects. However, no further studies have been conducted based on the categorized information. We believe that there is value to debugging research in such analysis. In order to observe and analyze ....
D. E. Knuth. The errors of T E X. Software Practice and Experience, 19(7):607-- 685, July 1989.
....not address the lookahead problem; backtracking is not allowed. Rex [7] uses a tunnel automaton for efficient scanner generation. It does not address the look ahead problem. Traditionally, scanners generated from regular expressions [10] are slower than one carefully coded by hand. However, Waite [18] reports that new scanner generators can produce scanners that are as fast as hand coded scanners. GLA [8] and Mkscan [9] do not support the full set of regular expressions. They aim at handling only those tokens that are used in common programming languages. LexAGen [17] provides a graphic user ....
Waite, W.M., The cost of lexical analysis, Software---Practice and Experience 16(5) pp. 473-488 (May 1986).
....token classes, like identifiers, no longer has to be copied to a separate name list but can remain where it is. One simply has to remember its position and its length. This idea is in accordance with the principle that during scanning every input character should be touched as little as possible [Waite86]. Another advantage of this technique is that it permits the backup of the input pointer to any previous position. This is useful for handling tokens with CONTEXT phrases in Cocol R. To recognize such tokens the right hand context has to be analyzed, too. After the token and its context have been ....
W.M.Waite: The Cost of Lexical Analysis. Software -- Practice and Experience 16 (1986), 5, 473-488
....Equation solver (LE) and the System Solver (SS) which call lower level subroutines. Both the SS subroutines (GESS, SYSS, BASS, etc. and the LE subroutines (GELE, SYLE, BALE, etc. solve systems 2 AX = B (2. 1) using variants of Gaussian elimination adapted to the structure of the matrix[8]. For example, partial pivoting is used for general matrices but no pivoting is used for band symmetric positive definite matrices. The matrix B in (2.1) may have several columns. In all the subroutines the matrix A is overwritten, and the solution replaces the right hand side matrix B. Besides ....
....definite. 4. Sparse Matrices A matrix is considered sparse if not more than about 1 of its elements are nonzero. 5. Relation to PFORT, PORT, and LINPACK The linear algebra package achieves portability by using the PFORT subset of ANSI FORTRAN, as defined and enforced by the PFORT Verifier [8], and by using the machine constants module from the PORT Mathematical Subroutine Library[4] to characterize the host computer. This package also depends on PORT s dynamic storage allocation module to provide temporary working space, and on PORT s error handling module to respond to errors, which ....
B.G. Ryder, The PFORT Verifier, Software Practice and Experience 4, pp.359-377, October 1974.
No context found.
Malcom W. Oliphant. The mobile phone meets the internet. Software Practice and Experience, 36(8):20--28, August 1999.
No context found.
The parser generating system PGS, E. Klein, M. Martin, Software Practice and Experience, Vol. 19(11), p. 1015-1028, November 1989
No context found.
P. Brinch-Hansen. The design of Edison. Software Practice and Experience, 11(4):362-396, 1981.
No context found.
B.G. Ryder. The PFORT verifier. Software: Practice and Experience, 4(4):359--377, 1974.
No context found.
B.G. Ryder. The PFORT verifier. Software: Practice and Experience, 4(4):359--377, 1974.
No context found.
Malcom W. Oliphant. The mobile phone meets the internet. Software Practice and Experience, 36(8):20-28, August 1999.
No context found.
Beyond the chalkboard: computer suuport for collaboration and problem solving in meetings. CACM, 30(1): 32-47. W. F. Tichy (1985). RCS -- a system for version control. Software Practice and Experience, 15(7): 637--654.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC