Research Collection Doctoral Thesis Separate compilation and module extension Author(s): Crelier, Régis Bernard Joseph Publication Date: 1994 Permanent Link: https://doi.org/10.3929/ethz-a-000945227 Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library Separate Compilation and Module Extension OÏSS.ETH j£*3> Diss.ETH No 10650 Separate Compilation and Module Extension A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH for the degree of Doctor of Technical Sciences presented by Régis Bernard Joseph Crelier ing. informaticien dipl. EPFZ bomJanuan/10,1965 citizen of Bure, Jura ^^y^ accepted on the recommendation of Prof. Dr. N. Wirth, examiner Prof. Dr. H. Môssenbôck, co-examiner 1994 Leer - Vide - Empty A mes parents Leer - Vide - Empty Contents Acknowledgements xi Résumé xii Abstract xiii Chapter 1 Introduction Déclarations and Statements 2 Modules and Interfaces 3 Separate Compilation and Interface Checking 4 Program Linking and Loading 8 Chapter 2 Symbol Files Symbol Table 11 Type Craph 11 ScopeGraph 14 A Brief History 16 Symbol File Classification 16 Symbol File Linearization 17 Chapter 3 System Consistency and Client Invalidation Consistency Checking 21 Granularity of the Checks 22 Compilation Dependence Craph 23 Using Keys for Consistency Checks 25 Restoring System Consistency 27 Trickle-Down Recompilations 27 Benefits of Tools 28 Background 30 Checksum Versus Timestamp 30 Enhancing the Granularity 31 Integrating Type Information into Object Files 32 Motivation 34 Chapter 4 The Portable Oberon-2 Compiler OP2 Architecture of the Compiler 37 Module Structure 38 Symbol Table 40 Syntax Tree 42 Compilation Phases 45 Lexical Analysis and Syntax Analysis 46 Storage Allocation 47 Code Génération 48 Chapter 5 The Layer Model Theldea 51 A Stack of Extension Layers 52 Extensions Versus Modifications 53 Consistency Checking 55 The Implementation 58 Symbol File Format 58 Extemalization, Fingerprinting, and Internalization 64 Storage Allocation and Reallocation 69 Front-End Modifications 76 Object File Format and Linker Modifications 76 Drawbacks and Limitations of the Model 77 Record Field Révélation 77 History of Development 78 Chapter 6 The Object Model The Idea 81 A Fingerprint per Object 82 Fingerprinting Recursive Types 86 Breaking Cycles 89 Fingerprinting Signatures 93 Fingerprint Computation 95 Anonymous Types and Name Equivalence 98 A Fingerprint per Object Component 100 The Implementation 103 Symbol File Format 103 Fingerprinting Structures 106 Fingerprinting Objects 113 Consistency Checking at Compile Time 114 Comparing with the Old Symbol File 117 ix Object File Format 123 Linker and Run-Time Data Structures 127 Chapter 7 Efficiency Considérations and Conclusions Implementation Costs and Measurements 131 Outlook 138 Automating Recompilations 138 Inserting New Type-Bound Procédures 139 Multiple Interfaces 140 Applying the Models to Other Languages 141 Conclusions 142 Appendix A: Layer Model File Formats 143 Appendix B: Object Model File Formats 146 Références 149 Curriculumvltae 153 Acknowledgements Professor Niklaus Wirth, supervisor of this thesis, introduced me to the fasci- nating world of compiler construction. I leamed more by studying both his Modula-2 and Oberon compilers than by reading any book on programming. By offering me the opportunity to work in his research group, he providéd me with a sharper vision of what computer science really is, and should be. Professor Hanspeter Môssenbôck accepted promptly the coreference of this thesis. His numerous questions, comments, and valuable suggestions greatly helped to improve the comprehensibility of the text Joseph Templ was always ready to discuss or propose solutions to encoun- tered problems. In particular, he had the idea to dissociate the fingerprint of a pointer type from the fingerprint of its base type. Clemens Szyperski suggested that client modules not using the size of an imported record type should not be invalidated when this record is augmented by new hidden fields. Jacques Supcik adopted the Object Model for his project of implementing the Oberon System on HP PA-RISC workstations. Thereby, he helped to test the model which was still in an early phase of its development Beat Heeb also applied the Object Model in a commercial Oberon program¬ ming environment based on the OP2 compiler. He found one bug. Cuno Pfister and Stefan Ludwig carefully proofread parts of the manuscript and corrected many language mistakes and inélégances. Hans Meier willingly commented on the page layout of this booklet His expertise in typography is an inexhaustible source of wise counsel. I express my deep gratitude to ail the persons cited above for their guidance, advice, or contribution. I am also thankful to ail my colleagues of the Institute for Computer Systems for the enjoyable working atmosphère and for the fruitful arid exciting discussions during coffee breaks. The implementation on DECstation has been supported by Digital Equip- ment's Systems Research Center in Palo Alto, Califomia, USA, by their generous donation of a workstation. Résumé L'évolution incessante du matériel informatique permet la construction d'ordi¬ nateurs toujours plus performants. Parallèlement, de nouveaux concepts et de nouvelles techniques de programmation deviennent nécessaires afin de maîtri¬ ser la complexité grandissante des logiciels. L'une de ces techniques, la compilation séparée de modules, a fait ses preuves en Modula-2 et en Oberon, entre autres langages de programmation fortement typés. Le module, qui est à la fois l'unité structurelle et l'unité de compilation des programmes, est interchangeable sans affecter les autres modules d'un système. Toutefois, si l'interface du nouveau module est différente de l'ancienne, les modules clients de cette interface modifiée doivent être recompilés afin de maintenir la cohérence du système. L'éditeur de liens vérifie habituellement que la clef réelle de chaque interface importée est identique à la clef attendue par le client, une différence indiquant une incohérence. Ce modèle simple et efficace n'est pas très souple, puisqu'une légère modification d'interface, telle l'insertion d'une nouvelle procédure, par exemple, peut provoquer de nombreuses recom¬ pilations inutiles. Cette thèse présente deux nouveaux modèles de vérification fine de cohé¬ rence, ainsi que leur mise en oeuvre. Ces modèles permettent l'extension d'interfaces de modules compilés séparément sans qu'une recompilation des clients ne soit nécessaire, ce qui est particulièrement utile dans des systèmes avec chargement dynamique, où les clients d'une bibliothèque de modules ne sont pas forcément connus lors de la révision ou de l'extension de cette bibliothèque. L'édition d'interface sans conséquence ne se limite pas à des extensions, puisque la modification d'un article existant n'invalide pas les clients n'utilisant pas cet article. Et même s'ils l'utilisent d'une manière encore compatible après modification, une recompilation n'est pas plus indispensable. Ces techniques ont été implantées dans le Système Oberon, mais elles ne sont spécifiques ni au Langage, ni au Système Oberon, et pourraient être appliquées à n'importe quel système de programmation modulaire pour en améliorer la sécurité, la flexibilité, ou tous les deux à la fois. De plus, ces techniques ne se présentent pas au programmeur sous forme d'outils dont l'utilisation reste facultative, mais elles sont entièrement intégrées au compi¬ lateur ainsi qu'au chargeur de modules. La sécurité ne doit pas être offerte en option. Abstract As continuous évolution in hardware results in more powerfui computers, new programming techniques and concepts must be developed to master the consequently increasing software complexity. Separate compilation of modules is such a technique that has proven valuable in Modula-2 and in Oberon, among other strongly-typed programming languages. The module is both the structural unit and the compilation unit of pro- grams. Replacing a module by a new one does not affect the rest of the System, provided that the module interface has not changed. Otherwise, client modules of the modified interface hâve to be recompiled to maintain System consis¬ tency. The last opportunity to detect an inconsistency is when modules are linked to form an exécutable unit The check usually consists in comparing, for each imported interface, the expected key of that interface, as known at compilation time of the client, with the key of the effectively supplied interface. A mismatch indicates an inconsistency. This model is simple and efficient but not very flexible. Indeed, a minor modification of an interface, such as the insertion of a new procédure, can trigger many unnecessary recompilations. This thesis présents two new models for fine-grained consistency checking and their implementation. Thèse models allow the interface of separately compiled modules to be extended without requiring a recompilation of client modules. This is particularly valuable in Systems with dynamic loading, where the clients of a library are not known when the library is revised or extended. Interface editing that does not require client recompilation is not restricted to extensions, since the modification of an existing item does not invalidate clients not using this particular item. Even if they use it in a way that is upward-compatible with the modification,