One way of thinking about types is that they are static approximations of the behavior of a program. For example, if expression e has type int → int, then we know statically (i.e., without executing the expression) that the execution of e will result in a function from integers to integers (provided the execution terminates). There are in fact many kinds of static analyses that approximate the behavior of programs without actually executing them. Today we will consider control flow analysis, a program analysis that approximates the order that individual expressions or commands are evaluated. In a first-order language like IMP (i.e., a language where functions are not values), control flow analysis is straightforward: the lexical structure of the program tells us the control flow structure. But in a functional language, if we see a application f y, then control will jump to the function body of whatever function the variable f evaluates to. This makes determining the control flow of a functional language more complex than determining the control flow structure of a language like IMP, where functions are not first-class values. (Similar issues arise in object-oriented languages, where objects are first class and contain executable code.) We will consider the 0-CFA analysis. (CFA stands for Control-Flow Analysis; it is an instance of k-CFA analysis, where the parameter k determines the precision of the analysis.) Like our type inference analysis, we will generate a set of constraints from a program, and then find a solution to the set of constraints. 1.1 Labeled lambda calculus Let's consider a lambda calculus with integers. The syntax of the language is similar to what we've seen before, but every expression in our source program will have a unique label. Labels are used to uniquely identify program expressions. We use l to range over labels. e ::= n l | x l | (λx. e) l | (e 1 e 2) l | (e 1 + e 2) l Every expression has a label, and we write labelof (e) for the label of expression e. For convenience, we also write e l to mean that l is a label such that labelof (e) = l. Also, given a program e, we write exprof (e, l) for the (unique) subexpression e ′ of e such that labelof (e ′) = l. That is exprof (e, l) allows us to get the expression associated with label l. We will use a large-step environment semantics for this analysis. Environments ρ are maps from variables to values, and that judgment ⟨e, ρ⟩ ⇓ v means that expression e in environment ρ evaluates to value v. Note that in an environment semantics, a function λx. e evaluates to a closure ((λx. e) l , ρ lex), where ρ lex is the environment that was current when λx. e was evaluated. That is, ρ lex binds the free variables (except x) in the function body e. We define the label of a closure to be the label of the function: labelof (((λx. e) l , ρ lex)) = l. Values in our language are thus the following. v ::= n l | ((λx. e) l , ρ) ⟨x l , ρ⟩ ⇓ ρ(x) ⟨n l , ρ⟩ ⇓ n l ⟨e 1 , ρ⟩ ⇓ n l1 1 ⟨e 2 , ρ⟩ ⇓ n l1 2 ⟨(e 1 + e 2) l , ρ⟩ ⇓ n l n = n 1 + n 2

, IBM announced the start of a five-year effort to build a massively parallel computer, to be applied to the study of biomolecular phenomena such as protein folding. The project has two main goals: to advance our understanding of the mechanisms behind protein folding via large-scale simulation, and to explore novel ideas in massively parallel machine architecture and software. This project should enable biomolecular simulations that are orders of magnitude larger than current technology permits. Major areas of investigation include: how to most effectively utilize this novel platform to meet our scientific goals, how to make such massively parallel machines more usable, and how to achieve performance targets, with reasonable cost, through novel machine architectures. This paper provides an overview of the Blue Gene project at IBM Research. It includes some of the plans that have been made, the intended goals, and the anticipated challenges regarding the scientific work, the software application, and the hardware design.

The global data relationships in a program can be exposed and codified by the static analysis methods described in this paper. A procedure is given wbicb determines all the definitions which can possibly "reach" each node of the control flow graph of the program and all the definitions that are "live" on each edge of the graph. The procedure uses an "interval" ordered edge listing data structure and handles reducible and irreducible graphs indistinguishably.

No abstract

No abstract

No abstract

The Experimental Compiling System (ECS) described here represents a new compiler construction methodology that uses a compiler base which can be augmented to create a compiler for any one of a wide class of source languages. The resulting compiler permits the user to select code quality ranging from highly optimized to interpretive. The investigation is concentrating on eo.vy expression and efficient implementation of language semantics; syntax analysis is ignored.The other unique feature of the schema is that all operations are references to procedures which implicitly define Copyright 1980 by International Business Machines Corporation. Copying is permitted without payment of royalty provided that (1) each reproductioo is done without alteration and (2) the Journal reference and IBM copyright notice are included on the first page. The title and abstract may be used without further permission in computer-based and other information-service systems. Permission to republish other excerpts should be obtained from the Editor. 695 IBM

The history of language processor technology in IBM is described in this paper. Most of the paper is devoted to compiler technology; interpreters, assemblers, and macro systems are discussed briefly. The emphasis is on scientific contributions and technological advances from a historical perspective. The synergistic relationship between theory and practice is a subtheme.