• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 502 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Release build with Configuro?

Markus Grunwald
Expert 2060 points

Hello,

I'm building my C6747 (onDM814x) Software on Linux with a customized Makefile, using Configuro. Until now, I was mainly building with the "Debug" profile, but now it comes to optimisation. I read the very good SPRU425A/Optimizing C Compiler Tutorial (is there a newer one?), but I have one big question (and several smaller ones):

Do the "commodities" like Assert_IsTrue and System_printf waste a lot of time in release builds?

Oh, and: is it (generally speaking)  sufficient to tweak the compiler switches and to use xdc.tools.configuros -r release? And what's the exact difference between configuros -r debug and -r release?

Pointers to the Documentation are very appreciated.

Many thanks for your information :)

  • 0
    TI__Mastermind 37985 points

    Markus,
    the main difference between profiles "debug" and "release" is in compiler options that used in building the generated C file. The profile 'debug" does not use any optimization options, while "release" uses -O2.
    http://rtsc.eclipse.org/cdoc-tip/ti/targets/elf/C674.html#profiles

    There is another profile "whole_program" that offers even more aggressive optimization options, but that profile is not supported by SYS/BIOS. So, if you are SYS/BIOS user you can't use that one.

    Just by switching from "debug" to "release", there are no any specific improvements in Assert and System code other than what you get from the generic compiler optimization. However, you can easily turn on and off Asserts and Log statements by using defines xdc_runtime_Assert_DISABLE_ALL and xdc_runtime_Log_DISABLE_ALL. These two will completely eliminate call sites from your code, and you'll be able to estimate their overhead. I know that you asked about System_printf and not about Log, but generally System_printf is more expensive than using various Log functions. The purpose of Log is to offer printf-like functionality with less overhead.

    The costs of System_printf depend on the configured System.SupportProxy provider. Here is a description of System architecture, in case you still want to use it. SysStd calls the standard C putch(), and it is the most expensive option. SysMin is smaller and faster because it implements its own putch(), and then you also have SysCallback, where you can define your own version of putch() function.

    I hope this answers some of your questions. Please let me know if you have further ones.

  • 0 in reply to Sasha Slijepcevic
    Expert 2060 points

    Hello Sasha,

    many thanks for your very helpfull message. I'll try your instructions as soon as I can. In the meanwhile, I have a question regarding the build profiles:

    Since I wasn't aware of the options that are done by configuro, I added these switches to my release build:

    -pmm --call_assumptions=2 --opt_level=3

    I was a bit surprised that SYS/BIOS doesn't support some optimizations, so I wonder if "my" switches have any bad influence?

    Thank you again,

    Markus

  • 0 in reply to Sasha Slijepcevic
    Expert 2060 points

    Hello Sasha,

    I converted my sources to use Log_... instead of System_printf, but now I don't have a clue where to find the output … :)

  • 0 in reply to Markus Grunwald
    TI__Mastermind 37985 points

    Markus,
    the module Log sends the output to a logger configured in your CFG script. If you haven't done it, the simplest way to do it is to add
    var Log = xdc.useModule('xdc.runtime.Log');
    var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
    var Defaults = xdc.useModule('xdc.runtime.Defaults');
    Defaults.common$.logger = LoggerBuf.create({exitFlush: true});
    in your CFG script. Then, you would find the output in the ROV view, Tools->Viewvable Modules->LoggerBuf. Some other loggers can be used, for example LoggerSys can be also used. Here is an overview of logging in RTSC.

    The problem with the "whole_program" profile is not that SYS/BIOS does not support some optimization switches. To use "whole_program" effectively, the libraries included in the build have to be built in a certain way, and SYS/BIOS does not build such libraries. The options that you passed apply to your source code only, so they don't impact any other code.