deep

a Cross Development Platform for Java

User Tools

Site Tools

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

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:exceptions [2019/08/23 16:59] – [Java Exceptions] ursgrafdev:crosscompiler:backend_arm:exceptions [2019/11/17 18:24] (current) – [Floats in Exceptions] ursgraf
Line 10: Line 10:
 ===== ARM Exceptions ===== ===== ARM Exceptions =====
 Each ARM exception is caused by a synchronous or asynchronous event and generally causes the processor to switch its state and jump to its proper exception vector.  Each ARM exception is caused by a synchronous or asynchronous event and generally causes the processor to switch its state and jump to its proper exception vector. 
-[{{ .:ppcexception.png?550&direct |//PPC Exceptions and Interrupts// }}]+[{{ .:armexception.png?550&direct |//ARM Exceptions and Interrupts// }}]
 Exception classes and their corresponding exception methods have to be specified in the configuration. Instances of these classes are never created and therefore the object constructors are defined as //synthetic// and will not be translated into code.\\ Exception classes and their corresponding exception methods have to be specified in the configuration. Instances of these classes are never created and therefore the object constructors are defined as //synthetic// and will not be translated into code.\\
 The code generator has to create a special exception stack frame.\\ The code generator has to create a special exception stack frame.\\
Line 17: Line 17:
  
 ===== Floats in Exceptions ===== ===== Floats in Exceptions =====
 +In order to save processing time, floating point registers are not saved when entering exception handling. If an exception method calls a another method which uses EXTRs, however, all volatile EXTR's will be saved by a call to //US.ENABLE_FLOATS()//. Nonvolatile EXTR's, which are used in a method, will be saved on the stack by the prolog of a method in any case. //US.ENABLE_FLOATS()// has to be called in a exception method or in a method which is called by an exception method.\\
 +**Important:** A decrementer exception calls an action method. The decrementer class could be extended and its action method could be overridden. If this method of the subclass uses floats, you have to insert //US.ENABLE_FLOATS()// as well. 
 +**Important:** If an exception method or a method called by an exception method uses a method from //java/lang/Math//, you have to make sure that //US.FLOAT_ENABLE()// is called.
  
  
Line 46: Line 49:
  
 The figure below gives an example for the handling of exceptions. The figure below gives an example for the handling of exceptions.
-[{{ .:..:backend_ppc:exceptionoverview.png?700 | //Example for handling of exceptions//}}] +[{{ .:exceptionoverviewarm.png?700 | //Example for handling of exceptions//}}] 
dev/crosscompiler/backend_arm/exceptions.1566572367.txt.gz · Last modified: 2019/08/23 16:59 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