• 状态 Resolved
  • 已锁定 已锁定
  • 回复 4 回复
  • 订户 1 订户
  • 视图 347 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] 编译器/TMS320C6678：库的内存模型

admin
Guru**** 2539500 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/574900/compiler-tms320c6678-memory-model-for-a-library

部件号：TMS320C6678

工具/软件：TI C/C++编译器

您好，编译器专家

在我的领域中，我们使用中间件来抽象化操作系统和硬件架构，软件应用程序构建在此中间件之上。
硬件由DSP C6678组成。
中间件是设计用于在此DSP上运行的库。

下面是我用来生成库的编译选项：

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

(我们VOLONTARY选择让库完全可调试)

默认情况下，内存模型为--mem_model:data=fal_Aggregates。

应用程序编译选项包括：

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

我们将初始化代码放在DDR3内存中(因为初始化时不需要性能)，其他代码则放在L2中(用于性能)。
我们注意到很多蹦床呼叫，但由于DDR3中有一些代码，我不担心它们。


我已阅读了C6000内存型号上的Wiki和应用报告SPRAA46A

我的问题是：

－我应该默认使用库的“近”内存模型吗？

－我是否应该为我错过的库使用其他重要选项？ (您有什么建议)

谢谢
此致
克莱门特

  • 0
    TI__Guru**** 2539500 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    -我是否应该默认使用库的“近”内存模型？[/QUOT]

    否。 问题是是使用 --mem_model:data=far，还是依赖默认  值--mem_model:data=fal_Aggregates。  我建议您从FAR开始。  如果性能足够好，则停止。  此模型最容易支持。  如果在关键路径上有大量标量全局变量访问，则依赖默认的FAR_Aggregates是有意义的。  如您所知，Wiki文章 C6000内存模型和供应商库中讨论了所有这些内容。  

    -我是否应该为我错过的库使用其他重要选项？ (您有什么建议)[/QUOT]

    否。 数据存储模型是重要的模型。

    谢谢，此致，

    -George

  • 0
    TI__Guru**** 2539500 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好George

    应用说明中的此段
    "或者，考虑构建相关函数库。 在这两种情况下，通常不知道的位置
    代码可能会被放入内存中，因此附近的呼叫是否始终可以到达其目标位置。
    此类代码通常使用命令行选项构建，这些选项使调用始终使用较大的
    编码。 在C6000上，选项包括-ML1，-ml2和-ml3选项。
    虽然使用这些选项会增加周期和代码大小，但成本会超过
    方便地将代码放置在内存中的任何位置。
    蹦床使这些构建选项变得不必要，并且通常会提高性能。 在实践中，
    大多数调用都是针对相关函数的。 此类函数通常分组在同一个文件或库中，因此
    通常在内存中彼此接近。 因此，附近的呼叫可以到达这些目的地。 使用
    trampolines意味着此类调用以最佳方式执行"

    导致人们认为"近"内存模型是库的一个好选择。
    您能详细说明您不考虑它的原因吗？

    我将尝试使用"far (远)"内存模型

    此致
    克莱门特
  • 0
    TI__Guru**** 2539500 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    请明确区分数据内存模型和代码内存模型。  在C6000编译器的早期版本(10多年前)中，代码的内存模型是一个值得关注的问题。  最终，开发了trampolines，这就消除了对代码内存模型的需求。  您引用的段落描述了此过渡。  在写这篇文章的时候，人们对蹦床的理解很差。  这是理所当然的。  现在只保留数据存储器模型。  最后，术语"内存模型"是指数据内存模型。  "数据"一词不存在，因为它是不言而喻的。

    总之：关于代码内存模型，请依赖trampolines，而不必担心。  对于数据存储器模型，请使用FAR。

    谢谢，此致，

    -George

  • 0
    TI__Guru**** 2539500 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是的，我确实混淆了数据模型和代码模型。
    现在要清楚得多，感谢您抽出宝贵时间

    此致
    克莱门特