【超高速】C/C++に代わる低級言語を開発したい 8
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。 しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。 そこで、このスレッドでは、 低レベルなシステム開発のためのプログラミング言語 を一から考えたい。 既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、 「既存のXX言語を使えばいい。」という類の発言は無意味である。 「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。 現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、 一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、 という観点で考えたい。 ◆前スレ 【超高速】C/C++に代わる低級言語を開発したい 7 http://toro.2ch.net/test/read.cgi/tech/1275235018/l50 Cを高級アセンブラという人はアセンブラを知らない。 高級アセンブラは p-code や IL。 俺は C よりアセンブラを先にやったクチだが C はまっとうな高級アセンブラだよ ソフトウエアで構築したVMが機械語のつもりのやつこそ diagnose 命令を知らない 初期のCは高級アセンブラと言って良かったが、最新のC/C++はインラインアセンブラがサポートされなくなってきたので 高級アセンブラとは言いにくくなってきた。Cはロジックのわかりやすさを優先して、CPUのレジスタを意識させない構文に してしまったから、レジスタを意識しなくてよくなった反面、フラグを見ることもできないし、CPUの固有命令を使うことも できない。インラインアセンブラも使えなくなってきたので、いろいろある言語の1つに落ちぶれてしまった。 簡単なサンプルをCとアセンブラで書いて比較すると速度が違うし、実行ファイルサイズも大きく違う。 Cは非常に無駄が多いということだ。 インラインアセンブラは関係ない 特権命令が必要な箇所はもともとアセンブラで書いてリンクするのが正統派で Cソースの中に直接ニーモニックを書くのは邪道である フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ レジスタ名称もそうで、このためアセンブラはオンレジスタ、Cはオンメモリという相違が生じた アセンブラを習得している者がCを憶えるとき自動変数に違和感を持つのはこのためで いついつからCがそうなってしまったわけではなく、始めからそうなのだ Hello C world のサイズだけ見てCそのものが非効率という人は サイズの違いの主成分を知らないだけ >>76 > Cソースの中に直接ニーモニックを書くのは邪道である 今まで正式な文法としてインラインが書けたのに、それを勝手に邪道と言い切るのはどうかと。 単なる個人的意見だよね。 > フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ > いついつからCがそうなってしまったわけではなく、始めからそうなのだ もちろんわかってるよ。別にCの文法に文句を言いたいわけじゃないから。 でも抽象化できるというなら、ニーモニックを直接書ける仕様にして、 それをラップ関数で覆って見えなくしてライブラリに入れてしまえば Cで書いたソースはそのまま使えるよね。 > Hello C world のサイズだけ見てCそのものが非効率という人は > サイズの違いの主成分を知らないだけ その主成分を知ってる人に聞きたいんだけど、アセンブラでは不要で、 Cならその主成分とやらが必要という根拠は何か教えてくれないかな。 インラインアセンブラなら、ふつうのユーザーもビルドで悩まないですむ 移植性を重視した言語なのにasm文があるのは何故ですか? asm文は、Dの関数内に直接アセンブリのコードを書き込むことを可能にします。 アセンブラのコードは自明に移植性のないものとなりますが、しかし、 システムアプリの開発には非常に便利なものです。 システムアプリは 大なり小なりシステム依存のコードを含むことになるので、 インラインアセンブラは 大した問題にはなりません。 インラインアセンブラは、CPUの特殊命令や フラグビットへのアクセスによって、 特別な処理の場合や、 限界までコードを最適化したいときに役立ちます。 Cコンパイラがインラインアセンブラ機能を持つ前は、 私は外部のアセンブラを使っていました。 アセンブラは 沢山の、本当に沢山のバージョンがあって、 各バージョン毎に微妙に 構文が違っていたりバグがあったりコマンドラインの文法まで 変わっていたりして、非常に残念な思いをしました。 つまり、アセンブラの必要なコードは、 ユーザーには安心してビルドはできなかったのです。 インラインアセンブラができてからは、そんなことはなくなりました。 よくある質問 - プログラミング言語 D (日本語訳) http://www.kmonos.net/alang/d/faq.html#q1_1 >>53 英語で middle-level 検索したらでてくる >>77 単なる個人的意見? #pragma のオンパレードと同じだと言っているんだが 単にニーモニックが書けるだけでは不十分で オペランドの装飾名やレジスタアサインまで最適化の影響も受けずにクリアする必要がある 高級言語でだぞ? これを邪道だというのの、どこが個人的意見なんだ? > ラップ関数で覆って見えなくして 日本語でおk > その主成分を知ってる人に聞きたい 逆アセンブル読めよ、読めないならもう一度言ってやる「主成分を知らないやつめ」 >>78 asmがあるのはなぜって、俺に聞くのはお門違いだ 移植性を重視しながら sizeof(int) が処理系定義だしねえ > システムアプリは大なり小なりシステム依存のコードを含むことになるので そのとおりだが > インラインアセンブラは大した問題にはなりません なぜこうつながる? > 私は外部のアセンブラを使っていました。 過去形ということは「あの問題」を知らないわけだね このくだり、突っ込みどころ多すぎて投げたわ >>80 なんだ、ただの知ったか君か、ご苦労w もう来なくていいから >>81 おいおい、>>78 はD言語のFAQのコピペだぞ。つまり「私」というのはD言語の開発者だ。 どう見てもおまいよりコンパイラの内部に詳しい。 「あの問題」とかわけわかんないこと言ってんじゃないぞw 知ったか君はろくに文章も読めないから困る。話にならんな。 >>80 日本語不自由な人みたいなので wrap function と書けば理解できるのかな。在日君ですか? Cがアセンブラより太る原因は逆アセなんかしなくてもわかるんだが。 おまいさあ、Cコンパイラのソース一度も読んだことないだろw 「低レベルなやつめ」 Cのファイルサイズサイズ語るならリンカだろ? gcc読むにしてもCコンパイラ部分は読まねえよ。 コンパイラなら普通にアセンブリ吐くから逆アセンブルもしねえ。 >>84 いーや、逆アセよまなきゃ10倍にもなる理由は説明できない コンパイラのソースとか何言ってるんだ? 頭が発狂したのか? 具体的な説明でもobjdumpで十分だろ。 逆アセンブルしたコードなんて読まねえよ低能。 逆汗読めねえ低脳でもリンカのマップくらい読めよせめて ついに逆アセンブルに意味がないことを認めてしまった低能w は? 10倍という定量的な値に反論できないのはてめえだろうが 説明出来れば十分だろ? 構造とシンボル情報見せてlibcの初期化コードが含まれているで十分じゃん サイズ知るためだけに逆アセンブルコード読む必要なんて全然ないだろw どこに必要あるのか言ってみろよ低能w それは10倍にならないコードを示せれば充分だ Hello World しかできねーバカにそれは無理だが このまま逆アセンブルが必要である具体的な理由を示せないなら負けだぞ低能 別に負けで結構だ 有料なノウハウをただでぶちまける必要はない 具体的に言えないどころかあえて言わないだってw ここまで否定してきて根拠も出せないw まさに負け犬の遠吠えw readmemoryとか writememoryがどうなるのだろうか scalaみたいな、Cかアセンブラのコードに変換してくれる言語作れば? PGはバカでいいという思想はCOBOLの轍そのもの 開発環境は言語のうち つまりVisualStudioを超える開発環境を作れ >>103 Javaも割とその思想が入ってる まあJavaの場合はC++がPGを過信してることへのアンチテーゼもあるんだろうけど PGはバカでいいというなどという突拍子もない捉え方は1ビット脳そのもの なぜ中間がないのか >既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、 >「既存のXX言語を使えばいい。」という類の発言は無意味である。 >「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。 >現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、 >一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、 >という観点で考えたい。 >>1 大事なのは俺TUEEE感に浸れるかどうかだから 既存のものを流用するなどというのは根本から間違っている トランスコーダから始めよう。 謎言語toASMが最終目標だ! >>110 既存の言語を使えと言って思考停止するのは間違っているが 既存のものを流用するのは間違っていない。 C言語が糞なのはヘッダファイルが原因だ #includeが#importになれば全て解決する 上からモノ言う人って、すごい人なのかと思ってた。 でも意外とそうでもないんだね。 昨日、C言語スレで構文解析の話題があった時、上からモノを言ってくるので 凄い人だと思って話を聞いてたら、実は初心者だった。 RUSTってC++と比較されるけど低レベル組み込み系もいけんの? C++、stlが許されるだけのリソースがあるなら大丈夫そうだ。 コンパイル時リフレクション(javaでいうアノテーション・プロセッサ)がほしいな シリアライザーとか自動でつくってほしい vecterはc、c++から外して欲しい、元はjavaだろ、イテレータとか。 ___ _ ヽo,´-'─ 、 ♪ r, "~~~~"ヽ i. ,'ノレノレ!レ〉 ☆ 日本のカクブソウは絶対に必須です ☆ __ '!从.゚ ヮ゚ノル 総務省の『憲法改正国民投票法』のURLです。 ゝン〈(つY_i(つ http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html `,.く,§_,_,ゝ, ~i_ンイノ 言語作ってるんだけど、 コンパイラ作る時って一旦アセンブラ出力してからmasmとかに機械語出力してもらった方がいいの? masm自身はアセンブラコードの最適化とかはしてくれなそうだしそのまま機械語出力したいんだけど アセンブラ介したほうが少なくともデバッグはしやすいと思うぞ そのコンパイラで何ができるもしくは何をやらせるのかも 決めてないんだ >>134 どれくらいしやすくなる? 命令のバイナリ列を理解しやすい(?)形でアセンブラに1対1で置き換えてデバッグする、っていう手間が省ける程度なら雀の涙という感じ むしろデバッグするときは結局機械語読むことになるから最初から機械語で出力したほうが理解が早い気もする それ以上のメリットってなにかあるのかな >>135 一応決まってるよ Windows8以降向けのUI・ゲーム開発言語 x86系の命令、16進数で読めるんだ なら、直接コード出して、ハマりまくったほうがいいかもね >>136 用途からすると機械語やアセンブラへのコンパイルどころか C言語+HLSLへのトランスレータが最適解な気もするなあ… 結局、何だかんだでDirectXの関数呼ぶことになりそう んで関数呼び出して処理するなら、機械語とC言語の差は間の計算処理になるが そこも巷のC処理系の最適化はノウハウ詰まってるから 下手なアセンブラコードより速かったりする 何れにしても何層かに処理を分けることにはなるだろうから いきなり全部やろうとするより、やるべき層をひとつひとつ集中してやったほうが >>137 わーい >>138 そのとおりです DirectXの関数は呼ぶよ。でもスレの主旨的にもC言語を介したくないのよね GPUへの命令はさすがに手に余るからとりあえずHLSL出力することになると思うけど… ううーん。とりあえずCに翻訳してコンパイルして、でてきたアセンブリを研究してみようかな ありがとう 本スレは、コンパイラをどのように作るか、ではなく、どのような言語仕様にするか、を重視しています。 コンパイラの話が終わったら、言語仕様の話をしましょう。 LLVM/Clang 実践活用 ハンドブック、出村成和、2014 LLVM 言語マニュアル(Language Reference Manual) ttp://www.h3.dion.ne.jp/~mu-ra/llvm/LangRefJ.html 日本語訳です。ただし、翻訳は適当と書いてある >>140 ,142 奥が深そうだねえ どれくらいのパフォーマンス出してくれるのか想像つかない >>141 C/C++並の低レベルプログラミングができて、人間が話せて、かつ人工知能も理解しやすいような言語という設定でいろいろ考えてる 自然言語に声調というのがあって、これは抽象化すれば音階としても処理できるから、人工知能にも扱いやすいし、 音階の配列である声調は命令の配列である機械語とも相性が良い。 LLVMはフロント・ミドル・バックの、3つの部分に独立している フロントはプログラミング言語とコンパイラ Clangなら、C/C++ → IR ミドルはコンパイル後の擬似的なアセンブラ。IR(中間コード) バックはx86,ARMなどのCPU 新言語を作っているなら、 フロントのコンパイラ(字句・構文解析)の部分だけを作って、 IRになるようにすればよい >142の本を買うのが速い >>143 「人工知能も理解しやすい」というのはコンパイラにとって効率が良いという意味? >>145 人間との会話のときに相互の情報伝達の効率がいいということ わりと強めの人工知能を想定している >>146 その効率はプログラミング言語としてどういう意味を持つの? >人間との会話のときに相互の情報伝達の効率がいい いわゆるドラえもんをつくる気か。すごいな。 何でも良いけど、動作速度がトロくて高級言語がとかぬかして ジェネリック要求してくるLL使いが鬱陶しいわ >>1 Cは高級言語だ。 そんなことも知らないのか。 >>147 基本的な記述はより直感的になるし、抽象度の高い表現もそのまま扱える プログラミングと会話は違うけど、そこをあえて統一した規格で表現できるような言語仕様 >>2 にも書いてあるように既存のプログラミング言語にないような機能でプログラム書いてみるの楽しいでしょ >>149 そうそうそんな感じ >>152 人工知能とか、ネタなのか本気なのか分からなかったので若干しつこく聞いたけど、本気ならその方針で面白いものへと広げてほしい。 といいながら、興味本位で聞いてしまうけど、人間はともかく、人工知能にとって「直感的」ってどういうことなの? 人工知能ってコンパイラだよね。コンパイラにとっての直感性というのが分からなかったので。 それと、作りたいのは「言語」でいいんだよね?コンパイル可能な自然言語とか。 しゃべればしゃべるほど非マの妄言と化していくな 板違いだべ >>153 純粋なコンパイラというよりはコンパイラとインタプリタを統合した処理系だね。 Prologのような対話(厳密にはうちの言語のは対話ではないけど似たようなもの)を繰り返してプログラミングすることもできる。 その場合、処理系は対話によって学習できるし、学習したところから発話もするように考えてるから人工知能と呼んでいる。 人工知能にとって直感的っていうのは、手続き型の制御フローに沿った発話がそのままできるってこと。 たとえばうちの言語はそもそも語順がかなり自由だから、手続き型プログラミング的な構文をそのまま人間の言葉として理解できる、とか。 一言で言えば言語だね。芸術言語とプログラミング言語を足したようなものだよ。 >>155 OK。現状ではコンセプトを理解するのが難しいということがわかった。 早く具体的な言語仕様を知りたいので、ぜひその議論を進めてほしい。 Cは高級言語であって、スレタイがすでに間違ってるのに、お前ら はあほか、こんなものを続けて何の意味があるんだ。 高水準言語の基準は人間がそのまま動作を読み取れる言語だろ よってC言語は当然高水準言語 ハードウェアを直接操作できるのが低級、できないのは低脳 高級、低級の呼び名はどうでもいい。C言語を低級言語と呼びたくないならそれでも構わない。そのことに大した意味はない。 スレタイの意味は>>162 がほぼ正しい。 >>162 の言葉を借りれば、「ハードウェアをオーバーヘッド最小で直接操作できる言語」、それがこのスレで言うところの低級言語。 低級言語という言葉が嫌なら、ハナモゲラでもゲゲボでも好きな呼び方をすればよい。 但し、呼び方を使用する前に、定義を明確にすること。 Cは昔から「高級アセンブラ」と呼ばれていたと思ったが >>157 どうやっても個人開発だから実験言語までいけばいいところだね。 それでむしろ実用的な最適化とかはちゃんとノウハウのあるところに開発してもらうのが一番いいんだけどな。 高級言語でも低級言語でもないから、中級言語である。 There are following reason that C is called Middle Level Language as: C programming language behaves as high level language through function, it gives a modular programming and breakup, increased the efficiency for resolvability. C programming language support the low level language i.e. Assembly Language. C language also gives the facility to access memory through pointer. Its combines the elements of high-level languages with the functionalism of assembly language. So, C language neither a High Level nor a Low level language but a Middle Level Language. C Programming: Middle level Language http://cprogrammingcodes.blogspot.jp/2011/12/middle-level-language.html 諸説あるよ "middle-level language" Googleで検索 各CPUのアセンブラを勉強しなくていいから、Cは、高級な感じがするが、 オブジェクト指向言語ではないし、セキュリティが不足している(実際は、それもCで達成できるはず)ようにみえるから、 Cは、高級言語ではない。 ID:997Wnr2J には、このスレでCを「高級言語ではない」と呼ぶ権利を与えます。どうぞご自由に。 高級言語ではあるけど、メモリアドレスを直接指定しての書き込みや 必要とあらばインラインアセンブラも使える言語って意味だろ 更にC言語の場合、アドレスの抽象化があまりされていなくて それらが必要でなくともアドレスを扱うことになるからそう言われるんだろう 高級言語って30年前の言葉だからな。C/C++より上のいまどきの言語は超高級言語だろ。 肉体労働向け言語に進化しましたから、超高級とかいってるのは read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる