🚀 go-pugleaf

　久野さんの<6g56ch$hkq@utogw.gssm.otsuka.tsukuba.ac.jp>へのレス/フォ
ローです。


　最終的な実行可能コードを得るための，中間過程のコード，intermidiate-
codeの意味で，中間コードをしたのですが。最初は中間に括弧を付けていまし
たが，そのうち面倒臭くなって止めてしまいましたね。「オブジェクトコード」
「再配置可能コード」，object-codeは，.EXEやELFなどの実行可能コードをも
包括する「目的コード」ですし，元来リロケーションを必要としないアーキテ
クチャもある事ですし。しかし，OBJやo，RELが何を意味するかは分かっていま
す。その方がよろしければそうしましょう。

－－－

　クロスコンパイラの定義，難しいです。

　ですが，やはり狭義の「異アーキテクチャのコードを生成するコンパイラ」
は捨てがたいと思います。

　同アーキテクチャ，異プラットフォームの実行コードを生成するものはクロ
ス開発システムであって，必ずしもクロスコンパイラを必要とするとは限らな
い，と考えています。プラットフォームの差違をライブラリやリンカなどが吸
収する事は十分に考えられる事ですし，実際その様なものが世の中にあったり
します。

　開発環境のコンパイラが複数の開発システムで利用可能な場合，セルフ/ク
ロスの色分け自体が無意味と考えています。敢えて言うならばセルフ/クロス
開発システムの中のコンパイラ，またはセルフ的/クロス的に利用されるコン
パイラ，辺りが穏当で良いかもしれません。

　下位互換性を有するCPUのコードを生成するコンパイラ，例えばP5のコード
も出せる，iAPX86/10/20のコードも（当然ながら）出せるコンパイラ，これを
クロスと称するのは苦しいと思います。

　一応逃げを打って置きます，この見解に対する限定や補足は留保します。

－－－

　同CPU，異プラットフォームのクロス開発で使用されるコンパイラは，すべ
からくクロスコンパイラ，この様な主張，あるいはそう受け取られてもおかし
く無い様な主張，これに対してボクは異論を唱えているのです。同CPU，異プ
ラットフォームのクロス開発でのクロスコンパイラの存在や必要性を，真っ
向から完全否定しているのではありません。

　例えば標準ライブラリルーチンをインラインで展開する様なコンパイラ，例
えば，putchar('A');に対して，


	MOV	AH,2
	MOV	DL,'A'
	INT	21H

の様なコードを吐き出すDOSのコンパイラがあるとすれば，このコンパイラを
クロス開発システムの一部として利用する事は絶望的でしょう（プラットフォ
ーム次第ですが）。

　言うまでもない事ですがそれでも言ってしまうと，システムサービスの呼び
出し方法は，そのOSやモニタの実装に依存しますし，ユーザプログラムとシス
テムサービスをどの様に結び付けるかは，通常はライブラリの実装に依存しま
す。しかしその様な手法を取らないケースもあるでしょう。


　　　　James君