deep

a Cross Development Platform for Java

User Tools

Site Tools


dev:crosscompiler:backend_ppc:linker32

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
dev:crosscompiler:backend_ppc:linker32 [2015/04/18 07:57] – external edit 127.0.0.1dev:crosscompiler:backend_ppc:linker32 [2022/12/20 11:33] (current) ursgraf
Line 5: Line 5:
   * Create system table   * Create system table
   * Create target image   * Create target image
 +When creating the target image or calculating a crc the endianess of the target platform has to be taken into account.
  
 ===== Initialization ===== ===== Initialization =====
Line 13: Line 14:
  
 ===== Create Constant Block ===== ===== Create Constant Block =====
-Each class has a constant block. Certain interfaces need a reduced constant block and arrays just need a type descriptor, see [[.:type_descriptor|Type Descriptor]]. The constant block holds information about the class, which is constant:+Each class has a constant block. Certain interfaces need a reduced constant block and arrays just need a type descriptor, see [[dev:crosscompiler:type_descriptor|Type Descriptor]]. The constant block holds information about the class, which is constant:
   * Header (base, size, ...)   * Header (base, size, ...)
   * Global pointer list   * Global pointer list
Line 20: Line 21:
   * Constant pool    * Constant pool 
   * Checksum   * Checksum
-[{{ .:constblock.png?450&direct | Structure of the constant pool for a class }}]\\+[{{ dev:crosscompiler:constblock.png?450&direct | Structure of the constant pool for a class }}]\\
 The //const pool// contains values of type //float// and //double// which are not placed directly into the code. After all elements are added the //constBlockSize// can be determined and the indices (''Item.index'') of all elements will be fixed. It's important to note that all elements, which are addresses (''AddressItem'', ''ConstantBlockItem'', ...), simply contain a reference to the according item. Only later, after address fixing, can the real addresses be inserted!\\ The //const pool// contains values of type //float// and //double// which are not placed directly into the code. After all elements are added the //constBlockSize// can be determined and the indices (''Item.index'') of all elements will be fixed. It's important to note that all elements, which are addresses (''AddressItem'', ''ConstantBlockItem'', ...), simply contain a reference to the according item. Only later, after address fixing, can the real addresses be inserted!\\
-When the system ist starting up, the [[..:rts:start|Runtime System]] reads the start addresses of the constant block for all classes from the //System Table// (see below). With the predefined offset //cblkClinitAddrOffset// the address of the class constructor can be fetched in order to load a class. With another offset the heap manager can read the global references of this class. This information is used by the garbage collection. //codeBase// holds the start address of code of a class whereas //codeSize// is the size of the code. Methods, which are defined in the configuration as system methods and which are assigned a fixed offset are excluded from //codeSize// (Exception Handlers).+When the system ist starting up, the [[dev:rts:start|Runtime System]] reads the start addresses of the constant block for all classes from the //System Table// (see below). With the predefined offset //cblkClinitAddrOffset// the address of the class constructor can be fetched in order to load a class. With another offset the heap manager can read the global references of this class. This information is used by the garbage collection. //codeBase// holds the start address of code of a class whereas //codeSize// is the size of the code. Methods, which are defined in the configuration as system methods and which are assigned a fixed offset are excluded from //codeSize// (Exception Handlers).
  
-In the compiler the constant block is modeled as linked list of ''ch.ntb.inf.deep.linker.ConstBlkEntry''. Depending on the type of entry one of the following classes is used.+In the compiler the constant block is modeled as linked list of ''org.deepjava.linker.ConstBlkEntry''. Depending on the type of entry one of the following classes is used.
   * **''AddressEntry''**: For entries representing an address.   * **''AddressEntry''**: For entries representing an address.
   * **''ConstantEntry''**: For entries representing a constant (StdConstant).   * **''ConstantEntry''**: For entries representing a constant (StdConstant).
Line 33: Line 34:
  
 ==== Type Descriptor ==== ==== Type Descriptor ====
-The structure and purpose of the [[Type Descriptor]] is described separately.+The structure and purpose of the [[dev:crosscompiler:type_descriptor|Type Descriptor]] is described separately.
  
 ==== String pool ==== ==== String pool ====
-The string pool holds the constant strings of a class. They are stored as follows (also see [[strings|Strings]]:+The string pool holds the constant strings of a class. They are stored as follows (also see [[dev:crosscompiler:strings|Strings]]:
   [ tag                ]   [ tag                ]
   [ stringClassAddress ]   [ stringClassAddress ]
Line 52: Line 53:
   [401921FB] 6.283185307179586 (double)   [401921FB] 6.283185307179586 (double)
   [54442D18]   [54442D18]
- 
  
 ===== Calculate Size and Offsets ===== ===== Calculate Size and Offsets =====
-[{{  .:linker_code_methods.png?350px&direct|Machine Code: Size and Offsets}}]+[{{  dev:crosscompiler:linker_code_methods.png?350px&direct|Machine Code: Size and Offsets}}]
 Before the memory map can be fixed, a couple sizes and offsets must be calculated for each class: Before the memory map can be fixed, a couple sizes and offsets must be calculated for each class:
   * ''void calculateCodeSizeAndOffsets(Class)'': This methods determines the size of the machine code of the whole class and sets the field //offset// of each method of this class. //offset// is the byte offset of the machine code of a method in the memory starting from the start address of the code of this class. If a method offset is given by the configuration (e.g. exception handlers), then this method is not included in the culculation of the code size. The offset given by the configuration is not relative to the base of a class but to the base of the appropriate segment.   * ''void calculateCodeSizeAndOffsets(Class)'': This methods determines the size of the machine code of the whole class and sets the field //offset// of each method of this class. //offset// is the byte offset of the machine code of a method in the memory starting from the start address of the code of this class. If a method offset is given by the configuration (e.g. exception handlers), then this method is not included in the culculation of the code size. The offset given by the configuration is not relative to the base of a class but to the base of the appropriate segment.
Line 61: Line 61:
  
 ===== Create System Table ===== ===== Create System Table =====
-The linker assembles a system table for the whole system. This table must be loaded to a prefixed address in the target system and holds information for the [[..:rts:start|Runtime System]]. Various settings must be handled:+The linker assembles a system table for the whole system. This table must be loaded to a prefixed address in the target system and holds information for the [[dev:rts:start|Runtime System]]. Various settings must be handled:
   - The system runs from the flash   - The system runs from the flash
   - The system runs from the RAM.   - The system runs from the RAM.
Line 69: Line 69:
  
 The structure of the system table is: The structure of the system table is:
-[{{ .:systemtable.png?450&direct |//Structure of the system table// }}]+[{{ dev:crosscompiler:systemtable.png?450&direct |//Structure of the system table// }}]
  
 First, the class constructor of the class kernel must be found. For this, the class name of the kernel is fetched from the configuration and the method //<clinit>// is searched. Then, the table can be built. The offset to the addresses with the constant blocks is placed at the beginning. Heap and stack information is added. For each class the address of the constant block must be entered. The table ends with the value 0. First, the class constructor of the class kernel must be found. For this, the class name of the kernel is fetched from the configuration and the method //<clinit>// is searched. Then, the table can be built. The offset to the addresses with the constant blocks is placed at the beginning. Heap and stack information is added. For each class the address of the constant block must be entered. The table ends with the value 0.
  
-The references to the constant blocks are assembled as follows. First come the classes with class constructors. These classes are already sorted in correct order as described in [[class_initialization|Initialization]]. Classes without initialization follow afterwards. Arrays and interfaces have no constant block and are not listed. The exception to this rule are interfaces with class constructor, see [[.:interfaces|Interfaces]].+The references to the constant blocks are assembled as follows. First come the classes with class constructors. These classes are already sorted in correct order as described in [[dev:crosscompiler:class_initialization|Initialization]]. Classes without initialization follow afterwards. Arrays and interfaces have no constant block and are not listed. The exception to this rule are interfaces with class constructor, see [[dev:crosscompiler:interfaces|Interfaces]].
  
 ===== Fix Memory Map ===== ===== Fix Memory Map =====
-[{{  .:linker_code.png?350px&direct|Fixing the memory map}}]+[{{  dev:crosscompiler:linker_code.png?350px&direct|Fixing the memory map}}]
 In this step the code is placed in the memory, as well as the class variables and the constants. First, each class is assigned a memory segment for the code (''Class.codeSegment''), class variables (''Class.varSegment'') and constants (''Class.constSegment''). Which segments to use can be read from the configuration. The linker traverses the possible segments and choses a suitable one. While doing this, the used space of each segment is stored (''Segment.usedSize'') and the appropriate offsets are set (''Class.codeOffset'', ''Class.varOffset'' and ''Class.constOffset''). Arrays and interfaces must be handled as well. Further, the size of the segment for the system table has to be set and also the size of the segment for the global constant table.  In this step the code is placed in the memory, as well as the class variables and the constants. First, each class is assigned a memory segment for the code (''Class.codeSegment''), class variables (''Class.varSegment'') and constants (''Class.constSegment''). Which segments to use can be read from the configuration. The linker traverses the possible segments and choses a suitable one. While doing this, the used space of each segment is stored (''Segment.usedSize'') and the appropriate offsets are set (''Class.codeOffset'', ''Class.varOffset'' and ''Class.constOffset''). Arrays and interfaces must be handled as well. Further, the size of the segment for the system table has to be set and also the size of the segment for the global constant table. 
 Now, the base address of each used segment can be determined. \\ Now, the base address of each used segment can be determined. \\
dev/crosscompiler/backend_ppc/linker32.1429336672.txt.gz · Last modified: 2016/02/25 13:33 (external edit)