This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
dev:crosscompiler:backend_arm:code_generator [2019/07/27 16:32] – [Code Generator for ARM] ursgraf | dev:crosscompiler:backend_arm:code_generator [2019/11/17 18:17] – [Exception Stackframe] ursgraf | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Code Generator for ARM ====== | ====== Code Generator for ARM ====== | ||
- | Everything which is not fully implemented is listed below | ||
- | ^topic^remarks^ | ||
- | |throw| do together with exceptions | | ||
- | |new| tests for three dimensional arrays fail| | ||
- | |exceptions| | | ||
- | |US.HALT|what to do here?| | ||
- | |||
All results of all SSA instructions have an assigned register. Now, each SSA instruction can be translated into one or a sequence of machine instructions. In order to do this, we must define the stackframe, which is used when calling a method. | All results of all SSA instructions have an assigned register. Now, each SSA instruction can be translated into one or a sequence of machine instructions. In order to do this, we must define the stackframe, which is used when calling a method. | ||
Line 14: | Line 7: | ||
Explanation: | Explanation: | ||
- | LR is saved onto the stack together with the necessary nonvolatile GPRs. Even if method is a leaf method LR must be saved onto the stack because LR serves as a scratch register within a method. Considering the GPR's and EXTRs, all nonvolatile register, which are used within this method, must be saved on the stack. Nonvolatiles in EXTR registers occupy either 8 bytes (EXTRD) or a bytes (EXTRS). \\ | + | LR is saved onto the stack together with the necessary nonvolatile GPRs. Even if a method is a leaf method LR must be saved onto the stack because LR serves as a scratch register within a method. Considering the GPR's and EXTRs, all nonvolatile register, which are used within this method, must be saved on the stack. Nonvolatiles in EXTR registers occupy either 8 bytes (EXTRD) or 4 bytes (EXTRS). \\ |
Important: volatile EXTR's must be saved as well if '' | Important: volatile EXTR's must be saved as well if '' | ||
- | 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 (see below). | + | 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. |
- | The field // | + | When calling interface methods some temporary space on the stack might be necessary (see below). |
+ | The field // | ||
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. | ||
\\ | \\ | ||
===== Exception Stackframe ===== | ===== Exception Stackframe ===== | ||
- | In case of an exception | + | In case of an exception |
- | FPR's need no saving, as they are normally | + | 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 '' |
- | [{{ .:exceptionstackframe.png?250&direct | //Stack frame for exception method//}}] | + | [{{ :dev: |
- | Optimization: | + | Optimization: |
===== Method Call ===== | ===== Method Call ===== |