マイコンは、やがて１６ビットとなり、処理能力も安いミニコンに近くなる。当時、１６ビットマイコンは、インテルの8086、モトローラの68000、ザイログのZ8000などがしのぎを削っていたのだが、最初にザイログが落ち、MS-DOSという汎用OSを得て、当時の巨大メインフレームメーカーIBMに後押しされたインテルが、勝利を手中にしようとしていた。個人的にはインテルの煩雑な命令体形や、セグメントレジスタなどというややこしい代物が嫌いで、モトローラのMC68000が大好きだった。当時、組み込みシステムでも１６ビットCPUが使われ始めていて、命令体形やアセンブリ言語が綺麗で、アドレス空間が広い68000が好んで使われた時期もあった。しかし、１６ビットの世界では、そろそろアセンブラを使うことが重荷になりはじめていた。というのも、処理能力の高さから、開発するプログラムの規模もどんどん大きくなっていたからだ。
私が、その後長い付き合いになるC言語と出会ったのもこのころだ。UNIXとそのOSを記述している言語であるC言語は、アセンブラを使いこなせて、かつて趣味でPASCALのような構造化志向の言語をかじっていた私にとって、非常にありがたい言語だった。なぜなら、構造化志向の言語である上に、これまでアセンブラでしか書けなかった処理の多くが記述できるような仕組みが用意されていたからである。C言語をはじめて学んだ際に、「ポインタ」で苦しんだ人も多いだろう。でも、アセンブラを振り回して、メモリ空間狭しと飛び回るプログラムを書いていた私にとっては、ポインタは、CPUのインデックスレジスタと同じものだった。中身はメモリのアドレスで、＊をつけると、そのアドレスが示すメモリの中身を意味するところは、インデックスレジスタ間接アドレッシング命令そのもの。唯一の違いが、ポインタには「型」があることだ。この「型」のおかげで、メモリ上の値を、必要に応じた型の変数とみなして処理できるのである。実際に、コンパイル結果をアセンブラのソースコードに出力してみると、その仕組みがよくわかる。おかげで、処理速度の関係などで、どうしてもアセンブラで書かなければいけない処理を、Cの関数として呼び出す方法なども、誰に教えられるでもなく会得していた。C言語の参考書は当時はほとんどなく、故石田晴久先生が訳されたカーニハン＆リッチー（ＵＮＩＸ／Ｃの開発者）著の「プログラミング言語Ｃ」が唯一のテキストだった。みんな傍らに置いて、ボロボロになるまで読んだものだ。余談だが、この本（初版）の中に書かれている例題が、後々深刻な問題を引き起こすとは、誰も予想しなかっただろう。標準入力からの読み込みにgets() 関数が使われていたわけだ。ちなみに、このネタがわからないＣプログラマーはただちに廃業したほうがいい。バッファオーバフローの餌食にならないうちに・・・。
UNIX上のC言語はすでにかなり安定した存在だった。しかし、マイコン用のCコンパイラは、かなりきわどい代物で、時々、バグのため、間違ったコードを吐き出すことも多かった。某M社のコンパイラ（だけではないが）には、よく泣かされたものだ。どれだけ、Cのソースコードを眺めても動かない原因が分からず、仕方なくコンパイルをアセンブラソースコードの出力に切り替えてチェックしてみたら、おかしなコードが吐き出されていた・・・などということも少なくなかった。これはもう、アセンブラを知らない人だったらお手上げな事態だ。そういうようなこともあり、当時、Cなどという言語を振り回す輩は周囲のプログラマーから変態扱いされたものだ。特に、もう一つのCを頭文字に持つ言語のプログラマーたちには、絶対に理解できなかっただろう。
16ビットになって、そろそろ「マイコン」から「パソコン」の時代になる。ようやく実用的な用途に使えるだけの処理能力を得た「パソコン」は、ビジネス用途にも使われるようになる。しかし、一台のパソコンで出来ることには限りがあるので、最初は中小企業向けのパッケージソフトを動かすくらいが関の山、多くはワープロの代わりなどに使われていた。
一方、UNIXは、DEC社製のミニコン、PDP/11とか、当時、スーパーミニコンと呼ばれたVAX/11などの上で動いていたが、やがて、１６ビットマイコンのプラットホーム上でも動くようになる。これらはパソコンではなく、ワークステーションと呼ばれて、別の方向に発展しはじめた。当時のUNIXは、オリジナルのAT&Tバージョンとその派生版で米国カリフォルニア大学バークレイ校で開発されたBSDバージョンに大きく分かれていた。BSDバージョンは、バージョン4.2以降、TCP/IPプロトコルが実装され、当時次第に使われ始めていた初期のイーサネットを使ったLANを構成できた。御同輩にはおなじみの、イエローケーブルの時代である。これを皮切りに、UNIXネットワークの世界では、TCP/IPが標準となっていく。
一方、パソコンの世界でもネットワーク化が始まったが、最初、それはベンダ独自の方式だった。マイクロソフトはNETBIOSプロトコルを、ノベルはIPXプロトコルを、インテル系ではなく、モトローラを採用したアップルはApple Talkといった具合だ。一方、TCP/IPの実装も始まったものの、その目的はUNIX機との間の通信だった。つまり、PCをUNIX機の端末として使うためである。
マイクロプロセッサの技術は急速に発展していった。それと同時に、インテル系はパソコン、モトローラはワークステーションといった棲み分けがはじまり、さらにワークステーション用に高性能な32ビットCPUが開発される。モトローラの68020は、すぐれた32ビットプロセッサだった。一方で、インテルの80386は、いまだ16ビット時代のしがらみをかかえ、複雑怪奇な代物だった。しかし、マイクロソフトもまた、インテル同様、過去のしがらみ（互換性）に縛られていた。そういう意味でこの二社は最初から一蓮托生だったのだろう。
サン・マイクロシステムズを筆頭とするワークステーションメーカーは、そうした過去のしがらみにとらわれず、自由な発展を遂げていく。当時の技術では、インテルのような複雑な命令体系を持つCPUの高速化には限界があると言われていた。このため、新興メーカーは、高速化のために命令を単純化したRISC（Reduced Instruction Set Computer）アーキテクチャを生み出す。単純な命令セットしか持たなければ、たとえば高級言語をコンパイルした結果は冗長なコードになってしまう。しかし、コードサイズが倍になったとしても、処理速度が数倍向上すれば、結果的に高速化が可能だというのが、RISCの考え方である。一方、従来型のCPUはCISC（Complex Instruction Set Computer）と呼ばれ、両者のつばぜり合いが始まった。インテルは一時は、RISCに走りかけたが、過去との互換性維持の方針からCISCに戻り、x86系列のCPUを進化させていく。結果として、ワークステーションはRISCでUNIX系OS、PCは互換メーカーも含めたインテル系CPUで、MSDOSからWindowsという形が出来上がっていった。この流れはずっと続いていくように思われたのだが、予想を裏切る結果が待っているとは、当時は誰も思わなかっただろう。
（続く）
コメントする