deep

a Cross Development Platform for Java

User Tools

Site Tools


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
dev:crosscompiler:backend_arm:code_generator [2019/11/17 18:21] – [Fixup] ursgrafdev:crosscompiler:backend_arm:code_generator [2022/12/20 11:34] (current) – [Accessing the Hardware] ursgraf
Line 16: Line 16:
 \\ \\
 ===== Exception Stackframe ===== ===== Exception Stackframe =====
-In case of an exception all volatile GPRs together with LR must be saved. Further, the nonvolatile GPRs which are used in this method must be saved as well. \\  +In case of an exception all volatile GPRs together with LR must be saved. The scratch register R6 must be saved firstbecause it is used to save the original stack pointer before any other registers can be pushed. The nonvolatile GPRs which are used in this method must be saved as well. \\  
-EXTR's need no saving, as they are not allowed to be used in exceptions. If an exception method calls a method where EXTR are used (e.g. in an interrupt handler or in a decrementer subclass) you have to use ''US.ENABLE_FLOATS()'' to store the them.+EXTR's need no saving, as they are not allowed to be used in exceptions. If an exception method calls a method where EXTR are used (e.g. in an interrupt handler or in a timer subclass) you have to use ''US.ENABLE_FLOATS()'' to store them.
  
 [{{ :dev:crosscompiler:backend_arm:exceptionstackframearm.png?350&direct | //Stack frame for exception method//}}] [{{ :dev:crosscompiler:backend_arm:exceptionstackframearm.png?350&direct | //Stack frame for exception method//}}]
 +
 +For efficiency, the exception stack frame does not contain space for locals. Hence, you are not allowed to use so many locals that this becomes necessary. This will be checked for when compiling exception methods. Storage for interface methods as well as the area for parameter passing are not necessary as well.
 +
  
 Optimization: The ARM architecture has lots of EXTR's. One could use half of them in normal methods and the other half in exception methods. For such a case all normal methods which could be called from within exception methods must be translated a second time with the second set. The compiler would have to find out how to handle each method. Optimization: The ARM architecture has lots of EXTR's. One could use half of them in normal methods and the other half in exception methods. For such a case all normal methods which could be called from within exception methods must be translated a second time with the second set. The compiler would have to find out how to handle each method.
Line 39: Line 42:
  
 ===== Accessing the Hardware ===== ===== Accessing the Hardware =====
-Java does not allow direct access and manipulation of absolute memory locations. Nevertheless this is essential for embedded programming. We therefore include this possibility by using a special class //ch.ntb.inf.deep.unsafe.arm.US.java// (US stand for unsafe). Wenn methods of this class are used the code generator has to insert machine code directly. The register allocator does not have to allocate registers for this instructions. //US.java// therefore serves as simple stubs. +Java does not allow direct access and manipulation of absolute memory locations. Nevertheless this is essential for embedded programming. We therefore include this possibility by using a special class //org.deepjava.unsafe.arm.US.java// (US stand for unsafe). When methods of this class are used the code generator has to insert machine code directly. The register allocator does not have to allocate registers for this instructions. //US.java// therefore serves as simple stubs. 
  
 ===== Low Level Classes ===== ===== Low Level Classes =====
dev/crosscompiler/backend_arm/code_generator.1574011264.txt.gz · Last modified: 2019/11/17 18:21 by ursgraf