The scheme of things

Now you’re ready to look at how the FOO compiler works. The main difference between a compiler and an interpreter is that an interpreter processes a program and directly generates some behavior—generating HTML in the case of a FOO interpreter—but a compiler processes the same program and generates code in some other language that will exhibit the same behavior. In FOO, the compiler is a Common Lisp macro that translates FOO into Common Lisp so it can be embedded in a Common Lisp program. Compilers, in general, have the advantage over interpreters that, because compilation happens in advance, they can spend a bit of time optimizing the code they generate to make it more efficient. The FOO compiler does that, merging literal text as much as possible in order to emit the same HTML with a smaller number of writes than the interpreter uses. When the compiler is a Common Lisp macro, you also have the advantage that it’s easy for the language understood by the compiler to contain embedded Common Lisp—the compiler just has to recognize it and embed it in the right place in the generated code. The FOO compiler will take advantage of this capability.KeywordsSpecial OperatorHelper FunctionParameter ListProperty ListPredicate FunctionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

As program behavior becomes complex, it’s increasingly important to analyze their behavior statistically. The article describes two separate but synergistic tools for statistically analyzing large Lisp programs. The first tool, called CLIP (Common Lisp Instrumentation Package), allows the researcher to define and run experiments, including experimental conditions (parameter values of the planner or simulator) and data to be collected. The data are written out to data files that can be analyzed by statistics software. The second tool, called CLASP (Common Lisp Analytical Statistics Package), allows the researcher to analyze data from experiments by using graphics, statistical tests, and various kinds of data manipulation. CLASP has a graphical user interface (using CLIM, the Common Lisp Interface Manager) and also allows data to be directly processed by Lisp functions. Finally, the paper describes a number of other data-analysis modules that have been added to work with CLIP and CLASP.

John McCarthy designed the LISP programming language for the symbolic computation typical of artificial intelligence at the time, and LISP was strongly associated with AI at least through the 1990s. By 1963, a number of ideas had been proposed for how LISP 1.5 could be improved and extended. This lead to the LISP 2 project, which was carried out at System Development Corporation by personnel from SDC and Information International, Inc., using the military AN/FSQ-32 computer. LISP 2 extended LISP 1.5 with ALGOL-like syntax, static type checking, efficient support for arithmetic and arrays, pattern-matching, and more, but the LISP 2 language failed to displace LISP 1.5. Despite this, LISP 2 foreshadowed later languages, such as ECL, Common Lisp, and Java. An online archive of LISP 2 documents and source code exists at the Computer History Museum, providing a snapshot of mid-1960s ARPA-funded research and development.

To assess how much faster Lisp programs would run on large multiprocessor systems, several application kernels were modified for parallel execution and simulation of their behavior. The kernels exhibited speed-ups ranging from one to 850 times faster, suggesting that the technique is of no value to a few programs, of great value to a few programs, and of moderate value to most programs. The modifications were originally done manually but now are accomplished by a program. Further manual editing may yield even more parallelism.KeywordsParallel ExecutionRecursive CallParallel EnvironmentMemory CycleApplication KernelThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

: We ported the Portable Standard Lisp compiler to MIPS-X, a reduced-instruction-set processor. In this paper we report on a number of profiling measurements made on a set of 11 LISP programs. The measurements give information on two levels. Because the instruction set of MIPS-X contains only very simple, basic instructions the profiling information is at avery low level. In a second group of measurements, we determine how much time each program spends on most common primitive LISP operations. Because MIPS-X executes all machine instructions in a single cycle, it is possible to get very accurate timing measurements by instruction counts. (Author)

CHAPTER 4 - GPS: The General Problem Solver

The authors have conducted a series of benchmark studies on two implementations of a Cockpit Information Management system. Each implementation uses three different data support structures to determine the performance effects of changing the underlying data representation in a specific Blackboard system implementation. A third implementation, also discussed briefly, is a Common LISP program which addresses the Cockpit Information Management (CIM) domain directly using arrays as the data representation structure. A strong case is presented for the use of a particular data support structure based upon the type of application being implemented by the blackboard system. It is shown that a system that has a frequent need to sort objects by their attributes, benefits from the use of a data support system that provides efficient access to the blackboard objects based upon their attribute values. The choice of an indexing support is similar to the decision during relational database design to index a particular field in a relation. The CIM application has benefitted from the use of a support structure that allows the use of indexed attributes because it allows the application to do many fewer blackboard reads and writes than would otherwise be required. The Boeing Company has been using Blackboards to develop prototype Cockpit Information Management systems for several years. The Blackboard model was chosen because of its inherent flexibility which has been useful in our efforts to define the function of a Cockpit Information Manager. In the course of this work we have been prototyping the functions to be performed by advanced Pilot Vehicle Interfaces (PVIs) and have identified benefits from using prototypes that react quickly to pilot inputs and other external events. We have revised our designs repeatedly in order to improve the performance of our prototype PVIs while retaining flexibility in our development environment [l].As our systems have become more robust, and the CIA1 domain has become more precisely defined, tllc need to address performance issues has become more critical. This work presents some timing measurements for a previous revision and a current prototype with our analysis of why the current prototype runs more quickly, and includes some general observations concerning the optimization of blackboard applications based upon the types of tasks the application performs.

This paper describes the BL addressing mode and the address tag in FLATS2 machine, which is a general-purpose MIMD computer now under construction. The BL addressing mode integrates memory accessing and range checking by hardware. Address tag is a bit in word, which indicates the capability for memory access. Combining them together, efficient memory protection is provided at run-time. It reduces the cost of run-time type checking in Lisp by checking the address tag and the address of a pointer against the range of the region associated to a type, in parallel with the memory access. The arithmetic instructions check the address tags of operands to support the generic arithmetic in Lisp. We can also make use of this scheme to check the number of arguments and multiple return values and to check array-bounds to support faster execution of Common Lisp program. These facilities are not specific to Lisp, so that they can be used more generally than other tagged architectures.

No abstract available.

: The principal goal of the COMMON LISP Framework project was to support Strategic Computing (SC) contractors with a comprehensive, state-of-the- art programming framework for the development and evolution of COMMON LISP programs. The CLF has affected the technical community by shaping both the structure of modern programming environments and the development paradigm they support. This structure rests upon an active objectbase which maintains integrity, integrated tools and provides persistence. CLF's integrity management is unique in providing declarative integrity condition statements--which can be reasoned about and analyzed--while still permitting efficient algorithmic maintenance of these conditions. Its declarative persistence mechanism, based on conceptual aggregations of objects, is also unique. Tools are integrated with the objectbase rather than each other. They gather their inputs from, and place their results back in, the objectbase and are invoked (demonically) by relative activity in the objectbase.