【TOPPERS】ITRON総合スレ3【NORTi】【HOS】

**Be名無しさん** · 2008/06/19(木) 00:25:31

★ TOPPERS
http://www.toppers.jp/

★ NORTi
http://www.mispo.co.jp/

★ HOS
http://sourceforge.jp/projects/hos/

前スレ
【TOPPERS】ITRON総合スレ2【NORTi】【HOS】
http://pc11.2ch.net/test/read.cgi/os/1077188504/

**ITRON名無しさん** ◆4WD27e3i1o · 2010/11/25(木) 14:34:12

>>626
http://www.assoc.tron.org/spec/itron/itron403/mitron-40303j.pdf
の284ページ[補足説明]あたりを読むと良いと思うよ．
def_inh は複数ハンドラを同時には登録できないよね．
レベルトリガで割込み線を共有しているようなターゲット，isrのほうが便利かもね．

仕様策定時，既存のカーネルにinhとisrの2派があって纏め切れなくて…
って裏話を聞いたような気もするから >>627 のように理解してもOKかもね．

**Be名無しさん** · 2011/01/03(月) 12:04:31

TOPPERS Builder キタコレ

**Be名無しさん** · 2011/01/09(日) 15:55:36

ITRONではない独自OSだけどKOZOSってどう？
http://www.saturn.dti.ne.jp/~hsakai/kozos/osbook_03.html

**Be名無しさん** · 2011/01/09(日) 21:46:22

割り込みで切り替えてるから、まともな方では？

**Be名無しさん** · 2011/02/07(月) 20:08:30

12個のタスクをsta_tskすると、15秒に1回程度acre_isrで
生成した定期割り込みサービスルーチンが遅延してしまいます。
sta_tskを11個に減らすと問題ありません。
すべてのタスクが同じ優先度3で動いています。
なぜこのような現象が起きるのかわかりません。
回避方法があれば教えてください。

**Be名無しさん** · 2011/02/07(月) 21:21:19

同時に動かそうとしてるからでしょ。
動く必要がないtaskは、wait状態にするんじゃないの？

**Be名無しさん** · 2011/02/07(月) 22:19:38

>632
どの程度を遅延すると言っているのかにもよるけど、
なんとなくカーネルのバグのにおいがします。
下手な実装のITRONでも、スタートタスクで多くの時間はかからないから。
理由は、タスクキューは優先度別に分けられている場合がほとんどで
FIFOでTCBを並べればいいから、割り込みに影響が受けるほど処理時間は
かからないと思うから。

**Be名無しさん** · 2011/04/24(日) 17:55:25.21

(･∀･≡･∀･) ﾀﾞﾚﾓｲﾅｲ

**Be名無しさん** · 2011/05/05(木) 13:43:25.48

･｡･ﾟ･(ﾉД`)･ﾟ･｡･

**Be名無しさん** · 2011/06/07(火) 01:10:10.79

ほ

**ITRON名無しさん** ◆4WD27e3i1o · 2011/06/29(水) 14:43:56.67

>>632-634
それらのタスクの中で loc_cpu が呼ばれていたとすると，12個だとダメで11個ならOKという現象は作れるかもしれないね．

**Be名無しさん** · 2011/06/29(水) 15:45:47.37

この手ので長期の割禁なんかするほうがおかしいでしょ

**ITRON名無しさん** ◆4WD27e3i1o · 2011/06/29(水) 16:57:55.81

>>639
割り込み禁止が短かったとしても，"定期割り込み"の周期が短ければ起こせちゃうかもよ．
絶対時間でなく，相対時間で考えないといけないのではないかな．
もう少し可能性の話を続けるならば，サービスコール中は原則割り込み禁止だから，loc_cpu を使わなくても現象は起きるかもしれないね．

**634** · 2011/06/30(木) 10:12:55.69

>640 さんは　わかっているし、その通りなんだけど、たぶん、ここの住民には理解できないように思う。
自分も少し勘違いしてたと思うけど、sta_tskしたときじゃなくて、sta_tskした後、割り込みが遅延することがあるということ
なんだと思う。
平たく言えば、ITRONカーネルそのものも割り込みのオーバーヘッドがあるので、割り込みが遅延するのは当然の話です。
だからどの程度の遅延を起こしていて、遅延したと言っているかによる。
TOPPERSの実装および、Nortiもそうだけど、最大割り込み禁止時間は思ったより大きいですよ。

**Be名無しさん** · 2011/06/30(木) 16:53:46.25

まだ、悩んでたんだ

**Be名無しさん** · 2011/06/30(木) 18:19:30.19

割り込みが禁止だったんだろw

**ITRON名無しさん** ◆4WD27e3i1o · 2011/06/30(木) 22:52:14.16

>>641
sta_tsk の時かもしれないよ．そうじゃないのかもしれないけれどね．
sta_tsk も割込み禁止時間が延びがちなサービスコールだから．
キューの長さで実行時間が変わるサービスコールを使っていたりすると，
タスクの数が要因になることもあるかもね．(フルセット仕様のイベントフラグのように)

**ITRON名無しさん** ◆4WD27e3i1o · 2011/06/30(木) 22:54:20.07

>>643 loc_cpu が入っていましたというほうが，ありがちな気はするね．

>>642 「プロバイダ規制ってのがあってね…．」書こうとしたらまた規制食らってたよ．orz

**Be名無しさん** · 2011/07/01(金) 16:34:15.77

TOPPERSは構造体の定義が？な所があるから、下回りの要の部分がなんだかなって感じになってるからな

**641** · 2011/07/01(金) 21:37:25.80

>644
間違ってはいないけど、誤解する書き方されていますね。
1.sta_tskはキューの長さによって実行時間の変わるサービスコールではない。
2.キューの長さによって実行時間の変わるものは優先度待ちのサービスコールすべて
3.TOPPERS Nortiに限ると　実行時間==最大割り込み禁止時間
だけど、半導体メーカー純正は、　実行時間　> 最大割り込み禁止時間　になってる
　ものが多い。

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/02(土) 16:46:43.16

>>647 の1.は，>>644の上二行と下二行の間に空行を入れろって話かな．
2. は，全てをカバーできていないのではないかな． flg で TA_WMUL がある場合もキューの長さに依存するね．
3. は，TOPPERSやNORTiでも実行時間 > 最大割り込み禁止時間ではないかな．割り込み禁止が係るのは，サービスコールのエントリポイントの内側だよね．

てな感じで， >>641 でさえ誤解しない書き方をするのはとても難しいことなので，少しくらい大目に見てほしいな．

**423** · 2011/07/02(土) 17:14:27.91

>>647
1についてはその通り、関連のないことを書いてるからね
2については特殊なケースのみと勘違いされるので多くの一般的条件を書いたまで
3はエントリーの内だそとだという些細なことじゃないよ。
例えば優先度待ちでタスクが100個待っていた場合100回ループするけど
その間割り込みをあけるあけないの違いがある

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/02(土) 18:35:24.25

判っている人同士で，細かい足の取り合いしてもつまらないね．ごめんね．

**423** · 2011/07/02(土) 22:20:06.20

>>650
実際には特殊なことさえしなければ大丈夫ということを書かれているので
比較的やんわり書くとあげあしとりみたいかもね。

3について、つまり割り込み応答性能はtoppers やnorti は手をぬいているよ。ってことです。
それがわかっていないとエントリーの内側だとか言う
ほとんど意味のない理由をづけになるんじゃないかな

**Be名無しさん** · 2011/07/02(土) 22:25:59.68

>>651
名前が423だけどこのスレの番号じゃなかったです。失礼

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/03(日) 07:57:07.23

JSPカーネルはμITRON仕様のスタンダードプロファイルでサービスコールの不可分性を保証することが求められているので，サービスコール中でカーネル管理の割り込みを開けられないよ．
TOPPERSもFI4カーネルで一部，サービスコール内で割り込み開けたりしていた時期もあったのだけれど，検定仕様書に基づくテストが通らなくなるなどあって戻したりしてるよ．

つまりは，"サービスコールの不可分性"とのトレードオフだよ．ってことです．
それが判っていないと手抜きだとか言う
粗暴な理由付けになるんじゃないかな

**Be名無しさん** · 2011/07/03(日) 08:41:17.55

>653
なんだ、ある程度わかっている人みたいですね。　そう　サービスコールの不可分性の保証の話ですよ。
ただ勘違いしていると思えるのは、サービスコールの不可分性の保証は、かならず処理の前後関係まで保証
しないといけない規定ではないし、実装定義として一部のケースで可分性を認めてもよいという取り決め
になっているわけですよ。
例えば優先度のwaitキュー検索に関して言えば、割り込みを空けることがあっても不可分性は保証される
よ。だからトレードオフということはない。　確かに複数待ちイベントフラグのiset_flgとiclr_flgにおいては
保証できないケースがある。ただ、この場合に限り貴殿の言う割り込み応答性と不可分性の保証のトレード
オフにはなるけど、特殊なケースで、問題にならないと思う。それよりもTOPPERSで優先度待ちキュー検索で
割り込みを空けなかったのはテスト量が増えるからしなかったというのが真相らしいので、これを手抜き
というのは「粗暴な」ではなく真っ当な理由ですよ。
実際には、割り込みを空ける手法はマルチプロセッサ対応のSMPカーネルで実装されている。もちろん不可分性
も保証されているよ。先ほどの前後関係が変わる動きになる。これが実装上必須なのでやっていて、
この対応のためにテスト手法を工夫されているのも事実。だからASPやJSPでもテスト手法を工夫すればできる
話なんだな。やっぱ手抜きですよ。

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/03(日) 21:53:00.08

>>654 技術的/仕様的な点でツッコミどころ満載な長文をありがとう．
でもごめん，それらはとりあえず脇においておくよ．揚げ足の取り合いの前に，確かめておきたい大事なことが一つある．
段落分けずに書いたってことは，SMPカーネルっていうのはTOPPERS/SMPカーネルを指すわけだよね．
ならば君は「TOPPERS開発成果物の知的財産権に関する規則」もしくは，どこかの会社と結んでいるはずのNDAに抵触してる可能性があると，ぼくは思う．
もし君が当時学生だとしたら，その管理責任を君の所属研究室が追うことになるだろう．君はどう思う?

**Be名無しさん** · 2011/07/03(日) 22:18:08.90

あちゃー

**Be名無しさん** · 2011/07/03(日) 23:22:58.31

NDAがどうしたって？

**Be名無しさん** · 2011/07/04(月) 00:54:02.95

SMPの仕様は一般公開されて無いみたいね
会員は見れるのかな？
会員しか知りえない情報を漏らしたらまずい気がする

**Be名無しさん** · 2011/07/04(月) 01:26:47.14

>思う
>気がする
この手の話題に...

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/04(月) 10:19:45.74

>>659
条件分けしてみようか．

まず，TOPPERS/SMPカーネル仕様の disclosure level は概ね3層に大別できる．
a. 学会発表やカンファレンスなどで公知となっているもの．
b. 早期リリースでTOPPERS会員のみ読めるもの．
c. TOPPERS会員でも読めないもの．

実は c. が存在するかどうかは，ぼくは知らない．なのに c. を仮定するのには理由がある．早期リリースで読めるのは，仕様"案"だからだよ．
("案"であることは， ttps://www.toppers.jp/members.html#early に書いてある公知な事実だよ．)
>>654 で，TOPPERS/SMPカーネルが仕様として成立しているように書いているのがブラフでなければ， c. は存在する可能性が高い．
c. の権利者は名古屋大学もしくはセイコーエプソンかな．少なくとも片方ががその仕様を進んでダダ漏れさせているなら >>654 はシロ．そうでなければクロだね．
(ダダ漏れがあったとして，その経緯次第では，上記組織の信頼性に関わるかもしれないけれど．それはとりあえず横に置いておこう)

b. の内容を，ぼくは知っている．でもそれに沿っての揚げ足とりは，ぼくには続けられない．知財約款を反故にするほどヤンチャじゃないよ．このケースでも >>654 はクロ．

最後に >>654 が a. の情報のみで話を組み立てている場合には，シロとなるね．
ただし，サービスコールの不可分性を云々できるほどの詳細な発表は，ぼくは知らない(世の中にはあるのかもしれない)．

現時点では黒白どちらの可能性もあるんだよね．
だから「可能性があると，ぼくは思う．」と書いたんだよ．

>>654 には，白黒がはっきりと判るよう，情報のソースを説明して欲しいな．

**Be名無しさん** · 2011/07/04(月) 12:46:35.58

>割り込みを空ける手法
この部分かな
誰？でも思いつきそうな

**Be名無しさん** · 2011/07/04(月) 12:57:33.57

思いつくのはいいけど
それがSMPに実装されて実現しているという情報が
一般に公開されているかどうかじゃないの？

**Be名無しさん** · 2011/07/04(月) 13:12:11.38

妙な縛り入れるところとは付き合わないほうがいいのかな
何かあると、あとでグダグダ言い出しそうだな

**ITRON名無しさん** ◆4WD27e3i1o · 2011/07/04(月) 22:13:06.00

>>662 知財縛りで書けないことを省くと，ざっくり，そういうことだよね．

**654** · 2011/08/11(木) 18:07:24.91

一応誤解を与えたということで、すまんかった。あやまっておく。
ここはスレタイにもあるように用語はTOPPERSの特有の用語で
書くのが基本であり、
「マルチプロセッサ対応のSMPカーネル」
と書けば、TOPPERS/SMPのことと理解されるのに違いないこと
ですね。
自分の見たソースはTOPPERS/FMPのことで、FMPとは一般用語では
ないので、上記の記載にした。
FMPはAMP型でSMP型じゃないよ。という突っ込みがあるかもしれ
ないが、AMPだSMPだというのはあまり一般的じゃないのでそう
書いた次第だ。

**Be名無しさん** · 2011/08/11(木) 19:16:24.70

衒学脳の厨っぷりを堪能した。

**654** · 2011/08/11(木) 23:31:02.90

突っ込みどころ満載とか言っていたけど、さらに追加かもしれないが、具体的に書こう。
TOPPERS/FMP1.2 のソース　wai_flgの部分だ。
wobj_make_wait();
について、t_acquire_nested_tsk_lock_self()のように、割り込みがあったら戻り値をNULLにして
retryに飛んだらよい。　ということなんだけどな。
つまりwaitQue検索時に適当な割合で割り込み許可と割り込み有無チェックをいれるわけだな。

eventflg.c のline:350～line:371
retry:
t_acquire_obj_lock(&GET_OBJLOCK(p_flgcb));
if ((p_flgcb->p_flginib->flgatr & TA_WMUL) == 0U
&& !queue_empty(&(p_flgcb->wait_queue))) {
release_obj_lock(&GET_OBJLOCK(p_flgcb));
ercd = E_ILUSE;
}
else if (check_flg_cond(p_flgcb, waiptn, wfmode, p_flgptn)) {
release_obj_lock(&GET_OBJLOCK(p_flgcb));
ercd = E_OK;
}
else {
if ((my_p_pcb = t_acquire_nested_tsk_lock_self(&GET_OBJLOCK(p_flgcb))) == NULL){
goto retry;
}
p_runtsk = my_p_pcb->p_runtsk;
p_winfo_flg = (WINFO_FLG *)(&(p_runtsk->winfo_obj));
p_winfo_flg->waiptn = waiptn;
p_winfo_flg->wfmode = wfmode;
p_runtsk->tstat = (TS_WAITING | TS_WAIT_FLG);
wobj_make_wait((WOBJCB *) p_flgcb, p_runtsk);
release_nested_tsk_lock(my_p_pcb);

**Be名無しさん** · 2011/08/12(金) 07:11:50.24

SSPまだー

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/16(火) 23:14:53.08

>>665, >>667
突っ込みどころ満載すぎて引用できないよ…．ごめんね．

**667** · 2011/08/17(水) 15:07:31.79

>669
夏休みモードなんかな(自分はそうだけど）

2.1 実装方針とモデル
サービスコールの大部分を一つの割込み禁止区間として実
装している

TOPPERS/JSP --->
スタンダードプロファイルの機能セットの範囲内では，この方法でもそれほど
悪い結果にはならない．(user.txt)

ところが
TOPPERS/FI4 ---> 同じ文面（動的生成のみ追記されている）(fi4_user.txt)

フルセットなのにスタンダードプロファイルでは、ってちょっとまじめに考えているのかと....

名古屋大でのカーネル内部構造の講義において
TOPPERS/JSP
「割り込み許可にしなかったのはテストの時間がかかりリリースの時期にマッチ
しないと判断したことがある」

--->
TOPPERS/FMP -->スピンロックにおいて割り込み応答性のため、
割り込み許可するロジックを実装。

テストの問題は?
---> TTSPによって、割り込みを起こすテストを網羅することも比較的容易にテスト可能になった。

それだったら、TOPPERS/JSPやASPでも、TTSPを利用することで割り込み許可するべきじゃないのか？
と思うけど、ニーズがないというか性能評価までして使うユーザーがいないということなのかな

**Be名無しさん** · 2011/08/17(水) 16:33:08.83

>ここはスレタイにもあるように用語はTOPPERSの特有の用語で
>書くのが基本であり、
>「マルチプロセッサ対応のSMPカーネル」
>と書けば、TOPPERS/SMPのことと理解されるのに違いないこと
>ですね。
ダウト
スレタイよく嫁よ
メインは「ITRON総合スレ」だろ
スレタイにTOPPERSが含まれているがNORTi、HOSも書かれている

あんたの言葉を借りると「スレタイにもあるように」
複数のOSが書かれているので
>用語はTOPPERSの特有の用語
とは限らない

あとテンプレにはT-Kernelもあるので
必ずしもSMP=TOPPERS/SMPとは限らない
話の流れ的にTOPPERSを指してると言えるけどね

あと、FMPは一般用語じゃないと言ってるが
仮にそうだとしても検索すれば意味ぐらいすぐわかるだろ

**667** · 2011/08/17(水) 17:38:01.91

>>971
>>「マルチプロセッサ対応のSMPカーネル」
>と書けば、TOPPERS/SMPのことと理解されるのに違いないこと
>>ですね。
>ダウト

じゃあ、それとは限らないという意見なので、誤解されてもしかたないことでもない
ということなんかな。
まぁ誤解を与えたわけだし、あやまってるし、そうでもないよといわれてもどっちでもいいことなんだけどな

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/20(土) 23:27:27.64

>>665
> AMPだSMPだというのはあまり一般的じゃないのでそう書いた次第だ。

マルチプロセッサの文脈で両者を混同すると，たぶん学部生でも単位もらえないと思うのだけれど，最近は違うのかな．
TOPPERSかどうかではあまり関係なくて．
T-Kernelには興味ないのでろくに追いかけていないけれど，彼らもAMPかSMPかはきちんと分けているよね．
謝ってくれる必要はないけれど，用語はきちんと使いましょうよとは思うよ．

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/20(土) 23:35:08.47

>>670
> 「割り込み許可にしなかったのはテストの時間がかかりリリースの時期にマッチ
> しないと判断したことがある」

これホントかなと言うのが直感．いや誰か(高田センセ?)が言ったと信じてみたとしても．
JSP1.0のリリース時点で，テストスイートなんてなかったよ．
最初のテストスイートができたのは，FI4と同じ時期． IPA案件の成果だから間違いないよ．
2000年当時からかなり長い間，割り込み禁止が長いのは「読みやすさを優先した」ということになっていたんだよね．

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/20(土) 23:45:20.50

別段の守秘がある話でもないから過去振り返っちゃおう．
公開前のFI4カーネルって，割と割り込み開けてたんだよ．
けれども，それやっちゃうとトロン協会の検証仕様書(案)のテストケースが通らなくなっちゃうんだよね．
で，テストスイートがオカシイのかカーネルがオカシイのか判らんという話になって，結局戻したんだよ．
FI4のソースコードを見ると，特にIDのチェックの辺で「なんでこんな変な処理?」っていうのが時々残っているかもしれないけれど，それはその残骸．

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/21(日) 00:17:10.68

>>667
で，割と本質なFMPでの実装の話だっけね．
これは別にJSP/ASPの割込み禁止区間を問題視して割込みを開けているわけではないよね．
プロセッサ内排他に比べてプロセッサ間排他の時間があまりにも読めないので，仕方なく開けているのではないかな．
もし，JSP/ASPの割込み禁止区間の長さがこの実装の理由なら，whileループでぐるぐる回る[i]set_flg のほうは更に頑張るはずだよね．(あとはソースコード読みなおしてみて)

**Be名無しさん** · 2011/08/21(日) 19:51:36.68

>>674
>これホントかなと言うのが直感．いや誰か(高田センセ?)が言ったと信じてみたとしても．
直感を何度もはずしているのに懲りないですね。

>JSP1.0のリリース時点で，テストスイートなんてなかったよ．
あくまで後からTTSPができたと書いているのに誤解しないでほしいものです。「テスト可能になった。」と順番に書いてるよね。
そうです。そのとき無かったからできないのは理解しているつもり。
今テストスイートがあるなら、やってみるべきだし、割り込み空けない理由がなくなった時点
で対処すべきことだと思う。

>2000年当時からかなり長い間，割り込み禁止が長いのは「読みやすさを優先した」ということになっていたんだよね．
理由はひとつではないとは思うけどね。また高田先生の思っていることがプロジェクトの総意でもないかもしれない。
表向きには、やはりドキュメントに書かれてあるとおり、それほど問題にならないから　ということだと思うけどね。(JSPにおいては）
ただ、当初JSPにおいては、コードが仕様書の延長ともいえるので、「読みやすさ優先」という理由にはなるけど、
ASP以降はμITRONの仕様にとらわれない決定版という方針からするとおのずと「読みやすさのため」という理由は無い話ですよ。

**Be名無しさん** · 2011/08/21(日) 19:54:14.23

>676
なんだかなぁ、君の言うとおりのことを指摘しているんだけど。どうも言葉が伝わらないな。
そうですよ。　スピンロックは必然。　waitQの待ちは有限時間なので必然ではない。
だから、WaitQの待ちでも有限時間だけども、STDPROFよりも大きいものは問題なので
対応したいが、テストがかかるため天秤にかけた結果WaitQの待ちは見送った。
見送った理由は、開発期間、時間的な理由もちゃんとした理由としてできない理由としてそれは
それでそのときの判断としては正しいと思うよ。
一方、スピンロックは必然的に割り込みを空けなくてはならなくなった。
必要は発明の母という言葉があるようにそれでようやくTTSPを作ったわけ。
必要であれば作れたってことは、FMPの開発時で、waitQの問題に対処できるわけなんだな。
これも実は開発者自身に直接聞いて回答いただいている。
「WaitQの割り込みをあけることも可能だが、性能的に問題にならないので対応していない」
という回答。まぁさらに聞きたかったけど、あまりにその講義の範囲を超える話に
なりそうなのでそれまでしか聞かなかった（聞けなかった）です。

>whileループでぐるぐる回る[i]set_flg のほうは更に頑張るはずだよね．
>(あとはソースコード読みなおしてみて)
[i]set_flgを見ているからわざと、wai_flgを引用しているんだけどな。
ただこれはドキュメントに書いてある。
---------------------------------------------
ASPカーネルでは，以下のシステムコールは待ち解除されるタスクの数に比例
して長くなる．
・init_xxx
・イベントフラグ set_flg()
FMPカーネルでは，ロックを取得する関係ため，実行時間の上限が定まらない．
------------------------------------------------
ちょっとこれってお粗末じゃないのと正直思うけどね。

**Be名無しさん** · 2011/08/21(日) 19:56:05.48

>675
以前も同じこと書いていたよね。
JSPやFI4はμITRON4.0準拠なのでそうかもしれないけど
ASP以降においてはμITRONの仕様を超えて決定版を作るという話だから
その枠にはめる必要は今の時点ではないと思う。

くだらない話をすれば、FI4において、トロン協会の検証仕様書(案)に準拠
しないために割り込み空けるのやまたのならその旨を正直にドキュメント
に書いておくべきじゃないのかと思うけどね。
そうあるべきなのに、フルセットなのにスタンダードファイルではとか
おかしなドキュメントのままというのが今の状態ですね。

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/21(日) 22:57:45.82

まずは，過去についての話．

>>677
え? だって
> TOPPERS/JSP
> 「割り込み許可にしなかったのはテストの時間がかかり

っていった時点のTOPPERS/JSPのコーディング時点ではTTSPなんて無いよね．
TTSPができた時点で，NCESは既にJSPなんか興味持ってないよ．(ちょっと言い過ぎかな)
時系列で並べると，JSPについていえば，TTSPとかテストスイートとかにかかわらずああいう実装になっているはずなのだけれど．
歴史語るなら時系列をキチンとしようよ．未来からなら何でも言えるよね．
もしASPの話に限るなら，JSPの話を持ち出す必要なんて無いよね．過去のことなのだから．

>>679
fi4のドキュメントが貧弱なのはそのとおりw．
それは認めた上で，君の主張に沿って議論するならば，君の指摘も蛇足でしか無い気がするよ．
フルセットだから割込みを開けるべきということが自明なら別だけれどね．

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/21(日) 22:59:31.62

そして，新世代系の話題．
TOPPERSも10年だし，時系列を混同すると話がワケワカラなくなるよね．

>>678
> [i]set_flgを見ているからわざと、wai_flgを引用しているんだけどな。

えっと…
割り込み禁止区間が長いのがTOPPERSの手抜き→FMPのwai_flgみたいにすりゃいいのに，と主張して，同[i]set_flg は目をつぶるの?
主張がよくわからないよ．もうちょっと細かく説明してほしいな．

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/22(月) 01:26:39.25

ああそうか，>>679 と同一人物と思しきカキコを読みなおして判った気になったよ．
ASPは決定版だから，すべからくの箇所で頑張って割込み開けて当然って話なのかな．FMPの例とかはこじつけで．
(もしくはTTSPある今，JSPも変えろって話…の主張は取り下げたのかな?)
もしそうならば，割込み開けるのが決定版の条件であることを >>679 は示せばよいのではないかな．

極めて個人的にはだけれども，頑張って割込み開ける処理を入れるオーバヘッドをいれることで救われるアプリケーションよりも，そのオーバヘッドがウザいアプリのほうが多いのではという気がするよ．
「いやオレのアプリは違う」っていう意見が多ければ，いくら伽藍のTOPPERSでも考えを改めるだろうね．

**Be名無しさん** · 2011/08/22(月) 15:57:24.38

1,時系列云々について
>680
>歴史語るなら時系列をキチンとしようよ．未来からなら何でも言えるよね．
>もしASPの話に限るなら，JSPの話を持ち出す必要なんて無いよね．過去のことなのだから．

何度も書いているように、JSPでTTSPは無かったよ。それは異論は無いよ。
何度も書いているでしょ。

JSPの話を持ち出していることがおかしいという意見なら、その部分はJSPの実装から
変更されておらず、そのまま引きずっているよね。だから過去のことでは無いよ。

実際にJSPの内部構造で聞いた話だからJSPでと正確に書いているわけ。
JSPが過去のものというならWaitQの実装をASPにおいて過去のものにしてからの
話ですよ。

誤解しないようにわかりやすく書くよ
以下、時系列

WaitQの処理

1.JSP 理由　テストに時間がかかるから割り込みあけなかった
2.FI4 JSPと同じ実装じゃないとトロン協会の検証仕様書(案)が通らないので割り込みあけなかった
3.ASP JSPと同じにした。standerdプロファイルだしいいよね
4.FMP ASPと同じにした。standerdプロファイルよりも大きい仕様だけど
　　　　でも、ASPと同じ割り込みを開けなくても性能的に問題なかったのでそれでいいよね
　　　　割り込みをあけるテストはTTSPでできるようになった。

それなら、ベースとなるASPにおいても割り込みあける処理にすべきことだよ。

**Be名無しさん** · 2011/08/22(月) 16:02:29.89

>680
>君の指摘も蛇足でしか無い気がするよ．
どの部分がどう蛇足なんでしょうか？
「くだらない話」の部分のことを言っているのかな？

>フルセットだから割込みを開けるべきということが自明なら別だけれどね．
自明じゃないと思う理由は何？
μITRON4.0の仕様書のサービスコールの不可分性の保証に割り込み応答性の
ために云々書いていることと、JSPのドキュメントにおいて、スタンダードプロファイル
においてという枕詞を付けている点で自明だと思うけど、そうでないことを示す
公式ドキュメントなどあるのかな？

**Be名無しさん** · 2011/08/22(月) 16:08:58.06

>681
>割り込み禁止区間が長いのがTOPPERSの手抜き→FMPのwai_flgみたいにすりゃいいのに，と主張して，同[i]set_flg は目をつぶるの?
>主張がよくわからないよ．もうちょっと細かく説明してほしいな．
目をつぶっているわけじゃないけど、set_flg iclr_flgで不可分性の保証ができない
ケースがどうしてもあるから、話が君にとって難しいと思ったからわかりやすいほうを
例に挙げただけだよ。

set_flgの割り込みをあけた場合に、iset_flgには対応できるけど
iclr_flgには対応できないことがあることを君がわかるなら説明してもいいけどね。
説明できますか？

**Be名無しさん** · 2011/08/22(月) 16:17:35.21

>682
>極めて個人的にはだけれども，頑張って割込み開ける処理を入れるオーバヘッドをいれることで
>救われるアプリケーションよりも，そのオーバヘッドがウザいアプリのほうが多いのではという気
>がするよ．「いやオレのアプリは違う」っていう意見が多ければ，いくら伽藍のTOPPERSでも考えを改めるだろうね．

オーバーヘッド測ってから言えばいいこと。
自分の知る限りチップメーカー純正のITRONで割り込みをあけないものは無いはずだしね
是か非かというのは、もともとの議論のポイントではない。
ひょっとするとメーカーは必要のないことを一生懸命やっているのかもしれない。

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/08/22(月) 20:37:01.36

>>686
> オーバーヘッド測ってから言えばいいこと。

そっくり返すよ．

**686** · 2011/09/12(月) 10:04:36.92

>687
本業で、割り込みをあける場合のオーバーヘッドを測ってるからそういったんだよ。

**Be名無しさん** · 2011/09/13(火) 03:06:40.03

構造体の定義が頭壊れる方向にできてるから、割禁が長い、TOPPERS

**Be名無しさん** · 2011/09/13(火) 07:50:25.44

おまえの頭が壊れてるんだろ

**Be名無しさん** · 2011/09/13(火) 09:46:47.51

＞構造体の定義が頭壊れる方向
kwsk

**Be名無しさん** · 2011/09/13(火) 13:11:43.21

タスク切り替えの本体の汗読んでたら、おかしくなってこないか？
あのこねくり回した流れは何って感じだけど

**Be名無しさん** · 2011/09/13(火) 17:11:04.78

自分で書いてみりゃわかるが、ああいうのは
何度書きなおしてもきれいにならん

**Be名無しさん** · 2011/09/13(火) 17:14:36.13

＞構造体の定義が頭壊れる方向
と逝ってるでしょうが

**Be名無しさん** · 2011/09/13(火) 17:26:31.08

>692　タスク切り替えの本体の汗
ってディスパッチャのこと？　だとすればporting.txtからの引用だけど、なんのひねりもないけどな。タスク例外だけ少しひねりがあるぐらいだけどね。
void
dispatch(void)
{
改行が多いので省略
}
void
dispatcher(void)
{
#ifdef LOG_DSP_ENTER
log_dsp_enter(p_runtsk);
#endif /* LOG_DSP_ENTER */
dispatcher_0:
while ((p_runtsk = p_schedtsk) == NULL) {
割込みを許可したらCPUロック解除状態になるよう準備する
非タスクコンテキストに切り換える … (*1)
do {
割込みをすべて許可し，割込み発生を待つ … (*2)
割込み許可前の状態に戻す（＝カーネル管理の割込みを禁止する）
} while (!reqflg);
reqflg = false;
タスクコンテキストに戻す … (*1)
CPUロック状態に戻す ... (*3)
}
自タスク（p_runtsk）のTCBからスタックポインタを復帰する
#ifdef LOG_DSP_LEAVE
log_dsp_leave(p_runtsk);
#endif /* LOG_DSP_LEAVE */
自タスクのTCBから実行再開番地を復帰し，そこへ分岐する … (*a)
}

**Be名無しさん** · 2011/09/13(火) 17:29:53.11

HOSのスタックの切り替えは簡潔だった

**Be名無しさん** · 2011/09/13(火) 17:30:05.53

省略したもの
----------------------------------------
void
dispatch(void)
{
スクラッチレジスタを除くすべてのレジスタをスタックに保存する
スタックポインタを自タスク（p_runtsk）のTCBに保存する
dispatch_rを，実行再開番地として自タスクのTCBに保存する … (*a)
dispatcherに分岐する

dispatch_r:
スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
calltex(); … (*b)
}
----------------------------------------

**Be名無しさん** · 2011/09/13(火) 17:38:52.85

擬似コード書いて楽しいかい？

**697** · 2011/09/13(火) 19:09:57.76

>698
それを言うなら、TOPPERSのporting.txtを書いたやつに言えよ。俺はそれをコピペしただけ

**Be名無しさん** · 2011/09/13(火) 19:51:40.39

なんだかなって、擬似コードが出回ってるのかよ

**Be名無しさん** · 2011/09/13(火) 22:04:54.21

ディスパッチャの部分はアセンブリ言語だから、porting.txtはC風に書いて説明しているだけ。

**Be名無しさん** · 2011/09/13(火) 22:08:50.76

C風で中身がないと

**Be名無しさん** · 2011/09/14(水) 07:26:36.15

そうだね。中身がないほどひねりがないのに、おかしくなるっていうやつ >692 の頭はどうなっているんだろな。

**Be名無しさん** · 2011/09/14(水) 15:09:30.79

汗読める奴もいなくなってきたか

**Be名無しさん** · 2011/09/30(金) 11:51:20.26

ITRON懐かしすぎる
もう1年たったんだな

**Be名無しさん** · 2011/09/30(金) 15:31:43.07

?軽く 20年は経ってるだろww

**Be名無しさん** · 2011/09/30(金) 16:12:26.77

>>706
いや仕事で手がけてから
今はやってない

**Be名無しさん** · 2011/09/30(金) 18:03:36.49

TOPPERSプロジェクトの2011年公募事業(採択）が発表されましたね。
http://www.toppers.jp/puboffer.html

**Be名無しさん** · 2011/10/01(土) 16:31:00.43

え、今頃arm?

**Be名無しさん** · 2011/10/01(土) 20:00:47.08

gccじゃなくてrvctとかiar対応ってことじゃねーの？

**Be名無しさん** · 2011/10/01(土) 20:09:04.93

はあ、移植性のない作り方してましたっていいたいのかい

**Be名無しさん** · 2011/10/01(土) 22:33:11.12

OSなんてコンパイラの拡張機能使わなきゃきれいに書けない
インラインアセンブラの仕様だけでも規格になっていればねえ…

**Be名無しさん** · 2011/10/02(日) 02:37:26.97

>きれいに書けない
ってところが今更って感じ

**Be名無しさん** · 2011/10/02(日) 05:43:41.50

そこをアセンブラで書くモジュールと、機種非依存部に切り分けるのが、
現代のOS実装というものだと思うが。

**Be名無しさん** · 2011/10/02(日) 08:33:28.65

ルネサスのアセンブラとGASぐらいしか知らないけど、
GASって、Cのヘッダファイル読めるよね。　armのアセンブラもCのヘッダファイル読めるのかな？

**Be名無しさん** · 2011/10/02(日) 09:28:16.51

そういう妙な挙動に頼るより、Makefile で明示的に cpp か cc -E を使ってプリプロセスして
プリプロセス済みファイルを作って、それをアセンブラに食わせたほうがいいと思う。

**Be名無しさん** · 2011/10/02(日) 12:20:50.36

>>714
そう思うなら実際に試してみれ

>>715
gas単体じゃ読めないでよ
gccに.S食わせるとcppかけてからgasに結果を食わせてるだけだ

**715** · 2011/10/02(日) 16:52:54.43

訂正
GASって、Cのヘッダファイル読めるよね。　[GAS以外の]armのアセンブラもCのヘッダファイル読めるのかな？

>717
たしかにそうだけど、GCCやGAS環境以外のARMアセンブラでそれ（cppだけ食わして）ができるわけでもないでしょ。

**Be名無しさん** · 2011/10/03(月) 01:46:55.36

>>718
だから>>716みたいなことすればいいんでないかいという話なわけだが

**718** · 2011/10/03(月) 08:12:09.09

>719
できないかいじゃなくて、できるのか？　理屈じゃなくてやってうまくいったことがあるの？って聞いているわけ
できるなら、ヘッダファイルをCとアセンブラに分けて提供する必要なくなると思うから、現状できない
のじゃないかと思っているわけ。

**Be名無しさん** · 2011/10/03(月) 08:20:29.06

だから何がしたいわけ？

アセンブラにCのヘッダファイル食わせてなにがうれしいのかわからんから、
アセンブリ言語ソースをCプリプロセッサに通したいということだろうと思ったので、
アセンブラごとに違ったりしそうな仕様に依存したりするより、ポータブルな
方法使えば、ってアドバイスしたまでで。

できないのじゃないかと思っているなら、できないということにして、
別の方法を考えたら？　そこまで面倒見れんわ。

**720** · 2011/10/03(月) 10:50:49.61

>721
>なにがうれしいのかわからんから、

もともとのネタは、公募のARMコンパイラ対応について
の話からなんだけど、自分の考えでは、GASでは、Cのヘッダが
読めるけどarm（GAS以外)から読めないから結構面倒かな　と思ったわけ
です。

具体的にできるというなら、
具体的に聞くけど
基本的にマイコンが同じでもアセンブリ言語の文法は処理系（アセンブラー）によって
違うのはわかるよね。
たとえば　iarのcppだけ利用して、Cのヘッダファイルを利用したアセンブリ言語の
出力してiarのアセンブラに通るかどうかですね。

renesasのコンパイラはできないと思うし、できるようなら
toppers/jspなどで、アセンブリ言語のヘッダファイルは不要のはず。
h8s-renesas で　h8s2339f.inc h8s2339f.hとどちらかがいらないはずになります。

armは疎いので、その辺ひょっとしたらいけるのかなと思ったので聞いてみたわけです。
できれば、できたよという話があれば、と思いましたが。

ヘッダファイルを両方用意しないことが何がうれしいのかもわからないというのは
ちょっと自分とは感覚が違いますね

**元ITRON名無しさん** ◆4WD27e3i1o · 2011/10/03(月) 11:13:25.48

5～6年前に受託でJSPをRVCTに移植したけれど，ひたすら面倒だったよ．
既出だけれど，インラインアセンブラの書式は違う．そもそもアセンブラの書式も違ったよね．
それとリンカっていうか，リンカのスクリプトも違うよ．
簡単で地味で面倒ゆえに誰もやりたがらない作業だから，公募案件としては妥当じゃないかな．

**Be名無しさん** · 2011/10/03(月) 11:22:03.48

>723
ありがとう。　すっきりしました。
>　簡単で地味で面倒ゆえに誰もやりたがらない作業だから，公募案件としては妥当じゃないかな．
全く同意です。

**Be名無しさん** · 2011/10/03(月) 13:26:22.80

> ヘッダファイルを両方用意しないことが何がうれしいのかもわからないというのは
> ちょっと自分とは感覚が違いますね

アセンブラのプリプロセスに、C言語的な制限かかりまくりのCプリプロセッサと、
常識的に考えて、C言語のソースコードの共通部分をまとめたものである
ヘッダファイルを使う、というのは、普通でない使い方だと思いますが、
それを何の説明もなく他人が理解しているという前提の上で話されているわけですから、
全く違うのがあたりまえですね。

**Be名無しさん** · 2011/10/03(月) 13:50:00.34

>>725
#defineは共通にできる
つかそれしか使い道ない

**Be名無しさん** · 2011/10/03(月) 13:55:06.71

>725
できるだけやんわり書いたつもりだけど、角がたったようですね。せっかく回答くれているのにそれはすまなかった。
ただ、「何の説明もなく」というのは、文脈を理解できていないようだな。　この話題はあくまで、TOPPERSカーネルの
arm対応に関して、たとえばヘッダファイルを再利用できるかどうかという話で、それが理解できていなかったの
でしょうね。

>常識的に考えて、C言語のソースコードの共通部分をまとめたものである
>ヘッダファイルを使う、というのは、普通でない使い方だと思いますが、
誤解してたら、あやまるけど、具体的にはたとえば、TOPPERSのカーネルでgccのものは、アセンブリ
言語用のヘッダファイルは用意していなくて、貴殿の言う普通でない使い方にあたるという
ことなのかな？

たぶん、貴殿の常識とか普通とかがかなり違うようだし、TOPPERSのカーネルも貴殿の普通
でも無いということ言っているのかな？

**Be名無しさん** · 2011/10/03(月) 22:55:47.69

>>725
処理系の依存の問題だけど,
Unix 系の文化だと "#define ..." の定数は普通に共用してるわな
で, "#define ..." の定数部分だけアセンブラから読めるように工夫してる

例)
.S:
#define LOCORE
#include <xxx.h>

.h:
#define ...
#ifndef LOCORE
struct foo {
...
};
#endif /* LOCORE */
#define ...

アセンブラとCで定数２重管理ってアホらしいやない