コンパイラについて。

Question

言語のコンパイラって、究極のところは、人間がわかりやすい書き方を、コンピュータがわかる形に変えているだけですよね？

ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？
もちろん、すごい知識と技術が要求されるのはわかるんですが、理論的にはできるのかなー？と。

あと、最近は共通の動作環境を使うことが、新しい流れになりつつありますが。（．ＮｅｔやＪＡＶＡ。

用は、動作環境がＯＳの違いを吸収するんですよね？
当然、動作環境のハード側は、ＯＳによって違うと思います。
それぞれのＯＳのコンパイラを作るのとでは、やはり違うのでしょうか？
動作環境がＯＳの対応外の事をサポートしてたりもするのかな？

詳しい方、お願いいたします。

precog · Accepted Answer

コンピューターは常に性能との闘いなんで、泥臭いものです。

ハードウェアに近いと性能が出せますけど、作るのに大変だしシステムを不安定にする原因になります。従って全てを原始的なレベルで作るのは非合理的です。

それと、どんなに高級化してもハードウェアの性能の差は隠蔽できません。コンパイラーは記述を統一してくれますけど設計までは統一できません。

動作環境が導入される主な理由は、コンパチビリティではなくセキュリティです。動作環境が監視することで不正な活動をある程度防止することが出来ます。コンパイラーは一般的にOSの許すことはなんでも出来る様にデザインされます。が、これだけではネット時代には対応できないのでJAVAなどが普及したわけですね。

それとは別に、あまり使われないようなソフトを簡単に作れるようにしようとすると、共通ルーチンで足場を固めて行く必要があります。共通ルーチンは必要なものだけリンクする方法と、共通ルーチンをシステムで一つにとどめる方法がありますけど、オブジェクト指向は呼び出されるメソッドを特定しづらいのでどうしても全部乗っける話になります。というのと、30MBが例えば10MBになったとして、3つのソフトで10MBをリンクすると30MBになりますんで、すぐに元の木阿弥です。ってのがあります。

もちろんコンピューターは常に性能が関係する世界なので「30MBくらいゴミだろ」って話もありますけど。

tyamamoto · Answer

> ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？

実際に開発中のようです。

http://itpro.nikkeibp.co.jp/article/NEWS/20090805/335174/
によると、Windows上でMac OS用、Linux用のネイティブ・バイナリ・コード生成する「Project Delphi "X"」というプロジェクトが進行中のようです。

参考URL：http://itpro.nikkeibp.co.jp/article/NEWS/20090805/335174/

noname#119957 · Answer

たしかに、ＭＡＣが売れない理由は結局そういう部分だとおもいますね。言語の開発がwindowsに比較して遅れているからではないのかな？
一部のクリエーターに人気なのは、ブランド意識なのかなと思います。
それと、詳しいユーザーには、UNIX環境が人気なのかなと思います。
MACの可能性は、基本がUNIXな点にあるのかもしれませんね。
**

用は、動作環境がＯＳの違いを吸収するんですよね？
>>？？

当然、動作環境のハード側は、ＯＳによって違うと思います。
>>入出力のライブラリとか？（ＰＨＰのＰＥＡＲとか？）

それぞれのＯＳのコンパイラを作るのとでは、やはり違うのでしょうか？
>>ＯＳが違えば当然コンパイラ自体が別物で共通部分はソースのみ

動作環境がＯＳの対応外の事をサポートしてたりもするのかな？
>>？？

プログラマがＯＳに依存するコード（関数など）を使用しなければ、プラットホームに左右されないソースは書けると思います。
**
コンパイラはあくまでもＯＳの基本機能（システムコールなど）への変換を行うようなものなので当然ＯＳ毎に異なってきます。コンパイラとＯＳの間にもうひとつの階層を設けることはＯＳのエミュレータのようなものになるかとおもいます。そうなると元々のＯＳ自体に意味がなくなると思います。
**
結局、世の中を便利にするには、ＯＳを統一するのが正解になってきます。そうなるとＷＩＮＤＯＷＳかＭＡＣ・ＬＩＮＵＸ・ＵＮＩＸ・・・・のいずれかに統一すればよいことになると思います。しかし、それは無理で・・

**
現在の、ＯＳはそれぞれの役割を果たしていますので、いまのままでいいのかと思います。お役所仕事ではなく、みんな企業ですからね。。

**
ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？
>>それが売れるという保証はないのでやらないだけでしょうね。

cametan_42 · Answer

ちょっと一応纏めておきましょうか。

＞Ｗｉｎ、Ｍａｃ、Ｌｉｎｕｘの３つのコンパイラを作って、３つのアプリができれば、動作環境を入れなくても動くのになー、と。
＞こっちの方が楽な気がするんですが。

全く仰る通り、です。
そもそも質問のスタート地点が「Delphi」と言う単一ベンダーによる一実装だったので、ポイントが見え辛かったんですが、元々C言語なんかもそう言う発想ですよ。Pascalもそうですし。そもそも「高級言語」では、プラットフォームを変えても書いたコードは再コンパイルすればどこでも動く、と。全くその通り、です。理想的には、ですね。
ただし、「ソフトウェア」が複雑化してきた、って事なんですよね。APIの話が出てきたように、OSが「提供している」ツールとかが、プラットフォーム毎に違ってくると「言語自体」に互換性があっても「その他諸々」の部分で引っかかってくる、と。移植性に難が出てきたのです。
いずれにせよ、ここである「互換性」ってのは70年代までの技術上の話なんです。

＞中間言語コンパイラ

これは#6でも書きましたが、別にJavaの専売特許、ってわけではないです。Java以前(例えば初期のPascal)からありました。
#3の方が説明していますけど、中間言語を実行するインタプリタがターゲットとするOS別に用意されていたら、一旦コンパイルしたアプリケーションはどのプラットフォームでも動きます。Javaで言うと、細かく言うとJVM(JavaVirtualMachine)、大きく言うとJRE(JavaRuntimeEnvironment)ですよね。仮想マシン、とか呼んだりしますが。元々の質問で言う「共通の動作環境」ってのはこれを指してるんでしょ?
これは#6でも書きましたが、大昔から「ある」仕組みなんですが、Javaが登場した辺りではじめてPCのパフォーマンスでもこう言うのを動かしても問題が少なくなった、って事です。それ以前だと、計算機資源は貴重だったんで、「発想は良い」けど「実用的には疑問符」だったんですよ。
OSや仮想マシンは、別の一般的な呼び方で「レイヤー」(階層)とか表現したりするんですが、要するにOSが一つのレイヤーでJVMはその「上に」乗ってるレイヤーですよね。そのレイヤーの頂点でアプリケーションを動かす、と。考えてみれば凄い「重そう」ですよね(笑)。でも、現代のPCのパフォーマンスでは大した問題じゃあありません。

ところで、JVMみたいな機構はJavaの専売特許ではない、んで、そう言う意味では別に独創的なアイディアじゃないんですが、結局#7さんが丁寧に解説してくれてる通り(タイポが多いですけど)、JREのポイントは「独自のAPIやライブラリ」を提供してくれている辺りですよね。
今、JREが面白いのは、恐らくJava自体は大して魅力が無い言語なんですけれども(笑)、このJREが提供しているツールを自在に使える「JVM上で動くプログラミング言語」が実験的ではあれ、色々と開発されている、って事です。つまり、フルスクラッチ(一から組み上げる事)で移植性を考慮したプログラミング言語特有のライブラリ等を自作しなくても良い、と。「流用しちゃえば」オーケーなんで。これはプログラミング言語開発者側にとっても、ユーザーにとってもメリットがありますよね。
例えば、今はJDK(JavaDevelopmentKit)に同梱されていますが、Rhinoと言うJVM上で動くJavaScript処理系なんかがあります。

Rhino:
https://developer.mozilla.org/ja/Rhino

RubyのJavaによる実装、JRubyも有名ですよね。

JRuby:
http://jruby.codehaus.org/

他にも、ハッカー連中が注目している、Lisp新方言「Clojure」なんかもあります。

Clojure:
http://clojure.org/

つまり、言語として「Java」を選ばなくても、JVM上で動くプログラミング言語があればそれを「使って」プラットフォーム非依存のアプリケーションが書ける、って事です。

注:割に、JVMで動くLisp系言語処理系を作ろう、って動きは昔からあって、翻ってみると言語「自体の」パワーはともかくとして、見栄えのいいアプリケーションを書く為のライブラリがLisp系言語には殆ど無い(あるいは、あってもドキュメントが完備されていない)、と言う不満が多かったんでしょう。JavaでLispを書けばこの辺は一気に解決しますから。

こう言うレイヤーの増加は#7さんが仰ってる通り、マシンの速度が上がるに連れ「効率性」より「利便性」が重視されるようになってきた、と言う結果です。トレードオフがあって、「利便性」が上がれば「効率性」は落ちるんですが、結局、人員を大量投入した「効率的なコードの」開発コストの方が肥大化してきた、って事でしょうね。
ですから、あらゆる意味で、#8さんが仰ってる通り、

＞その30MBのおかげてソフトが1MBで収まるのです。

ってのは適用出来るでしょう。OSの上にレイヤーがもう一つあれば、開発コストも削減出来る、って事でしょうしね。

Tacosan · Answer

「共通の動作環境」というなら P-system なり P-code なりを出しておこう. 30年以上前ですけどね.

tom233 · Answer

>でも、１ＭＢのソフトを動かすために、３０ＭＢくらい？をインストールするのは、何だかなー、という気にもなります。
その30MBのおかげてソフトが1MBで収まるのです。

mitoneko · Answer

＞ちょっと知りたかったのは、なぜ動作環境をかませる開発環境が普及したのかなー？と。

　ハードウェアの違いは、ＯＳが吸収してくれます。というか、それがＯＳの大きな仕事のひとつです。
　その上に、もう一枚皮をかぶせれば、ＯＳの違いを吸収することも可能です。これをやろうとしているのが、ｊａｖａとか．ｎｅｔですね。
　ところで、皮を一枚かぶせるたびに、機能か性能（もしくは両方）は低下せざるをえません。
　どんな環境でも同じように動くようにしようというのが、皮を被せる目的ですから、両者に違いがあれば、同じところだけを抽出して使えるようにする（この場合、機能が低下する）か、他者にない機能を、シミュレートして同じように動くようにする（この場合、速度・リソース使用量などの性能を犠牲にする）かということになりますから。

　いま目の前にあるハードウェアの性能・機能をフルに活用しようとすれば、総てのプログラムを機械語で書くことになります。技術と無限の開発時間があれば、これが一番です。でも、そのプログラムは、そのマシンでしか動きません。
　人間がわかりやすい・汎用性があるという言葉から一番遠いところにいる開発手段です。
　これでは、あまりに酷いので、ＯＳと高級言語が登場します。これで、同じＯＳなら、同じプログラムが動くようになり、同じソースコードなら、ＯＳに依存した部分以外は、他のＯＳでも動くようになります。
　これが、ＯＳや高級言語などの形で、皮を被せてきた大きな目的の一つです。「機能の汎用化」というか、「下位の土台の違いの吸収」というか・・・まぁそぉいった目的です。

　ところで、近年、ＯＳがどんどん高機能になり、複雑化していく中で、ＯＳの機能をちゃんと使おうとするだけでも何か手助けが欲しい状態になってきました。（例えば、windwos環境でプログラミングする時には、ＯＳの機能にアクセスするために、win32APIというＯＳ独自のインターフェース（ライブラリー）を使用します。例えば、Ｃ言語で、ウィンドウの真ん中に「hello world」と表示するＧＵＩプログラムを書くだけで、１００行以上のソースを書く必要があります。ちょっと大変です。）

　この大変さを解消するために、最近の開発環境では、ＧＵＩの部分をマウスでお絵かきする感覚で作れば、開発環境が自分でその部分のプログラムを自動で書いてくれるというものが登場しました。これを実現するために、開発・実行環境という皮を一枚被せています。
　この皮は、さっきの話題の「機能の汎用化」と言った目的と全く違う目的で被せています。それは、「プログラミングの自動化」です。
　Delfhiの大きな目的の一つは、GUI部分の開発に関して、ボタンやメニューなどを部品を貼り付けるだけで、基本的な動作を「自動的にDelfhi開発環境がプログラミングする」ということです。
　自動的に作られた部分が、自分で作ったより目に見えて遅かったり、ＯＳにある主要な機能が使えなかったりしたら、開発環境そのものの目的が果たせませんから、この皮は、ＯＳにべったりと依存することになります。（例えば、windows準拠のメニューを出すという部品の構成は当然、windowsに依存しますよね。）

　一方、ｊａｖａ等の目的は、ＯＳによる差異を吸収することが主要目的ですから、機能や性能には若干目をつぶっているところがあります。（開発・実行環境も、見方によっては、ＯＳの上にもう一つのＯＳを被せたかのように見ることもできる構造となっています。ＯＳの主要目的の一つは、それより下位の違いを吸収することにありますから、その意味では、ＯＳ上のＯＳですね。）
　そして、この上に、更に「プログラミングの自動化」の為の皮を被した開発環境も存在します。当然、それらの開発環境は、今度はＪＡＶＡ実行環境に依存する開発環境となります。

　こんな感じでイメージできますか？

cametan_42 · Answer

＞ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？

元々、Mac用にDelphiも提供されてたんですよね。

FreePascalと言う処理系があります。

FreePascal:
http://www.freepascal.org/

FreePascal(Wikipedia):
http://ja.wikipedia.org/wiki/Free_Pascal

完全互換ではないみたいですけど、これ使えばDelphiっぽいプログラムをMacでも書ける模様です。
試してみては?

＞最近は共通の動作環境を使うことが、新しい流れになりつつありますが。

いや、別に「最近は」じゃないです。仮想マシン技術は昔(Java以前)からありました。ただし、大昔は遅くて重くてしゃーなかったようです。
結局「最近は」が本当にかかってるのは、Java登場時点辺りでPC自体のスピードが

「仮想マシンを動かすのに無理が無い」

程に速くなってきた、って事ですよね。
元々、Pascalなんかも設計当初では「仮想マシン上で動く」コンパイラを提供してた模様です。

vaidurya · Answer

単純に人が理解できる言語でプログラムを作っているのは
まぁアセンブラまでの話です。

私自身はハンドアセンブルだけ必要に迫られてやったことあるけど
とてもじゃないけど、全部をハンドアセンブルで開発するとか無理。
アセンブラを使えばマシだけど、開発性も修正性もはげしく低い。
言い換えれば、その都度全部を一から作っていたら効率が悪いという話です。

ですから、より新しい言語ではライブラリーが用意され
それを静的リンクしたプログラム開発に移行しました。
Windowsでは動的リンクされるライブラリーが増え

現在ではある程度大きなプログラムでは
1.単純に計算などを行なうコード
2.静的リンクされるライブラリを呼び出すコード
3.動的リンクされるライブラリを呼び出すコード
4.OSのAPIを呼び出すコード
この四つに分類できます。(四つでいいかはよくわかりません)

1.にはCPUのアーキテクチャの違いという問題が含まれて
これは、intel用のソフトをPowerMacに移植する際の大きな障害でした。
ただし、ほとんどの部分は互換性がとれるからこそ
LinuxやNetBSDは、x86,R3000,ARM,SPARC,68k,PPCほか多くのCPUに対応しました

2.はDelphiやVisual C等に付属しているもので、これと同等のものを
ソースコード無しに、第三者が開発することは非常に困難です。
でも、それが無ければ互換性を得ることは不可能です。

3.はWindows付属のものなど、自由に入手できないものについては
同等のものをMac用として開発せざるを得ません。

4.APIの違いはOSの違いの最たるものなのですが、幸い既に
実用段階のWin32APIの互換ライブラリがあります。
つまりWineであり、それを応用したCrossOver Macです。


動的ライブラリについては、無償で配布されているものも多いので
intel CPUを採用したLinux,FreeBSD,それにMacOSXの環境では
DLLとWineを導入することで、Windowsソフトの一部が動きます。

言い換えれば、DelphiでMacintosh用ソフトを作るより
CrossOver Macを使う方が、まだ現実味があると言えます。

しかしDirectX等を利用したゲームソフト等には対応できませんし
やはり、元からMacintosh用として書かれていなければ
簡単にコンパイルの設定だけでMacintosh用になったりしません。

Javaの強みは、そういった特有の機能のすべてを一つにまとめ
Java Virtual Machineという形式を作り出したことにあります。
そもそも、彼らはWindowsに依存しないためのVirtual Machineデザインをしたのですから。

tom233 · Answer

>別に、Ｗｉｎ、Ｍａｃ、Ｌｉｎｕｘの３つのコンパイラを作って、３つのアプリができれば、動作環境を入れなくても動くのになー、と。
こっちの方が楽な気がするんですが。
もうそういうのありますけど
 WideStudio/MWTが有名ですかね。

>「Ｗｉｎで使っていたソフトを、Ｍａｃに移動させて使いましょう！」って事も、あんまりないかなー？と。
インテルMac限定ならもうそういう環境ありますけど
WineやCrossOverが有名ですかね。(すべてが動くわけではないけど)

>小さなフリーソフトを入れるために、大きな動作環境をインストールしたくないというか
そのフリーソフトのサイズが小さく済むのも.NET環境のおかげてコンパイルしたアプリが肥大化しないですみます。

コンパイラについて。

コンピューターは常に性能との闘いなんで、泥臭いものです。

> ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？

たしかに、ＭＡＣが売れない理由は結局そういう部分だとおもいますね。

ちょっと一応纏めておきましょうか。

「共通の動作環境」というなら P-system なり P-code なりを出しておこう. 30年以上前ですけどね.

>でも、１ＭＢのソフトを動かすために、３０ＭＢくらい？をインストールするのは、何だかなー、という気にもなります。

＞ちょっと知りたかったのは、なぜ動作環境をかませる開発環境が普及したのかなー？と。

＞ＤｅｌｐｈｉはＭａｃで動くソフトは作れないのですが、Ｍａｃ用のコンパイラを作れば、動くのではないでしょうか？

単純に人が理解できる言語でプログラムを作っているのは

>別に、Ｗｉｎ、Ｍａｃ、Ｌｉｎｕｘの３つのコンパイラを作って、３つのアプリができれば、動作環境を入れなくても動くのになー、と。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング