Linker error when using GateMutexPri

Hi Martin,

Have you tried not using whole_program_debug? The release notes for 6.32.05.54 say this:

We are planning to remove support for the whole_program and whole_program_debug profiles because of build time problems and compatibility problems when using different compiler versions. SYS/BIOS 6.32 will output a warning message when the whole_program or whole_program_debug profiles are used. We are now providing pre-built libraries which can be selected via the BIOS.libType configuration parameter (see section 7.6.1 of the BIOS User's Guide for details). The instrumented library contains Assert() and Log statements. The non-instrumented library does not. The custom library can be used to build a custom BIOS library which will be built using #define constants reflecting some of the key configuration parameters from your application .cfg file. The non-instrumented library and custom library should give you similar or better performance to SYS/BIOS 6.31 using the whole_program profile.

You may want to consider moving to a newer version of SYS/BIOS if it's not too much of a hassle.

Whitney

Hi Whitney,

I tried to build the program using "whole_program_debug" and "whole_program" which both lead to the same results. I also tried building with "debug" which lead to an error when calling configuro.

error: ti.sysbios.BIOS: "/opt/ti/bios_6_32_05_54/packages/ti/sysbios/BIOS.xs", line 557: ti.sysbios.utils.Load hwiEnabled: Load.hwiEnabled must be set to 'false' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.
error: ti.sysbios.BIOS: "/opt/ti/bios_6_32_05_54/packages/ti/sysbios/BIOS.xs", line 573: ti.sysbios.utils.Load swiEnabled: Load.swiEnabled must be set to 'false' when BIOS.libType == BIOS.LibType_Instrumented.  Set 'BIOS.libType = BIOS.LibType_Custom' to build a custom library or update your configuration.

I'd love to see section 7.6.1 of the BIOS User's Guide but the one shipped with my SysBIOS version does not have a section 7.6.1.

Unfortunately, at my current project's state, changing the SYSBIOS version is not really an option.

Regards

Martin

Hi Martin,

I think the section that the release notes meant to refer to was 2.3.3. It should explain using the BIOS.LibType configuration parameter. Sorry for the confusion there.

Those errors are saying that you need to use the "Custom" LibType in order to use the settings you've selected. You can either select this on the "Runtime" page in the graphical .cfg editor or add the following to your .cfg script

var BIOS = xdc.useModule('ti.sysbios.BIOS');
BIOS.libType = BIOS.LibType_Custom;

Whitney

Hi Whitney,

when we build the BIOS using BIOs.LibType_Custom and "debug" instead of "whole_program", we see an incline in our system load of about 4% points, even if our compiler builds with -O3 and -pm.

What can we do to build a BIOS binary which performs as fast as the pre-compiled one?

To be clear: what we need is a BIOS binary of the same BIOS version we already use with support for GateMutexPri which performs (almost) as fast as the one shipped with SysBIOS.

Regards

Martin

Martin,

See the following thread: http://e2e.ti.com/support/embedded/bios/f/355/t/300601.aspx

Hi David,

when we build SysBIOS without logs and asserts, we can reduce the performance loss (comapred to pre-compiled BIOS) from 4% points to 2% points.

Still, we need to reduce the performance loss to <1% point. Could you please provide the compiler arguments used to build the pre-compiled BIOS?

Regards

Martin

Martin,

The pre-compiled BIOS libraries are built with the following options:

" --program_level_compile -o3 -g --optimize_with_debug "

Judah

Hi Judah,

using your compiler options, we were able to reduce the performance loss to about 1%. However, I have some questions about those options.

1. What does "--optimize_with_debug" do? It's not documented in SPRU187O (May 2008).
2. Is "-o3" (lower case o) the same as -O3 (upper case O)? SPRU187O states that the options are case sensitive and only the upper case version is documented.
3. Why do those options perform better than our previously used options ("-O3 -pm")?

Regards

Martin

Martin Bober said:

What does "--optimize_with_debug" do? It's not documented in SPRU187O (May 2008).

It is covered in the latest revision of that manual.  The condensed answer is it re-enables compiler optimizations that are disabled by building with -g.

Martin Bober said:

Is "-o3" (lower case o) the same as -O3 (upper case O)?

Yes.

Martin Bober said:

SPRU187O states that the options are case sensitive and only the upper case version is documented.

The options are case sensitive.  In very old compiler versions the options are not case sensitive.  Because of that --opt_level=3 -O3 -o3 are all equivalent.  Sorry about the confusion.  

Martin Bober said:

Why do those options perform better than our previously used options ("-O3 -pm")?

When you build with -g, certain optimizations are disabled because they make it more difficult to debug the code.  By using --optimize_with_debug, you indicate that you don't care about that, optimize it anyway.  

Thanks and regards,

-George

Hi George

George Mock said:

Why do those options perform better than our previously used options ("-O3 -pm")?

When you build with -g, certain optimizations are disabled because they make it more difficult to debug the code.  By using --optimize_with_debug, you indicate that you don't care about that, optimize it anyway. [/quote]

I understand that building with -g has negative impact on program performance. But we called the compiler without a -g option (only "-O3 -pm"). Does one of our given options implicitly include -g?