SPRUIG5E January   2018  – March 2023 TDA4VM , TDA4VM-Q1

 

  1.   Abstract
  2. 1About This Document
    1. 1.1 Related Documents
    2. 1.2 Trademarks
  3. 2Migrating C Source from C6000 to C7000
    1. 2.1  Compiler Options
    2. 2.2  Native Vector Data Types
    3. 2.3  Type Qualifiers: near and far
    4. 2.4  64-bit long Type
    5. 2.5  References to Control Registers
    6. 2.6  Memory-Mapped Peripherals
    7. 2.7  Run-Time Support
    8. 2.8  Contents of Migration Header File c6x_migration.h
      1. 2.8.1 Supported Macros
      2. 2.8.2 Non-Supported Macros
      3. 2.8.3 Legacy Data Types
      4. 2.8.4 Legacy Intrinsics
    9. 2.9  Galois Field Multiply Instructions
    10. 2.10 Performance Considerations for Migrated Code
      1. 2.10.1 UNROLL Pragma
      2. 2.10.2 Subvector Access
      3. 2.10.3 16x16 and 16x32 Bit Multiplies
      4. 2.10.4 __x128_t Type
      5. 2.10.5 Unsigned Array Offsets
      6. 2.10.6 Streaming Engine and Streaming Address Generator
      7. 2.10.7 Additional Optimization Guidance
  4. 3Host Emulation
  5. 4Revision History
    1.     29
    2.     30

Legacy Intrinsics

The C6000 intrinsic names, which are defined in c6x.h, do not conflict with any C7x intrinsic names. Therefore, including both the migration header c6x_migration.h as well as c7x.h will not cause an issue. Each C6000 intrinsic is mapped to either a single C7000 instruction or a set of C7000 instructions that perform or emulate the same behavior.

  • If a C6000 intrinsic is mapped to a single C7000 instruction, then search c7x.h for the C7000 C-idiom for that instruction.
  • If a C6000 intrinsic is mapped to a set of instructions, then an example C7000 C-idiom will be providedin c7x.h.

For example, in c6x_migration.h, the _dadd intrinsic is declared and the mapped C7000 instruction, VADDW , is indicated in the comment above the declaration:

/* VADDW */
long long __BUILTIN _dadd(long long, long long);

In c7x.h, the same instruction is shown as well as its supported C-idiom, whether that is a C intrinsic or operator:

VADDW
int = int + int;
int2 = int2 + int2;
int4 = int4 + int4;
int8 = int8 + int8;
int16 = int16 + int16;
cint = cint + cint;
cint2 = cint2 + cint2;
cint4 = cint4 + cint4;
cint8 = cint8 + cint8;
uint = uint + uint;
uint2 = uint2 + uint2;
uint4 = uint4 + uint4;
uint8 = uint8 + uint8;
uint16 = uint16 + uint16;

As another example, the _unpkbu4 intrinsic is declared, but there is no single C7000 instruction to which it corresponds. So, c7x.h shows the C7000 C-idiom as follows:

/*---------------------------------------------------------------------------*/
/* _unpkbu4 uses the VUNPKLUB and VUNPKHUB to unpack the low and high 2      */
/* bytes of the argument, and then constructs the result. An equivalent C7X  */
/* piece of code would look like:                                            */
/*                                                                           */
/* ushort4 _unpkbu4(uchar4 src)                                              */
/* {                                                                         */
/*   ushort4 dst;                                                            */
/*   dst.lo = __unpack_low(src);                                             */
/*   dst.hi = __unpack_high(src);                                            */
/*   return dst;                                                             */
/* }                                                                         */
/*---------------------------------------------------------------------------*/
long long __BUILTIN _unpkbu4(unsigned)

The following deprecated C6000 intrinsics are not supported with the C7000 Compiler Tools. Use the long long variants instead:

  • _mpy2 is not supported, use _mpy2ll instead
  • _mpyhi is not supported, use _mpyhill instead
  • _mpyli is not supported, use _mpylill instead
  • _mpyid is not supported, use _mpyidll instead
  • _mpysu4 is not supported, use _mpysu4ll instead
  • _mpyu4 is not supported, use _mpyu4ll instead
  • _smpy2 is not supported, use _smpy2ll instead

The following aligned memory access intrinsics will not align input addresses:

  • amem2 will not align address
  • amem2_const will not align address
  • amem4 will not align address
  • amem4_const will not align address
  • amem8 will not align address
  • amem8_const will not align address
  • amemd8 will not align address
  • amemd8_const will not align address