TASKING VX-toolset for ARM



TASKING ARM Product Page, TASKING ARM Support Page, TASKING Developers' Forum, TASKING Home Page, Eclipse


These release notes describes ABI issues, important notes and changes and new features since version v2.0r1, v2.0r2 & v2.0r3 of the TASKING VX-toolset for ARM.

The following parts are described:

The tools support architectures ARMv4, ARMv4T, ARMv5T, ARMv5TE and XScale. The Jazelle extension of the ARMv5TE architecture (ARMv5TEJ) is supported by the assembler only, i.e. the bxj instruction is supported.

With version v2.0r1 support is added for ARMv6-M, ARMv7-M and for Vector Floating Point (VFP).

With version v2.0r2 a Cortex only version of the tools is available. The Cortex only products support the ARMv6-M and ARMv7-M architectures.

With version v3.0r1 the Eclipse platform is used as Integrated Development Environment (IDE).

With version v3.0r1 the time-unlimited, size-limited evaluation version has been extended by a 15-day full trial mode.


Eclipse environment

Before you start using this toolset, please read the Getting Started with the TASKING VX-toolset for ARM documentation to become familiair with Eclipse and the debugger

Thumb-2 Instruction Set

The ARMv7-M architecture profile implements the Thumb-2 instruction set. Besides some new 16-bit Thumb instructions it introduces 32-bit Thumb instructions and an IT instruction for conditional execution. This makes the Thumb-2 instruction set almost as powerful as the 32-bit ARM instruction set. The 32-bit Thumb-2 instructions can be executed in Thumb state and need only be half-word aligned in memory. The IT instruction (If/Then) sets the conditions for up to four instructions following the IT instruction. For a number of Thumb-2 instructions both 16-bit encodings as well as 32-bit encodings exist. The assembler selects the proper encoding for such an instruction, although in some situations you can force the selection of a specific encoding.

Unified Assembly Language (UAL)

With the Thumb-2 instruction set ARM Ltd introduced the Unified Assembly Language (UAL) which provides a canonical form for all ARM and Thumb instructions. The UAL allows you to write assembly code which can be assembled using 32-bit ARM instructions or using 16-bit and 32-bit Thumb-2 instructions. This means that you can use IT instructions followed by a block of up to four conditional instructions in both ARM and Thumb-2 code. The assembler checks for consistency between the two, and assembles the appropriate code depending on the current instruction set.

With version v2.0r1 the C compiler generates UAL code for all architectures.


When you use the product without a valid license, the tools will first run in trial mode. This means that you can use the toolset for 15 days with full functionality. After the trial periode has expired, parts of the toolset may switch to evaluation mode. The evaluation mode has the following restrictions:






When you use a license that does not cover the full toolset, only the tools which are not covered by the license will run in trial/evaluation mode.

Tools running in trial/evaluation mode emit an informational message. If, after installing a valid license file, the tools which are covered by the license still emit this message, then there is a license error. Use command line option -V to get the actual FLEXlm license error message. You may also force termination of trial or evaluation mode by setting the environment variable FORCE_NO_TRIAL to "yes".


The TASKING VX-toolset for ARM optionally includes a C++ compiler.

The C++ compiler accepts the C++ language of the ISO/IEC 14882:1998 C++ standard (with some minor exceptions) and can be seen as a preprocessor or front end which accepts C++ source files or sources using C++ language features. The output generated by the C++ compiler is C, which can be translated by the C compiler. The C++ compiler also accepts embedded C++ language extensions.

With version v2.0r2 the C++ compiler option --instantiate=none became obsolete. This lacks the need of a Prelinker, so this utility is no longer part of the tools.


With version v2.0r1, the C compiler generates Unified Assembly Language (UAL) code.

New compiler options (since version 2.0r1)

 Option Description
--fpu=fpu With this option you define the kind of FPU support with which you create your application.
--unaligned-access With this option you tell the compiler to generate more efficient instructions to access unaligned 16-bit or larger data. Halfword or word load and store instructions are used instead of byte instructions. This option is only useful for cores that have support for unaligned access.
To address the memory of the ARM, you can use far 32-bit indirect calls or near 26-bit PC-relative calls.
This option is especially relevant for ARMv6-M. For other architectures near calls (the default) are preferred and the linker will generate veneers if necessary.

New function qualifiers (since version 2.0r1)

Keyword Description
__interrupt_svc Software interrupt (replaces old function qualifier __interrupt_swi).
__interrupt(n) Interrupt for vector n.

New intrinsic functions (since version 2.0r1)

Intrinsic Description
__getapsr() Get the value of the APSR status register (ARMv6-M and ARMv7-M).
__setapsr(int set, int clear) Set or clear bits in the APSR status register (ARMv6-M and ARMv7-M).
__getipsr() Get the value of the IPSR status register (ARMv6-M and ARMv7-M).
__svc(int number) Generates a supervisor call (replaces old intrinsic function __swi() ).

New pragmas for code and const sections (since version 2.0r2)

Pragma Description
section_code_init Copy code sections from ROM to RAM at application startup.
section_no_code_init Don't copy code sections from ROM to RAM.
section_const_init Copy read-only data sections from ROM to RAM at application startup.
section_no_const_init Don't copy read-only-data sections from ROM to RAM.

New pragmas to influent code generation for switch statements (since version 2.0r2)

Pragma Description
smart_switch The C compiler supports two ways of code generation for a switch statement: a jump chain (linear switch) or a jump table.

By default, the compiler tries to use the switch method which uses the least space in ROM (i.e. table size in ROMDATA plus code to do the indexing).

For a switch with a long type argument, only linear code is used.

For an int type argument, a jump table switch is only used when the table of cases is not too sparse.

It is obvious that, especially for large switch statements, the jump table approach executes faster than the binary search table approach. Also the jump table has a predictable behavior in execution speed. No matter the switch argument, every case is reached in the same execution time.

With a small number of cases, the jump chain method can be faster in execution and shorter in size.

For ARMv7M a switch using the tbh instruction gets priority over a normal switch table implementation.
jump_switch A jump table is a table filled with jump labels for each possible switch value. The switch argument is used as an index to jump using labels within this table.
linear_switch A jump chain is comparable with an if/else-if/else-if/else construction.
binary_switch A binary search table is a table filled with a value to compare the switch argument with and a target address to jump to. This is currently not supported.
tbb_switch Force usage of tbb instruction. Uses a table of 8-bit jump offsets.
tbh_switch Force usage of tbh instruction. Uses a table of 16-bit jump offsets.
no_tbh_switch As smart_switch, but don't use tbh instruction.


With version v2.0r1 the assembler runs in UAL mode by default. Use the assembler option --old-syntax to get the old behavior.

New assembler options (since version 2.0r1)

 Option Description
--old-syntax The assembler will run in pre-UAL mode.
--inversions With this option you tell the assembler to try to invert some data processing instructions with an immediate operand. Inversions are available for MOV/MVN, CMP/CMN, AND/BIC, ADC/SBC, and ADD/SUB.

New assembler directives (since version 2.0r1)

Intrinsic Description
.FLOAT/.DOUBLE Define a 32-bit / 64-bit floating-point constant.
.THUMB/.ARM Treat instructions as Thumb or ARM instructions using UAL syntax.

Compatibility with ARM RVCT v3.0 assembly

The assembler supports the pseudo-instructions defined by ARM RVCT v3.0 tools (except the ADRL pseudo-instruction for Thumb-2), and the canonical forms for POP, PUSH, LSL, LSR, ASR, ROR and RRX instructions, .

For Thumb-2 the assembler only accepts the condition code as the last element of any mnemonic. For ARM the assembler accepts infix condition code, but only if --old-syntax option or .code32 directive is used.

The assembler only supports the UAL syntax for VFP instructions.

With the option --relaxed the assembler accepts 2-operand versions of 3-operand instructions when the first and second operand are a destination and a source register and the same register is used for both. E.g. 'add r1,r1,r3' may be written as 'add r1,r3' and 'add r1,r1,#4' may be written as 'add r1,#4'.

You should not add 1 to Thumb label expressions in literal pools or data sections. This will be taken care of automatically by the assembler and the linker.


The linker automatically generates ARM-Thumb interworking veneers when needed. This release always creates a long veneer, i.e. short veneers and inline veneers are not used. Veneer symbol names do not follow the convention proposed by the EABI (not mandatory).

The linker does not generate long-branch veneers for out-of-range function calls by default. You can enable this feature with option --long-branch-veneers, but use it with care. The option slows down the linking process considerably and it can lead to larger code size even when veneers are not needed after all. It is better to prevent long branches and only use this option when long branches are out of range.

The ARMv6-M architecture profile has no support for veneers. Use compiler option --call to force far 32-bit indirect calls or near 26-bit PC-relative calls.


Since version 3.0r1, the Eclipse Ganymede platform is used as Integrated Development Environment (IDE)


All product libraries are suitable for ARM-Thumb interworking. None of the libraries are optimized for VFP.

The startup code for ARM and Thumb included in the C library (carm.lib & cthumb.lib) provides basic functionality: it initializes the separate stack pointers for each processor mode, copies global data from ROM to RAM, calls the application's main function and calls the exit function upon return from main. It does not do any hardware initialization. You may contact Altium Support for assistance on hardware-specific issues pertaining to the use of the TASKING VX-toolset.


The new TASKING Debugger is integrated in the Eclipse environment.


Copyright 2004-2008 Altium BV