Blackfin Options (Using the GNU Compiler Collection (GCC))

#### 3.20.7 Blackfin Options ¶

`-mcpu=cpu[-sirevision]` ¶

  Specifies the name of the target Blackfin processor. Currently, cpu can be one of ‘`bf512`’, ‘`bf514`’, ‘`bf516`’, ‘`bf518`’, ‘`bf522`’, ‘`bf523`’, ‘`bf524`’, ‘`bf525`’, ‘`bf526`’, ‘`bf527`’, ‘`bf531`’, ‘`bf532`’, ‘`bf533`’, ‘`bf534`’, ‘`bf536`’, ‘`bf537`’, ‘`bf538`’, ‘`bf539`’, ‘`bf542`’, ‘`bf544`’, ‘`bf547`’, ‘`bf548`’, ‘`bf549`’, ‘`bf542m`’, ‘`bf544m`’, ‘`bf547m`’, ‘`bf548m`’, ‘`bf549m`’, ‘`bf561`’, ‘`bf592`’.

  The optional sirevision specifies the silicon revision of the target Blackfin processor. Any workarounds available for the targeted silicon revision are enabled. If sirevision is ‘`none`’, no workarounds are enabled. If sirevision is ‘`any`’, all workarounds for the targeted processor are enabled. The `__SILICON_REVISION__` macro is defined to two hexadecimal digits representing the major and minor numbers in the silicon revision. If sirevision is ‘`none`’, the `__SILICON_REVISION__` is not defined. If sirevision is ‘`any`’, the `__SILICON_REVISION__` is defined to be `0xffff`. If this optional sirevision is not used, GCC assumes the latest known silicon revision of the targeted Blackfin processor.

  GCC defines a preprocessor macro for the specified cpu. For the ‘`bfin-elf`’ toolchain, this option causes the hardware BSP provided by libgloss to be linked in if `-msim` is not given.

  Without this option, ‘`bf532`’ is used as the processor by default.

  Note that support for ‘`bf561`’ is incomplete. For ‘`bf561`’, only the preprocessor macro is defined.

`-msim` ¶

  Specifies that the program will be run on the simulator. This causes the simulator BSP provided by libgloss to be linked in. This option has effect only for ‘`bfin-elf`’ toolchain. Certain other options, such as `-mid-shared-library` and `-mfdpic`, imply `-msim`.

`-momit-leaf-frame-pointer` ¶

  Don’t keep the frame pointer in a register for leaf functions. This avoids the instructions to save, set up and restore frame pointers and makes an extra register available in leaf functions.

`-mspecld-anomaly` ¶
`-mno-specld-anomaly`

  When enabled, the compiler ensures that the generated code does not contain speculative loads after jump instructions. If this option is used, `__WORKAROUND_SPECULATIVE_LOADS` is defined.

`-mcsync-anomaly` ¶
`-mno-csync-anomaly`

  When enabled, the compiler ensures that the generated code does not contain CSYNC or SSYNC instructions too soon after conditional branches. If this option is used, `__WORKAROUND_SPECULATIVE_SYNCS` is defined.

`-mlow64k` ¶
`-mno-low64k`

  When enabled, the compiler is free to take advantage of the knowledge that the entire program fits into the low 64k of memory. The default behavior is to assume that the program is arbitrarily large (`-mno-low64k`).

`-mstack-check-l1` ¶

  Do stack checking using information placed into L1 scratchpad memory by the uClinux kernel.

`-mid-shared-library` ¶
`-mno-id-shared-library`

  Generate code that supports shared libraries via the library ID method. This allows for execute in place and shared libraries in an environment without virtual memory management. This option implies `-fPIC`. With a ‘`bfin-elf`’ target, this option implies `-msim`. The default is `-mno-id-shared-library`, to generate code that doesn’t assume ID-based shared libraries are being used.

`-mleaf-id-shared-library` ¶
`-mno-leaf-id-shared-library`

  Generate code that supports shared libraries via the library ID method, but assumes that this library or executable won’t link against any other ID shared libraries. That allows the compiler to use faster code for jumps and calls.

  The default is `-mno-leaf-id-shared-library`, in which the no assumption is made that the code being compiled won’t link against any ID shared libraries. Slower code is generated for jump and call insns.

`-mshared-library-id=n` ¶

  Specifies the identification number of the ID-based shared library being compiled. Specifying a value of 0 generates more compact code; specifying other values forces the allocation of that number to the current library but is no more space- or time-efficient than omitting this option.

`-msep-data` ¶
`-mno-sep-data`

  Generate code that allows the data segment to be located in a different area of memory from the text segment. This allows for execute in place in an environment without virtual memory management by eliminating relocations against the text section. The default is `-mno-sep-data`, which tells GCC to generate code that assumes that the data segment follows the text segment.

`-mlong-calls` ¶
`-mno-long-calls`

  Tells the compiler to perform function calls by first loading the address of the function into a register and then performing a subroutine call on this register. This switch is needed if the target function lies outside of the 24-bit addressing range of the offset-based version of subroutine call instruction.

  This feature is not enabled by default. Specifying `-mno-long-calls` restores the default behavior. Note these switches have no effect on how the compiler generates code to handle function calls via function pointers.

`-mfast-fp` ¶

  Link with the fast floating-point library. This library relaxes some of the IEEE floating-point standard’s rules for checking inputs against Not-a-Number (NAN), in the interest of performance.

`-minline-plt` ¶

  Enable inlining of PLT entries in function calls to functions that are not known to bind locally. It has no effect without `-mfdpic`.

`-mmulticore` ¶

  Build a standalone application for multicore Blackfin processors. This option causes proper start files and link scripts supporting multicore to be used, and defines the macro `__BFIN_MULTICORE`. It can only be used with `-mcpu=bf561[-sirevision]`.

  This option can be used with `-mcorea` or `-mcoreb`, which selects the one-application-per-core programming model. Without `-mcorea` or `-mcoreb`, the single-application/dual-core programming model is used. In this model, the main function of Core B should be named as `coreb_main`.

  If this option is not used, the single-core application programming model is used.

`-mcorea` ¶

  Build a standalone application for Core A of BF561 when using the one-application-per-core programming model. Proper start files and link scripts are used to support Core A, and the macro `__BFIN_COREA` is defined. This option can only be used in conjunction with `-mmulticore`.

`-mcoreb` ¶

  Build a standalone application for Core B of BF561 when using the one-application-per-core programming model. Proper start files and link scripts are used to support Core B, and the macro `__BFIN_COREB` is defined. When this option is used, `coreb_main` should be used instead of `main`. This option can only be used in conjunction with `-mmulticore`.

`-msdram` ¶

  Build a standalone application for SDRAM. Proper start files and link scripts are used to put the application into SDRAM, and the macro `__BFIN_SDRAM` is defined. The loader should initialize SDRAM before loading the application.

`-micplb` ¶

  Assume that ICPLBs are enabled at run time. This has an effect on certain anomaly workarounds. For Linux targets, the default is to assume ICPLBs are enabled; for standalone applications the default is off.