Task State Segment(TSS)というものをご存知だろうか．
これはIntelがマルチタスクをハードウェアでサポートするために286以降に搭載している機構である．
コンテキストの保存と回復はマルチタスクでは必須であり，それをハード化しようとするのは自然(ありがち)な発想である．
しかし実際のOSでは，このTSSはまともに活用されていないようである．
というのもこのTSSという機構はかなり限定された場合にしか都合よく使えないらしく(例えば1タスク=1スレッド)，
結局コンテキストスイッチをソフトウェアで書く羽目になるからだ．
(単にソフトで書いたほうが自由度が高くて処理が目に見えて，気分的に安心するという事も影響してるんだろうけど)
参考 :
Multitasking
参考 :
コンテクスト管理 について
ただ，組込みのような環境だとOSにあわせてハードをカスタマイズすることもできる．
(できるといっても普通はOS機能をハードでやるなんてことは労力の割りに効果が無いのでやらないだろうけど)
例えば
Silicon TRONなんてものがあったりする．
ITRONの基本的な機能をハードで実装したものだ．
ハードウェアの利点は並列化であり，順序的な要素が強そうなOSの機能はハード化する必然性はないともいえる．ただRTOSの基本的な機能程度ならばハードで実装してもそれほどコスト(面積)はかからないので，悪くは無いのかもしれない．
このシリコンTRONでは，完全にCPUとは独立したモジュールになっているが，仮にコンテキストスイッチ等を実現する場合，CPUのアーキテクチャを変更する必要がある(レジスタやCPUの状態を変更する必要があるため)．
これが問題のような気がする．というのも現在のRISC系アーキでは，原則的にパイプラインをストールさせない事を目標に設計されている．コンテキストスイッチとかそういった類の重い命令の追加は根本的なアーキに手を加えることになり，不用意な複雑化を招く(CISCの二の舞)．
そういったロジックを載せる位なら，その面積をキャッシュにでも充てた方がシンプルで良いというのが普通の人の考えるところである．
やるとしたら先日紹介した
RMT Processorのように，超高速にスイッチングできるようにタスクコンテキストブロック(TCB)を全てCPUに埋め込む方法が考えられる．
しかしそこまでやる価値があるだろうか．RMTの場合はコンテキストスイッチが多発するマルチスレッドCPUなので理に適っているが，シングルスレッドCPUの場合そこまでコストをかける必要性が見当たらない．(いくらハードリアルタイムだといっても，スクラッチパッドメモリを載せてそこにカーネルやTCB群，クリティカルなタスクを載せてしまえば普通は問題はないはず．それで問題があるならそもそもワイヤードロジッックでやるべきだろうし)
ということはRISC系プロセッサでは下手にハードでOS的機能は支援しない方が良いのだろうか？
うーん，誰もやってないってことはしない方が良いって事なのかなあ．
