Refinement-Based Game Semantics for Certified Abstraction Layers∗
Total Page:16
File Type:pdf, Size:1020Kb
Load more
										Recommended publications
									
								- 
												  Constructive Design of a Hierarchy of Semantics of a Transition System by Abstract Interpretation1 Constructive Design of a Hierarchy of Semantics of a Transition System by Abstract Interpretation Patrick Cousota aD´epartement d’Informatique, Ecole´ Normale Sup´erieure, 45 rue d’Ulm, 75230 Paris cedex 05, France, [email protected], http://www.di.ens.fr/~cousot We construct a hierarchy of semantics by successive abstract interpretations. Starting from the maximal trace semantics of a transition system, we derive the big-step seman- tics, termination and nontermination semantics, Plotkin’s natural, Smyth’s demoniac and Hoare’s angelic relational semantics and equivalent nondeterministic denotational se- mantics (with alternative powerdomains to the Egli-Milner and Smyth constructions), D. Scott’s deterministic denotational semantics, the generalized and Dijkstra’s conser- vative/liberal predicate transformer semantics, the generalized/total and Hoare’s partial correctness axiomatic semantics and the corresponding proof methods. All the semantics are presented in a uniform fixpoint form and the correspondences between these seman- tics are established through composable Galois connections, each semantics being formally calculated by abstract interpretation of a more concrete one using Kleene and/or Tarski fixpoint approximation transfer theorems. Contents 1 Introduction 2 2 Abstraction of Fixpoint Semantics 3 2.1 Fixpoint Semantics ............................... 3 2.2 Fixpoint Semantics Approximation ...................... 4 2.3 Fixpoint Semantics Transfer .......................... 5 2.4 Semantics Abstraction ............................. 7 2.5 Fixpoint Semantics Fusion ........................... 8 2.6 Fixpoint Iterates Reordering .......................... 8 3 Transition/Small-Step Operational Semantics 9 4 Finite and Infinite Sequences 9 4.1 Sequences .................................... 9 4.2 Concatenation of Sequences .......................... 10 4.3 Junction of Sequences ............................. 10 5 Maximal Trace Semantics 10 2 5.1 Fixpoint Finite Trace Semantics .......................
- 
												  A Hardware Abstraction Layer in JavaA Hardware Abstraction Layer in Java MARTIN SCHOEBERL Vienna University of Technology, Austria STEPHAN KORSHOLM Aalborg University, Denmark TOMAS KALIBERA Purdue University, USA and ANDERS P. RAVN Aalborg University, Denmark Embedded systems use specialized hardware devices to interact with their environment, and since they have to be dependable, it is attractive to use a modern, type-safe programming language like Java to develop programs for them. Standard Java, as a platform independent language, delegates access to devices, direct memory access, and interrupt handling to some underlying operating system or kernel, but in the embedded systems domain resources are scarce and a Java virtual machine (JVM) without an underlying middleware is an attractive architecture. The contribution of this paper is a proposal for Java packages with hardware objects and interrupt handlers that interface to such a JVM. We provide implementations of the proposal directly in hardware, as extensions of standard interpreters, and finally with an operating system middleware. The latter solution is mainly seen as a migration path allowing Java programs to coexist with legacy system components. An important aspect of the proposal is that it is compatible with the Real-Time Specification for Java (RTSJ). Categories and Subject Descriptors: D.4.7 [Operating Systems]: Organization and Design—Real-time sys- tems and embedded systems; D.3.3 [Programming Languages]: Language Classifications—Object-oriented languages; D.3.3 [Programming Languages]: Language Constructs and Features—Input/output General Terms: Languages, Design, Implementation Additional Key Words and Phrases: Device driver, embedded system, Java, Java virtual machine 1. INTRODUCTION When developing software for an embedded system, for instance an instrument, it is nec- essary to control specialized hardware devices, for instance a heating element or an inter- ferometer mirror.
- 
												  Towards a Unified Theory of Operational and Axiomatic Semantics — Extended Abstract —View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Illinois Digital Environment for Access to Learning and Scholarship Repository Towards a Unified Theory of Operational and Axiomatic Semantics — Extended Abstract — Grigore Ros¸u and Andrei S¸tefanescu˘ Department of Computer Science, University of Illinois at Urbana-Champaign fgrosu, [email protected] Abstract. This paper presents a nine-rule language-independent proof system that takes an operational semantics as axioms and derives program properties, including ones corresponding to Hoare triples. This eliminates the need for language-specific Hoare-style proof rules in order to verify programs, and, implicitly, the tedious step of proving such proof rules sound for each language separately. The key proof rule is Circularity, which is coinductive in nature and allows for reasoning about constructs with repetitive behaviors (e.g., loops). The generic proof system is shown sound and has been implemented in the MatchC program verifier. 1 Introduction An operational semantics defines a formal executable model of a language typically in terms of a transition relation cfg ) cfg0 between program configurations, and can serve as a formal basis for language understanding, design, and implementation. On the other hand, an axiomatic semantics defines a proof system typically in terms of Hoare triples f g code f 0g, and can serve as a basis for program reasoning and verification. Operational semantics are well-understood and comparatively easier to define than axiomatic semantics for complex languages. More importantly, operational semantics are typically executable, and thus testable. For example, we can test them by executing the program benchmarks that compiler testers use, as has been done with the operational semantics of C [5].
- 
												  Axiomatic SemanticsAdvanced Topics in Programming Languages Spring Semester, 2012 Lecture 6: April 24, 2012 Lecturer: Mooly Sagiv Scribe: Michal Balas and Yair Asa Axiomatic Semantics 6.1 The basic idea The problem we would like to solve is how to prove that a program does what we require of it. Given a program, we specify its required behavior based on our intuitive understanding of it. We can run it according to the operational semantics or denotational semantics and compare to its behavior there. For some programs we need to be more abstract (for example programs that receive input), and then it is necessary to use some logic to reason about the program (and how it behaves on a set of inputs and not in one specific execution path). In this case we may eventually develop a formal proof system for properties of the program or showing that it satisfies a requirement. We can then use the proof system to show correctness. These rules of the proof system are called Hoare or Floyd-Hoare rules. Floyd-rules are for flow-charts and Hoare-rules are for structured languages. Originally their approach was advocated not just for proving properties of programs but also giving a method for explaining the meaning of program. The meaning of a program was specified in terms of \axioms" saying how to prove properties of it, in other words it is given by a set of verification rules. Therefore, this approach was named axiomatic semantics. Axiomatic semantics has many applications, such as: Program verifiers • Symbolic execution tools for bug hunting • Software validation tools • Malware detection • Automatic test generation • It is also used for proving the correctness of algorithms or hardware descriptions, \extended static checking (e.g., checking array bounds), and documenting programs and interfaces.
- 
												  Modeling of Hardware and Software for Specifying Hardware AbstractionModeling of Hardware and Software for specifying Hardware Abstraction Layers Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, Pierre Moreau, Samuel Rochet To cite this version: Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, et al.. Modeling of Hardware and Software for specifying Hardware Abstraction Layers. Embedded Real Time Software and Systems (ERTS2014), Feb 2014, Toulouse, France. hal-02272457 HAL Id: hal-02272457 https://hal.archives-ouvertes.fr/hal-02272457 Submitted on 27 Aug 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Modeling of Hardware and Software for specifying Hardware Abstraction Layers Yves BERNARD1, Cédric GAVA2, Cédrik BESSEYRE1, Bertrand CROUZET1, Laurent MARLIERE1, Pierre MOREAU1, Samuel ROCHET2 (1) Airbus Operations SAS (2) Subcontractor for Airbus Operations SAS Abstract In this paper we describe a practical approach for modeling low level interfaces between software and hardware parts based on SysML operations. This method is intended to be applied for the development of drivers involved on what is classically called the “hardware abstraction layer” or the “basic software” which provide high level services for resources management on the top of a bare hardware platform.
- 
												  A Game Theoretical Semantics for a Logic of Formal InconsistencyA game theoretical semantics for a logic of formal inconsistency CAN BA¸SKENT∗, Department of Computer Science, University of Bath, BA2 7AY, England. Downloaded from https://academic.oup.com/jigpal/article/28/5/936/5213088 by guest on 25 September 2020 PEDRO HENRIQUE CARRASQUEIRA∗∗, Center for Logic, Epistemology and the History of Science (CLE), Institute of Philosophy and the Humanities (IFCH), State University of Campinas (UNICAMP), Campinas 13083-896, Brazil. Abstract This paper introduces a game theoretical semantics for a particular logic of formal inconsistency called mbC. Keywords: Game theoretical semantics, logic of formal inconsistency, mbC, non-deterministic runs, oracles 1 Motivation Paraconsistent logics are the logics of inconsistencies. They are designed to reason about and with inconsistencies and generate formal systems that do not get trivialized under the presence of inconsistencies. Formally, a logic is paraconsistent if the explosion principle does not hold—in paraconsistent systems, there exist some formulas ϕ, ψ such that ϕ, ¬ϕ ψ. Within the broad class of paraconsistent logics, Logics of Formal Inconsistency (LFIs, for short) present an original take on inconsistencies. Similar to the da Costa systems, LFIs form a large class of paraconsistent logics and make use of a special operator to control inconsistencies [8, 9]. Another interesting property of LFIs is that they internalize consistency and inconsistency at the object level. To date, the semantics for LFIs has been suggested using truth tables and algebraic structures. What we aim for in this paper is to present a game theoretical semantics for a particular logic within the class of LFIs. By achieving this, we attempt at both presenting a wider perspective for the semantics of paraconsistency and a broader, more nuanced understanding of semantic games.
- 
												  Making Classes Provable Through Contracts, Models and FramesView metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by CiteSeerX DISS. ETH NO. 17610 Making classes provable through contracts, models and frames A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH (ETH Zurich)¨ for the degree of Doctor of Sciences presented by Bernd Schoeller Diplom-Informatiker, TU Berlin born April 5th, 1974 citizen of Federal Republic of Germany accepted on the recommendation of Prof. Dr. Bertrand Meyer, examiner Prof. Dr. Martin Odersky, co-examiner Prof. Dr. Jonathan S. Ostroff, co-examiner 2007 ABSTRACT Software correctness is a relation between code and a specification of the expected behavior of the software component. Without proper specifica- tions, correct software cannot be defined. The Design by Contract methodology is a way to tightly integrate spec- ifications into software development. It has proved to be a light-weight and at the same time powerful description technique that is accepted by software developers. In its more than 20 years of existence, it has demon- strated many uses: documentation, understanding object-oriented inheri- tance, runtime assertion checking, or fully automated testing. This thesis approaches the formal verification of contracted code. It conducts an analysis of Eiffel and how contracts are expressed in the lan- guage as it is now. It formalizes the programming language providing an operational semantics and a formal list of correctness conditions in terms of this operational semantics. It introduces the concept of axiomatic classes and provides a full library of axiomatic classes, called the mathematical model library to overcome prob- lems of contracts on unbounded data structures.
- 
												  Game Semantics of Homotopy Type TheoryGame Semantics of Homotopy Type Theory Norihiro Yamada [email protected] University of Minnesota Homotopy Type Theory Electronic Seminar Talks (HoTTEST) Department of Mathematics, Western University February 11, 2021 N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 1 / 19 Just like axiomatic set theory is explained by sets in an informal sense, the conceptual foundation of Martin-L¨oftype theory (MLTT) is computations in an informal sense (a.k.a. the BHK-interpretation). Proofs/objects as computations (e.g., succ : : max N); MLTT as a foundation of constructive maths. On the other hand, homotopy type theory (HoTT) is motivated by the homotopical interpretation of MLTT. HoTT = MLTT + univalence + higher inductive types (HITs); Homotopical interpretation: formulas as spaces, proofs/objects as points, and higher proofs/objects as paths/homotopies. Introduction Background: MLTT vs. HoTT N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 2 / 19 Proofs/objects as computations (e.g., succ : : max N); MLTT as a foundation of constructive maths. On the other hand, homotopy type theory (HoTT) is motivated by the homotopical interpretation of MLTT. HoTT = MLTT + univalence + higher inductive types (HITs); Homotopical interpretation: formulas as spaces, proofs/objects as points, and higher proofs/objects as paths/homotopies. Introduction Background: MLTT vs. HoTT Just like axiomatic set theory is explained by sets in an informal sense, the conceptual foundation of Martin-L¨oftype theory (MLTT) is computations in an informal sense (a.k.a. the BHK-interpretation). N. Yamada (Univ. of Minnesota) Game semantics of HoTT Feb. 11, 2021, Western 2 / 19 MLTT as a foundation of constructive maths.
- 
												  The Monastic Rules of Visigothic Iberia: a Study of Their Text and LanguageTHE MONASTIC RULES OF VISIGOTHIC IBERIA: A STUDY OF THEIR TEXT AND LANGUAGE By NEIL ALLIES A thesis submitted to The University of Birmingham for the degree of DOCTOR OF PHILOSOPHY Department of Theology and Religion College of Arts and Law The University of Birmingham July 2009 University of Birmingham Research Archive e-theses repository This unpublished thesis/dissertation is copyright of the author and/or third parties. The intellectual property rights of the author or third parties in respect of this work are as defined by The Copyright Designs and Patents Act 1988 or as modified by any successor legislation. Any use made of information contained in this thesis/dissertation must be in accordance with that legislation and must be properly acknowledged. Further distribution or reproduction in any format is prohibited without the permission of the copyright holder. Abstract This thesis is concerned with the monastic rules that were written in seventh century Iberia and the relationship that existed between them and their intended, contemporary, audience. It aims to investigate this relationship from three distinct, yet related, perspectives: physical, literary and philological. After establishing the historical and historiographical background of the texts, the thesis investigates firstly the presence of a monastic rule as a physical text and its role in a monastery and its relationship with issues of early medieval literacy. It then turns to look at the use of literary techniques and structures in the texts and their relationship with literary culture more generally at the time. Finally, the thesis turns to issues of the language that the monastic rules were written in and the relationship between the spoken and written registers not only of their authors, but also of their audiences.
- 
												  A Full Stack Approach to FPGA Integration in the CloudThis article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/MM.2018.2877290, IEEE Micro THEME ARTICLE: HARDWARE ACCELERATION Galapagos: A Full Stack Approach to FPGA Integration in the Cloud Naif Tarafdar Field-Programmable Gate Arrays (FPGAs) have University of Toronto shown to be quite beneficial in the cloud due to their Nariman Eskandari energy-efficient application-specific acceleration. University of Toronto These accelerators have always been difficult to use Varun Sharma University of Toronto and at cloud scale, the difficulty of managing these Charles Lo devices scales accordingly. We approach the University of Toronto challenge of managing large FPGA accelerator Paul Chow clusters in the cloud using abstraction layers and a University of Toronto new hardware stack that we call Galapagos. The hardware stack abstracts low-level details while providing flexibility in the amount of low-level access users require to reach their performance needs. Computing today has evolved towards using large-scale data centers that are the basis of what many call the cloud. Within the cloud, large-scale applications for Big Data and machine learn- ing can use thousands of processors. At this scale, even small efficiency gains in performance and power consumption can translate to significant amounts. In the data center, power consump- tion is particularly important as 40 % of the costs are due to power and cooling [1]. Accelerators, which are more efficient for classes of computations, have become an important approach to ad- dressing both performance and power efficiency.
- 
												  The Game Semantics of Game TheoryThe game semantics of game theory Jules Hedges We use a reformulation of compositional game theory to reunite game theory with game semantics, by viewing an open game as the System and its choice of contexts as the Environment. Specifically, the system is jointly controlled by n ≥ 0 noncooperative players, each independently optimising a real-valued payoff. The goal of the system is to play a Nash equilibrium, and the goal of the environment is to prevent it. The key to this is the realisation that lenses (from functional programming) form a dialectica category, which have an existing game-semantic interpretation. In the second half of this paper, we apply these ideas to build a com- pact closed category of ‘computable open games’ by replacing the underly- ing dialectica category with a wave-style geometry of interaction category, specifically the Int-construction applied to the traced cartesian category of directed-complete partial orders. 1 Introduction Although the mathematics of games shares a common ancestor in Zermelo’s work on backward induction, it split early on into two subjects that are essentially disjoint: game theory and game semantics. Game theory is the applied study of modelling real-world interacting agents, for example in economics or artificial intelligence. Game semantics, by contrast, uses agents to model – this time in the sense of semantics rather than mathematical modelling – situations in which a system interacts with an environment, but neither would usually be thought of as agents in a philosophical sense. On a technical level, game semantics not only restricts to the two-player zero-sum case, but moreover promotes one of the players to be the Player, and demotes the other to mere Opponent.
- 
												  W4118 Operating Systems OS OverviewW4118 Operating Systems OS Overview Junfeng Yang Outline OS definitions OS abstractions/concepts OS structure OS evolution What is OS? A program that acts as an intermediary between a user of a computer and the computer hardware. User App stuff between OS HW Two popular definitions Top-down perspective: hardware abstraction layer , turn hardware into something that applications can use Bottom-up perspective: resource manager/coordinator , manage your computers resources OS = hardware abstraction layer standard library OS as virtual machine E.g. printf(hello world), shows up on screen App can make system calls to use OS services Why good? Ease of use : higher level of abstraction, easier to program Reusability : provide common functionality for reuse E.g. each app doesnt have to write a graphics driver Portability / Uniformity : stable, consistent interface, different OS/version/hardware look same E.g. scsi/ide/flash disks Why abstraction hard? What are the right abstractions ??? Too low level ? Lose advantages of abstraction Too high level? All apps pay overhead, even those dont need Worse, may work against some apps E.g. Database Next: example OS abstractions Two popular definitions Top-down perspective: hardware abstraction layer, turn hardware into something that applications can use Bottom-up perspective: resource manager/coordinator , manage your computers resources OS = resource manager/coordinator Computer has resources, OS must manage. Resource = CPU, Memory, disk, device, bandwidth, Shell ppt gcc browser System Call Interface CPU Memory File system scheduling management management OS Network Device Disk system stack drivers management CPU Memory Disk NIC Hardware OS = resource manager/coordinator (cont.) Why good? Sharing/Multiplexing : more than 1 app/user to use resource Protection : protect apps from each other, OS from app Who gets what when Performance : efficient/fair access to resources Why hard? Mechanisms v.s.