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
en:multiasm:paarm:chapter_5_3 [2025/12/11 10:14] – [CPU Configuration] eriks.klavinsen:multiasm:paarm:chapter_5_3 [2026/05/27 09:30] (current) – [CPU Configuration] ktokarz
Line 5: Line 5:
 The term ‘Rn’ refers to architectural registers, not the registers to be used in the assembler code.  The term ‘Rn’ refers to architectural registers, not the registers to be used in the assembler code. 
  
-{{ :en:multiasm:paarm:registersizes.svg |}}+<figure registersizes> 
 +{{ :en:multiasm:paarm:registersizes.png?600 |R0 and R2 general-purpose registers}} 
 +<caption>R0 and R2 general-purpose registers</caption> 
 +</figure>
  
 Note that accessing the W0 or W1 register does not allow access to the remaining 32 most significant bits. Also, when the W register is written in a 32-bit register, the top 32 bits (most significant bits of the 64-bit register) are zeroed. And there are no registers named R0 or R1, so if we need to access the 64-bit register result, we need to address it with X0 or X1 (or other register up to X30), and similarly with 32-bit registers – W0, W1 and so on are used to address general-purpose registers.  Note that accessing the W0 or W1 register does not allow access to the remaining 32 most significant bits. Also, when the W register is written in a 32-bit register, the top 32 bits (most significant bits of the 64-bit register) are zeroed. And there are no registers named R0 or R1, so if we need to access the 64-bit register result, we need to address it with X0 or X1 (or other register up to X30), and similarly with 32-bit registers – W0, W1 and so on are used to address general-purpose registers. 
 These examples perform single 32-bit arithmetic operations: These examples perform single 32-bit arithmetic operations:
  
-{{ :en:multiasm:paarm:arthmetic32bit.svg |}}+<figure arithmetic32bit> 
 +{{ :en:multiasm:paarm:arthmetic32bit.svg?450 |32-bit arithmetic operations}} 
 +<caption>32-bit arithmetic operations</caption> 
 +</figure>
  
 These examples perform single 64-bit arithmetic operations: These examples perform single 64-bit arithmetic operations:
  
-{{ :en:multiasm:paarm:arithmetic64bit.svg |}}+<figure arithmetic64bit> 
 +{{ :en:multiasm:paarm:arithmetic64bit.svg?600 |64-bit arithmetic operations}} 
 +<caption>64-bit arithmetic operations</caption> 
 +</figure>
  
 Special registers like the Stack Pointer (SP), Link Register (LR), and Program Counter (PC) are available. The Link Register (LR) is stored in the X30 register. The Stack Pointer SP and the Program Counter PC registers are no longer available as regular general-purpose registers. It is still possible to use the SP register with a limited set of data-processing instructions via the WSP register name. Unlike ARMv7, the PC register is no longer accessible via data-processing instructions. The PC register can be read by ‘ADR’ instruction, i.e. ‘ADR, X17, . ’ – the dot ‘.’ means “here” and register X17 will be written with the exact PC register value. Some branch instructions and some load/store operations implicitly use the value of the PC register. Special registers like the Stack Pointer (SP), Link Register (LR), and Program Counter (PC) are available. The Link Register (LR) is stored in the X30 register. The Stack Pointer SP and the Program Counter PC registers are no longer available as regular general-purpose registers. It is still possible to use the SP register with a limited set of data-processing instructions via the WSP register name. Unlike ARMv7, the PC register is no longer accessible via data-processing instructions. The PC register can be read by ‘ADR’ instruction, i.e. ‘ADR, X17, . ’ – the dot ‘.’ means “here” and register X17 will be written with the exact PC register value. Some branch instructions and some load/store operations implicitly use the value of the PC register.
Line 30: Line 39:
 Example adding two registers together with different register notation. Example adding two registers together with different register notation.
  
-{{ :en:multiasm:paarm:exampleregnotations.svg |}}+<figure add64_32> 
 +{{ :en:multiasm:paarm:exampleregnotations.png?600 |Result of ADD instruction using 64-bit and 32-bit registers}} 
 +<caption>Result of ADD instruction using 64-bit and 32-bit registers</caption> 
 +</figure>
  
  
Line 36: Line 48:
 ARMv8 has an additional 32 register set for floating-point and vector operations, like general-purpose registers. These registers are 128 bits wide and, like general-purpose registers, can be accessed in several ways. The letters for these registers identify byte (Bx), half-word (Hx), single-word (Sx), double-word (Dx) and quad-word (Qx) access.  ARMv8 has an additional 32 register set for floating-point and vector operations, like general-purpose registers. These registers are 128 bits wide and, like general-purpose registers, can be accessed in several ways. The letters for these registers identify byte (Bx), half-word (Hx), single-word (Sx), double-word (Dx) and quad-word (Qx) access. 
  
-{{ :en:multiasm:paarm:vectorreg1.svg |}}+<figure vectorreg> 
 +{{ :en:multiasm:paarm:vectorreg1.svg?600 |Registers for floating-point and vector operations}}
  
-{{ :en:multiasm:paarm:vectorreg2.svg |}}+{{ :en:multiasm:paarm:vectorreg2.svg?600 |Registers for floating-point and vector operations}} 
 +<caption>Registers for floating-point and vector operations</caption> 
 +</figure>
  
  
-More information on these registers and operations performed with floating-point is described in the following section, “Advanced Assembly Programming”.+More information on these registers and operations performed with floating-point is described in the following section: [[en:multiasm:paarm:chapter_5_10]].
  
 ===== CPU Configuration===== ===== CPU Configuration=====
Line 50: Line 65:
 ''<fc #800000>MSR</fc> CTR_EL0, <fc #008000>X0</fc> <fc #6495ed>@ Move X0 into CTR_EL0 – write back the modifications</fc>'' ''<fc #800000>MSR</fc> CTR_EL0, <fc #008000>X0</fc> <fc #6495ed>@ Move X0 into CTR_EL0 – write back the modifications</fc>''
  
-{{:en:multiasm:paarm:exceptionlevels_new.jpg?600|}}+<figure exceptionlevels> 
 +{{ :en:multiasm:paarm:exceptionlevels_new.jpg?600 |ARM exception levels}} 
 +<caption>ARM exception levels</caption> 
 +</figure>
  
-In the image, all of the exception levels are visualised. The Orange area is so-called the untrusted or non-secure state. The region with a blue background is the Operating System and its parts and applications. User applications can request resources using SVC (supervisor calls), or on Raspberry Pi OS (and others), this is called SysCalls. The operating system is treated as a separate program on the exception level EL1 from the EL2 perspective. If the hypervisor is available, the OS may request resources via HVC (Hypervisor calls), and the hypervisor can request resources from the secure monitor via SMC (Secure monitor calls). On Raspberry Pi 5, the bootloader runs on EL3, loading memory and initialising the hardware. Then the operating system is started at the EL1 level, and the rest of the applications in the OS are at the EL0 level. Raspberry Pi 5 does not have hypervisor software, which is why Exception Level 2 is not used.+In Fig. {{ref>exceptionlevels}}, all of the exception levels are visualised. The Orange area is so-called the untrusted or non-secure state. The region with a blue background is the Operating System and its parts and applications. User applications can request resources using SVC (supervisor calls), or on Raspberry Pi OS (and others), this is called SysCalls. The operating system is treated as a separate program on the exception level EL1 from the EL2 perspective. If the hypervisor is available, the OS may request resources via HVC (Hypervisor calls), and the hypervisor can request resources from the secure monitor via SMC (Secure monitor calls). On Raspberry Pi 5, the bootloader runs on EL3, loading memory and initialising the hardware. Then the operating system is started at the EL1 level, and the rest of the applications in the OS are at the EL0 level. Raspberry Pi 5 does not have hypervisor software, which is why Exception Level 2 is not used.
 The Green region is a Secure State where only special secure applications and operating systems are executed. This may be used in system duplication, where two identical systems must run, with the second used for integrity checks, fault and error detection in the central system that runs in a non-secure state. Note that both secure and non-secure states are isolated, and the resources can be shared only through the EL3 level. The Green region is a Secure State where only special secure applications and operating systems are executed. This may be used in system duplication, where two identical systems must run, with the second used for integrity checks, fault and error detection in the central system that runs in a non-secure state. Note that both secure and non-secure states are isolated, and the resources can be shared only through the EL3 level.
  
Line 90: Line 108:
  
 You can see how many states this processor has. Not all of them are used during program execution. Many registers are related to debugging and resource management. On the Raspberry Pi, the OS and bootloader have already configured all CPU Cores and the registers. Trace registers are used only when hardware debugging is enabled, such as JTAG or TRACE32. You can see how many states this processor has. Not all of them are used during program execution. Many registers are related to debugging and resource management. On the Raspberry Pi, the OS and bootloader have already configured all CPU Cores and the registers. Trace registers are used only when hardware debugging is enabled, such as JTAG or TRACE32.
-Summarising: in Cortex-A76, ARMV8.2-A, installed on Raspberry Pi 5, on EL1, the system OS (kernel) is running. Since the OS is booted from the SD card, there is no Hypervisor software, which means EL2 is not used, and the Linux OS is the only one running on the Raspberry Pi 5 board. All users’ software runs in EL0. However, any code executed by the OS kernel runs at EL1, and it can be designed and executed as a kernel module.+Summarising: in Cortex-A76, ARMV8.2-A, installed on Raspberry Pi 5, on EL1, the system OS (kernel) is running. Since the OS is booted from the SD card, there is no Hypervisor software, which means EL2 is not used, and the Linux kernel is the only one running on the Raspberry Pi 5 board. All users’ software runs in EL0. However, any code executed by the OS kernel runs at EL1, and it can be designed and executed as a kernel module.
  
-There are rules for creating a Linux OS kernel module – it must contain functions that initialise the module and exit when the job is finished. The skeleton for the kernel module is given below in C. It will require a GCC compiler to compile the code, but inline assembly can be written directly in the code itself. After changing the Exception level from EL0 to EL1, only some system instruction executions will be allowed.+There are rules for creating a Linux kernel module – it must contain functions that initialise the module and exit when the job is finished. The skeleton for the kernel module is given below in C. It will require a GCC compiler to compile the code, but inline assembly can be written directly in the code itself. After changing the Exception level from EL0 to EL1, only some system instruction executions will be allowed.
  
 <codeblock code_label> <codeblock code_label>
en/multiasm/paarm/chapter_5_3.1765440867.txt.gz · Last modified: by eriks.klavins
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0