Cコンパイラ自体は、X68kを買ってすぐに手に入れた。しかしこれは、Cでの開発を行うというより、X-BASICからのコンバートが主な目的であった。もちろん、のちのちC自体を勉強しようとは思っていたけどね。
　結局1年ほど経ってから、ぽつりぽつりとC言語に触るようになった。

　UNIXの項で触れたとおり、C言語はUNIXのOS自体を記述するための言語として開発された。
　C言語の大元のルーツをたどると、Algolにまでさかのぼれるようだ。Algolはヨーロッパで開発された言語で、C言語のような構造化言語の親分的存在である。
　その後、影響を与えた順に書くと、Algol60→CPL→BCPL→B言語→C言語、という風に発展していったようだ。中でもBCPLの影響は深い。C言語の開発者であるデニス・リッチーもその策定に加わっていたので、それも当然と言える。

　C言語とBCPLを比べると、C言語は変数の型を大幅に増やす代わりに、制御構造を単純化している。C言語の肝である関数呼び出しも、多くのアセンブラで使われているスタックを利用したサブルーチン呼び出しの手続きを汎用化したものであって、大きな仕掛けではない。
　そう考えると、C言語は、各種のデータ型の取り扱いを(配列も含めて)規格化した、汎用アセンブラという雰囲気も感じられる。しかしその割には、例えばintが何ビット分のデータなのかが規定されていなかったりする。これは、Cのコンパイラが開発されるマシンの性能に合わせて、最適なデータ幅をコンパイラベンダーが決めて良いという事にしていたためだ。とは言うものの、それによる効率の向上よりも移植性の低下によるデメリットが大きかったように思うので、最初からビットサイズを固定しておけば良かったのに、と思う。

　C言語がアセンブラに近い低水準言語だと言われるのは、一つはポインタが自由に操作できる点にある。ポインタとは、マシンのメモリアドレスを格納した変数の事で、これを介して直接特定のメモリを読み書きできる。000047a5h番地に、35というデータを書き込め、みたいな事が可能なわけだ。
　こんな危なっかしい仕組みを直接言語仕様として保持しているプログラム言語は多くない。だが、メモリを直接触れるようにした事により、C言語はアセンブラに近い性能を持つようになった。

　さて、X68kでのCコンパイラのオペレーションとなると、ちょっと面倒な事がある。
　今でこそほぼ全てのPCにはHDDが搭載されているが、私の持っていたX68000PROIIには、そんな便利なものはついていなかった。全て、フロッピーディスクドライブでなんとかする。だから、Cコンパイラのような大物を動作させるのはちょっと面倒だった。
　実際には、まず起動用のディスクで立ち上げた後、そのディスクをコンパイラの入ったディスクと入れ替える。そちらがAドライブだとすると、Bドライブには作業用のディスクを入れておき、ソースコードや実行ファイルなどはこちらに格納される。そんな風に、ディスクの入れ替えを使わないといけない。
　そのため、日本語変換が出来ない。この頃のPCというのは、変換用の辞書をディスクに持っているため、辞書ディスクが入っていないと変換が出来ない。そもそも、コンパイラが使用するメモリが結構ぎりぎりなので、FEP(ASK)自体を入れていなかったりする。
　そういうわけで、私の初期のソースコードには、全角かな(これなら入力できる)でコメントが入っている。「/* ここがきおくりょういき */」みたいな感じで。馬鹿っぽくて面白い。

　X-BASICからC言語にコンバートできるという事は、BASICで書いたものがどうC言語になるかというのが見て取れるわけで、そういう意味では勉強になった。
　が、結局はコンバータ。C言語であっても、BASIC風の使い方でプログラムを書く。だから結局、C言語らしい使い方というのは身につかなかった。
　ありがたかったのが、シャープのCコンパイラのマニュアルに、最初のステップのところがかなり詳しく書かれていた事。これで、オペレーションからして良くわかってない私もどうにかコンパイルまではできた。
　が、そこから先はなかなか進まなかった。

　結局、のちに頑張って勉強し、C言語を習得するに至るのだが、それはまた後日のお話で。