The ARM-THUMB Procedure Call Standard

The ARM-THUMB Procedure Call StandardSummary of basic variants and indicative costs of useVariant ARM-state Thumb-state Recommended usageShared-library friendly(no use of v6)Inter-working (returnsand indirect calls)1% 0% Always for run-time libraries. Otherwise a user choice(can impact ARM-state performance much more).2% 2% Always for run-time libraries when supported by thetarget architecture. Otherwise a user choice. Generallyimpacts performance by less than 2%.ROPI 0.3% 0.5% Always? Negligible impact on space and speed.RWPI 3.3% 1.8% Use the shared library variant (+2.3%) for run-timelibraries. Shared library is usable as RWPI but notconversely. Otherwise a user choice.Shared library 5.6% 4.1% Always a user choice.Stack-limit checked 3.5% 3.9% Always a user choice.Measurements and extrapolations apply to the way that ARM compilers generate code and may not accuratelyrepresent what should be expected using other compilers.8.2 ARM Shared LibrariesThe ARM shared library architecture has been designed with the following in mind:ooooIt works the same way in ARM-state and Thumb-state and efficiently in both states.It implicitly supports inter-working between ARM-state and Thumb-state.It neither requires, nor precludes, dynamic linking and permits dynamic loading:- A system built using shared libraries can, nonetheless, be linked statically.- But, like a DLL, a shared library can be attached to a running process.It neither requires, nor precludes, a function entry veneer between a caller and a callee unless:- A base-standard, shared-library-friendly client must call a member of a shared library.- A call must swap between ARM-state and Thumb-state.- A call must span a larger address range than BL allows.- Dynamic linking is needed on first use of a library.There are differences of detail between ARM-state and Thumb-state. The standard cannot be simultaneously:oooRigidly symmetrical between ARM and Thumb.Efficient in both states.Derived from a base standard compatible with the earlier APCS and TPCS.The biggest surprise of the ATPCS shared library mechanism is that the read-only part of a library embeds thelibrary’s identity in the form of a small index into a process-specific table of libraries. It is more conventional for theidentity to be implicit in the stub, or procedure linkage table, used to access the library code. Unfortunately, wehave been unable to make the more conventional scheme work efficiently in Thumb-state.As a consequence, the identities of libraries committed to ROM must be allocated statically, before the ROMimage is created.SWS ESPC 0002 A-05 Page 29 of 37