(toppers-users 3831) Re: 8bit時代の手法

高橋和浩@nifty takahashi_kazuhiro ＠ nifty.com
2012年 1月 24日 (火) 11:27:17 JST
前の記事 (toppers-users 3830) Re: 8bit時代の手法
次の記事 (toppers-users 3825) 2つの優先度の有効な利用方法は？ 5.先取り方式の提案補足と訂正
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
宮川様

すいません、なにか話がかみ合っていないように思います。


> 要するにシーケンサみたいに定周期で起動され、その回の処理を済ませたら
> 次の起動までは動かない設計にします。
> 
> 超簡潔に言うと優先度グループは定周期の間隔が同じものって事です。
> そうしないと保証可能な時間設計が出来ません。

そうでなくても、保証可能な設計はできるのですが、
それともSSPではなく、貴殿の昔話に限った話ならそうだということおっしゃっているの
でしょうか？

厳密に貴殿の言う定周期で起動するディスパッチャを作ったという昔話の
ことなら、あまり興味がないですね。

そういう事例をSSPで動かせるのではないかという話かと思いましたが
そうでもないならそれ以上議論しても意味がないと思います。


以下の、たとえ話からすると、登山に有効な制限された
機材をもって臨めばいいというのはもっともな話ですが、

例えば、コンパスを磁石式のものじゃなくてソーラー電池式の
コンパスで現地で使い物にならないレベルの機能が実装されていると
思われるので、夜になったり、日光があたらなくなったらどうやって方角を
知ることができるか　という問いかけをしているのです。
これを制限を楽しむ気持ちで臨める人もいるかもしれませんが、
大抵の人は山で遭難するように思います。


> OSの進歩とはリソースの管理をしながら、いかにユーザーに自然な発想で
> プログラミングできるような環境を提供するか!って事ですから
> どんどん高機能に成りました。
> 
> それは、逆に言うとH/Wリソースの要求も高くなってきたという事です。
> 
> そして、それに慣れちゃいました。
> なので、制限付けられるとあれが出来ない、これで困ると感じます。
> 
> SSPみたいなものは、ソフトが使えるH/Wリソースが少ないという
> 制限の元で、何処まで機能を提供できるかという割り切りと、
> その少ない機能をどう活用したら効果があるのかという
> 発想力の勝負なのだと思います。
> 
> 例えばFPGAに小さなCPUを乗せて、マンマシンI/Fを管理しつつ、
> 組み込んだアクセラレータで高度な仕事をさせるなんて状況だと
> 有効そうに思えます。
> 
> 作成者のイメージしているターゲットが何なのかは知らないのですが ;-)
> 
> 全く別の話ですが、登山は似たような部分があります。
> 持てる範囲の装備と食料で如何に楽しむか、
> 危険予知と経験と発想力の合わせ技です。
> 
> 制限を楽しむ気持ちで見てみたら、また違った見え方が
> 見つかるのではないでしょうか?
> 
> その中で、何を変えたらもっと良くなるのか、ですね。
> これは大いに状況依存の問いだと思います。


On Tue, 24 Jan 2012 10:12:28 +0900
Miyagawa <miyagawa ＠ trail4you.com> wrote:

> おはようございます。
> 宮川@[ぷーたろう] です。
> 
> (2012/01/24 9:12), 高橋和浩@nifty wrote:
> > おはようございます。アライブビジョンソフトウエアの高橋です。
> > 
> > SSPでの2つの優先度の有効な事例ですね。
> > 
> >>   H_max < 1秒
> >>   H_max*60 + M_max < 1分
> >>  (H_max*60 + M_max)*10 + L_max < 10分
> > 
> > ということで、なるほどこれでSSPで動きそうに思いますが、たぶん一点問題が
> > あってそう上手くいかないと思います。
> > 理由は、全タスクが一回づつ動かないからです。
> > 例えば、Lグループのタスクが複数あるはずですが、L1 L2 L3があるとしたら
> > L1が起動優先度のLの中で最も高い場合としては、L1起動して処理が終わりタスク終了し、その後L2が
> > 起動して処理終了してタスク終了した場合、L1が起動された後、L2の終了までに
> > L1が再度起動されていた場合にL3ではなくL1が起動されてしまう場合があると考えるからです。
> 
> これは「設計として許さない」、と言うのが回答です。
> 
> 要するにシーケンサみたいに定周期で起動され、その回の処理を済ませたら
> 次の起動までは動かない設計にします。
> 
> 超簡潔に言うと優先度グループは定周期の間隔が同じものって事です。
> そうしないと保証可能な時間設計が出来ません。
> 
> 実際には割込み処理タスク等はランダムに割込み毎に動くような設計も
> 有りですが、可能なものは定周期ポーリングで済ませてしまいます。
> 設計上は割込みにも最大回数制限を付けます。
> 
> 
> > これは、ちゃんとわかってられるので、以下対策をすれば問題ないです。、
> >>> ちょっと大きな処理は、再度走り始める時にステータスを
> >>> 見て今は何をしないといけないかを毎回判定して実行する
> >>> 様な作りに成ります。
> > で対策するということなのですが、結局スケジューラを別途持つような対策が必要
> > ということです。起動してやらないとか結構いやらしい処理になります。
> > 
> > この事例は現状のSSPのスタック共有の欠点を端的に示す良い例だと思います。
> > 
> > なので、5.先取り方式の提案 をさせていただいています。
> > 5.先取り方式の提案なら貴殿の方式で再度走り出しの防止対策も不要になり、利用できると思います。
> 
> OSの進歩とはリソースの管理をしながら、いかにユーザーに自然な発想で
> プログラミングできるような環境を提供するか!って事ですから
> どんどん高機能に成りました。
> 
> それは、逆に言うとH/Wリソースの要求も高くなってきたという事です。
> 
> そして、それに慣れちゃいました。
> なので、制限付けられるとあれが出来ない、これで困ると感じます。
> 
> SSPみたいなものは、ソフトが使えるH/Wリソースが少ないという
> 制限の元で、何処まで機能を提供できるかという割り切りと、
> その少ない機能をどう活用したら効果があるのかという
> 発想力の勝負なのだと思います。
> 
> 例えばFPGAに小さなCPUを乗せて、マンマシンI/Fを管理しつつ、
> 組み込んだアクセラレータで高度な仕事をさせるなんて状況だと
> 有効そうに思えます。
> 
> 作成者のイメージしているターゲットが何なのかは知らないのですが ;-)
> 
> 全く別の話ですが、登山は似たような部分があります。
> 持てる範囲の装備と食料で如何に楽しむか、
> 危険予知と経験と発想力の合わせ技です。
> 
> 制限を楽しむ気持ちで見てみたら、また違った見え方が
> 見つかるのではないでしょうか?
> 
> その中で、何を変えたらもっと良くなるのか、ですね。
> これは大いに状況依存の問いだと思います。
> 
> 
> -------------------------------
> 
> > On Mon, 23 Jan 2012 23:56:07 +0900
> > Miyagawa <miyagawa ＠ trail4you.com> wrote:
> > 
> >> どうも間違いが多いなぁ
> >>
> >>>   (H_max*60 + M_max)*10 < 10分
> >>
> >>   (H_max*60 + M_max)*10 + L_max < 10分
> >>
> >> -----
> >> アドレス変えました。
> >>
> >>
> >>
> >> (2012/01/23 19:16), Miyagawa wrote:
> >>> 昔を思い出したのでちょっとだけ昔話を書きます。
> >>>
> >>> 今やメモリーは数GBという世界に住んでいるので
> >>> オブジェクトにたっぷりとメモリーを割り当てて
> >>> 疎結合なシステム設計をするのが当たり前な状況ですが
> >>> 30年前は 8bit CPUをアセンブラでプログラムしてました。
> >>>
> >>> その頃はメモリーの制約が大きく、タスクモニターの
> >>> 課題のひとつがスタック領域でした。
> >>>
> >>> 各タスク毎にスタックを割り付ければ、待ちを行う
> >>> システムコールは比較的簡単に作れます。しかし、
> >>> そうするとタスク数分のスタックが必要となる。
> >>>
> >>> そこで、待ちは必ずスタックがボトムに戻った時しか
> >>> 出来ないようにすれば、スタックを共有していても
> >>> 待つ事が出来る。しかし、これをやるのは実際は
> >>> 面倒です。昔はアセンブラでやっていましたけれどね。
> >>>
> >>> まあ、タスクは待つ事が出来ないとして、一旦走りきって
> >>> 終了する物とするのが簡単確実な手でした。
> >>>
> >>> ちょっと大きな処理は、再度走り始める時にステータスを
> >>> 見て今は何をしないといけないかを毎回判定して実行する
> >>> 様な作りに成ります。
> >>>
> >>> 優先度設計は例えば下記のように時間制限で決めます。
> >>>
> >>> 優先度 H : 1秒以内に走らなければ成らないタスク
> >>> 優先度 M : 1分以内に走らなければ成らないタスク
> >>> 優先度 L : 10分以内に走らなければ成らないタスク
> >>>
> >>> それぞれの優先度のタスクの実行時間の和をH_max,
> >>> M_max, L_maxとすると下記の条件が成り立つように
> >>> システム設計します。
> >>>
> >>> 話を簡単にするため割り込み処理時間は無視します。
> >>> H_maxに含まれると考えてください。
> >>>
> >>>   H_max < 1秒
> >>>   H_max*60 + M_max < 1分
> >>>   (H_max*60 + M_max)*10 < 10分
> >>>
> >>> 極々当たり前の話ですね。
> >>>
> >>> ここで、優先度Lのタスクが走りきれないというのは
> >>> 設計上許さないと言う事に成ります。
> >>>
> >>> 例外的にLのタスクが1本だけで、状況に応じて品質を
> >>> 調整するような作りは有りです。
> >>> 忙しすぎれば間引いてしまうような事です。
> >>>
> >>> また、1秒のタスクが1秒以内に全目的を完了する必要は無く
> >>> 完了まで定期的に呼ばれて順次実行する作りも有りです。
> >>> 時間制限を満たす所で一旦終わるわけです。
> >>>
> >>> 昔の記憶だと、優先度の高いのが制御や計測部分、
> >>> 中くらいがその加工や記録部分、低いのが印刷等の
> >>> レポート機能部分と言う様な感じが多かったかな?
> >>>
> >>> 例えば3本のレポート印刷するタスクがあれば
> >>> そいつらは全部まとめて10分以内に印刷できれば良い
> >>> という感じです。
> >>>
> >>> 根本的にオーバーロードな設計を禁止すれば
> >>> それなりに動きます。
> >>>
> >>> SSPだとHグループ(実行時1、起動時2-4)、Mグループ
> >>> (実行時5、起動時6-8)、Lグループ(実行時9、起動時10-16)
> >>> 見たいな感じかなぁ。
> >>>
> >>> まあ、レベル数は3段階でなくても良いし。
> >>>
> >>> スタックの共有が出来れば各グループの最大値の和程度に
> >>> 割込み分を加えた値位に抑えられますよね。
> >>>
> >>> タスク毎に持たなくて良いと言うのは大きいですし、
> >>> 通常は余裕度の部分が優先度グループ分足されて多少楽になる
> >>> はずですよね。
> >>>
> >>> 昔の作り方からすればSSPもシステム設計しだいで
> >>> 役に立つのではないかなぁ?
> >>>
> >>> でもまぁ
> >>>
> >>> 待ちが出来ないと手続き通りの素直なプログラミングが出来ない
> >>> と言うのは間違いないので開発効率は下がりますよね。
> >>>
> >>> ------
> >>> このメールはsanritz.co.jpから出しますが、実は1/20で
> >>> 辞めちゃいましたので、アドレス登録しなおします。
> >>> 今回だけ御免なさい。
> >>>
> >>>
> >>>
> >>>
> >>
> > ---
> > アライブビジョンソフトウエア株式会社
> > 高橋和浩
> > 673-0005兵庫県明石市小久保2-2-7幹線ビル4F
> > Email:takahashi_kazuhiro ＠ nifty.com
> > http://homepage3.nifty.com/ALVS/
> > 
> 
---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/
前の記事 (toppers-users 3830) Re: 8bit時代の手法
次の記事 (toppers-users 3825) 2つの優先度の有効な利用方法は？ 5.先取り方式の提案補足と訂正
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]