🚀 go-pugleaf

kuno@gssm.otsuka.tsukuba.ac.jp wrote:
>久野です。
>
>james@james.jp9.orgさん:
>> 全文引用が「馬鹿げた」事かどうかは考え方の相違ですね。悪意なく，
>> 場合によっては恣意的，作為的に，適当に切り張りしたものを引用と
>> 称して，原文の主旨を勝手に変えてしまう，その様な事をボクは明確
>> に否とするだけの話です。
>
>  はあ、そういう引用にならないように心がけます。
>
>  しかし全文引用で議論してると記事がどんどん長くなって誰も読まな
>くなるんではないでしょうか。まあそれはさておき。
>
>> 「リンカーまで含める」とは， 
>> <1998Apr2.064056.4602@merope.opus.or.jp>中の第１パラグラフ，
>> 「『コードジェネレイター』だけが」で始まる部分ですね。「その環
>> 境の形式」には中間コードの.oや.OBJが含まれるのでしょうか。とな
>> ると，.OBJ形式の中間コードを出さないDOSのセルフコンパイラは，
>> 実はクロスコンパイラなのですか。
>
>  たとえば.OBJを出さずいきなりメモリ上に実行コードを吐き出すコン
>パイラもあっていいですよね。ただ、そのコードがそのコンパイラと同
>じ環境で動かないならそれはセルフコンパイラじゃないような気がしま
>す。
>
>> また，その様な中間形態のファイルは，何が含まれるのでしょう。コ
>> ンパイラの実装次第では，中間形態のファイルを大量に出す場合があ
>> りますね。それが全て一致しなければ，あるプラットフォームで動作
>> し，そのプラットフォーム用の実行コードを出力する開発システム内
>> のコンパイラは，実はクロスコンパイラなのですか。
>
>  同じ環境で動くかどうか、というのはシステムコールや呼び出しのコ
>ンベンションによって変わって来るわけですよね。そういうものを使わ
>なければ、命令セットアーキテクチャが同じならそりゃ動くでしょう。
>ですから、環境依存な部分を使わないようなプログラムをコンパイルし
>たコードがその環境で動くとしても、環境依存な部分を使ったらその環
>境で動かないコードが出るようなコンパイラはクロスコンパイラである
>ように思います。
>
>                確固たる定義というのは難しい…              久野



　全文引用で議論してると記事がどんどん長くなる，当然起こりうる事です。
その様な場合は，何に対するレス/フォローなのかを明確にしさえすれば，レ
ファレンスだけでも良いと考えます。

　この久野さんの記事，<6g4kf1$dvf@utogw.gssm.otsuka.tsukuba.ac.jp>の様
に，部分引用してもその原意が損なわれない様な引用ならば，それはそれでボ
クは是とします。問題は原意の改変です。

－－－

　中間コードを外に出さない/再利用可能な形ででは出さない，その様なコン
パイラ（というよりは開発システム）が存在する事は存じております。８ビッ
ト全盛の頃のＣコンパイラの中にその様なものがありましたし，ボクの記事，
<35239E24.67476193@james.jp9.org>中の，

>　まさかコード生成＝実行コードの出来上がりとなる様な，PIC16C用のCコン
>パイラ(もどき)みたいなものの話をしているのでは無いでしょうね。これは非
>常に特殊なケースです。

ば，将にその様なものの事を言っています。

－－－

　ですが話はその様なものではなく，中間コードは出すが，そのフォーマット
は.OBJ形式ではない，その様なものの話です。GNUのＣコンパイラとリンカを
DOSに移植するとします。現存するWin32用のGNU-Cの様に.OBJ形式の中間コー
ドを出すのではなく，UNIXで使っている.oの形式を出す様にします。リンカは
.oから.EXEを作るとします。

　こんな無用の苦労をする人がいるかは疑問ですが，それはさておいて，この
GNU-Cを含む開発システムの移植は，DOSやWindowsで動作し，DOSやWindowsで
実行出来るコードを生成します。しかし中間コードは.oの形式で，.OBJと互換
性がありません。では，DOSやWindowsで動作し，DOSやWindowsで実行出来るコ
ードを生成する，このDOS/Windowsで動く様に移植された開発システム中の
GNU-Cは，クロスコンパイラなのですか，とお聞きしているのです。

　また，この場合，ライブラリ内ルーチンが一致していて，同様の機能を果た
す様に出来ていれば，UNIXのGNU-Cコンパイラでコンパイルした.oファイルを
DOS/Windowsに持ってきてリンクすれば，DOS/Windowsの実行ファイルである
.EXEを作る事が出来ますね。この場合のUNIXのGNU-Cコンパイラはクロスコン
パイラなのでしょうか。当然その.oファイルは，UNIXでリンクすればUNIXで
動く実行ファイルが作れますよね。

－－－

　「環境依存な部分を使ったらその環境で動かないコードが出るようなコンパ
イラはクロスコンパイラであるように思います」ですが，同CPU，同バージョ
ンの同OSの場合においてすら，環境依存の部分は存在する事は，久野さんな
らご存じの事と思います。

　その一例がshadow-passwordです。パスワードアクセスに関連した実行ファ
イルはshadow-passwordを導入したものとしていないもので，互換性はありま
せん。shadow-passwordに作ったプログラムはshadow-passwordなしのシステ
ムでは動きません。その逆もしかり，です。

　ではshadow-passwordの有無によって，使用するGNUのＣコンパイラは違うの
でしょうか。shadow-passwordを導入した時に，ライブラリやヘッダの入れ替
えはしましたが，Ｃコンパイラの入れ替えはしていないのですが。shadow-
passwordが導入されている環境で，shadow-password無しの環境に対応するプ
ログラムを作成する際，別種のクロスＣコンパイラを使用しなければならない
のでしょうか。

　shadow-passwordが導入されているマシン上で，shadow-password導入前にイ
ンストールしたＣコンパイラを使って，shadow-passwordが無い環境用のプロ
グラムを作って，shadow-passwordが無い環境用で動かしましたが，問題無く
動きました。これは幸運だったからでしょうか。

－－－

　繰り返しになりますが，DOSマシンで，同CPU搭載の１ボードの開発を行う，
とします。DOSマシンと１ボードととは構成が大きく違うとします。ハードウ
ェア構成も全然違えば，１ボードにはDOSは載っておらず，独自のサービスを
持ったモニタがあるとします。そうですね，この１ボードではソフトウェア割
り込みの33番は，ユーザが起動出来る，ハードリセットを行うもの，とでもし
て於きましょうか。

　さて，本来そのDOSマシン用の実行コードを生成するための開発システム中
のコンパイラを１ボードの開発用に流用するとします。.OBJを１ボードにダウ
ンロード出来る形にする，リンカ/ローダ，ライブラリは揃っているとします。
そして，１ボード用のライブラリとセルフ用のライブラリは，互換性があると
します。これは，そのコンパイラがＣコンパイラとした場合，ソースコード中
にputchar(getchar());とあれば，標準コンソールの入力が標準コンソールに
出力される，その様な意味です。

　さて，めでたく１ボード用の.OBJファイルが出来上がりました。専用のリン
カ/ローダ/ライブラリを使えば１ボード上で実行プログラムが動作します。
DOS用のリンカ/ライブラリを使えば，この.OBJから作られた.EXEファイルは
DOS上で動作します。

　.OBJファイルを作ったこのDOS上のコンパイラ，このコンパイラはセルフコ
ンパイラなのでしょうか，それともクロスコンパイラなのでしょうか。

　この.OBJファイルに適当な処理を施すと，DOSで動く，１ボードで動く，ど
ちらの実行ファイルも作る事が出来る，この.OBJファイルは，セルフコンパ
イラの出力結果なのでしょうか，それともクロスコンパイラの出力結果なので
しょうか。

－－－

　「確固たる定義というのは難しい」その通りです。「これがクロスコンパ
イラ」などと簡単に言える訳がないですし，簡単に異って貰っては困ります。
それこそ山の様な限定や補足が必要なはずです。

　逆に，「DOS上で動いている，このH8用のコンパイラはクロスコンパイラ」
などは簡単ですけどね。一応調べれば，そう断言出来るでしょう。



　　　　James君