deep

a Cross Development Platform for Java

User Tools

Site Tools


dev:crosscompiler:interfaces

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dev:crosscompiler:interfaces [2015/03/29 09:36] – [Methods] ursgrafdev:crosscompiler:interfaces [2019/07/11 19:34] (current) – [Methods] ursgraf
Line 1: Line 1:
 ====== Interfaces ====== ====== Interfaces ======
-Interfaces generally don't have to be translated. All fields are constant and the methods are abstract. Interfaces don't need a type descriptor with a single exception as mentioned in [[.:type_descriptor|Type Descriptors]]. They also don't need a constant block and don't have to be included in the system table compared to regular classes (see [[.:linker32|Linker32]]). However, here again, there is an exception to this rule. And special care has to be given to interface methods.+Interfaces generally don't have to be translated. All fields are constant and the methods are abstract. Interfaces don't need a type descriptor with a single exception as mentioned in [[.:type_descriptor|Type Descriptors]]. They also don't need a constant block and don't have to be included in the system table compared to regular classes (see [[dev:crosscompiler:backend_ppc:linker32|Linker32]]). However, here again, there is an exception to this rule. And special care has to be given to interface methods.
  
 ===== Class Constructors ===== ===== Class Constructors =====
Line 17: Line 17:
 </code> </code>
  
-Such an interface must be inserted into the list //initClasses// (see [[.:cfr|Class File Reader]]) and must be added to the systemtable so that its class constructor can be called when classes are loaded (see [[.:linker32|Linker32]]).\\+Such an interface must be inserted into the list //initClasses// (see [[.:cfr|Class File Reader]]) and must be added to the systemtable so that its class constructor can be called when classes are loaded (see [[dev:crosscompiler:backend_ppc:linker32|Linker32]]).\\
  
 ===== Methods ===== ===== Methods =====
Line 72: Line 72:
  
 === Case 2 === === Case 2 ===
-class implements one interface with several methods or several interfaces -> in the type descriptor we place the address of a //delegate// method at the index //interfaceDelegateMethod//. This method is a [[.:backend_ppc:code_generator#compiler_specific_subroutines|Compiler Specific Subroutine]]. The //delegate// method fetches the proper interface from the interface table (adjacent to the delegate method in the type descriptor). Each interface has an entry with 32 bit. The first 16 bit are reserved for the //id//, whereas the next 16 bit caontain an offset into the method table. The offset is taken from the field //size//. With this offset the address of the desired method can finally be found.\\ +If a class implements one interface with several methods or several interfaces -> in the type descriptor we place the address of a //delegate// method at the index //interfaceDelegateMethod//. This method is a [[.:backend_ppc:code_generator#compiler_specific_subroutines|Compiler Specific Subroutine]]. Before calling the //delegate// method, the compiler puts the information about the specific interface the method belongs to together with the method index into a scratch register. For this purpose all interfaces are given a unique id. To give an example. The scratch register contains 0x00020003 -> the interface has id=2 and the method no. 3 within this interface is called. 
-Important: For jumping into the interface method the LR cannot be used anymore, because the LR contains the address of the caller and the LR was not saved so far. This happens only at the start of the interface method. +The //delegate// method fetches the proper interface from the interface table (adjacent to the delegate method in the type descriptor). Each interface has an entry with 32 bit. The first 16 bit are reserved for the //id//, whereas the next 16 bit contain the offset into the method table. The offset is taken from the field //size//. With the first 16 bit given in the scratch register, the correct interface is searched. With the second half of the register you get the offset to the method table for this specific interface. Together with the method index from the scratch register the desired method can finally be found.\\ 
- +Important: For jumping into the interface method the LR cannot be used anymore, because the LR contains the address of the caller and the LR was not saved so far. This happens only at the start of the interface method. For practical implementation see notes in the code generator for the desired architecture[[dev:crosscompiler:backend:start|Backend]].
-==== Practical Implementation ==== +
-Case 2 needs 3 auxiliary registers. At compile time we cannot reserve such auxiliary registers as these registers must always be the same. Therefore, we use parameter registers. They are volatile and can be freely used though this means, that interface methods can pass less parameters, which is generally true. If not true the compiler will report.\\ +
-R0 holds the necessary information for the delegate method. The first two bytes are the ID of the sought-after interfacetho last to bytes contain the method offset. Loading of R0 should happen after parameter copying as R0 is used then+
  
 ==== Special Case ==== ==== Special Case ====
-What happens if two independent interfaces each give a method with identical signature and class A implements both? A will have the address of method once in its method table and will have the method in listed in both interface blocks.+What happens if two independent interfaces each give a method with identical signature and class A implements both? A will have the address of the method once in its method table and will have the method listed in both interface blocks.
  
  
dev/crosscompiler/interfaces.1427614588.txt.gz · Last modified: 2016/02/25 13:33 (external edit)