【超高速】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 オブジェクト思考なんて何十年も前
今は最新なんなんだ? >>55
アスペクト指向というのがあるがまだ実用化されてない
アスペルガー指向の方が多くないか?wwww アスペクト指向はソースコードのXML化といって差し支えない
XMLタグの量を増やせばできることも増えるがソースは冗長で不細工になる。
OWL推論でコンポーネント間が繋がれば、超冗長だが再利用しやすくなったりするかもな
<Entity name="DBTable">
class Persons {}
</Entity>
@Entity(name="DBTable")
class Persons 型付きlisp風言語作ればいいじゃんて話だろ、まとめると 関数コール時値やアドレス値をスタックやレジスタへ積み積みする暗黙に埋め込まれるコードもアスペクト
暗黙だけでなくあちこちにユーザーコードまで混ぜれるようにしちまう開放的且つカオス世界への招待を
有難いと感じるかどうかが別れめっスね 自分一人でやる分にはいいが複数人でやるとたちまち世界が破滅する 構文を工夫して文字数を減らしても仕方ないし、XML/アスペクト指向も終わった。
最近の新しい発想というとKVSぐらいだな。1人でプログラミングすると効率悪いが、
多人数での分業に向いている言語とかいんじゃね? >>59
なにか変だと思ったら DIとAOPを混同しているな >>53 と >>67 って同一人物?
C++ はともかく, C って高級アセンブラだろ?
立派な低級言語じゃん 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
人工知能とか、ネタなのか本気なのか分からなかったので若干しつこく聞いたけど、本気ならその方針で面白いものへと広げてほしい。
といいながら、興味本位で聞いてしまうけど、人間はともかく、人工知能にとって「直感的」ってどういうことなの?
人工知能ってコンパイラだよね。コンパイラにとっての直感性というのが分からなかったので。
それと、作りたいのは「言語」でいいんだよね?コンパイル可能な自然言語とか。 しゃべればしゃべるほど非マの妄言と化していくな
板違いだべ