Exploiting loop level parallelism in nonprocedural dataflow programs

Discussed are how loop level parallelism is detected in a nonprocedural dataflow program, and how a procedural program with concurrent loops is scheduled. Also discussed is a program restructuring technique which may be applied to recursive equations so that concurrent loops may be generated for a seemingly iterative computation. A compiler which generates C code for the language described below has been implemented. The scheduling component of the compiler and the restructuring transformation are described

Generating Data Flow Programs From Nonprocedural Specifications

Data flow is a mode of parallel computation in which parallelism in a program can be exploited at the fine grained as well as macro level. A data flow computer executes a data dependency graph rather than the program counter controlled sequence of instructions executed by conventional machines. Nonprocedural languages appear to be especially appropriate high level languages for data flow computers. Nonprocedural languages have only two statement forms: data description and assertion. The assertions enumerate the relationships among the data. A data dependency graph is also a suitable representation for a nonprocedural language program (or specification). This research is concerned with translating the dependency graph form of a specification to a program graph for a data flow machine. Specifications in the MODEL language are translated into an intermediate form, the data flow template. The template is a language-independent representation of the specification. The template is then translated into a data flow language (Manchester Dataflow) for the Manchester University machine. The translation consists of creating an array graph to represent the specification; generating the data flow program template from the array graph; and translating the template into MaD

Reasoning About a Simulated Printer Case Investigation with Forensic Lucid

In this work we model the ACME (a fictitious company name) "printer case incident" and make its specification in Forensic Lucid, a Lucid- and intensional-logic-based programming language for cyberforensic analysis and event reconstruction specification. The printer case involves a dispute between two parties that was previously solved using the finite-state automata (FSA) approach, and is now re-done in a more usable way in Forensic Lucid. Our simulation is based on the said case modeling by encoding concepts like evidence and the related witness accounts as an evidential statement context in a Forensic Lucid program, which is an input to the transition function that models the possible deductions in the case. We then invoke the transition function (actually its reverse) with the evidential statement context to see if the evidence we encoded agrees with one's claims and then attempt to reconstruct the sequence of events that may explain the claim or disprove it.Comment: 18 pages, 3 figures, 7 listings, TOC, index; this article closely relates to arXiv:0906.0049 and arXiv:0904.3789 but to remain stand-alone repeats some of the background and introductory content; abstract presented at HSC'09 and the full updated paper at ICDF2C'11. This is an updated/edited version after ICDF2C proceedings with more references and correction

Formally Specifying and Proving Operational Aspects of Forensic Lucid in Isabelle

A Forensic Lucid intensional programming language has been proposed for intensional cyberforensic analysis. In large part, the language is based on various predecessor and codecessor Lucid dialects bound by the higher-order intensional logic (HOIL) that is behind them. This work formally specifies the operational aspects of the Forensic Lucid language and compiles a theory of its constructs using Isabelle, a proof assistant system.Comment: 23 pages, 3 listings, 3 figures, 1 table, 1 Appendix with theorems, pp. 76--98. TPHOLs 2008 Emerging Trends Proceedings, August 18-21, Montreal, Canada. Editors: Otmane Ait Mohamed and Cesar Munoz and Sofiene Tahar. The individual paper's PDF is at http://users.encs.concordia.ca/~tphols08/TPHOLs2008/ET/76-98.pd

Reverse Software Engineering

The goal of Reverse Software Engineering is the reuse of old outdated programs in developing new systems which have an enhanced functionality and employ modern programming languages and new computer architectures. Mere transliteration of programs from the source language to the object language does not support enhancing the functionality and the use of newer computer architectures. The main concept in this report is to generate a specification of the source programs in an intermediate nonprocedural, mathematically oriented language. This specification is purely descriptive and independent of the notion of the computer. It may serve as the medium for manually improving reliability and expanding functionally. The modified specification can be translated automatically into optimized object programs in the desired new language and for the new platforms. This report juxtaposes and correlates two classes of computer programming languages: procedural vs. nonprocedural. The nonprocedural languages are also called rule based, equational, functional or assertive. Non-procedural languages are noted for the absence of side effects and the freeing of a user from thinking like a computer when composing or studying a procedural language program. Nonprocedural languages are therefore advantageous for software development and maintenance. Non procedural languages use mathematical semantics and therefore are more suitable for analysis of the correctness and for improving the reliability of software. The difference in semantics between the two classes of languages centers on the meaning of variables. In a procedural language a variable may be assigned multiple values, while in a nonprocedural language a variable may assume one and only one value. The latter is the same convention as used in mathematics. The translation algorithm presented in this report consists of renaming variables and expanding the logic and control in the procedural program until each variable is assigned one and only one value. The translation into equations can then be performed directly. The source program and object specification are equivalent in that there is a one to one equality of values of respective variables. The specification that results from these transformations is then further simplified to make it easy to learn and understand it when performing maintenance. The presentation of translation algorithms in this report utilizes FORTRAN as the source language and MODEL as the object language. MODEL is an equational language, where rules are expressed as algebraic equations. MODEL has an effective translation into the object procedural languages PL/1, C and Ada

Simultaneous Equations in the Model System With an Application to Econometric Modelling

This report describes modifications to the MODEL language and processor to facilitate automatic implementation of solution procedures for systems of simultaneous equations. MODEL is a very high level nonprocedural language for specifying computational tasks. The MODEL processor compiles a specification in the MODEL language into a computer program in PL/I . The purpose of the current modifications is to allow users with relatively little programming expertise to solve complex mathematical systems involving sets of simultaneous equations quickly and efficiently using an automatic program generation approach to modelling. The primary application which has motivated these modifications is that of Project LINK, an international econometric model composed of independent constituent country/region models which are linked together into a complex network of simultaneous equations. This report presents the rationale behind these modifications, describes the syntax, semantics, scheduling and code generation of specifications containing simultaneous equations, and illustrates these facilities in applications to two small national models from the LINK system and to a novel linkage mechanism used to simulate trade among the national models

Monitoring framework for stream-processing networks

Vu Thien Nga Nguyen, Raimund Kirner, and Frank Penczek, 'Monitoring framework for stream-processing networks'. Paper presented at the Workshop on Feedback-Directed Compiler Optimization for Multi-Core Architectures (FD-COMA 2012), Berlin, Germany. 21-23 January 2013.In this paper we present a monitoring framework that exploits special characteristics of stream-processing networks in order to reason the performance. The novelty of the framework is to trace the non-deterministic execution which is reflected in i) the dynamic mapping and scheduling of network components at the operating system level and ii) the dynamic message routing across the network at runtime. We evaluate the efficiency with an implementation for the coordination language S-Net, showing negligible overhead in most cases

Using the General Intensional Programming System (GIPSY) for Evaluation of Higher-Order Intensional Logic (HOIL) Expressions

The General Intensional Programming System (GIPSY) has been built around the Lucid family of intensional programming languages that rely on the higher-order intensional logic (HOIL) to provide context-oriented multidimensional reasoning of intensional expressions. HOIL combines functional programming with various intensional logics to allow explicit context expressions to be evaluated as first-class values that can be passed as parameters to functions and return as results with an appropriate set of operators defined on contexts. GIPSY's frameworks are implemented in Java as a collection of replaceable components for the compilers of various Lucid dialects and the demand-driven eductive evaluation engine that can run distributively. GIPSY provides support for hybrid programming models that couple intensional and imperative languages for a variety of needs. Explicit context expressions limit the scope of evaluation of math expressions (effectively a Lucid program is a mathematics or physics expression constrained by the context) in tensor physics, regular math in multiple dimensions, etc., and for cyberforensic reasoning as one of the use-cases of interest. Thus, GIPSY is a support testbed for HOIL-based languages some of which enable such reasoning, as in formal cyberforensic case analysis with event reconstruction. In this paper we discuss the GIPSY architecture, its evaluation engine and example use-cases.Comment: 14 pages; 8 figure