7.1.1. When to use interworking

When you write code for a Thumb-capable ARM processor, you will probably write most of your application to run in Thumb state, because this provides the best possible code density and performance with 8-bit or 16-bit memory. However, you may want parts of your application to run in ARM state for reasons such as:

Speed

Some parts of an application may be highly speed critical. These sections may be more efficient running in ARM state than in Thumb state, because in some circumstances a single ARM instruction can do more than the equivalent Thumb instruction.

Some systems include a small amount of fast 32-bit memory from which ARM code can be run, without the overhead of fetching each instruction from 8-bit or 16-bit memory.

Functionality

Thumb instructions are less flexible than their ARM equivalents. Some operations, such as accessing the program status registers directly, are not possible in Thumb state. This means that a state change is required in order to carry out these operations.

Exception handling

The processor automatically enters ARM state when a processor exception occurs. This means that the first part of an exception handler must be coded with ARM instructions, even if it re-enters Thumb state to carry out the main processing of the exception. At the end of such processing, the processor must be returned to ARM state to return from the handler to the main application.

Refer to Handling exceptions on Thumb-capable processors for more information.

Standalone Thumb programs

A Thumb-capable ARM processor always starts in ARM state. To run simple Thumb assembly language programs under the debugger, add an ARM header that carries out a state change to Thumb state and then calls the main Thumb routine. See Example ARM header for an example.

Copyright © 1997, 1998 ARM Limited. All rights reserved.ARM DUI 0040D
Non-Confidential