ストリード
「マルチコアＯＳ−祭ＭＡＴＵＲＩ−」仮
昔の研究室に有ったアレ全部下さい、と言う事で。今のＣＰＵ構造でもマルチコア化は結構楽？と言う事らしいのでＯＳネタとして考えてみる。次世代というと次世代。
2010/12/10
森宮 照
プロデューサーシート
タイトル「マルチコアＯＳ”祭（まつり）”」仮
概略 マルチコアで有る事を前提にしたパソコンＯＳ
コンセプト「１コア１アプリ」
ハード的テーマ「マルチコア」肯定否定
とにかくマルチコアで有る事が大前提のＯＳで、それを用いての信じられない様な快適な環境の構築。
ソフト的テーマ「一台の中に沢山のパソコン」否定肯定
結局見た目は普通のＧＵＩなんだが、ただ開いているアプリ窓一つが一つのコアで占拠されていて、それが完全に並列動作している環境。
目的 マルチコアＣＰＵの普及とか利用性の向上
それは無い 販売者が経営難
ディレクターノート
ＯＳ名が、「祭−ＭＡＴＵＲＩ−」
マルチ アプリケーション トランス ユニット リーダー インターフェースの略。
テーマ
表「使い易い解りやすい」肯定否定
ともかく簡単で、数枚のマニュアル読めば誰でも解る感じで、ＯＳの操作方法に関しては馴れる必要がない感じだが何でも出来ちゃう感じ。
裏「使いこなす必要が無い」否定肯定
まずマルチコアが並列動作し、”同時に”メモリからデータをリード出来、書き込みは速い物順ではあるが衝突せず書き込み出来る、そう言うハード上での話。
マルチコアは全てが等価で、使用感としては一台の中に同時にそのコア分のＰＣが動いている、と言うイメージ。
なのでＧＵＩ（グラフィカルユーザーインターフェイス、Windowsで言う所のシェル）は、１／６０（ともかく画面のリフレッシュレート）で全アプリ”同時に”更新されている。見た目上はゲーム機が何台も同時に稼働している、様な感じ。プログラマーから見ると、アプリは一枚の板だけ渡されて、それをＶＲＡＭと見て書き込み、”更新”を掛けると次のフリップタイミングで描き変わる仕様。
構造としては、第一コアがＯＳコアとなり、画面他ハード情報や制御、メモリ管理、使用権制御などを全て受け持っていて、他のコアは基本的にはＯＳコア上で動くＧＵＩアプリケーションから”呼ばれて”動いている（アプリコア）。アプリコアはＯＳコアからアプリケーションに割り振られないと、駆動出来ない。
まず最初に、”全てのコアへ”ＢＩＯＳ（或いはＤＯＳ）にあたる物をロードさせ、全てのコアを同一環境に置く。この時点で各コアはハードを勝手に全て使える状態に置かれるが、ともかく規定の領域をコントロールテーブルとして設定、アイドリング状態に入る。そのコントロールテーブルに書かれる命令を見て、その後の「自分の行動」を各コアは決める様になる。その上で、ＯＳコアに対してＯＳシェルがロードされる。
ＯＳシェルは通常のWindowsの様な感じだが、もっとあっさりと言うか。単体ではＤＯＳ程度の事しか出来ない。起動するアプリは全てこのＯＳ上でまず動く事になる。アプリ他、ウインドウは”全て”、言うならＳＴＧでの敵キャラと言うイメージで、マルチタスクで動いている。アプリは起動すると”定期的にコールされる”ので。適当な時間内に１回の処理を終了させて、ＯＳへリターンする事で複数のアプリが同時に動いている、様に見える仕様。画面に存在するアイコンや窓（オブジェクト）は全てそのマルチタスクの一つで、表示に関しては１／６０（ともかくリフレッシュレート）以内で表示完了可能な範囲までしか表示出来ない。それは起動時に測られて、リソースとして存在。画面にアイコン等を置いていくと、どんどん減っていく。
アプリケーションは、起動するとそのＯＳシェルが持つ「リソース」を貰って使用する事に成る。同時にアプリケーションなら必ず「１コア」の使用権を貰えて、”それ”に対してのみ、プログラムをロードさせたりする”命令”を送る権利が得られる（それはＡＰＩとして存在し、ＯＳがコントロールテーブルへアクセス、制御する感じに）。
具体的には。アプリ起動、アプリリソースは獲得したアプリコアに、このプログラムをロードして実行しろと、命令を出す。アプリコアはその命令に従いプログラムをロードし、自身のコア内で実行を始める。動き始めるアプリは、随時自分を起動させているアプリ窓に、必要なリソースを要求し、アプリ窓はそれをＯＳへ要求し、獲得出来たらそれをアプリコアに渡す。なのでアプリ窓はアプリが起動中、それが使用する全リソース情報を持っている事になる。
※この時、アプリ窓はアプリコアとの連絡しかしていないのでリフレッシュレートに送れる、と言う事は基本的に無い。またアプリコア側で処理が間に合わず画像が更新できなかった、としても更新されないだけなので、ＯＳシェルの他の動きを阻害する事も無い。
プログラマーサイドから見ると、この時プログラムは完全に「シングルタスク」で動ける。どれだけ重い処理を長時間続けコアを占有しようとシェルその物には影響がない。
また、リソースの中には「クリップボード」もある。そこは全コア共通に見る事が出来る公共のメモリで、そこに情報を掲載する事で、各アプリは情報をやり取りも出来る。
リソースとしてコアが足りないと、それ以上はアプリが起動出来ない。
いわゆる「常駐アプリ」（通常のＦＥＰとかドライバとか）は、ＯＳシェル側の専用領域で駆動する。それは今までのＯＳでの開発の様に「作法」に則って創らねばならないので多少面倒で、また作り方が悪いとＯＳの更新が遅れたりとか迷惑が掛かったりする。ただ、これに関しては「今までのwindowsアプリ」と言う見方も出来るのでそれ程混乱は無いと思われる。
マルチコアの場合、基本構造として「ＣＰＵとキャッシュメモリ」で１コア、その外にメモリコントローラーと通常メモリ、だと思われるので。タスクは基本的にインタプリタで駆動する物、と思う。”キャッシュ内に”基本動作の全て（ＢＩＯＳ）と例えばＢＡＳＩＣ（の中間コード）インタプリタを搭載する方が、アプリのコードが短くなりまたキャッシュメモリを効率的に利用出来る、様だ。
概念としてはこれは「昔のサーバーと端末」の構造、らしい。サーバーとはメモリコントローラーとメモリで、そこからメモリ情報を自分のメモリにダウンロードし駆動する、のが端末。それを全て一台で実現する、と言うコンセプトなので、１コア１アプリと言う事に成っている。８コアしかないと同時に数アプリしか駆動出来ない訳だが、そこはハードメーカー側の奮闘を期待したいｗ。
end