ARM Assembler Workbook



ARM

Assembler

Workbook

[pic]

ARM University Program

Version 1.0

January 14th, 1997

Introduction

Aim

This workbook provides the student with a basic, practical understanding of how to write ARM assembly language modules.

Pre-requisites

The student should be familiar with the following material:

1. The ARM Instruction Set

2. Either:

a) The ARM Windows Toolkit Workbook, or

b) The ARM Command Line Toolkit Workbook

Building the example code

The example routines used in this practical can be built and executed either using the command line or using the Windows toolkit.

For the command line:

To build a file using the ARM assembler, issue the command:

armasm -g code.s

The object code can then be linked to produce an executable:

armlink code.o -o code

This can then be loaded into armsd and executed:

armsd code

Note: The assemblers’ -g option adds debugging information so that the assembly labels are visible within the debugger.

Some exercises require you to compile a piece of C code. To do this use the ARM C compiler:

armcc -g -c arm.c

In such exercises, you will also need to link your code with the appropriate C library. The C libraries can be found in the lib subdirectory of the toolkit installation. Thus if the toolkit is installed in c:\arm200, you would link using with the appropriate library as follows:

armlink arm.o code.o c:\arm200\lib\armlib.32l -o arm

For the Windows toolkit:

An appropriate ARM Project Manager file (.APJ) is supplied to build the first exercise in each session. This can be copied and altered as for the subsequent exercises in that particular session.

After building the project, simply click on the Debug icon on the APM toolbar to load the resultant executable into the ARM Debugger for Windows.

Session 1 : Structure of an ARM Assembler Module

The following is a simple example which illustrates some of the core constituents of an ARM assembler module. This file can be found as c:\work\asm\session1\armex.s

AREA ARMex, CODE, READONLY ; name this block of code

ENTRY ; mark first instruction

; to execute

start

MOV r0, #10 ; Set up parameters

MOV r1, #3

ADD r0, r0, r1 ; r0 = r0 + r1

stop SWI 0x11 ; Terminate

END ; Mark end of file

Description of the module

1) The AREA directive

Areas are chunks of data or code that are manipulated by the linker. A complete application will consist of one or more areas. This example consists of a single area which contains code and is marked as being read-only. A single CODE area is the minimum required to produce an application.

2) The ENTRY directive

The first instruction to be executed within an application is marked by the ENTRY directive. An application can contain only a single entry point and so in a multi-source-module application, only a single module will contain an ENTRY directive. Note that when an application contains C code, the entry point will often be contained within the C library.

3) General layout

The general form of lines in an assembler module is:

;

The important thing to note is that the three sections are separated by at least one whitespace character (such as a space or a tab). Actual instructions never start in the first column, since they must be preceded by whitespace, even if there is no label. All three sections are optional and the assembler will also accept blank lines to improve the clarity of the code.

4) Code description

The application code starts executing at routine of the label start by loading the decimal values 10 and 3 into registers 0 and 1. These registers are then added together and the result placed back into r0. The application then terminates using the software interrupt 0x11, at label stop, which causes control to return back to the debugger.

5) The END directive

This directive causes the assembler to stop processing this source file. Every assembly language source module must therefore finish with this directive.

Exercise 1.1 - Running the example

Build the example file armex.s and load it into your debugger as described in the introduction.

Set a breakpoint on start and begin execution of the program. When the breakpoint is hit, select Execute -> Step In or choose Stem Into from the menu bar. Now single step through the code by choosing Execute->Step or Step from the menu bar, displaying the registers after each step. You should be able to see their contents being updated after each step. Continue until the program terminates normally.

Exercise 1.2 - Extending the example

Modify the example so that it produces the sum (+), the difference (-) and the product (x) of the two values originally stored in r0 and r1. Build your modified program and check that it executes correctly using the debugger.

Session 2 : Loading values into registers

The following is a simple ARM code example that tries to load a set of values into registers. This file can be found as c:\work\asm\session2\value.s

AREA Value, CODE, READONLY ; name this block of code

ENTRY ; mark first instruction

; to execute

start

MOV r0, #0x1 ; = 1

MOV r1, #0xFFFFFFFF ; = -1 (signed)

MOV r2, #0xFF ; = 255

MOV r3, #0x101 ; = 257

MOV r4, #0x400 ; = 1024

stop SWI 0x11 ; Terminate

END ; Mark end of file

Exercise 3.1 - What is wrong with the example?

Pass the example file value.s through armasm.

What error messages do you get and why?

[Hint: Look at the sections on Immediate values and loading 32-bit constants in the ARM Instruction Set training module]

Exercise 3.2 - Producing a correct version of the example

Copy the example file as value2.s and edit this so as to produce a version which will be successfully assembled by armasm.

[Hint: Make use of LDR Rn,=const where appropriate]

After assembling and linking, load your executable into the debugger. Set a breakpoint on start and begin execution of the program. When the breakpoint is hit, display the registers. Single step through the code, until you reach stop, taking careful note of what instruction is being used for each load. Look at the updated register values to see that the example has executed correctly and then tell the debugger to execute the rest of the program to completion.

Session 3 : Loading addresses into registers

The following is a simple ARM code example that copies one string over the top of another string. This file can be found as c:\work\asm\session3\copy.s

AREA Copy, CODE, READONLY

ENTRY ; mark the first instruction to call

start LDR r1, =srcstr ; pointer to first string

LDR r0, =dststr ; pointer to second string

strcopy ; copy first string over second

LDRB r2, [r1],#1 ; load byte and update address

STRB r2, [r0],#1 ; store byte and update address;

CMP r2, #0 ; check for zero terminator

BNE strcopy ; keep going if not

stop

SWI 0x11 ; terminate

AREA Strings, DATA, READWRITE

srcstr DCB "First string - source",0

dststr DCB "Second string - destination",0

END

Notable features in the module

1) LDR Rx, =label

This is a pseudo-instruction that can be used to generate the address of a label. It is used here to load the addresses of srcstr and dststr into registers. This is done by the assembler allocating space in a nearby literal pool (portion of memory set aside for constants) for the address of the required label. The instruction placed in the code is then a LDR instruction which will load the address in from the literal pool.

2) DCB

“Define Constant Byte” is an assembler directive to allocates one or more bytes in memory. It is a therefore a useful way to create a string in an assembly language module.

Exercise 3.1 - Running the example

Build the example file copy.s using armasm and load it into your debugger as described in the introduction.

Set a breakpoint on start and begin execution of the program. When the breakpoint is hit, single step through the code, up to strcpy. Watch the addresses of the two strings being loaded into r0 and r1, noting the instructions used to generate those addresses. Now set two further breakpoints, one on strcpy and one on stop. Now restart execution of the program. Each time the program hits a breakpoint, look at the updated string contents, until execution completes.

Session 4 : Assembler subroutines

Exercise 4.1 - Converting copy.s to use a subroutine

This file copy.s in c:\work\asm\session4 is the same program as that used in exercise 3.1. Convert this version so that the code between strcpy and stop becomes a subroutine that is called by the main program using a BL instruction. The subroutine should return using a MOV pc,lr instruction.

Build your converted copy.s using armasm and load it into your debugger. Follow the execution as per exercise 3.1, to ensure that your converted copy.s has the same result as the original.

Session 5 : Calling assembler from C

ARM defines an interface to functions called the ARM Procedure Call Standard (APCS). This defines that the first four arguments to a function are passed in registers r0 to r3 (any further parameters being passed on the stack) and a single word result is returned in r0. Using this standard it is possible to mix calls between C and assembler routines.

The following is a simple C program that copies one string over the top of another string, using a call to a subroutine. This file can be found as c:\work\asm\session5\strtest.c

#include

extern void strcopy(char *d, char *s);

int main()

{ char *srcstr = "First string - source ";

char *dststr = "Second string - destination ";

printf("Before copying:\n");

printf(" %s\n %s\n",srcstr,dststr);

strcopy(dststr,srcstr);

printf("After copying:\n");

printf(" %s\n %s\n",srcstr,dststr);

return (0);

}

Exercise 5.1 - Extracting strcopy from copy.s

Copy the copy.s produced in Exercise 4.1 into c:\work\asm\session5. Now modify this so that it only contains the subroutine strcopy. Note that you will also need to remove the “ENTRY” statement as the entry point will now be in C, and add an “EXPORT strcopy”, so that the subroutine is visible outside of the module.

Build the application using armcc for strtest.c and armasm for copy.s, linking with the ARM C library as detailed in the Introduction. Load the executable into the debugger and ensure that it functions correctly.

Session 6 : Jump tables

The following is a simple ARM code example that implements a jump table. This file can be found as c:\work\asm\session6\jump.s

AREA Jump, CODE, READONLY ; name this block of code

num EQU 2 ; Number of entries in jump table

ENTRY ; mark the first instruction to call

start MOV r0, #0 ; set up the three parameters

MOV r1, #3

MOV r2, #2

BL arithfunc ; call the function

SWI 0x11 ; terminate

arithfunc ; label the function

CMP r0, #num ; Treat function code as unsigned integer

BHS DoAdd ; If code is >=2 then do operation 0.

ADR r3, JumpTable ; Load address of jump table

LDR pc, [r3,r0,LSL#2] ; Jump to the appropriate routine

JumpTable

DCD DoAdd

DCD DoSub

DoAdd ADD r0, r1, r2 ; Operation 0, >1

MOV pc, lr ; Return

DoSub SUB r0, r1, r2 ; Operation 1

MOV pc,lr ; Return

END ; mark the end of this file

Description of the module

The function arithfunc takes three arguments. The first controls the operation carried out on the second and third arguments. The result of the operation is passed back to the caller routine in r0. The operations the function are:

0 : Result = argument2 + argument3

1 : Result = argument2 - argument3

Values outside this range have the same effect as value 0.

EQU

This is an assembler directive that is used to give a value to a label name. In this example it assigns num the value 2. Thus when num is used elsewhere in the code, the value 2 will be substituted (similar to using a #define to set up a constant in C).

ADR

This is a pseudo-instruction that can be used to generate the address of a label. It is thus similar to the LDR Rx,=label encountered earlier. However rather than using a literal pool to store the address of the label, it instead constructs the address directly by using its offset from the current PC. It should be used with care though as it has only a limited range (255 words for a word-aligned address and 255 bytes for a byte-aligned address). It is advisable to only use it for generating addresses to labels within the same area, as the user cannot easily control how far areas will be apart at link time.

An error will be generated if the required address cannot be generated using a single instruction. In such circumstances either an ADRL (which generates the address in two instructions) or the LDR Rx,=label mechanism can be used.

DCD

This declares one or more words. In this case each DCD stores a single word - the address of a routine to handle a particular clause of the jumptable. This can then be used to implement the jump using:

LDR pc, [r3,r0,LSL#2]

This instruction causes the address of the required clause of the jump table be loaded into the PC. This is done by multiplying the clause number by 4 (to give a word offset), adding this to the address of the jump table, and then loading the contents of the combined address into the PC (from the appropriate DCD).

Exercise 6.1 - Running the example

Build the example file jump.s using armasm and load it into your debugger as described in the introduction.

Set a breakpoint on arithfunc and begin execution of the program. When the breakpoint is hit, check the registers to ensure that the parameters have been set up correctly. Now single step through the code, ensuring that the correct jump is taken depending upon the value in r0. When you return back from arithfunc to the main program, check that the correct result has been passed back. Now tell the debugger to execute the rest of the program to completion.

Now reload the program and execute up to the breakpoint on arithfunc. Check the registers to ensure that the parameters have been set up but then change r0, so that another action will be carried out by the jump table. Single step through the program again and check that the correct path is taken for your amended parameter.

Exercise 6.2 - Logical operations

Create a new module called gate.s, based on jump.s, which implements the following operations, depending on the value passed in r0:

0 : Result = argument2 AND argument3

1 : Result = argument2 OR argument3

2 : Result = argument2 EOR argument3

3 : Result = argument2 AND NOT argument3 (bit clear)

4 : Result = NOT (argument2 AND argument3)

5 : Result = NOT (argument2 OR argument3)

6 : Result = NOT (argument2 EOR argument3)

Values outside this range should have the same effect as value 0.

Add a loop to the main program that cycles through the each of these values. Build gate.s using armasm, and check that it functions correctly.

Session 7 - Block Copy

The following is a simple ARM code example that implements copies a set of words from a source location to a destination. This file can be found as c:\work\asm\session7\word.s

AREA CopyBlock, CODE, READONLY ; name this block of code

num EQU 20 ; Set number of words to be copied

ENTRY ; mark the first instruction to call

start LDR r0, =src ; r0 = pointer to source block

LDR r1, =dst ; r1 = pointer to destination block

MOV r2, #num ; r2 = number of words to copy

wordcopy

LDR r3, [r0], #4 ; a word from the source

STR r3, [r1], #4 ; store a word to the destination

SUBS r2, r2, #1 ; decrement the counter

BNE wordcopy ; ... copy more

stop SWI 0x11 ; and exit

AREA Block, DATA, READWRITE

src DCD 1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4

dst DCD 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

END

Exercise 7.1 - Running the example

Build the example file word.s using armasm and load it into your debugger as described in the introduction.

Set breakpoints on wordcopy and stop. Begin execution of the program. When the breakpoint on wordcopy is hit, check the registers to ensure that they have been set up correctly and examine the src and dst blocks of memory. Now restart and each time a breakpoint is hit, re-examine the src and dst blocks. Continue until the program runs to completion.

Exercise 7.2 - Using multiple load and stores

Create a new module called block.s, based on word.s, which implements the block copy using LDM and STM for as much of the copying as possible. A sensible number of words to transfer in one go is eight. The number of eight word multiples in the block to be copied can be found (if r2 = number of words to be copied) using:

MOVS r3, r2, LSR #3 ; number of eight word multiples

The number of single word LDRs and STRs left to copy after doing copying the eight word multiples can be found using:

ANDS r2, r2, #7 ; number of words left to copy

Build block.s using armasm, and check that it functions correctly by setting breakpoints on the loop containing the eight word multiple copies and the single word copies, and examining the src and dst blocks of memory when a breakpoint is hit.

Test further that you code does work by modifying the number of words to be copied (specified in num) to be 7 and then 3.

Exercise 7.3 - Extending block.s

Copy the file, block.s produced in Exercise 7.2 as block2.s. Extend this so that when the copying of eight word multiples has completed, if there are four or more words left to copy, then four words will be copied using LDM/STM.

Test your code with num set to 20, 7 and 3.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download