(toppers-users 3645) Re: タスクを生成するだけでE_CTX

[Masaki Muranaka]

斉藤さん，みなさま:
こんにちは．

> その場合，割り当てアドレスを明示的に指定する必要はありますが．

確かにこれは新たなバグを産みそうですね．

そこで，対策案です．
非タスクコンテキスト用スタックのための配列定義を kernel_cfg.c に出す
というオプションを cfg に加えるという機能追加を提案したいと思います．
(新世代カーネル同様に静的API にすると，μITRON仕様からの拡張に
なってしまいますので)

メモリのアクセススピードなどで特定のアドレスに置きたいなどいう
ターゲット固有の要求までは救いきれないかもしれませんけれども，
なるべく救いたいところです．

で，試験実装しました．jsp_parse.cpp をちょっと hack しただけです．
手元の kernel_cfg.c の出力(抜粋)はこんな感じです．
▼
/* Interrupt context stack */
#ifndef  TOPPERS_ICS_DEFINE_PREFIX1__
# define TOPPERS_ICS_DEFINE_PREFIX1__
#endif
#ifndef  TOPPERS_ICS_DEFINE_PREFIX2__
# define TOPPERS_ICS_DEFINE_PREFIX2__
#endif
#ifndef  TOPPERS_ICS_DEFINE_SUFFIX__
# define TOPPERS_ICS_DEFINE_SUFFIX__
#endif
TOPPERS_ICS_DEFINE_PREFIX1__
char TOPPERS_ICS_DEFINE_PREFIX2__
__toppers_stack_interrupt_context[500]
TOPPERS_ICS_DEFINE_SUFFIX__ ;
▲

スタックサイズは，C言語側で参照することは無いと判断して，
ケアしていません．sys_config.h や sys/Makefile.config 辺りで
決め打つことを想定しています．

pragma 使う処理系，独自拡張を使う処理系のいずれにも
対応しているつもりなのですが，このコードでは救えない処理系に
心当たりがありましたらご教示下さい．
(なんとなく suffix 側も  prefix 同様に 1 と 2 に分けたほうが良いような
気もしているのですが，冗長かどうかが判断付かずにいます)

あと，型が char で良いかどうかもご意見があれば頂きたいと思います．
なんとなく，ABIが要求するアラインを守れないケースもあるのかなとも思ったりもしています．
(その場合，タスクコンテキストスタックの定義についても再考の余地有りかもしれません)


2011年10月18日13:25 Saito Naoki <saito.naoki ＠ nmiri.city.nagoya.jp>:
> もなかさん，みなさま
>
> 斉藤です．
> お返事が遅れてしまいました．
>
> NCの場合でも非タスクコンテキストのスタック用として
> セクションを定義してやれば，セクションのオーバーラップ時の
> 異常を検出することはできると思います．
> その場合，割り当てアドレスを明示的に指定する必要はありますが．
>
> 以上です．