home > コンピュータ開発の思い出 >

8 3 5 0 の 思 い 出

酒 井 寿 紀

PDFをご希望の方は ここ をクリックして下さい。 (A5 20ページ 両面印刷)

(PDFの閲覧には Adobe社の "Acrobat Reader" が必要です。ダウンロードする方は ここ をクリックして下さい。)


目   次

1. はじめに

2. (電サ)が主役

3. やりたい放題

4. 「試験プログラム」をシミュレート

5. IBMに出し抜かれる

6. (電サ)の人をソフト工場へ送り込む

7. 「いつのまにかできていた」

8. 京大情報工学科へ納入

9. おわりに


1. はじめに

 

8350とは1969年から71年にかけて開発された日立の中型コンピュータである。60年代後半の8000シリーズに続く、70年代前半の8X50シリーズの一員で、8300の後継機として位置づけられるものであった。

1988年に日立電子サービス[以下(電サ)と略称]の溝口さんが言い出して、8350の同窓会が開かれた。ソウルでオリンピックが開催された年だった。当日は秦野市の渋沢の料理屋に、東は茨城から西は広島まで、全国各地から昔いっしょに仕事をした仲間が集まって昔話に花を咲かせた。

それは忘れもしない88年の11月22日のことだった。どうして日にちまではっきり覚えているかというと、その日は米軍のヘリコプタが日立の神奈川工場に不時着したり、私の靴を間違えて履いて新幹線に乗って名古屋まで帰ってしまった人がいたり、変なことが立て続けに起き、翌日新聞を見たらケネディ暗殺の25周年の日とのことだった。

ちょうどオリンピックの年だったので、今後4年に1回、オリンピックの年に集まろうということになった。こうして第2回は92年、バルセロナの年に真鶴に集まった。今回は何も起こらないだろうと寺島(光一)さんといっしょに大森から出かけたが、東海道線と新幹線が同時に架線切れで不通になるという珍しい事故が起き、宴も終ろうという頃にやっと真鶴までたどり着いた。この時は日立の保養所に泊まり、翌日ゴルフをした。

こういうわけで同窓会のたびに変な事件が起きるのだが、昔の仲間と思い出話しをするのは実に楽しく、時のたつのを忘れる。みんなの記憶力のよさにも驚かされる。

今と比べるとこの時代の方がみんなのびのびと仕事をしていたように思う。私など好き勝手に仕事をさせてもらっていた。新しい技術は管理されすぎた開発プロジェクトからはなかなか生まれない。技術の方向を見極めた上でのいい加減な判断が重要なことも多い。これからの仕事のしかた、させかたについて考えなければいけない点と思っている。

4年に1回となると、次は96年のアトランタの年になったのだが、もうみんな先が短くなったので、この時以来冬季オリンピックも含めて2年に1回開くことになった。

本小冊子はリレハンメルで冬季オリンピックが開催された1994年の同窓会の時に、思い出話のよすがにと書いたものである。

「8500の思い出」同様、これは極めて個人的な、8350の一面についての思い出で、8350の開発にはここに登場しない多くの方々の貢献があったことは言うまでもない。

また手元にあまり資料もなかったので、記憶違いもあるかと思う。失礼なことがあったら御容赦頂きたい。間違いに気付かれた方は御連絡頂ければ幸いです。

 

 

2. (電サ)が主役

 

8350の開発は1969年の始めに始まった。

68年12月に神奈川工場の設計部隊が横浜の戸塚から秦野に引っ越した。その後69年の始めまで私は8500Sの後始末に携わっていた。8500Sの目処がつくや否や、8350の開発に取りかかった。69年の2月か3月のことだったと思う。

当時神奈川工場では3大プロジェクトが走っていた。

その一つは8700であった。これは銀行等で最も要求が強かった8000シリーズの第2世代の最上位機を目指したものだった。

もう一つのプロジェクトは通産省の「超大型プロジェクト」に対応する技術計算専用の超大型機とそれを一般マーケット向けに商用化した8800の開発であった。

これら二つのプロジェクトには村田(健郎)さん、中澤(喜三郎)さんはじめ5020を開発した方々が主として従事されていた。

3番目のプロジェクトは当時の電電公社の「DIPS」であった。このプロジェクトには8500に従事されていた関(弘)さん、井上(武洋)さん他、馬場(徳夫)君、野上(康一)君等がごっそり移って行った。

こうして8500のメンバーで残ったのは私一人になってしまった。

しかし3大プロジェクトだけで飯を食っていくわけにはいかなかった。8300、8400の後継機を何とかしなければならなかった。

8300等の8000シリーズの第1世代機はRCAのSPECTRAシリーズをベースにしたものだった。ところがRCAはその後継機をまじめに開発していなかった。SPECTRAの70/45を開発したYen,70/35を開発したNeilson等の主力エンジニアはRCAを離れてしまっていた。当時「3R」作戦と呼ばれていたが、SPECTRAシリーズの「Renaming、Reskining、Repricing」、要するにお化粧直しでごまかそうとしていた。こんなことでは到底うまくいくように思われなかった。そこで8000の後継シリーズは自社開発することになった。この決断には8500の自力開発に成功した自信が大きかったと思う。

結局RCAはその後2年あまりたった71年9月にコンピュータから撤退してしまった。早めに縁を切っておいたおかげで日立は助かった。

8300の後継機である8350については、8400の仕事から開放された寺島(光一)さんが中心になって検討を進めていた。そこへ私が加わったのだが、当初は他には小宮(充男)君、石橋(陸泰)君、木田(正彦)君ぐらいしかいなかったと思う。

あとはもっぱら電子サービスの人に仕事をしてもらっていた。開発の初期からALUまわりと故障診断は常世田君、チャネルは南君に中心になって設計してもらった。その後全国各地から順次応援に来てもらった。溝口、永橋、福井、末次、横山、後藤、他の皆さんだった。

その後新しい方式の「マイクロ診断」のプログラムと辞書の作成に人が足りなくて困っていると、今は亡き(電サ)の角田(基文)さんが教育を終ったばかりの(電サ)の新人を大勢一度に送り込んでくれた。新しい故障診断システムを何とかものにしたいと企んだものだった。それは伊藤、小嶋、松本、持沢、他の皆さんだった。

松本君はその後私のところで庶務の仕事をしていた久保珠美さんと結ばれた。角田さんの媒酌で大阪の天王寺で式を挙げられ、私も出席させて頂いた。これも8350プロジェクトの一つの成果であった。

こうしてピークには20人に近い(電サ)の人がいっしょに仕事をしていた。

当時はみんな若かったのでよく遊びに出かけた。山中湖、湯河原、伊香保等へ車を連ねて繰り出したことを懐かしく思い出す。一杯入ると必ず聞けるのが横山さんの秋田の民謡だった。先日同窓会の折、20年振りに大変懐かしく聞かせてもらった。

こうして今でも同窓会を開くと工場の人より(電サ)の人の方がはるかに多い。あまり多くなりすぎるので後半戦に参加した(電サ)の新人は呼ばなかったのにこのありさまであった。

「いったい8350は誰が設計したんだ?」

と話し合った。

ない袖は振れなかったわけだが、こういう体制で仕事をしたため、工場に開発力の蓄積を充分できなかったのは残念であった。ただわれわれ工場の者にとって最前線のサイトの生々しい話しを聞くことができたことは貴重な経験であった。

開発を開始した当時の設計の主任技師は飛永(勝年)さん、部長は佐藤(利男)さん(現在の大沼さん、元 (電サ))だった。昔のことなので時期がはっきりしないが、多分1年くらいして主任技師は関(弘)さん(現 国際電気)、部長は波多野(泰吉)さん(現 トキコ)に変わった。そして寺島さんは新たに8250を開発するためにわれわれのチームを離れていかれた。

3大プロジェクトのあおりは開発の最後まで続いた。DAのマシン時間の取り合いもその一つであった。まともにぶつかっては勝ち目がないので、間隙を縫うようにして仕事を進めた。

「ダンプカーの合間を縫って走る軽自動車のようなものだ。近寄りすぎるとはね飛ばされるから気を付けろ」

と当時話し合っていた。いっしょに仕事をした人達には大変な苦労をかけた。

 

 

3. やりたい放題

 

私が参加する前に寺島さん他が8350の検討を始めていた。

基本回路には当時一般化し始めていた市販品のTTLを使うことになっていた。またプリント基板には先行していた8210で開発された「高密度配線板」の使用が予定されていた。これは4層で100ミルピッチの格子間を2本の配線が走るごく普通のものだったが、8000シリーズの手書きのミミズが走るものに比べればはるかに高密度であった。

この二つの新しいハードウェア技術で、8500に近い性能のCPUをコンパクトに安く実現し、8300の後継機を作ろうというのが8350のねらいであった。

このように基本的な方針は決まっていたが、私としては今回是非とも実現したいと思っていたことが二つあった。

その一つは設計を見通しよく、手戻りなく進めることであった。前回の8500の開発の時は、経験不足のため、手探り、試行錯誤の連続であった。ある程度設計が固まったところで、机上でのチェックは行き詰まり、試作機を作って延々何ヶ月もかかって調整した。今後はこういうことではだめだと思っていたので、8350ではマイクロプログラムのシミュレーションの改善を図った。これについては別項で触れる。

もう一つは保守性、信頼性の改善であった。8500ではこれの不足のため大変な苦労をした。サイトで事故が起きても原因が分からず、何日間も徹夜して調べたことが何回もあった。徹夜明けの朦朧とした頭で、「設計者が何日間も徹夜しても分からないような事故を起こす機械を世の中に送り出すのは社会的罪悪だ。次の時は何とかしなければ」と思い続けていた。

保守性改善の面で最も力を入れたのは「マイクロ診断」と「エラーロギング」だった。これらについても項を改めて触れる。

保守機能の強化については(電サ)の常世田君、南君他といっしょになって、考えられることは何でもやってみようという方針で進めた。当時の報告書を見ると、

   過去2サイクルのROMアドレスを保管しておくレジスタ

   プログラムによるコアメモリのマージン試験機能

   マイクロプログラムの指定部分を繰り返し実行する機能

   スタートスイッチの信号を自動的に繰り返し出す機能

等、変わった機能が数多く出ている。

8500では少なすぎて困ったので今度は逆方向に振り切ってみようというのが私の考えであった。何年かたってからこれらの機能のサイトでの使用状況を調べたところ、障害自身が大幅に減ったこともあって、ほとんど使われていない機能が多かった。しかし今でも技術の進歩のためには振り切ってみることも重要と信じている。

今から思うと8350の保守性強化については本当にやりたい放題のことをやったように思う。なかには道楽に近いようなものまであった。最近はコストの競争が厳しくなってこのような道楽じみたことをするゆとりはほとんどなくなっているが、製品開発時のこういう「ゆとり」は非常に重要だと思っている。

それにしても性能、信頼性、早期開発が最重要課題でコストは二の次の古きよき時代であった。

 

 

4. 「試験プログラム」をシミュレート

 

8500の経験から私が何とかしたいと思っていた問題の一つは、いい加減な設計で試作機を作ってしまい、あとは延々と実機調整で機械を動かしていくという野蛮な仕事のしかたからの脱却であった。

特に当時のマイクロプログラムにはワードシート型のROMが使われていたので、変更があると大変だった。バグが見つかると手動のワードシート穴あけ機で1ビットづつ穴をあけ、ROMのスタックをばらしてワードシートを交換し、スタックを組み立て直して調整を続ける。そうするとすぐまた次のバグが見つかるという具合であった。

こういう事態を解決するためマイクロプログラムのシミュレーションに挑戦することにした。

すでに8500等でも一部シミュレーションを実施していたが、8350では新しい試みとして「試験プログラム」を直接シミュレーションのテストデータとして使う方式に挑戦した。試験プログラムの磁気テープから指定したブロックを次々に読み込んでシミュレーションを実行するというものであった。これがうまく行けば、命令語のマイクロプログラムに関する限り、実機では試験プログラムが一発で通るはずであった。

8350のマイクロ命令の仕様は8000のアセンブラ言語で記述した。8000の命令語を実行するためのマイクロ命令を記述するのだから、FORTRAN等を使うよりこの方が容易なはず、との判断だった。当時は高級な論理記述言語など無かった。タイミング等もできるだけ実際の論理に忠実に記述し、方式設計の不良も見つかるよう狙った。

シミュレーションを制御する「モニタ」は69年に入社したばかりの吉田(和史)君に中心になって作ってもらった。

こうして作ったシミュレータを実行して、50件のマイクロプログラムのバグと10件の方式設計不良を見つけることができた。試作機の試験プログラムによるテストは命令語に関する限り不良ゼロで、当初の目的を達成することができた。

その後の神奈川工場でM−240等全面的にLSIを採用したCPUを開発の際、大型コンピュータを湯水のように使って試験プログラムを直接シミュレーションするのが一般化したが、8350のアプローチはいわばそのはしりであった。

 

 

5. IBMに出し抜かれる

 

8500で最も苦労したのは事故対策であった。事故のうちインターミッテントな故障については簡単にはいかないが、ソリッドな故障についてはいろいろな故障診断方法が世の中で試みられていた。

その一つはRCAの70/35等で試みられたマイクロプログラムによる診断であった。この方法の弱点はマイクロプログラムを磁気テープ等からメインメモリへロードして診断を開始するまでに半分以上の論理を使ってしまうことであった。つまり相当正気でないと自分自身の体の診断はできないということである。

もう一つはIBMの360/50等で試みられたFLT(Fault Locating Test)と呼ばれるものであった。これは診断専用のスキャンイン/スキャンアウトパス、制御論理を持つもので、気違いが気違いを診断するという問題はなかったが、ハードウェアの負担が大きく、また診断データの作成が大変であった。

われわれはマイクロプログラムによる診断を改善すれば実用に耐えるものにできるのではないかと考えた。これには(電サ)の常世田君の貢献が大きかった。

まず診断プログラムのロード用に単純化した入出力チャネルの機能を用意した。

次にこの機能を含め診断プログラムを実行するために正常に動作しなければならない機能(ハードコア)を、ごく単純な機能から一歩一歩確認するマイクロプログラムを作り、これをROMに常駐させた。これを「ハードコアテスト」と呼んだ。そして確認が済んだ機能を使いながら少しずつ確認済みの範囲を増やしていく方法を「ブートストラップ構造」と呼んだ。

こうして基本機能の診断が終ると、次はレジスタへのデータの書き込み、読み出しが正しくできるかを確認する。これを「スキャンイン・スキャンアウト・テスト」と呼んだ。

このあとこれらの診断済みの機能を使ってマイクロ命令の機能をひとつづつ確認していく。

このやり方は新設計のコンピュータの試作機の組み立てが終った時、基本機能からひとつづつ人手で確認するやり方と同じであった。これは人間の故障診断の手順と非常に近いため、複雑な故障で直接故障個所を指摘することができなくても、人間がトラブルシュートをする時の有力な手掛かりを与えることができると考えた。

こうして69年に診断方式の構想を固め、ハードウェアを作りこみ、70年に入って診断プログラムの開発に取りかかっていた。

こうしたある日、私はAFIPS(アメリカの情報処理学会)の70年のSJCC(春の学会)の論文集を見ていて腰を抜かさんばかりに驚いた。それにはIBMの360/85の診断方式の論文が載っていたが、その考え方はわれわれとまったく同じものであった。

われわれが「ブートストラップ構造」と呼んでいたものを彼らは「スタートスモール」と名付けていた。

われわれが「スキャンイン・スキャンアウト・テスト」と呼んでいたものを彼らは「ゼロサイクル・テスト」と名付けていた。

名前こそ違ったが基本的な設計思想はまったく同じであった。ただ360/85はマイクロプログラムの格納用にROMでなくRAMを使っていたので、診断用のマイクロプログラムの格納にメインメモリを使っていたわれわれの方式よりすっきりしていた。

IBMはこの方式を「マイクロダイアグノスティックス」と名付けていた。われわれもこれに対抗して名前をつけなければいけないとみんなで相談した。その結果、「HDS(日立ダイアグノーズ・システム)」と呼ぶことにした。

「マイクロダイアグノーズ」というのはIBMの用語だと、当時われわれは対抗意識を燃やして使わなかった。しかしこの診断方式が一般に普及し、日本でも「マイクロ診断」という言葉が定着すると日立社内でもこの言葉が一般に使われるようになった。

この8350で採用した診断方式を常世田君といっしょに電気通信学会の全国大会で発表し、「日立評論」にも論文を載せた。

その後のMシリーズではこの診断方式が広く採用されるようになった。

 

 

6. (電サ)の人をソフトウェア工場へ送り込む

 

8500の事故対策で一番困ったのは情報の不足だった。事故が起きた瞬間の計算機内の各部の状態はどうなっていたのか? どういう経過をたどって事故に至ったのか? こういう情報が決定的に足りなかった。交通事故の現場をいろいろな角度から撮った写真、そして飛行機事故の原因究明に使われるフライトレコーダのようなものが是非欲しいと思っていた。

交通事故の原因を調べる時に、事故直後の車の位置も分からず、事故に至った経緯についても何の情報もなければ全く当て推量で事故原因を推定するしかない。8500ではそういうことがしばしばあった。

IBMの大型機の資料を参考にして、障害が起きた瞬間の障害の検出、障害を検出した瞬間の現場情報の保存、障害にたどり着くまでの記録の確保等のしかけをいろいろ考えた。

これらの情報の獲得はハードウェアの仕事なので何とかなったが、問題はその後始末であった。

こうして確保した情報をあとでわれわれが使えるようにディスク等に確保しておくにはどうしてもOSの力を借りなければならない。これは「機器異常割込み」の処理ルーチンを作ることになるのだが、処理自体をどうしたらよいのか分からず、またソフトウェア部隊は自分達の仕事だけで手一杯で、とてもハードウェアの障害の後始末まで手が回らなかった。

そうこうしているうちに機器異常割込み処理の 参考資料が手に入った。これを参考にして機器異常割込み処理の仕様書を作成した。(電サ)の松戸さんにお願いし、ソフトの分かる人ということで長富さん、田口さんの二人に来てもらい、この仕事を手伝ってもらった。

仕様書ができるとこれに従ってプログラムを作り、OSに組み込まなければならない。ところが前にも触れたように当時のソフトウェア工場は忙しくてとてもわれわれの要求を聞いてくれるような状況になかった。そうかといってわれわれがプログラムを作成しようと思っても、OSの中のしくみ、OSとどうインターフェースをとったらよいかが分からなかった。

困ったあげく、松戸さんと相談し、長富、田口両名に今度はソフト工場に入り込んでもらうことにした。今度はソフトウェア工場の仕事として、二人に自分達で書いた仕様書に基づいてプログラムを作ってもらった。

新しい時代のコンピュータの機能として何が必要か、それをハードとソフトでどういうふうに分担するべきかが当時はまだはっきりしていなかった。とにかく必要を感じた者が仕様を決め、物を作るしかないという時代であった。

 

 

7. 「いつのまにかできていた」

 

8350の開発は69年の始めに始まり、8月には論理設計を終った。その後70年の8月まで延々1年間かかって実装設計と診断データの作成をやった。初めての高密度基板の設計で、まだDAが完備されてなく、人海戦術によるところが多かったためである。

70年9月に試作機に火が入った。基本機能の確認はほぼ1ヶ月で終った。この間1日24時間を8時間づつ3グループで勤務するシフト体制をしいた。1週間ごとにシフトの変更を行った。朝の8時と夕方の4時、そして夜中の12時にシフトの引継ぎの打合わせを行った。私はシフトには入らなかったが、この1日3回の打合わせに全部出席した。つまり朝の8時から夜中の12時過ぎまで毎日働いていたことになる。若かったからできたのだがよく続いたものだと思う。

しかしこの調整の第1期が終ると私は過労でダウンしてしまった。39度以上の熱がどうしても下がらず、東京日立病院に入院した。ところが医者は解熱剤を飲ませると発熱の本当の原因が分からなくなるからと飲ませてくれない。高熱で2、3日うなされ、同室の人達に迷惑をかけたことと思う。この時は死ぬ思いをした。しかしその後熱はひとりでに下がり、しばらくして退院することができた。

結果的には調整が一段落したところでちょっとした休養をとることができた。そしてもう20代のような無茶苦茶なことはできないと思った。私はちょうど30才になっていた。

ヒートラン等を含め評価試験を一通り終ったのは71年1月であった。

その後8450といっしょに製品発表が行われたのは71年7月、そして初号機が出荷したのは72年1月であった。

私は90年8月から2年半日立の中条工場にいた。中条工場では毎年、亀戸工場、中条工場の先輩をお招きして「亀友会」という会が開かれる。そこで8350の開発当時神奈川工場長をされていた甲本(幸男)さんに20年振りでお会いした。甲本さんは当時のことをよく覚えておられ、

「酒井君は8350をやってたんだよな。あの頃は、8000シリーズは終わりだし、3大プロジェクトはまだできないし、売るものがなくなってしまって本当に困っていたんだ。ところが8350がいつのまにかできてたんだよな。あれで本当に助かったよ」

と言われた。

当時の工場長としては3大プロジェクトで頭がいっぱいで、8350どころではなかったのだろう。

8350ができても、これだけで発表するわけにもいかないと、おお慌てで8450を開発することになった。さいわい8500のBPUの原価が下がり、もう1世代使えそうだということで、これをベースにしてメモリと電源を新しいものに切り替え、短期間で仕立て上げた。

こういういきさつのため、8350は早くできたわりには世の中に出るまでに時間がかかってしまった。

シリーズものとしての製品計画が始めからしっかりするようになったには次のMシリーズからであった。

 

 

8. 京大情報工学科へ納入

 

昭和47年度(1972年)に国立大学に情報工学科が新設されることになった。そして各大学にコンピュータ導入のため1億円の予算がついた。各社その受注戦にしのぎを削った。

京都大学では萩原 宏教授が機種選定に当たられていた。一日神奈川工場に来られて機種選定の考えを述べられた。

「マイクロプログラムをいろいろ書き換えて実験したいと思っている。それには8350のようにハードウェアをマイクロプログラムで自由に制御できる機械が望ましい。問題は8350はマイクロプログラム用としてROMしか持ってないことだ。ついてはユーザが自由に書き換えられるRAMをマイクロプログラム用メモリとして追加して欲しい。」

という趣旨の話をされた。

この要求を何とか手際よく実現しようと、関西支店の営業、システムの人といろいろ相談した。そしてマイクロプログラム用のRAMを増設し、これをチャネル経由で書き換えられるようにした。ハード上もソフトの面からもそれがもっとも少ない改造で京大の要求を満足する方法と思われた。この増設RAMをわれわれはRCM(Reloadable Control Memory)と名付けた。

関西支店からは入社したての柴田君が設計の手伝いに来てくれ、納入まで約1年間われわれといっしょに仕事をした。彼の高級車も動員してよく皆でドライブに行ったことを思い出す。伊香保に行った時、隣の部屋で飲んでいた連中に言いがかりをつけられた。彼は一人でその部屋へ出かけていき、河内音頭を歌っておさめてきた。

納入後萩原先生の研究室では渡辺 勝正先生等がこれを使ってファームウェアの研究をされていた。その後萩原先生が「マイクロプログラミング」という本を出版された時、8350のマイクロ命令語を付録に載せたいと希望され、われわれは喜んで応ずることにした。

 

 

9. おわりに

 

こうして8350との戦いは終った。

私が8350で実現したかったのは、一言でいえば「手におえる」製品を作りたいということだった。「手におえる」とは、予定の日程内に目標仕様、目標性能を実現する製品を開発し、できた製品が故障した時はその原因が容易に分かり修復できるということであった。8350の前に私が手掛けた8500はこれらの点でいささか「手におえない」ところがあった。これから量産する中小型機はこういうことではだめだと考えていた。この点では8350はほぼ当初の目標を実現できたと考えている。

世の中のコンピュータのウェイトはハードからソフトへ、そしてアプリケーションへと移りつつあった。ハードはもはや動くのがあたりまえになっていた。CPUはおとなしく部屋の片隅で働いていてくれればよいという時代になりつつあった。CPUでは商売が決まらない時代に入っていた。

時代は激しく動いていたが、汎用コンピュータの成長期の真っ只中であった。

そしてわれわれはみんな若くのびのびと仕事をしていた。

 

(完)

 

 

1994年9月(第1版)

1998年4月(第4版)

2009年2月(第5版)


Top       Copyright (C) 1998, Toshinori Sakai, All rights reserved