Data processing and flow control
In this first exercise, you will write a simple assembler function, which will then be called from C. A framework project is provided, so you only need to implement the function body. To complete the exercise, you will need to use data processing instructions, conditional operations, and a knowledge of the Procedure Call Standard (PCS).
Like all the exercises, there is more than one valid solution. This means that your answer may not match the suggested solution that is shown in Appendix A.
Get started
First, load the provided framework project into Arm Development Studio, following these steps:
- Launch the Arm data side.
- Click the Import Project icon or go to File -> Import.
- Select General then Existing Projects into Workspace.
- Click Browse and navigate to where you downloaded the files that accompany the exercise. Select 1_gcd.
- Click Finish to import the project into Arm data side.
The imported project then appears in the Project Explorer pane, as illustrated in this screenshot:
Note: You might need to expand the project to see the files.
Within the GCD project, you should see the following files:
startup.s- This is a simple reset handler. You will not need to modify this file for this exercise.
main.c- This contains the C
main()function, and implements a simple test harness for the function that you will develop. gcd.s- This is an A64 assembler file. This file contains an empty function definition that you will complete.
This exercise does not go into detail about the structure of the project or how it is built. If you are interested in how to construct an embedded image with Arm Compiler 6, see Building your first embedded image.
Implement an assembler function
In this exercise, you implement Euclid’s algorithm for finding the greatest common denominator (GCD) of two integers. The algorithm is illustrated in the following flow chart:
PICTURE
To complete this exercise, follow these steps:
- Open the file gcd.s
- Attempt to implement the function body using A64 assembler. You might want to read the sections Arithmetic and logic operations and Program flow in the Armv8-A Instruction Set Architecture (ISA)
- Which registers will the arguments a and b be passed in?
- Given that 32-bit types are being used, what kind of general-purpose register should be used?
- Which register should the return value be in?
- How do you return from the function?
- Right-click on the project and select Build Project. Or, select Build Project from the Project menu.
- Check for any errors. If there are any, correct them and try to rebuild the project.
- Double-click on the A64 – GCD.launcher file in the project, as shown in the following screenshot:
- Click Debug to launch the simulation.
- Click the green arrow icon to run the model.
This file contains the outline for the GCD function, as you can see in the following code:
.global gcd
// uint32_t gcd(uint32_t a, uint32_t b)
.type gcd, @function
gcd:
//
//
// ADD YOUR CODE HERE
//
//
The function takes two 32-bit unsigned integers as arguments, a and b. The function returns a single 32-bit unsigned integer, which is the GCD of the two arguments.
Here are a few things for you to consider before getting started:
Run the completed image
After you have completed the function, you can test it using the Fixed Virtual Platform (FVP) models that are provided with Arm Development Studio. Follow these steps:
You will see the Console tab, which is near the bottom of the screen in a fresh installation. The Console tab shows the build messages. If the project builds successfully, the output will look like what you can see in the following screenshot:
Once you have successfully built your image, you can test it using the FVP models. This exercise uses an FVP with a single-core Cortex-A53 processor.
The Edit Configuration window opens.
The debugger will launch the model, load the image, and run to the start of main(). You should see something that looks like the following screenshot:
The icons in the Debug Control tab let you run, stop, or step the model, as shown here in this detail from the larger screenshot:
The output from the simulator will be shown in the Target Console tab. The output for a successful run looks like what you can see in the following output log:
terminal_0: Listening for serial connection on port 5000 terminal_1: Listening for serial connection on port 5001 terminal_2: Listening for serial connection on port 5002 terminal_3: Listening for serial connection on port 5003 CADI server started listening to port 7000 Info: FVP_Base_Cortex_A53x1: CADI Debug Server started for ARM Models... CADI server is reported on port 7000 GCD Workbook: The GCD of 50 and 75 is 25
Debug your image
Note: This section introduces the Arm Developer Studio controls for debugging. If you are new to the Arm Developer Studio, you can work through this section. If have used Arm Developer Studio side before, or the DS-5 Debugger, you can skip this section.
To begin, we want a fresh simulation. Follow these steps:
- Disconnect from the model using the Disconnect from Target in Debug Control pane.
- Double-click on the entry for the model connection, to reconnect to the model.
The connection is pre-configured to run the simulation to the start of main().
At the start of the program, the Debug Control tab provides controls for running and stepping:
- Run - The simulation executes until it hits a breakpoint, or until it reaches the end of the program.
- Step Source Line - moves the simulation on either one C statement or one A64 instruction. The icon in Debug Control controls whether a C statement or A64 instruction is stepped.
- Step over or Step out are useful for functions. Step-over a function call will move execution to the next instruction after the function has returned. Step-out will move execution on until the current function as returned.
The current value of registers, or for C variables, can found in the Registers and Variables pane, as you can see in this screenshot:
Accessing memory
Data processing and flow control concentrated on data processing and flow control instructions. In this exercise, we show how to access memory with load and store instructions. To do this, we implement our own simple memory copy (memcpy) routine.
Get started
Like with Data processing and flow control, a framework project is provided to get you started. Follow these steps:
- Import the 2_memcpy project into the Arm data side.
startup.s
This is a simple reset handler. You will not need to modify this file for this exercise. Unlike Data processing and flow control, this startup file includes code to configure and enable the MMU.main.c
This contains the Cmain()function, and implements a simple test harness for the function that you will develop.memcpy.s
This is an A64 assembler file. This file contains an empty function definition that you will complete.- Open
memcpy.s. src- a pointer to the source buffer, which points to first data itemdst- a pointer to the destination buffer, which points to first empty locationsize_in_bytes- the number of bytes to be copied- Implement the function, copying one byte at a time.
- What size are addresses in AArch64?
- How will you update the pointers after each iteration?
- What is the syntax for loading a sub-register sized quantity?
- Right-click on the project and select Build Project to build the project.
- Check for any errors. If there are any, correct them and try to rebuild the project.
- Launch the model using the A64 – memcpy.launch script in the project.
- Click the green arrow icon to run the model.
- Make a note of the instruction count after running your implementation.
- Modify the
my_memcpy()function to use the LDP and STP instructions with X registers for the first iterations. Use smaller accesses for the last few bytes of the data. - Re-run the test program and check the instruction count. Has it changed?
- Experiment with different sizes of data and different implementations of the copy routine. Consider using the wider floating-point registers.
The imported project then appears in the Project Explorer pane, as you can see in the following screenshot:
You should see the following files in the memcpy project:
Implement byte by byte copying
The following code shows the empty function that we are going to implement:
.global my_memcpy
// void my_memcpy(uint8_t* src, uint8_t* dst, uint32_t size_in_bytes)
.type my_memcpy, @function
my_memcpy:
//
//
// ADD YOUR CODE HERE
//
//
RET
The function takes three arguments:
For this exercise, we can assume that the pointers are to memory that is marked as Normal and that strict alignment checking is not enabled. This means that unaligned accesses are permitted. There are several possible approaches to implementing the function. We start with the simplest approach, which is a byte by byte copy. In pseudocode, we can represent this as you can see here:
while size_in_bytes greater than 0 load byte from src increment src pointer by 1 store byte to dst increment dst pointer by 1 decrement size_in_bytes by 1
Here are a few things to consider before getting started:
Run the completed image
Once you have completed the function, you can test it using the Fixed Virtual Platform (FVP) models that are provided with Arm Development Studio.
As in Data processing and flow control, the Console tab shows the build messages. If the project builds successfully, the output will look like what you can see in this screenshot:
When you have successfully built your image, test it using the FVP models. This exercise uses an FVP with a single-core Cortex-A53 processor.
The Target Console tab shows the output from the simulator. The output for a successful run looks like this code:
terminal_0: Listening for serial connection on port 5000 terminal_1: Listening for serial connection on port 5001 terminal_2: Listening for serial connection on port 5002 terminal_3: Listening for serial connection on port 5003 CADI server started listening to port 7000 Info: FVP_Base_Cortex_A53x1: CADI Debug Server started for ARM Models... CADI server is reported on port 7000 Memcpy Workbook: Finished successfully
Every time you launch the model, you will see a window open, like the one that is shown here:
This window represents the LCD and switches of the simulated platform. These exercises do not use these features, but there is something else of interest. Total Instr reports the number of instructions that the simulator has executed since it was launched.
Note: Your figure might be different to that shown in the screenshot. The total instruction count 7,453 is based on the reference solution with Arm Compiler 6.12.
Implement multi-byte copying
Copying one byte at a time is simple, but inefficient. For most copy operations, we want to transfer more than one byte at a time, so that we can reduce the number of iterations. We might also try to issue multiple loads and stores for each iteration.
The next step is to modify my_memcpy() to use load and store pair instructions with X registers. This means that 128 bits, not 8 bits, are copied per iteration. The code needs also be able to handle data which is not a multiple of 128 bits in size. Follow these steps:
You should see that the instruction count has gone down. This screenshot shows the result using the reference solution:
Remember that this is the instruction count for the entire program, not just the running of my_memcpy(). But we can see that the more complex implementation has reduced the number of instructions needed to copy the data (7,453 instead of 6,778), at least with this size of buffer. The larger the data set, the bigger the reduction. However, with very small amounts of data, the new implementation might be slower.
System control
This exercise looks at the instructions for accessing system and special registers. System and special registers control the operation of the processor, for example cache configuration. Typically, system and special registers are programmed in start-up code, before switching to a C environment.
In Data processing and flow control and Access memory a startup.s file was provided, containing a very minimal reset handler. In this exercise, you will implement this file yourself. If you have a problem, look at the startup.s that is provided for the other examples as a reference.
Get started
Like with Access memory, a framework project is provided to get you started. Follow these steps:
- Import the 3_sys_regs project into the Arm data side.
main.c
A simple “hello world” C program.startup.s
This is the startup code that we will complete in the exercise.- Open startup.s.
- Detection of which core is being run on
We will run the example on a multiprocessor model, but the example is not written to be multi-threaded and needs to just run on core 0 (affinity 0.0.0.0). The startup code needs to check the ID of the core. If the ID of the core is not 0.0.0.0 then software should put the core to sleep using the WFI instruction. - Clearing floating-point trap
The floating-point traps are Unknown at reset, but the C compiler assumes that floating-point operations are available before the C library initialization code (__main) is called. The startup code needs to ensure that the traps on accesses to the FPU are cleared. - Install the EL3 vector table
Unlike earlier versions of the Arm architecture, in AArch64 there is no default vector table location. Software must install a vector table before the first exceptions are generated. This example does not use exceptions itself, but it is good practice to install a simple vector table to capture unexpected exceptions. TCPAC -Trap lower Exception level accesses toCPTR_EL2andCPACR_EL1TAM -Trap lower Exception level accesses to AMUTTA -Trap accesses to trace registersTFP -Trap EL3 use of FP registers- Write a sequence which will set
CPTR_EL3to 0. - Implement code that reads
MPIDR_EL1and check the affinity value, putting the core to sleep if not 0.0.0.0. - What is the format of the
MPIDR_EL1register? - How will you extract and compare the full affinity value?
- What will happen if the secondary cores are unexpectedly woken from standby?
ADR Xd, <label>LDR Xd, =<label>- Complete the code to set the EL3 vector table location, using either of these instructions.
LDR Xd, <label>Returns inXdthe value at <label>LDR Xd, =<label>Returns inXdthe address of <label>- Right-click on the project and select Build Project to build the project.
- Check for any errors. If there are any, correct them and try to rebuild the project.
- Use the A64 – sys reg.launch script in the project to launch the model.
- 0.0.0.0 Cortex-A72, core 0
- 0.0.0.1 Cortex-A72, core 1
- 0.0.1.0 Cortex-A53, core 0
- 0.0.1.1 Cortex-A53, core 1
- 0.0.1.2 Cortex-A53, core 2
- 0.0.1.3 Cortex-A53, core 3
- ARM_Cortex-A72_0: 0x0000000080000000 -> affinity 0.0.0.0
- ARM_Cortex-A72_1: 0x0000000080000001 -> affinity 0.0.0.1
- Step through the first few instructions of the image that is connected to core 0, to confirm that it is correctly checking the ID.
- Disconnect and re-launch the model, this time stepping through the image on core 1 to compare the results.
The imported project then appears in the Project Explorer pane, as you can see in this screenshot:
Within the **sys_reg**
Implement the startup code
The framework code is shown here:
.global start64 .type start64, @function start64: // Check which core is running // ---------------------------- // Core 0.0.0.0 should continue to execute // All other cores should be put into sleep (WFI) // // Your code here // // Disable trapping of CPTR_EL2 accesses or use of Adv.SIMD/FPU // ------------------------------------------------------------- // // Your code here // // Install EL3 vector table // ------------------------- // // Your code here // // The effect of changes to the system registers are // only guaranteed to be visible after a context // synchronization event. See the Barriers guide ISB // Branch to scatter loading and C library init code // ------------------------------------------------- .global __main B __main
This example runs in EL3. For this exercise, we do not consider what would be necessary to switch Exception levels. There are three pieces of functionality that we need to implement:
Floating point traps
The comment in startup.s tells us that the register that controls the FPU traps is CPTR_EL3. Let’s start by looking at the register description.
The register contains several trap controls:
If you read the description of each field, you will find that a value of 0 means do not trap. Therefore, in this case we want to set the register to 0.
Detect which core the software is running on
Each core has a unique affinity number, formatted as four 8-bit fields, as you can see here:
<aff3>.<aff2>.<aff1>.<aff0>
The affinity of a core can be read from the MPIDR_EL1 register. Unlike Data processing and flow control and Access memory, this exercise uses a model that contains multiple cores. However, the software is only written to run on one core. This means that the startup code must check which core it is running on, and if it is not core 0.0.0.0, the code should put the core to sleep using a WFI.
Things to consider:
Install a vector table
The provided project includes a simple vector table at the end of startup.s. The format of the table, and how exceptions are handled more generally, is beyond the scope of these exercises. For more information, refer to Exception model.
For this exercise, we need to write the address of the vector table into the Vector Table Base Address register (VBAR_EL3). To do this, we need to know the address of the vector table. Let’s look at the vector table in the project, which is shown in the following code:
.global vector_table vector_table: // ------------------------------------------------------------ // Current EL with SP0 // ------------------------------------------------------------ .balign 128 sync_current_el_sp0: B . // Synchronous …
The label vector_table marks the start of the table. We need to write the address of this label to VBAR_EL3.
There are two pseudo instructions which allow you to get the address of a label:
ADR only works for labels that are within the same compilation unit. LDR can also be used for imported global symbols.
Note: There are two similar operations for LDR:
Run the completed image
When you have completed the function, you can test it using the Fixed Virtual Platform (FVP) models that are provided with Arm Development Studio.
Like in Access memory, the Console tab shows the build messages. If the project builds successfully, the output will look like what you can see in the following screenshot:
Note: If you look at the link command that is being issued for the image, it includes “—entry=start64”. This tells the compiler to set the entry point of the image to the label start64, which is the beginning of the startup code. The entry point is the address that the PC will be set to when the image is loaded into the simulation.
When you have successfully built your image, you can try it out. Follow these steps:
The model used for this exercise contains a dual-core Cortex-A72 processor and a quad-core Cortex-A53 processor. The affinity values for these cores are:
The debugger is configured to connect to the two Cortex-A72 cores, as you can see in the following screenshot:
The different debugger panes, like Source view and Register view, can only show information for one core at a time. The Debug Control pane selects which core’s information is currently being displayed. In the preceding screenshot, you can see that core 0, ARM_Cortex-A72_0, is selected. If core 1 is selected, the Debug Control pane looks like what you can see in this screenshot:
Using the Register pane, we can manually check the MPIR_EL1 (AArch64 -> System -> ID) value that is reported by each core:
When you are satisfied that your code is working, run the image. The output from the simulator is shown in the Target Console tab. The output for a successful run looks like this code:
terminal_0: Listening for serial connection on port 5000 terminal_1: Listening for serial connection on port 5001 terminal_2: Listening for serial connection on port 5002 terminal_3: Listening for serial connection on port 5003 CADI server started listening to port 7000 Info: FVP_Base_Cortex_A72x2_A53x4: CADI Debug Server started for ARM Models... CADI server is reported on port 7000 Hello world
The startup file for this example is basic, and a real image would perform more initialization. To explore this topic, see the Bare Metal Boot guide.