目次
07-14 ジェイ・フォレスター 誕生日(1918)
07-14 厄介なバグ
今日は、ジェイ・フォレスターの誕生日(1918)。
Whirlwind I の開発発案者です。まだ御存命のようでなにより。
2017.7.14 追記
昨年、2016年の 11月16日に亡くなられています。
詳しくは Whirlwind I のページに書いていますが、ざっと略歴を。
第2次世界大戦中、MIT でサーボ機構の研究開発を行っています。
サーボ機構というのは、いまでいえば「フィードバック制御」のこと。
レーダーで敵機を捉え、捉えた敵機の動きに応じて、常にレーダー探知の「中心」にとどまるように、レーダー自体を動かします。
同時に、この敵機の動き・距離などを勘案し、「撃ったら弾が飛んでいき、当たる」と思われる向きに砲塔を向けます。
今で言えば「ロックオンされた」状態。後は引き金を引けば敵にあたります。
当時はコンピューターが開発される以前なので、全部アナログ回路で動かしていました。
微妙なノウハウの塊で、ジェイ・フォレスターはその第一人者でした。
ある日、彼の元に「訓練用のフライトシミュレータを作れないか」という相談が舞い込みます。
サーボ機構のノウハウを使い、空気抵抗などをシミュレーションして操縦するシステムを作るのですが、シミュレーションが要求された精度に全然届きません。
ここで発案されるのが、Whirlwind プロジェクト。「つむじ風」という意味です。
当時のコンピューターは、1bit の計算回路しか持たないのが普通でした。
1bit でも、繰り返し計算すれば大きな数を計算できます。
ちょうど、人間が大きな数の足し算をするときに、筆算を使って1桁づつの計算に分解するような感じです。
当時は、1bit の計算を繰り返して、36bit ~ 72bit 程度を一度に計算するのが主流でした。
これを、計算回路の幅が 1bit で、計算対象の幅が 36bit ~ 72bit 、と呼ぶようにします。
Whirlwind はフライトシミュレータのために、もっと計算速度が必要でした。
そこで、計算回路の幅を 16bit にして計算します。…これは、当時としては恐ろしく複雑な回路となりました。
計算対象の幅も 16bit です。当時は「対象の幅が大きいほど良い」風潮がありましたから、16bit では話にならない、という人もいました。
しかし、フォレスターはわかっていました。速度が速ければ、ソフトウェアで 16bit の計算を繰り返すことで、32bit にも、64bit にもできます。
計算回路が速くなればコンピューターが速くなる…というほど話は単純ではありません。
実は、当時一番の問題はメモリ。普通は水銀遅延管…超音波という「物理動作」が、電気回路よりも遅いことを利用して、この「遅さ」を記憶として使う方法でした。
実のところ、1bit づつ計算を行う当時のコンピューターは、水銀遅延管を使っていたことに由来します。
水銀遅延管は遅いため、1bit づつ計算するのにも、「メモリを待つ」状態になってしまうのです。
16bit を一度に取りだせて、超高速で動作するメモリが必要でした。
Whirlwind プロジェクトでは、新しいメモリを開発しようとしますが、結果的には失敗。
もう、なんでもいいからメモリとして使えそうなものを片っ端から試す、という状況になります。
ここで見出したのが、コアメモリでした。
非常に単純で、非常に安くて、なのに超高性能…と、中国系移民の発明者は言っていました。
もう、明らかに怪しすぎるし、当時はあまり相手にされていなかったようです。
でも、Whirlwind I は本当に片っ端からメモリを試す状況でした。…使ってみたら本当に理想的なメモリ。
Whirlwind I で採用されて以降、コアメモリはコンピューターメモリの花形となります。
1970年代に、集積回路でメモリを作ろう、というベンチャー企業…インテルが登場するまでは、メモリと言えばコアメモリでした。
#コアメモリは、非常に小さなビーズを入れて、細いワイヤを「編む」必要がある。
小型化に貢献したのは、手先の器用な日本人だった。かなりの量の生産を行い、アメリカに輸出していたらしい。
2017.7.14 追記
コアメモリの発明に関する話、少し勘違いがありました。
中国系移民の発明者が考案したのを使った、のではなく、中国人発明者のの見つけた「記憶効果」を応用し、WhirlWind I のチームが、
「コアメモリ」として発明しています。
高速なフライトシミュレータを作るのであれば、状況をすぐに図示する装置も必要です。
実は、Whirlwind I は、世界で初めて「画面表示」を採用した機械でもあります。
ベクタースキャンディスプレイで、何度か装置が交換されていますが、最終的には 2048x2048 の解像度を持ちます。
また、簡単に文字を表示する機構も備わっていました。
まだ作成中の初期段階で、画面に「弾むボール」を表示するデモプログラムが作られています。
スイッチを使って様々な係数を変更し、いろいろとボールを弾ませることができる。
特にゲームではないのですが、テレビ画面とコンピューターを使ったもっとも初期の「遊び」とされます。
プロジェクト最初の成果物、Whirlwind I (1951)は、現代のコンピューターの直接の「始祖」となるものです。
それ以前のコンピューターとは明らかに構造が異なっている。
本当は、I は性能を確認する実験機にすぎず、つづけて II が作られるはずでした。
しかし、I だけでも予算をはるかに超え、II は作成されません。
I を元にした量産機は、軍事用コンピューターとして多数作られました。
画面を表示するだけでなく、光を感知する「ライトペン」を使って、画面にタッチすることで操作できます。
コンピューターは元々計算用の機械でしたから、入力機器として文字を入れる「キーボード」が普通になるのは、もっと後の話。
キーボードより先に、画面にタッチして操作する、という入力方法が使われていたのです。
#もっとも、Whirlwind I では、タイプライターも接続されています。
キーを使った入力もできたようですが、主に出力のための「プリンタ」としての利用でした。
さて、もう一つ、APT の話も書いておきましょう。
こちらは、ジェイ・フォレスターが直接指揮を執ったわけではありませんが、彼の研究室で作られたもので、「サーボ技術」…最初に書きましたが、フィードバック制御の実績を買われて持ち込まれた相談でした。
コンピューターを使って金属の削り出し加工ができないか、というのがその相談。
当時、旋盤の刃を数値に従って動かす機械はあったのですが、金属の「固さ」に負けて、本当に必要な部分まで削ることができずに誤差が出るのです。
フィードバック制御ができれば、本当に必要なところに刃が達したことを確認でき、誤差のない加工ができるのではないか…というのが相談の内容。
こちらは、機械はほどなくしてできたのですが、その機械を制御するコンピュータープログラムの開発が難航しました。
最終的には、APT …Automatically Programmed Tool (自動プログラム装置)として完成します。(1959)
形状定義ファイルを入力すると、加工機を制御するためのプログラムを生成してくれるプログラムです。
これ、デジタルで形状を作り上げると、手に取れる形にしてくれる「3Dプリンタ」の元祖です。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
ファイナルアーチの話の続きです。
完成間近になって、エージングが行われます。
エージングとは、長時間ほったらかしで止まらないことを確認する作業。
業務用ゲームって、1日中電源入っていますからね。止まるようではお話にならない。
…数日置いといたら止まりました。
画面真っ黒で、どこで止まったかもわからない。
数時間で止まるなら、まだ対策もできます。ビデオにとっておいたりして、止まる瞬間を捕まえられますから。
でも、「数日」というのが手におえない。
時間もないので、プログラマー全員で原因究明、となりました。
普段は僕は「他人の領域には手を出さない」ことにしているのですが、こういうときは別。
先輩方が作ったプログラムも、片っ端からチェックします。
しかし、情報が少なすぎてなかなか原因がわからない。
#他人の領域に手を出さないのは、大学の頃に読んだ新聞記事の影響。
人の担当部分を見たら、バグの原因となりそうな処理があったので指摘したところ、相手のプライドを傷つけてしまい職場の人間関係にひびが…というような内容。
そういうトラブルは起こしたくないので、基本的に人のプログラムは見ないことにしています。
でも、バグ取りが「仕事」になれば、大義名分を得たことになるので他人の部分まで突っ込みます。
とにかく停止バグを捉えること、というので、一応ビデオも回しつつ、エージングを続けます。
すると、やっと停止の瞬間を捉えました。
デモ画面の途中、場面転換しようとした瞬間に停止しています。
メインプログラマー氏、その近辺の処理のプログラムを探し始めます。
それとは別に、ひたすらテストプレイも行われていました。
こちらでも、乱入したら停止した、という報告が。
えー、デモ画面と乱入した時では、全然違うことやってるよー。
全然違う個所なのに同じような停止バグを引き起こす。
原因のめどもつかず、一番厄介な状態です。
メインプログラマー氏は、自分のプログラムの何かがおかしいのだと考えて一生懸命チェックしています。
でも、僕としては、全然違う場所で同じようなバグが出るのだから、もっと深いルーチンがおかしいのではないか、と考えました。
でも、深いところにあるルーチンは、呼び出される頻度も高い。
なのにほとんど停止せず、ごくまれに停止するということは…
ヒントを求めて、ハードのバグなどの「追加仕様書」を片っ端から眺めます。
仕様書はプログラマーは全員手元にファイルを持っているのですが、後からの「追加」は、必要と思われるものだけがコピーされます。
完全版は、部内でファイルされたものが一冊あるだけ。
…怪しいものを発見しました。
追加仕様書に、サターンの CD用バッファから VRAM に向けて一定サイズ以上の DMA 転送を行ってはならない、という仕様がありました。
これ、ややこしい技術話ですが、面白いので書きます。
ST-V はサターンと同機能のボードです。
そして、サターンは3つのバスを持っていました。
CPU のメインバス、VRAM やサウンドが接続された A バス、CD-ROM 等が接続された B バスです。
メインバスは、命令実行のために CPU に頻繁に使われます。
VRAM やサウンドは、画面や音楽の出力のため、画面出力回路に頻繁に使われます。
そして、CD-ROM などは低速デバイスなので、バスを占有しがちです。
これを1つのバスに混ぜていると、信号がぶつかり合って、頻繁に「待つ」ことになります。
なので、3つに分離した設計。
でも、3つのバスでのデータやり取りは必要ですから、System Control Unit (SCU)という LSI で接続されています。
SCU はバスの利用を引き受ける回路で、DMA 転送も担当していました。
DMA とは Direct Memory Access の意味で、CPU を使わずにメモリアクセスをすることです。
一般的に、ある程度のサイズの内容をコピーする機能(DMA 転送)として使われます。
DMA を使わないと VRAM にアクセスできない、という意味ではありません。
VRAM には CPU からアクセス可能なアドレスが割り振られ、直接操作することは可能でした。
それでないと、画面を作れませんから。
つまり、SCU は CPU バスに流れる信号を検知し、VRAM に流すべきであれば自動的に A バスに転送します。
しかし、そうでない場合は VDP と CPU のバスを切り離し、それぞれ頻繁にバスアクセスしても、問題を起こさないのです。
巧妙な設計でした。
ところで、CPU には RAM リフレッシュ機能がついています。
RAM はしばらくほおっておくと記憶内容を「忘れる」ので、それを防止する機能です。
命令しなくても、CPU が勝手に「古くなりそうな」RAM 内容を読出し、改めて書き込みます。
これで内容が「リフレッシュ」され、記憶が消えるのを防ぎます。
さて、本題。
SCU が DMA 転送を行っている間、SCU がバスを占有します。
A バス・B バス間の転送であれば CPU バスは無関係に思えますが、CPU からのアクセスは SCU がどのバスに流すべきか判断するため、アクセスが生じた時点で CPU も待たされることになります。
CPU は内蔵キャッシュがあるので、DMA 中も命令を読み込み、同時稼働することは可能でした。
…が、リフレッシュ機能は、外部アクセスを必要とします。
結果として、DMA 転送の時間、リフレッシュは待たされます。
余り期間が長いと、「消えそう」な RAM の読出しが間に合わず、実際消えてしまいます。
普通は十分に時間に余裕をもってリフレッシュするため、致命的にはなりません。
しかし、何百回に1回は、間に合わずに RAM が消えてしまうこともあります。
これが、追加仕様にあった「CD用バッファから VRAM に向けて一定サイズ以上の DMA 転送を行ってはならない」の真意でした。
追加仕様書の記述は「CD用バッファ」だったため、CD-ROM を使用しない ST-V では関係のない話、と思われていたようです。
この仕様は、誰も気にすることなく、部内のファイルに埋もれていました。
しかし、ST-V カートリッジも B バスに接続されるので、これは CD-ROM と同じ扱いです。
これが原因ではないかと考え、メインプログラマー氏に詳細を報告します。
ここで「禁止」されていたデータサイズは、CD-ROM を前提とするのであれば、あまり問題にならないサイズでした。
読み込みバッファ全部を使いきるようなサイズでの転送を行わないと、禁止事項に触れませんでしたから。
しかし、ST-V ではカートリッジを使い、このバッファよりずっと大きなメモリを転送できます。
そして、まさにそれをやっていました。VRAM 上のテクスチャを、全部一気に転送していたのです。
デモ中の画面転換シーン、乱入されたとき…停止した場所は、特に画面が急変するため、多くのテクスチャを送っているシーンでした。
メインプログラマー氏は、DMA 転送の指示を分割し、1回で転送していたのを 10回程度に分けるようにしました。
この程度であれば、速度の低下はほとんどありません。
そして、この後はエージングしてもバグは再発しませんでした。
どうやら、推察した通りの原因だったようです。
でも、こういうバグって、原因も「多分」だし、治ったかどうかも、確率問題だから確認しようがないんですよね。
締切も近かったので、本当にこれで正しいのか不安だった記憶があります。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |