deep

a Cross Development Platform for Java

User Tools

Site Tools

You are here: start » dev » crosscompiler » backend_arm » code_generator
dev:crosscompiler:backend_arm:code_generator

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
Next revisionBoth sides next revision
dev:crosscompiler:backend_arm:code_generator [2019/05/18 10:26] – [Code Generator for ARM] ursgrafdev:crosscompiler:backend_arm:code_generator [2019/07/11 19:46] – [Stackframe] ursgraf
Line 2: Line 2:
 Everything which is not fully implemented is listed below Everything which is not fully implemented is listed below
 ^topic^I^L^F^remarks^ ^topic^I^L^F^remarks^
-|convFloat|y|n|y| | 
-|convDouble|y|n|y| | 
 |instanceof| ||| | |instanceof| ||| |
 |checkcast| ||| | |checkcast| ||| |
Line 21: Line 19:
 Important: volatile EXTR's must be saved as well if ''US.ENABLE_FLOATS()'' is called in this method (see [[.:exceptions|Exceptions]]). Important: volatile EXTR's must be saved as well if ''US.ENABLE_FLOATS()'' is called in this method (see [[.:exceptions|Exceptions]]).
  
-The field //local variables// is only used if the number of registers does not suffice and locals must be assigned a slot on the stack. When dealing with FPR's some temporary space on the stack might be necessary. Some compiler specific subroutines dealing with //long// operations need some temporary space (//temp. memory//) on the stack for saving and restoring some registers which are used therein.  \\ +The field //local variables// is only used if the number of registers does not suffice and locals must be assigned a slot on the stack. When calling interface methods some temporary space on the stack might be necessary.  
 The field //parameter// serves to hold parameters for method calls, which can not be placed directly into registers. The size of the field //parameters// is determined by considering all the calls to other methods within this method and taking the maximum size of their parameters. //parameters// must be at the top of the stack! This garantees that in all called methods these parameters can be accessed with the same offset. \\  The field //parameter// serves to hold parameters for method calls, which can not be placed directly into registers. The size of the field //parameters// is determined by considering all the calls to other methods within this method and taking the maximum size of their parameters. //parameters// must be at the top of the stack! This garantees that in all called methods these parameters can be accessed with the same offset. \\ 
 The stack pointer always points to the top of the actual frame. At the top the stack pointer of the caller has to be stored. The back chain pointer is used for the debugger, for exceptions and for the garbage collection. The stack pointer always points to the top of the actual frame. At the top the stack pointer of the caller has to be stored. The back chain pointer is used for the debugger, for exceptions and for the garbage collection.
Line 55: Line 53:
  
 ===== Compiler Specific Subroutines ===== ===== Compiler Specific Subroutines =====
-Subroutines are methods for which there is no Java code (and hence no Bytecode or SSA) but only machine code. This is useful for the delegation of interface methods (see [[.:..:interfaces|Interfaces]]) or for dividing longs. \\+Subroutines are methods for which there is no Java code (and hence no Bytecode or SSA) but only machine code. This is useful for the delegation of interface methods (see [[.:..:interfaces|Interfaces]]) or for exception handling. \\
 Such methods are listed in //Method.compSpecSubroutines// and the code generator issues code (if subroutines are used). These subroutines must be linked as well. Such methods are listed in //Method.compSpecSubroutines// and the code generator issues code (if subroutines are used). These subroutines must be linked as well.
-Currently, there are three types of compiler specific methods +Currently, there are two types of compiler specific methods
-  * Arithmetic and conversion: call to this methods inserted by the code generator+
   * Delegation of interface methods: address of this method inserted into the type descriptor by the linker   * Delegation of interface methods: address of this method inserted into the type descriptor by the linker
   * Exception handling: call to this methods inserted by the code generator   * Exception handling: call to this methods inserted by the code generator
 +
 +==== Practical Implementation of Searching the Correct Interface Method ====
 +imDelegIiMm needs 3 auxiliary registers. At compile time we cannot reserve such auxiliary registers as these registers must always be the same. Therefore, we use a special chunk of memory on the stack. This storage is only necessary and allocated for methods invoking interface methods. At the start of the delegate method three volatile registers which might contain parameters are saved onto the stack and reloaded at the end of the delegate method.
dev/crosscompiler/backend_arm/code_generator.txt · Last modified: 2022/12/20 11:34 by ursgraf

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki