記事
■  長寿の秘訣 - 長生きするソフトウェアを作る記事
@2004-09-11 17:36 (11476 ヒット)by kino

 K-Prologは、ちょうど第五世代コンピュータプロジェクト ('82-'92) が始まり、Prolog言語が注目されていたころ有名だった製品である。
 その頃からパーソナルコンピュータ環境が、16ビット機のUNIX,DOSから32ビット機のUNIX,Windowsに進化したが、OSとしてもオープンソースのLinuxやFreeBSDの登場もあり、現在では様々なPC環境が実現できるようになってきている。K-Prologはこれらの様々な環境に移植できるように設計改良されてきたが、本稿ではこのようなポータビリティの高いソフトウェアを実現するために考えてきたことを述べてみたい。

最初から移植を予定していた

 K-Prologを最初に開発したハードウェアは、東芝のUX-300である。PDP11ほどの名機とは思えないが、国産のUNIX機としては初期のものである。Prolog言語の開発としては2回目であるが、最初のものは受託開発でアーキテクチャーが自分の考えとは違うものでアセンブラ言語による開発だった。従って、UX300では初めてのC言語で初めての仕組みの言語処理系を開発したということになる。因みにその頃開発用に使用したエディタはedであり、K-Prolog全体のコンパイルには15分を要した。デバッガはadbという機械語レベルのデバッガがあった。現在の開発環境とは比べ物にならない劣悪な環境のようだが、当時としてはこれで十分な環境だったのだ。
 UX-300は16ビット機だったが、世界が32ビットになるのは目に見えていたので最初から移植可能にコーディングすることに決めていた。しかし、C言語の範囲で安全に書くことにするとメモリ性能がどうしても出ない。そこで、メモリのレイアウトについては機種依存性を排除しないというところで妥協することにする。UX-300のメモリ空間が命令56Kb+データ64Kbという狭さだったのでそうせざるを得なかったのだ。
 こういうことを考えていたのは1983年のことだから、もう20年以上も前のことである。

メモリ配置

 移植可能にコーディングすると言っても簡単なことではない。同じ32ビット機でも、メモリのバイトオーダとビットオーダには差があるので機種依存性をどこかで吸収しなければならない。バイトオーダがSparcのintが{1,2,3,4}の時、Vaxなどで{4,3,2,1}であることは知っている人が多いだろうが、バイトオーダが同じでもビットオーダにも差がある場合があるのである。さらに、構造体のメンバーのパディングやデータの整列の方式に差があることも判ってきた。
 K-Prologではそれをすべてマクロ(cpp)でカバーし、同じバス幅の機種では同じ仮想的なメモリイメージで動作するように設計を改良していった。

16ビットから32ビットへ

 16ビット機から32ビット機への移植は容易だった。その後、20機種以上の32ビット機に移植したが移植に要した最短時間は5分である(セットアップや品質検査にかける時間を除く)。
 最初の32ビット機は住友電工のU-StationとSun1.5である。Sun1.5というのは、Sunの最初のハードウェアSun1の確か最後のOSバージョンである。その後、大半の国産UNIX機とVax,それにマイクロソフトのXenixにも移植している。
 移植上の一番悩ましい移植上の問題点はCコンパイラのバグであった。バグを回避するための労力だけでなく、バグレポートを受け付けようとしないメーカとのやりとりもエネルギーを使う事柄なのだ。「それが仕様であるということならば、御社が正式の見解としてそう言っていることを公表しますよ」と言ってやっと認めさせたこともある。

システムコール

 移植対象はUNIXであったが、最初に開発したUX-300はVersion7からSystemIIIへの移行期のものであった。UNIXはその後、SystemV系とBSD系に分かれてゆくが、システムコールの差の調整も面倒な課題だった。当時は自社仕様が強い機種がありメーカはソフトウェアの移植性より自社固有技術のアピールに熱心だったので若干手を焼いたのもある。HPのHP-UX、IBMのAIX、NECの4800である。
 彼らがそんな変な競争をしていなければ、21世紀になってからSCOがLinuxを攻撃するなんてこともなかったはずだ。

 さて、一番面倒だったのは時間関係のシステムコールの調整である。ヘダーの置き場所、システムコール自体、時間解像度のすべてが異なり最も注意を要した部分の一つだ。OSによってはヘダーファイルにこの複雑さの歴史の一部が残されているので機会があれば眺めてみて欲しい。
/usr/include/time.h
/usr/include/sys/time.h
/usr/include/sys/times.h
struct tms
struct time
configureを知っている人ならば、なぜこんなことで困るのか不思議だろう。当時はautoconfもconfigureもなかったのだ。

ダイナミックローディング

 ダイナミックローディングとは、プログラムをコンパイルした結果のロードモジュールを実行中のプロセスに取り入れることである。dllやshared objectの仕掛けを使っている世代の人にはぴんと来ないかも知れないが、昔はこれは秘儀に近いものだった。Shared objectがない時代には、リンカーへの特殊な指示により指定アドレスから始まるロードモジュールを作成し、それをメモリ上に自分で配置する。OSによりシンボルの再配置(命令中のアドレスの調整)も自分で行なったりするのであった。
 現在では、dlライブラリによりこれらのことはシステム任せにできる。

LinuxとWindows

 1990年代初期に、PC-UNIXとWindows NTの機運が出てくる。16ビットのDos/Windowsではメモリの制約が大きく移植したくなかったので、NT用のMicrosoft Cを待っていた。いわゆるWin32APIである。
 PC-UNIXでは、需要予測の結果LinuxとFreeBSDに移植した。しかし、これらのPC版を製品にするのはWindows95を待つことになる。Windows95版で使用したコンパイラは結局Borland Cであり、製品の発表は95年の年末だったはずだ。Borland CはPosix仕様にほぼ準拠するライブラリAPIを持っており、UNIXからの移植が容易でかつコンパイル性能、実行性能ともに優れていたので採用した。それでも、UNIXからLinuxやFreeBSDへの移植と同じように一瞬で済ますと言うわけにはいかず、システムコール廻りでは調査にずいぶん時間をかけた。
 Windowsではfork()をUNIXと同じセマンティクスでは実現できないので、pipe()は自分で実装したりした。Windowsのライブラリで済まそうとするとProlog言語側からの使い勝手が違ってしまうのがいやだったからだ。

マーケティングとJavaの発見

 マーケティングについても書いておこう。
 主なマーケティング媒体は雑誌だった。共立出版の今は亡きBit誌には約15年間広告を掲載し続けた。その他には情報処理学会の学会誌にときどき出したくらいだ。その他UNIX機メーカの依頼によるセミナー、ユーザへのDMが主な広告手段だった。ニッチなユーザ層を持つ製品だったのでちょうど適合する雑誌に広告を出せば十分だったのだ。
 その頃コンピュータ業界の動向予測をどのように行なっていたかと言えば、NetNewsの流量と内容をウォッチするという方法を取っていた。この方法で1995年頃にはApacheの搭載によりインターネットサーバ用途でのLinuxが急成長することが看て取れるようになっていた。Apacheの隆盛を見てその頃にK-PrologのドキュメントをHTML化している。
 そして、同じ95年にはJava言語が発表される。この言語が世界に大きな衝撃を与え、普及してゆくことは公開された時点でほとんど明らかだった。発表の前に渡されたWhite paperを読んでゾクッとしたことを覚えている。
 97年にはJava1.1が発表された。 Java1.1にはreflectionという機能が搭載されており、これを使えば他の言語を容易に接続できるようになる。そのことを知っていたので、世界で最初にJavaと接続したProlog処理系を作る事ができた。このときは海外の人からは沢山反響をいただいたが、国内からはほとんど
反響がなく、また自分の会社での評価も低かったのである。しかし、この作業の結果多くの海外サイトからのリンクを得て、現在のkprolog.comサイトは、Googleランキングの上位に位置できることになった。これは大きな資産である。

  Google検索:Prolog+Java

 ちなみに、1995年のJavaの発表の時にはSunのカンファレンスに参加していたが、その時アナリストの女性に「LinuxについてはSunはどのような対応をするのか、脅威にはならないのか」という質問をしているが、Sunでは当時はLinuxは全く視野に入っていなかったらしい。
「Linux?なにそれ?BSDの一種か?Sunにとってなんでもないね」
というような答えだった。Javaの発表に自信を持っていたSunは、背後からゆっくり迫ってくる脅威に気がついていなかったのだ。

gcc/Mingw

 さて、32ビット化を待って移植したWindows版であるが、Borland C++のサポートがいまひとつ良くなかった。優れた処理系であったが、新しいバージョンのリンカーのドキュメントが不備で対応できないのだ。Borland Cの具合が悪くなってしまった原因はMicrosoftが開発責任者を引き抜いたからだという噂がある。真偽のほどは知らないが、こんなところでも影響を受けてしまうのだ。
 情報を得ることができずに古いBorland Cコンパイラだけへの対応を続けていた。Cygwinへの移植は済んでいたがライセンスが合わず製品化できずにいた。Cygwinの当時のライセンスではライブラリのライセンスがLGPLではなく配布が自由でなかったので、商用製品をその上で作ることが難しかったのだ。
 そこに出てきたのがMingwである。Mingwのライセンスならばコンパイル結果もライブラリも自由に配布できるので問題ない。Windows版をMingwに対応するのと合わせてSolaris版もgccに変更することにした。この結果、すべてのOSでCコンパイラとしてgccを使うことに統一できたので、今後は移植がさらに容易になることだろう。

 製品の歴史を通じてこれまで最も出荷が多かった対象OSはSolarisである。しかし、近年はLinux版の出荷も増えており、伸び率では最大となっている。Linuxを支持する者にとってこれはとても喜ばしいことである。


印刷用ページ このニュースを友達に送る

投稿された内容の著作権はコメントの投稿者に帰属します。
Powered by XOOPS Cube 2.0 © 2005-2012 The XOOPS Cube Project