This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: The Cool Runtime System 1 Introduction The runtime system consists of a set of hand-coded assembly language functions that are used as sub- routines by Cool programs. Under spim the runtime system is in the file trap.handler . The use of the runtime system is a concern only for code generation, which must adhere to the interface provided by the runtime system. The runtime system contains four classes of routines: 1. startup code, which invokes the main method of the main program; 2. the code for methods of predefined classes ( Object , IO , String ); 3. a few special procedures needed by Cool programs to test objects for equality and handle runtime errors; 4. the garbage collector. The Cool runtime system is in the file /usr/class/cs143/lib/trap.handler ; it is loaded automatically whenever spim / xspim is invoked. Comments in the file explain how the pre-defined functions are called. The following sections describe what the Cool runtime system assumes about the generated code and what the runtime system provides to the generated code. However, additional restrictions must be placed on the generated code for use with Coolaid , a debugging tool for Cool compilers based on program verification (see the Coolaid Reference Manual). Coolaid specific restrictions are marked in this manner. This document does not describe the expected behavior of Cool programs; refer to Section 13 of the Cool Reference Manual for a formal description of the execution semantics of Cool programs. 2 Objects The object layout describes the location of attributes, as well as the meta-data that must be associated with each object. Modified from Section 7 of A Tour of the Cool Support Code ( c circlecopyrt 1995-1996 by Alex Aiken). Last modified on Wed Nov 10 04:34:45 PST 2004. 1 offset -4 Garbage Collector Tag offset 0 Class tag offset 4 Object size (in 32-bit words) offset 8 Dispatch pointer offset 12 ... Attributes Figure 1: Object layout. 2.1 Object Layout The first three 32-bit words of each object are assumed to contain a class tag, the object size, and a pointer for dispatch information. In addition, the garbage collector requires that the word immediately before an object contain -1; this word is not part of the object. Figure 1 shows the layout of a Cool object; the offsets are given in numbers of bytes. The garbage collection tag is -1. The class tag is a 32-bit integer identifying the class of the object and thus should be unique for each class. The runtime system uses the class tag in equality comparisons between objects of the basic classes and in the abort functions to index a table containing the name of each class. The object size field and garbage collector tag are maintained by the runtime system; only the runtime system should create new objects. However, prototype objects (see below) must be coded directly by the code generator in the static data area, so the code generator should initialize the object size field and garbage collector tag of prototypes properly. Any statically generated objects must also initialize thesegarbage collector tag of prototypes properly....
View Full Document
This note was uploaded on 01/12/2010 for the course MATH 42 at Stanford.