• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1176 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.

Compiler/TMS320C6678: Memory model for a library

Clement FR
Genius 4750 points

Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Hello compiler experts

In my field we use a middleware to abstract the OS and HW archictecture and software applications are built on top of this middleware.
The HW is composed of DSP C6678.
The middleware is a library designed to run on this DSP.

Here are the compilation options I use to build the library:

-mv6600 --abi=eabi -mi10 --gen_func_subsections=on -Ooff -g

(we volontary choose to let the library fully debuggable)

By default the memory model is --mem_model:data=far_aggregates.

The application compilation options are:

-mv6600 --abi=eabi -mi10 --mem_model:data=far_aggregates

We put initialization code in DDR3 memory (because performance is not needed at initialization), other code is in L2 (for performance).
We notice quite a lot of trampolines call but I'm not worried about them due to some of the code being in DDR3.


I have read the Wiki on C6000 Memory models and the application report SPRAA46A

My questions are:

- Should I default to the "near" memory model for the library ?

- Should I use other important options for the library that I missed ? (do you have suggestions)

Thanks
Regards
Clement

  • 0
    TI__Guru**** 252300 points

    Clement FR said:
    - Should I default to the "near" memory model for the library ?

    No.  The question is whether to use --mem_model:data=far, or rely on the default  --mem_model:data=far_aggregates.  I recommend you start with far.  If performance is good enough, then stop.  This model is the easiest to support.  If you have lots of scalar global variable accesses on the critical paths, then it could make sense to rely on the default far_aggregates.  As you know, all of this is discussed in the wiki article C6000 Memory Models & Vendor Libraries. 

    Clement FR said:
    - Should I use other important options for the library that I missed ? (do you have suggestions)

    No.  The data memory model is the important one.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4750 points
    Hello George

    This paragraph in the application note
    "Alternatively, consider building a library of related functions. In both cases it is often not known where the
    code may be placed in memory, and thus whether near calls can always reach their intended destinations.
    Such code is commonly built with command line options that cause calls to always use the larger
    encoding. On C6000 the options include -ml1, -ml2, and -ml3 option.
    While using these options increases cycles and code size, that cost is outweighed by the
    convenience of being able to place the code anywhere in memory.
    Trampolines make those build options unnecessary, and improved performance often results. In practice,
    most calls are to related functions. Such functions are typically grouped in the same file or library and thus
    are typically near one another in memory. Therefore, near calls can reach these destinations. Using
    trampolines means that such calls are performed optimally"

    Was leading to think that the "near" memory model would be a good choice for the library.
    Can you elaborate why you don't consider it ?

    I'll give the "far" memory model a try

    Regards
    Clement
  • 0 in reply to Clement FR
    TI__Guru**** 252300 points

    Please make a clear distinction between memory models for data and memory models for code.  In early (more than 10 years ago) versions of the C6000 compiler, memory models for code were a point of concern.  Eventually, trampolines were developed, and this removed the need for memory models for code.  The paragraph you quote describes this transition.  At the time that was written, trampolines were poorly understood.  These days it is taken for granted.  Now only data memory models remain.  Eventually, the term "memory models" came to mean data memory models.  The word "data" is not present, because it is implicitly understood.

    In summary: Regarding code memory models, rely on trampolines and don't worry about it.  Regarding data memory models, use far.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4750 points
    Yes indeed I got confused between models for data & for code.
    It's much clearer now, thank you for your time

    Regards
    Clement