(toppers-users 3852) Re: SSPのスタックの記述
高橋和浩@nifty
takahashi_kazuhiro ＠ nifty.com
2012年 1月 30日 (月) 17:16:02 JST
斎藤様様
早速の回答ありがとうございます。
Q1.自動化のしくみを教えてください。
> そうしますと，その部分の計算を手で行うことが，
> 自動的に計算される場合に比べて手間がかかりメンドウであると
> そういうつもりでの表現でした．
すいません、それがどう面倒かわからないので聞いているのです。
SSPでは、手計算せずに自動的に計算される仕組みがあるように受け取れます。
どのように自動化されるのでしょうか？
こいさんさんの話によるとどこかにdefineしているのみで、DEF_ICSの静的APIの宣言も
されていないようなことが書かれていましたが、これは事実と違うのでしょうか？
Q2.設計思想の件その１
> > 2.TOPPERSの会員内のレビューで議題にあがっいなかったのでしょうか？
は、回答が難しいのでしょうか？
Q3.スタックサイズの安全係数
> ・サイズチェックは必要と思われるため，CRE_TSK の指定値から
> 全タスクのスタックサイズを算出し，すくなくともそれより
> 大であることはチェックする．
たぶん、多重割り込みやカーネル処理でのスタックサイズつまり本来のICSのサイズを見てチェックされる
と思うのですが、イコールでなく、少なくとも大であるというのはどの程度でチェックされていますか？
あまり大きすぎると小さく設定したいのにエラーになってできなくなることとかありませんか？
よろしくお願いします。
On Mon, 30 Jan 2012 16:23:11 +0900
Naoki Saito <nsaito.nmiri ＠ gmail.com> wrote:
> 高橋さん
>
> 斉藤です．
>
> > 1.ユーザ責任以外にスタックサイズ計算があり得るのか？
> （略）
> > 何がどう面倒なのかもわかりませんし、ユーザ責任以外でスタックサイズの算
> 出ができるとも想像がつきません。
> > どのような仕組みなのでしょうか？
>
> 言葉が足りませんでした．
> スタック設定は基本的にユーザ責任ですが，
> 少しでも少ないスタックで済まそうと思った場合，
> CRE_TSK で示した値から (toppers-users 3782) で示したような方法で
> 全タスクのスタック使用量の最悪値を計算する手順をとる
> ことになります．
> そうしますと，その部分の計算を手で行うことが，
> 自動的に計算される場合に比べて手間がかかりメンドウであると
> そういうつもりでの表現でした．
> しないならしないで済む話ではあります．どうもすいません．
>
> ちなみに余談ですが，kernel.tf は (toppers-users 3782) の計算をする
> 処理が(多少難ありですが)入っています．
> でもそれは DEF_ICS の設定値が小さすぎないかどうかを
> チェックするために使われているだけでして，
> 最終的なスタック確保の値を計算するのには使っていないです．
>
> > 2.TOPPERSの会員内のレビューで議題にあがっいなかったのでしょうか？
> > なにか思惑があって、現状の仕様になっているかと思いますが、どのような思
> 惑でこのような設計をしたのでしょうか？
> > その辺を説明いただけないでしょうか？ また、これはTOPPERSの会員内のレ
> ビューで議題にあがらなかったのでしょうか？
> > あがったのであればその結論についても興味があります。
>
> 公開済みのソフトウェアに対する話ですので
> 多分良いという想定の元で，お話しします．
>
> 基本的には用語定義と実装から導かれたもので，
> 特別な思惑ということでも無かったように記憶しています．
> あまりうまく説明出来る自信が無く誤認している
> 可能性が大ですが，私の理解では，
>
> ・SSPは全ての処理単位で同じスタック領域を共用する．
> ・共用されるスタック領域は，タスクと非タスクの両方で使用するので
> 厳密には「非タスクコンテキスト用のスタック領域」ではない．
> （それを「共有スタック領域」と呼ぼう）
> ・実装的には，DEF_ICS で出力されるスタック領域を
> 共有スタック領域として使いたい．
> → このときに，共有スタック領域生成の静的APIを作るのが自然であるが
> ASPとの下位互換性が崩れるため，既存の静的APIを使いたい
> → 実際には DEF_EPRI の時点で下位互換性は崩れていますが
> そこは目をつぶることにします．
> ・DEF_ICS は共有スタック領域の生成のための静的APIという具合に
> 意味を変えることにする．
> ・共有スタックは DEF_ICS でサイズ指定するため，
> CRE_TSK の値は使わない．
> ・サイズチェックは必要と思われるため，CRE_TSK の指定値から
> 全タスクのスタックサイズを算出し，すくなくともそれより
> 大であることはチェックする．
>
> ．．．とこんな具合だったかと．
>
> 以上，よろしくお願いします．
>
> (12/01/30 14:15), 高橋和浩@nifty wrote:
> > 斎藤様 MLの皆様
> > アライブビジョンソフトウエアの高橋です。
> >
> > 2点確認させてください。
> >
> > 1.ユーザ責任以外にスタックサイズ計算があり得るのか？
> >> これでは全体のスタックの必要量をユーザ責任で計算しなければならないなど
> >> 何かとメンドウですよね．
> > 何がどう面倒なのかもわかりませんし、ユーザ責任以外でスタックサイズの算出ができるとも想像がつきません。
> > どのような仕組みなのでしょうか？
> >
> > 2.TOPPERSの会員内のレビューで議題にあがっいなかったのでしょうか？
> > なにか思惑があって、現状の仕様になっているかと思いますが、どのような思惑でこのような設計をしたのでしょうか？
> > その辺を説明いただけないでしょうか？ また、これはTOPPERSの会員内のレビューで議題にあがらなかったのでしょうか？
> > あがったのであればその結論についても興味があります。
> > それでしたら、会員になってくださいは無で、開示可能な範囲でお答え願えないでしょうか？
> >
> > よろしくお願いします。
> >
> >
> >
> > On Mon, 30 Jan 2012 12:56:52 +0900
> > Naoki Saito<nsaito.nmiri ＠ gmail.com> wrote:
> >
> >> こいさんさん
> >>
> >> 斉藤です．
> >> ありがとうございます．
> >>
> >>> 私の意見は、従来と同じようにスタックサイズはCRE_TSKに書けばCFGが処理し
> >>> てくれることを望んでいます。CRE_TSKとDEF_ICSでスタックサイズを算出される
> >>> のがマート(?)だし、従来の考え方が継続できると思います。
> >>
> >> はい．そうですよね．．．
> >>
> >> 現状の実装においては，CRE_TSK の設定値は DEF_ICS の設定値が
> >> 足りないことをチェックするためにしか使われていません．
> >> これでは全体のスタックの必要量をユーザ責任で計算しなければならないなど
> >> 何かとメンドウですよね．
> >>
> >> CRE_TSK で指定したサイズが最終的なスタックサイズに反映される方が
> >> 使いやすいかもしれませんね．
> >>
> >> ご意見ありがとうございました．
> >>
> >> (12/01/30 11:27), koizumi yoshiyuki wrote:
> >>> 斉藤さん
> >>> 私の意見は、従来と同じようにスタックサイズはCRE_TSKに書けばCFGが処理し
> >>> てくれることを望んでいます。CRE_TSKとDEF_ICSでスタックサイズを算出される
> >>> のがマート(?)だし、従来の考え方が継続できると思います。
> >>> こうして於いて、スタックの共用を説明するのが分かり易いと思っています。
> >>> Cortex-MではタスクのスタックをPSP、DEF_ICSをMSPに割り当てる実装もある
> >>> でしょう。
> >>> 以上
> >>>
> >>> 2012年1月30日10:58 Naoki Saito<nsaito.nmiri ＠ gmail.com
> >>> <mailto:nsaito.nmiri ＠ gmail.com>>:
> >>>
> >>> こいさんさん
> >>>
> >>> 斉藤です．
> >>> お答え出来そうなものだけ回答致します．
> >>>
> >>> > Sample1の場合スタックサイズはDEF_ ICS＋各タスク割り当てたスタッ
> >>> クの合
> >>> > 計(INIT_TASK、MAIN_TASK、TASK1 ,TASK2)になると思っていましたが、
> >>> 即値で記
> >>> > 述されているようです。TASK3のスタックはTASK2と共用する。
> >>>
> >>> この点については．．．
> >>>
> >>> SSPでは一つのスタック領域を全ての処理単位で共用しますので，
> >>> そのサイズをどのように算出するかが問題となりました．
> >>>
> >>> 仕様検討時の候補としては2通りありました．
> >>> １．CRE_TSK の設定値をもとにタスクの最大使用量を見積り，それに
> >>> DEF_ICS の設定値を加えたものを全体のスタックサイズとする．
> >>>
> >>> ２．DEF_ICS は本来でならば非タスクコンテキスト用のスタック領域を
> >>> 指定する静的APIであるが，SSPに限っては「共有スタック領域」を
> >>> 指定するための静的APIとして使うことにする．
> >>> つまり，DEF_ICS にはタスク分と非タスク分の両方を合わせた値を
> >>> 指定し，その値が全体のスタックサイズとしてそのまま使われる．
> >>>
> >>> 結果として，第２案になりました．CRE_TSK を変更しても
> >>> 結果のスタックサイズは変更されないことになります．
> >>>
> >>> というのが現状なのですが，どのようにお感じになりますでしょうか？
> >>>
> >>> > 又、INTHDR_ENTRYの展開がASPとは異なっています(prc_config.h)、
> >>> > LOG_ISR_ENTER()がSSPでは無くなっていますが、従来と同じ作りで良い
> >>> ような気
> >>> > がしています。変わった理由がありましたら、お教え願いたいと思って
> >>> います。
> >>>
> >>> この点につきましては，当方のミスです．
> >>> 次期リリース版では出力するように致します．
> >>>
> >>> 以上，よろしくお願い致します．
> >>>
> >>>
> >>> (12/01/30 10:15), koizumi yoshiyuki wrote:
> >>> > こいさんです
> >>> > SSPのスタックの記述について疑問があります。というか、CFGでの
> >>> サービスが
> >>> > 欲しいと思っています。
> >>> >
> >>> > 公開されている資料とASPを使って見ての経験かするとSSPのsample1の
> >>> スタッ
> >>> > クは*.cfgで記述するCRE_TSKとDEF_ ICSからcfg.exeがkernel_cfg.cに自
> >>> 動生成
> >>> > してくれると思っていましたが、ssp-1.1.0.tar.gzではそのように作ら
> >>> れていな
> >>> > いようです。
> >>> >
> >>> > DEF_ ICSは記述は有りませんし。CRE_TSKのスタックサイズを変更しても
> >>> > kernel_cfg.c、マップファイル共変化がありませんでした。
> >>> >
> >>> > Sample1の場合スタックサイズはDEF_ ICS＋各タスク割り当てたスタッ
> >>> クの合
> >>> > 計(INIT_TASK、MAIN_TASK、TASK1 ,TASK2)になると思っていましたが、
> >>> 即値で記
> >>> > 述されているようです。TASK3のスタックはTASK2と共用する。
> >>> >
> >>> > 又、sample1のスタックサイズはtarget\cq_starm_gcc\target_test.h
> >>> > の#define STACK_SIZE (128)が使われていますが、target_test.h では無く
> >>> > sample1.hで指定すべきものだと思っています。
> >>> >
> >>> > 別件です。
> >>> >
> >>> > 又、INTHDR_ENTRYの展開がASPとは異なっています(prc_config.h)、
> >>> > LOG_ISR_ENTER()がSSPでは無くなっていますが、従来と同じ作りで良い
> >>> ような気
> >>> > がしています。変わった理由がありましたら、お教え願いたいと思って
> >>> います。
> >>> >
> >>> > どのような経緯でこのようになったのでしょうか。
> >>> >
> >>> > 以上
> >>>
> >>>
> >>
>