DOCSLIB.ORG

Lisaac Efficient Compilation Strategy for Object-Oriented Languages Under the Closed-World Assumption

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lisaac Efficient Compilation Strategy for Object-Oriented Languages Under the Closed-World Assumption Introduction The language Compiler Benchmark Future Conclusion Lisaac Efficient compilation strategy for object-oriented languages under the closed-world assumption Benoˆıt Sonntag – [email protected] http://www.lisaac.org Introduction The language Compiler Benchmark Future Conclusion History : Lisaac for IsaacOOS Language The futur... Lisaac In the past... Prototype based Object C language Oriented Language ⇓ ⇓ Unix system IsaacOOS Prototype Object Operating System Introduction The language Compiler Benchmark Future Conclusion Let them sink in a bigger box ? Introduction The language Compiler Benchmark Future Conclusion High-level vs Hardware Object Oriented for Hardware Software / High-Level / Expressivity Self Eiffel Lisaac Java C ASM Hardware support Introduction The language Compiler Benchmark Future Conclusion Class vs Prototype (1/3) Class Instance 1 Squeleton 1 Object (=class) Prototype Clone 1 Object prototype 1 other Object (=the One) Introduction The language Compiler Benchmark Future Conclusion Class vs Prototype (2/3) Prototype Class Class A A object (Prototype or not) B Instance 1 Object with A and B definition B.Clone Class B 1 other Object B object (Prototype or not) Introduction The language Compiler Benchmark Future Conclusion Class vs Prototype (3/3) Dynamic inheritance XOR Introduction The language Compiler Benchmark Future Conclusion Example : Hello world! hello.li Section Header + name := HELLO; Section Public − main < − ( (1+2).print; ’A’.print; ‘‘Hello world !\n’’.print; ); Command line : lisaac hello.li Executable result : hello (ou hello.exe for windows) Introduction The language Compiler Benchmark Future Conclusion Slot identifier − qsort tab:COLLECTION from low:INTEGER to high:INTEGER ← ( + i,j:INTEGER; + x,y:OBJECT; i := low; j := high; x := tab.item ((i + j)>> 1); { ... (i <= j).if { tab.swap j and i; ... }; }.do while {i <= j}; (low < j).if { qsort tab from low to j; }; (i < high).if { qsort tab from i to high; }; ); Introduction The language Compiler Benchmark Future Conclusion Slot identifier − qsort tab:COLLECTION from low:INTEGER to high:INTEGER ← ( + i,j:INTEGER; + x,y:OBJECT; i := low; j := high; x := tab.item ((i + j)>> 1); { ... (i <= j).if { tab.swap j and i; ... }; }.do while {i <= j}; (low < j).if { qsort tab from low to j; }; (i < high).if { qsort tab from i to high; }; ); Introduction The language Compiler Benchmark Future Conclusion Slot identifier: if − qsort tab:COLLECTION from low:INTEGER to high:INTEGER ← ( + i,j:INTEGER; + x,y:OBJECT; i := low; j := high; x := tab.item ((i + j)>> 1); { ... (i <= j). if { tab.textcolorblueswap j and i; ... } ; }.do while {i <= j}; (low < j).if { qsort tab from low to j; }; (i < high).if { qsort tab from i to high; }; ); Introduction The language Compiler Benchmark Future Conclusion Slot identifier : loop − qsort tab:COLLECTION from low:INTEGER to high:INTEGER ← ( + i,j:INTEGER; + x,y:OBJECT; i := low; j := high; x := tab.item ((i + j)>> 1); { ... (i <= j).if { tab.swap j and i; ... }; }.do while {i <= j}; (low < j).if { qsort tab from low to j; }; (i < high).if { qsort tab from i to high; }; ); Introduction The language Compiler Benchmark Future Conclusion If then else Introduction The language Compiler Benchmark Future Conclusion Assignment : code Example − color (r,g,b:INTEGER) < − ( true color:=r<<16|g<<8|b; ); ... ( color < − ( gray color := (r+g+b)/3; ); ); Introduction The language Compiler Benchmark Future Conclusion Inheritance : Dynamic once compute parent Once execution dynamic parent evaluation Section Inherit + parent:OBJECT < − ( + result:OBJECT; ...// compute my parent parent := result // my parent is a data now!!! ); Note The first lookup, the parent is dynamically defined The next lookup, the parent is a simple data value Introduction The language Compiler Benchmark Future Conclusion Multi-platform compiler Introduction The language Compiler Benchmark Future Conclusion Global analysis Java, C++: Classic technical Virtual Function Table (VFT) ⇒ Pointer of function ⇒ Indirect call ⇒ No optimization! Lisaac: Global analysis Transitive closure ⇒ Dispatch Binary Branch (DBB) ⇒ Static call ⇒ Full optimization! Introduction The language Compiler Benchmark Future Conclusion Global overview Lisaac source code First step Gathering the live code no yes Second step Stable ? Optimizing the with flow Closed Universe analysis no yes Third step Stable ? Back-end Optimizations Machine code / C code Introduction The language Compiler Benchmark Future Conclusion Dispatch Binary Branch (1/4) Introduction The language Compiler Benchmark Future Conclusion Dispatch Binary Branch (2/4) Introduction The language Compiler Benchmark Future Conclusion Dispatch Binary Branch (3/4) Introduction The language Compiler Benchmark Future Conclusion DBB: If then else Introduction The language Compiler Benchmark Future Conclusion Dispatch Binary Branch (4/4) Introduction The language Compiler Benchmark Future Conclusion Customization (1/6) Introduction The language Compiler Benchmark Future Conclusion Customization: Call #1 (2/6) Introduction The language Compiler Benchmark Future Conclusion Customization: Call #2 (3/6) Introduction The language Compiler Benchmark Future Conclusion Customization: Call #3 (4/6) Introduction The language Compiler Benchmark Future Conclusion Customization (5/6) Introduction The language Compiler Benchmark Future Conclusion Customization (6/6) Introduction The language Compiler Benchmark Future Conclusion Customization vs CPA number of arguments ATS 2 6 984 CPA 1,319 methods 124,903 methods 9 5 11352 20 4 74057 145 3 34326 526 2 3483 518 1 602 99 0 99 number of methods number of methods 600 500 400 300 200 100 0 10000 30000 50000 70000 20000 40000 60000 80000 Introduction The language Compiler Benchmark Future Conclusion Array: Pattern Matching control (1/2) used area supply area storage 0 1 2 3 4 5 6 7 size 4 NULL NC NC NC NC capacity 8 Obj_A Obj_B Obj_C Introduction The language Compiler Benchmark Future Conclusion Array: Pattern Matching control (2/2) Introduction The language Compiler Benchmark Future Conclusion As fast a C language Introduction The language Compiler Benchmark Future Conclusion Tiny test: Quicksort Introduction The language Compiler Benchmark Future Conclusion Compiler / Bootstrap Introduction The language Compiler Benchmark Future Conclusion Isaac OS benchmark Introduction The language Compiler Benchmark Future Conclusion MPEG2 benchmark Introduction The language Compiler Benchmark Future Conclusion Shootout benchmark (1/2) Introduction The language Compiler Benchmark Future Conclusion Shootout benchmark (2/2) Introduction The language Compiler Benchmark Future Conclusion Horizontal inheritance PARENT time Unpredictable (seconds) SmartEiffel method <- 40 abstract; 30 C++ inherit 20 CHILD_1 CHILD_2 CHILD_3 CHILD_N Lisaac method <- method <- method <- method <- 10 N "1".print; "2".print; "3".print; "n".print; 2 8 32 128 512 time Predictable 20 (seconds) Unpredictable MAIN Predictable MAIN C++ main <- main <- SmartEiffel Lisaac 1_000_000_000.times { 1_000_000_000.times { 10 array.item(random).method; array.item(random & 1).method; }; }; N 2 8 32 128 512 Introduction The language Compiler Benchmark Future Conclusion Vertical inheritance time Unpredictable PARENT 40 (seconds) SmartEiffel method <- "Hi".print; inherit 30 CHILD_1 crash inherit 20 C++ CHILD_2 Lisaac inherit 10 CHILD_3 N 2 8 32 128 512 CHILD_N time Predictable 20 (seconds) crash Unpredictable MAIN Predictable MAIN C++ SmartEiffel main <- main <- Lisaac 1_000_000_000.times { 1_000_000_000.times { 10 array.item(random).method; array.item(random & 1).method; }; }; N 2 8 32 128 512 Introduction The language Compiler Benchmark Future Conclusion Auto-cascading runtime Automatic cascading-calls detection. (seconds) 150 135 120 C++ MAIN 105 main <- 500_000_000.times { 90 receiver := array.item(random); 75 receiver.method1; 60 Lisaac receiver.method2; Same receiver receiver.method3; for all calls. 45 ... Dispatching code 30 ... is factorized. cascading receiver.methodN; 15 factor }; 1 2 3 4 5 6 7 8 9 10 N Introduction The language Compiler Benchmark Future Conclusion Call on self (this) PARENT time 256 method tmp <- m1 tmp <- (seconds) C++ tmp := self.m1(tmp) tmp + 1 tmp := self.m2(tmp) 128 . m2 tmp <- tmp := self.mN(tmp) tmp + 2 64 tmp . mN tmp <- 32 tmp + N 16 inherit 8 SmartEiffel CHILD_1 CHILD_2 CHILD_3 CHILD_N 4 m1 tmp <- m2 tmp <- m3 tmp <- mN tmp <- Lisaac tmp + 1+1 tmp + 2+2 tmp + 3+3 tmp + N+N 2 MAIN 1 main <- 200_000_000.times { tmp := array.item(random).method(tmp); 0.5 }; tmp.print; 0 N 24 8 16 32 64 128 256 Introduction The language Compiler Benchmark Future Conclusion Multiple inheritance (1/2) PARENT dta:INTEGER m1 tmp <- dta := dta + 1 method tmp <- tmp + dta tmp := self.m1(tmp) tmp := self.m2(tmp) m2 tmp <- . dta := dta + 2 tmp := self.mN(tmp) tmp + dta tmp . time mN tmp <- 32 (seconds) dta := dta + N tmp + dta 16 C++ Lisaac inherit 8 SmartEiffel CHILD_1 CHILD_2 CHILD_N dta1:INTEGER dta2:INTEGER dtaN:INTEGER 4 m1 tmp <- m2 tmp <- ... mN tmp <- dta1 := dta1 + 1 dta2 := dta2 + 1 dtaN := dtaN + 1 2 tmp + dta1 tmp + dta2 tmp + dtaN ... 1 0.5 INSTANCE_1 INSTANCE_2 ... INSTANCE_N 0 N MAIN 24 8 16 32 64 128 256 main <- 1_000_000.times { tmp := array.item(random).method(tmp); }; tmp.print; Introduction The language Compiler Benchmark Future Conclusion Multiple inheritance (2/2) N C++ SmartEiffel Lisaac C++ Lisaac 256 128 64 SmartEiffel 32 16 8 4 data segment text segment 2 128 64 32 16 8 4 2 1 256 128 64 32 16 8 4 2 1 0 0 1 2 4 8 16 32 64 128 256 1
Load more

Recommended publications
  • LNCS 4119, Pp
    Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application Joseph R. Kiniry School of Computer Science and Informatics University College Dublin Belfield, Dublin 8, Ireland [email protected] Abstract. Exceptions are frequently a controversial language feature with both language designers and programmers. Exceptions are controversial because they complicate language semantics—and thus program design, testing, and verifica- tion—and some programmers find them annoying or difficult to use properly. By examining two programming languages that have very different, even opposing, exception mechanisms, a set of exception principles is introduced that summarize the key semantic and social issues surrounding exceptions. 1 Introduction The designers of future programming languages must decide whether to include excep- tions in their new languages. If they decide exceptions are warranted, they must then consider what exceptions represent: (1) a structure for control flow, (2) a structure for handling abnormal, unpredictable situations, or (3) something in-between. Additionally, the syntax and meaning of exceptions must be considered. The syntax of exception mechanisms is also important. Syntax impacts how program code looks and is comprehended, it influences the design and realization of algorithms, and it affects the manner in which programmers handle unusual cases and unexpected situations, and thus indirectly impacts software reliability. And, while the syntax of exception mechanisms is the aspect most programmers see, tool developers and lan- guage theoreticians must wrestle with exception semantics. In general, a small, elegant semantics is desired by all parties. One way to consider how to design a feature like exceptions in future languages is to analyze their design in today’s languages.
    [Show full text]
  • From Eiffel to the Java Virtual Machine
    From Eiffel to the Java Virtual Machine Adding a new language target to the EiffelStudio compiler Søren Engel, [email protected] Supervisor Dr. Joseph R. Kiniry Thesis submitted to The IT University of Copenhagen for the degree of Bachelor of Science in Software Development August 2012 Abstract Previous attemps has been made towards translating and executing programs written in Eiffel on the Java platform, as described in Baumgartner [1]. However, the generated Java code has not been easy to use in terms of interoperability between the two languages, due to the restrictions of the Java language. Due to the evolution of the Java language, the work presented in this thesis examines whether it is possible to simplify the translation model of Eiffel to Java. In doing so, this thesis describes a refined translation model that leverages on some of the new features of the Java language, such as the invokedynamic bytecode instruction. Moreover, in order to verify the correctness of the proposed translation model, a description follows on how the translation model may be integrated into the existing EiffelStudio compiler, in terms extending the back-end to target the Java platform. In regards of simplicity, it was found that by using new language features of Java, the translation model of Eiffel to Java could be simplified to the extend that it solves the known issues found in the solution presented in Baumgartner [1]. In trying to integrate the translation model into the existing EiffelStudio compiler, it was found that no public documentation exists which described the internal structure of the EiffelStudio compiler.
    [Show full text]
  • Volume 28 Number 1 March 2007
    ADA Volume 28 USER Number 1 March 2007 JOURNAL Contents Page Editorial Policy for Ada User Journal 2 Editorial 3 News 5 Conference Calendar 38 Forthcoming Events 45 Articles C. Comar, R. Berrendonner “ERB : A Ravenscar Benchmarking Framework” 53 Ada-Europe 2006 Sponsors 64 Ada-Europe Associate Members (National Ada Organizations) Inside Back Cover Ada User Journal Volume 28, Number 1, March 2007 2 Editorial Policy for Ada User Journal Publication Original Papers Commentaries Ada User Journal – The Journal for the Manuscripts should be submitted in We publish commentaries on Ada and international Ada Community – is accordance with the submission software engineering topics. These published by Ada-Europe. It appears guidelines (below). may represent the views either of four times a year, on the last days of individuals or of organisations. Such March, June, September and All original technical contributions are articles can be of any length – December. Copy date is the first of the submitted to refereeing by at least two inclusion is at the discretion of the month of publication. people. Names of referees will be kept Editor. confidential, but their comments will Opinions expressed within the Ada Aims be relayed to the authors at the discretion of the Editor. User Journal do not necessarily Ada User Journal aims to inform represent the views of the Editor, Ada- readers of developments in the Ada The first named author will receive a Europe or its directors. programming language and its use, complimentary copy of the issue of the general Ada-related software Journal in which their paper appears. Announcements and Reports engineering issues and Ada-related We are happy to publicise and report activities in Europe and other parts of By submitting a manuscript, authors grant Ada-Europe an unlimited license on events that may be of interest to our the world.
    [Show full text]
  • Eiffel, Smarteiffel, Conception Par Objets, Programmation Par
    Eiffel, SmartEiffel, conception par objets, programmation par objets, programmation par contrats, interface, g´en´ericit´e, liaison dynamique, simulation, et cætera. Dominique Colnet { [email protected] 11 juillet 2007 Avertissement Ce document en cours de r´edaction n'a pas la pr´etention d'^etre un ou- vrage complet et exhaustif sur la conception et la programmation par objets avec le langage Eiffel. Ce n'est pas un manuel de r´ef´erence du langage Eiffel ni la documentation du com- pilateur et des outils de SmartEiffel1. Il s'agit plut^ot d'un ensemble de notes de cours, d'une suite plus ou moins p´edagogique de transparents ainsi qu'une collection h´et´erog`ene d'exercices. Comme c'est souvent le cas pour les polycopi´es d'enseignement, le document actuel est constamment en cours de r´edaction. La premi`ere version de ce document doit dater des ann´ees 19902, date `a laquelle nous avons d´ecid´e d'utiliser Eiffel pour la licence d'in- formatique de l'Universit´e Henri Poincar´e (Nancy 1) ainsi qu’`a l'ESIAL (Ecole´ Sup´erieure d'Informatique et Applications de Lorraine). Toutes les suggestions seront les bienvenues (m^eme les corrections orthographiques). Ce document peut ^etre diffus´e reproduit et/ou modifi´e librement a` la seule condition d'indiquer sa provenance initiale et de laisser le pr´esent avertissement inchang´e. Si vous souhaitez disposer du texte source (LATEX) du document, il suffit de me le demander par mail ([email protected]). Table des mati`eres 1 Les premiers pas 3 1.1 Le premier programme .
    [Show full text]
  • Technical Report
    Proceedings of the ECOOP 2003 Workshop on Exception Handling in Object-Oriented Systems: Towards Emerging Application Areas and New Programmi Technical Report Department of Computer Science and Engineering University of Minnesota 4-192 EECS Building 200 Union Street SE Minneapolis, MN 55455-0159 USA TR 03-028 Proceedings of the ECOOP 2003 Workshop on Exception Handling in Object-Oriented Systems: Towards Emerging Application Areas and New Programmi Alexander Romanovsky, Christophe Dony, Jorgen Lindskov Knudsen, and Anand Tripathi July 01, 2003 Exception Handling in Object Oriented Systems: Towards Emerging Application Areas and New Programming Paradigms Workshop July 21, 2003 ECOOP 2003 ii Table of Contents Introduction.............................................................................................................................. v Workshop Organizers ............................................................................................................. vi Workshop Program................................................................................................................ vii Invited talk Getting Control of Exception (Abstract)......................................................................... 1 Papers Errors and Exceptions – Rights and Responsibilities..................................................... 2 Analyzing Exception Usage in Large Java Applications.............................................. 10 Bound Exceptions in Object Programming .................................................................
    [Show full text]
  • Debian Build Dependecies
    Debian build dependecies Valtteri Rahkonen valtteri.rahkonen@movial.fi Debian build dependecies by Valtteri Rahkonen Revision history Version: Author: Description: 2004-04-29 Rahkonen Changed title 2004-04-20 Rahkonen Added introduction, reorganized document 2004-04-19 Rahkonen Initial version Table of Contents 1. Introduction............................................................................................................................................1 2. Required source packages.....................................................................................................................2 2.1. Build dependencies .....................................................................................................................2 2.2. Misc packages .............................................................................................................................4 3. Optional source packages......................................................................................................................5 3.1. Build dependencies .....................................................................................................................5 3.2. Misc packages ...........................................................................................................................19 A. Required sources library dependencies ............................................................................................21 B. Optional sources library dependencies .............................................................................................22
    [Show full text]
  • Designing Efficient and Safe Weak References in Eiffel with Parametric
    Designing efficient and safe weak references in Eiffel with parametric types Frederic Merizen, Olivier Zendra, Dominique Colnet To cite this version: Frederic Merizen, Olivier Zendra, Dominique Colnet. Designing efficient and safe weak references in Eiffel with parametric types. [Intern report] A03-R-517 || merizen03a, 2003, pp.14. inria-00107752 HAL Id: inria-00107752 https://hal.inria.fr/inria-00107752 Submitted on 19 Oct 2006 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. Designing efficient and safe weak references in Eiffel with parametric types Frederic Merizen∗ Olivier Zendray Dominique Colnetz Emails: {merizen,zendra,colnet}@loria.fr LORIA 615 Rue du Jardin Botanique BP 101 54602 VILLERS-LES-NANCY Cedex FRANCE December 15, 2003 Abstract In this paper, we present our work on the design and implementation of weak references within the SmartEiffel project. We introduce the known concept of weak references, reminding how this peculiar kind of references can be used to optimize and fine-tune the memory behavior of programs, thus potentially speeding up their execution. We show that genericity (parametric types in Eiffel) is the key to implementing weak references in a statically-checked hence safer and more efficient way.
    [Show full text]
  • Object-Oriented Literate Programming
    Object-Oriented Literate Programming By Ming Yu Zhao, B.Sc. A Thesis Submitted to the School of Graduate Studies in Partial Fulfilment of the Requirements for the Degree of Master of Science Department of Computing and Software McMaster University c Copyright by Ming Yu Zhao, August 2007 ii Master of Science (2007) McMaster University (Computing and Software) Hamilton, Ontario Title: Object-Oriented Literate Programming Author: Ming Yu Zhao, B.Sc. (Dalian University of Technology) Supervisor: Dr. Emil Sekerinski Number of pages: x, 179 Abstract During the past decades, programming methodology has seen an improvement by structured programming and object-oriented programming (OOP), leading to soft- ware that is more reliable and easier to develop. However, software engineers are still dealing with problems in processing associated documentation. Literate programming was introduced by Donald Knuth in the early 80's as an approach to produce pro- grams together with their documentation in a way that is aimed at consumption by humans rather than by compilers. However, dated and complex features, dependence on formatting and programming language, and a lack of methodology prevented the method from gaining in popularity. In this thesis, we propose an approach to \integrate" OOP with literate pro- gramming in order to present and document the whole design in a consistent and maintainable way. In our approach, both program code and corresponding documen- tation are generated from the same source. The resulting documentation consists of code chunks with detailed explanations, as well as automatically generated class diagrams with varying levels of detail. A tool, Spark, has been developed and applied to the design of a Transit Information System from requirement analysis to testing.
    [Show full text]
  • Diploma Thesis
    Eiffel SDL multimedia library (ESDL) DIPLOMA THESIS Till G. Bay 24th September 2003 Project Period: Monday, 2003-05-26 - Friday, 2003-09-26 Student: Till G. Bay ([email protected]) Student-No: 98-803-000 Supervising Assistant: Karine Arnout Supervising Professor: Bertrand Meyer 1 ETHZ D-INFK Eiffel SDL multimedia library (ESDL) - DIPLOMA THESIS Prof. Dr. Bertrand Meyer Till G. Bay Contents I Description 5 1 Project description 5 1.1 Overview ............................... 5 1.2 Scope of the work ........................... 6 1.3 Intended results ............................ 7 II Project Steps 8 2 Evaluation 8 2.1 Evaluation of SDL Wrappers .................... 8 2.1.1 Evaluation of EWG ..................... 8 2.1.2 Evaluation of jegl ....................... 8 2.1.3 Conclusion .......................... 9 2.2 Evaluation of existing multimedia libraries for Eiffel ....... 9 2.2.1 Evaluation of EiffelFURY .................. 9 2.2.2 Evaluation of Eiffel SDL .................. 10 2.2.3 Conclusion .......................... 10 3 Usability discussion 11 3.1 Demo Creation ............................ 11 3.2 Discussion of the found usability flaws ............... 12 4 Redesign 13 5 Applications 15 6 Extensions 16 III State and future of ESDL 17 IV Project Organization 22 7 Background material 22 7.1 Reading list .............................. 22 8 Project management 22 8.1 Objectives and priorities ....................... 22 8.1.1 Design objectives ....................... 22 8.1.2 Objectives for the intended results ............. 23 8.2 Criteria for success .......................... 23 8.3 Method of work ............................ 24 8.4 Quality management ......................... 24 8.4.1 Documentation ........................ 24 8.4.2 Validation steps ....................... 24 2 ETHZ D-INFK Eiffel SDL multimedia library (ESDL) - DIPLOMA THESIS Prof.
    [Show full text]
  • Unix Et Programmation Shell
    Unix et Programmation Shell Philippe Langevin d´epartment d'informatique UFR sciences et technique universit´edu sud Toulon Var Automne 2013 Philippe Langevin (imath/ustv) Unix et Programmation Shell Automne 2013 1 / 33 document brouillon en r´evision site du cours : http://langevin.univ-tln.fr/cours/UPS/upsh.html localisation du fichier : http://langevin.univ-tln.fr/cours/UPS/doc/intro.pdf Philippe Langevin (imath/ustv) Unix et Programmation Shell Automne 2013 2 / 33 derni`eresmodifications intro.tex 2013-06-23 10:07:23.697660496 +0200 macros.tex 2013-06-22 23:42:16.868263946 +0200 prologue.tex 2013-06-22 22:10:45.967471216 +0200 upsh.tex 2013-06-22 11:24:27.941744751 +0200 tools.tex 2013-06-22 11:24:27.940741957 +0200 term.tex 2013-06-22 11:24:27.934741399 +0200 syntaxe.tex 2013-06-22 11:24:27.931741678 +0200 proc.tex 2013-06-22 11:24:27.927741678 +0200 piped.tex 2013-06-22 11:24:27.922741399 +0200 perm.tex 2013-06-22 11:24:27.921741678 +0200 part.tex 2013-06-22 11:24:27.918742237 +0200 man.tex 2013-06-22 11:24:27.911741957 +0200 langage.tex 2013-06-23 10:04:58.364659987 +0200 file.tex 2013-06-22 11:24:27.896741119 +0200 dup.tex 2013-06-22 11:24:27.885741678 +0200 fic.tex 2013-06-22 11:24:27.885741678 +0200 bash.tex 2013-06-22 11:24:27.881741957 +0200 Philippe Langevin (imath/ustv) Unix et Programmation Shell Automne 2013 3 / 33 shell unix 1 - shell unix origine unices GNU/linux distribution shell unix GUI vs CLI exemple Philippe Langevin (imath/ustv) Unix et Programmation Shell Automne 2013 4 / 33 1969 Ken Thompson cr´eele syst`eme UNICS 1971 Dennis Ritchie cr´ee Le langage C utile pour le d´eveloppement d'unix.
    [Show full text]
  • Implementing Statically Typed Object-Oriented Programming Languages
    Implementing Statically Typed Object-Oriented Programming Languages ROLAND DUCOURNAU LIRMM { CNRS et Universit´eMontpellier II, France Object-oriented programming represents an original implementation issue due to its philosophy of making the program behaviour depend on the dynamic type of objects. This is expressed by the late binding mechanism, aka message sending. The underlying principle is that the address of the actually called procedure is not statically determined at compile-time, but depends on the dynamic type of a distinguished parameter known as the receiver. A similar issue arises with attributes, because their position in the object layout may also depend on the object's dynamic type. Furthermore, subtyping introduces another original feature, i.e. runtime subtype checks. All three mechanisms need specific implementations and data structures. In static typing, late binding is generally implemented with so-called virtual function tables. These tables reduce method calls to pointers to functions, through a small fixed number of extra indirections. It follows that object-oriented programming yields some overhead, as compared to usual procedural languages. The different techniques and their resulting overhead depend on several parameters. First, inheritance and subtyping may be single or multiple and a mixing is even possible, as in Java and .Net which present single inheritance for classes and multiple subtyping for interfaces. Multiple inheritance is a well known complication. Second, the production of executable programs may in- volve various schemes, from global compilation, which implies the closed-world assumption (CWA) as the whole program is known at compile time, to separate compilation and dynamic loading, where each program unit is compiled and loaded independently of any usage, hence under the open-world assumption (OWA).
    [Show full text]
  • Vulnerability Analysis (Axis I) § Malware Analysis (Axis II) § Research Projects § Additional Possibilities for Future
    Scientist who joined IRISA 2017 Institut de Recherche en Informatique et Systèmes Aléatoires Olivier ZENDRA CR (Inria) D4 -Language And Software Engineering (LSE) TAMIS Short BIO Olivier Zendra is new member of the Tamis team. His research focused on the analysis and transformation of programs, which he developed in the context of compilation and optimization, memory management and automatic garbage collection, impact of the hardwaresoftware interface on performance, power and energy optimizations for embedded systems, software visualization and cybersecurity. The research projects he has worked on include SmartEiffel, The GNU Eiffel Compiler (formerly SmallEiffel), during his PhD, for which he was one of the two key designers and implementers during his PhD; the software part of the Open-PEOPLE (Open Power and Energy Optimization PLatform and Estimator) project; and the VITRAIL (Advanced, Immersive and Real-Time Visualisation Software) project. He received the PhD degree in computer science with highest honors in 2000 from the the Université Henri Poincaré of Nancy, France, on the compilation and optimization of objetoriented programs. He then worked a year as postdoctorate at McGill University, Canada, on optimization of Java (bytecode) programs. He joined Inria Nancy in 2002, where he worked in the Miro, Design and TRIO teams, extending his work to power and energy, and later program visualization. He joined the Tamis team of Irisa and Inria- Rennes working in cybersecurity in September 2016, moving to Rennes in August 2017. Olivier ZENDRA Short BIO Who am I ? Timeline 1971: Birth (from + ) 1995: « DEA » in CS 1995 - 1997: « Coopérant Scientifique » at UCSB 1997 - 2000: PhD in CS (Highest honors) 2001 - 2002: Postdoctorate at McGill University 2002 - 09/2016: CR2/1 at Inria Nancy 09/2016 - 09/2017 : CR1 in Tamis team Inria RBA (living in Lorraine ) 09/2017 - : CR1 in Tamis team Inria RBA (living in Brittany ) Olivier ZENDRA Research project 1.
    [Show full text]