【超高速】C/C++に代わる低級言語を開発したい 7

1 ：10/05/31 〜 最終レス ：11/11/24

70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/

2 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

3 ：

◆新言語の要件 v0.1◆
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。

4 ：

◆新言語の名称（仮）◆
Programming Language I
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。

5 ：

>>1
> しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
> 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
概念的には全く同じものになるだろう。

6 ：

>>4
なんでLLが（ハッカーの手により）生まれ、Cみたいなのが生まれないのか
少し考えれば分かるだろ

7 ：

◆新言語を考える上でのキーワード◆
クロージャー
カリー化
型推定
構文を操作できるマクロ
ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント
◆マクロについて◆
「マクロ」に必要な要件って何なんだろう。
・構文を置き換えるルールを定義できる
・シンボルを置き換えるルールを定義できる
Lisp級の構文木を操作可能なマクロを作る要件
・マッOプログラムが簡単に書ける
・マクロの実行時に構文木を返すプログラムを書ける
また、作るのを容易にするには
・単純な式として構文解析が可能

8 ：

◆低水準に関連するキーワード◆
・ハードウェアを直接操作
・デバドラ
・直接アドレス参照
・OS
・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。
・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。
・０オーバーヘッド

9 ：

>>6
Cを作った人こそ
当時のハッカーというよりWizardだろ
有象無象が越えれる壁じゃないよね
LispがCより速い結果だしたそうな
どうみてもCのがわかりやすい
http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf
所でこのスレforkしたんじゃねえの
また関数言語とgcがわくぜ

10 ：

forkと連呼してる奴ｗ

11 ：

新言語の方は、GC付きオブジェクト指向でいくっぽいし。
低水準な方は、高級マクロアセンブラっぽいし。
>>1
乙

12 ：

俺よくわかってないんだけど
超高速ってC以上に高速なバイナリ吐くってこと？
機械語に落とす時に最適化される部分をプログラマが
指定できるみたいな要件が
ってとこで>>4読んだ
リソース管理でどっちでもいいよって言うのは
結局プログラマがリソース？の状態を気にしてプログラムしないといけないから
後始末必要の方が好み

13 ：

Cと同じ位の低レベルな時点で
RAMリソースなんて0で動かなきゃ

14 ：

0ってスタックも無しかよｗ

15 ：

RISC系のCPUで変数少なかったら
葉っぱの関数ではスタックもいらないのを見越して書く
メモリとかバスユニットの初期化コードとか。

16 ：

正直マジでレジスタとROMしか使えないんなら素直にアセンブラ使ったほうが
良くないか

17 ：

仮に使ってもゴミ読むだけなら
問題ない場合もあるしな

18 ：

>>16
見た目は普通に書けるよ
呼び出し側はアセンブラかもしれんけど

19 ：

アセンブラでよくてもポータビリティのためにCに書き直すことは意味ある。

20 ：

俺は後で自分や他人が読むためかなw
数ヶ月たつと忘れちまうし、若い奴に見せてもアセンブラだと敬遠しやがるし

21 ：

>>12
そもそもこのスレのテンプレは
>>1が重要だろうと思ってるレスを　過去ログから拾って来て、
適当に羅列してるだけだから、何一つ決まってないよ。

22 ：

決めたい人が決めればいいよ

23 ：

他人が決めてくれるのを待つ必要なんて無いんだよ

24 ：

ははぁ勝手にやればいいよってことですね
思いつきで書き込んだんですが、今思えば
コンパイラがやってることをCのレベルに持ってくるのは難しいというか無駄？
上に乗っけるのと違って現状の処理が変わるわけですし優秀なコンパイラあるし。
でもアセンブラいじりましたって状況がなくなるなら面白そうなのかな？
とりあえずC？にもってきたらどんな記法になるかを書いてみたいけど
当方素人なのでGCCが吐いたアセンブラを変更しないといけないシチュエーションが思いつきませんｗ

25 ：

あ？

26 ：

テンプレートメタプログラミングは必須だな

27 ：

手続き型アセンブラ
オブジェクトアセンブラ
関数型アセンブラ
LLアセンブラ

28 ：

アセンブラアセンブラ

29 ：

アスペクト指向アセンブラでダックタイピング

30 ：

どこかに小型のCコンパイラのソースって無い？
ベル研のPCCはテーブル定義が足りない。
TCCはちょいとでかい。

31 ：

なぜC

32 ：

Cにネタを積んで遊んでみようかと。

33 ：

>>31
僕の理由はCの実績。すでにあるプログラムに
手を加えるだけで恩恵が得られるって夢のようだとは思いませんか？
まあCに埋め込むものがどんなものになるかはまだ想像つかないです。
コンパイラ？を拡張するならまったく違う語法？でもいいのかもしれないし
改修してしまうならCがちょっと形を変えたものになるのかもしれない。
ベースになるのはCだろうなとは思ってますが
C++やC++0x、Java、Lisp?、といった言語だけでなく
Struts2やらシンフォニーといったフレームワークだったりとか
も参考にできるところがあるんじゃないかなあと
C++0xについてはいいものを見つけられた気がします。
とりあえず僕は他の言語をつまみ食いしながら
C99をよく見直して吟味するとこからなのでマイルストーンも何も置けない状況
今日は他の事してたので進捗はナシ。

34 ：

schemeから始めればいいのに。

35 ：

プロファイラ作ってみなよ

36 ：

プロファイラもデバッガも仕組みさえわかれば
下の方は簡単だが問題は見せ方だよな
XcodeのInstrumentsとか面白い

37 ：

プロファイラを言語機能に入れてよ

38 ：

え？もしかして僕ですか？
言語機能には入れないけど作ることにはなるんじゃないですかねー
新言語にしか興味ないので見せ方は他の方がどこかの誰かに丸投げ
僕のがモノになるのはずーっと先だろうなあ。

39 ：

アセンブラ言語から先は同じでいいんだからプロファイラ自体は先に作れるのかな？
アセンブラだから評価はステップベースでいいしあとはリソースの扱いを考えて・・・
静的なメソッドごとのステップと消費リソースを吐き出せばおｋだったり

40 ：

アセンブラ言語って呼び方やめてくれ。ムズ痒くなる

41 ：

アセンブラングエッジ

42 ：

アセンブラ言語なんていってごめんねアセンブラ言語なんてもう言わないよ
あーあーアセンブリ言語をアセンブルするアセンブラ。

43 ：

ラ行３段活用？

44 ：

国語の話はやめてくれ。ムズ痒くなる

45 ：

国語の能力とプログラミング能力の相間について

46 ：

国語というより作文能力とは相関がある

47 ：

どうせアセンブラやらないといけないし
プロファイラ先に作ってみる

48 ：

○静的な機能として
・ラムダ式
・名前空間
・テンプレート
・型推論
・マクロ
○動的な機能として
・文字列
・リスト、キュー、スタック、ハッシュテーブル
・正規表現
・並列処理
・多倍長演算
・ベクトル演算

49 ：

文字列とリスト以外いらん

50 ：

これからの時代、ベクトル計算は要るだろ。

51 ：

メニーコアプロセッサが普及するだろうから、並列処理とベクトル計算は必須。

52 ：

結局理想を追求したらGoになったでござるの巻

53 ：

低級言語にベクトル計算とか要らないよ
インラインアセンブラでやってくれ

54 ：

ベクトル計算機のベクトル計算のことだろ。
そういう計算機では機械語がベクトル計算なんだが。

55 ：

ベクトル演算専用言語を作るのは面白いけど
それが目的じゃないならインラインアセンブラでやればいいんじゃないの

56 ：

ベクトル演算は言語標準でまではいらないが
標準クラスライブラリに含まれて然るべきだろう。
その方が演算器にCPUだけでなくGPUも使えていい。

57 ：

ここはあれか、Core2DuoとかCellとかが最低ラインなのか。

58 ：

最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか？

59 ：

C/C++って低級言語じゃないんじゃ？

60 ：

配列はベクトルでは無い
ベクトルは行列、そして積和演算

61 ：

>>58
> 最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか？
ガイドラインを示すくらいなら、言語仕様に組み込んだほうがいいだろう。
特殊な小手先のハンドオプティマイズより、言語仕様に基づく公式なやり方の方がソースのポータビリティーも確保できる。

62 ：

>>581
つfortran

63 ：

Fortran と正しく書かないと

64 ：

えらいロングパスだな

65 ：

581に期待

66 ：

並列処理の構文欲しい

67 ：

ベクトル演算ってどんな感じで作るんですか？

68 ：

int a[5], b[5], c[5];
c = a*b;
int d[3][5], e[2][3], f[5][2];
d = e*f;
こんな感じとか。

69 ：

配列とベクトルは論理的に違うもの。
記述性を考えればdouble2,int4,float3とかのベクトル型は
組み込みで持っていたほうがいい。

70 ：

>>69
>配列とベクトルは論理的に違うもの。
これはどういう事？

71 ：

３次元が特殊なのは分かるけど
その他は特殊な事ってあったっけ

72 ：

>>70
「行列演算」でググれ

73 ：

>>72
ググったってたくさん出てくるから>>69が何を言いたいのかよく分からないよ。
具体的に説明して欲しい。

74 ：

>>69
配列で十分だろう。ベクトルの足し算だってループでまとめて記述できるしコンパイラが自動的にベクトル化してくれる。

75 ：

regster int a[5], b[5], c[5];
c = a*b;
regster int d[3][5], e[2][3], f[5][2];
d = e*f;
こんな感じで、コンパイラに努力目標を伝えられたらいいかもね。

76 ：

行列演算なんて普通lapack/blasだろ

77 ：

>>76
そういう機能をうまく構文に取り込めるといいね。

78 ：

志村！スレタイ、スレタイ

79 ：

だからFortranを勉強しろと
FORTRANじゃないぞ？　Fortranだ

80 ：

Fortranに変わる新言語を作りtai!!のスレになりました。

81 ：

AVXとかLNIとかに対応できる構文があればいいよね。
>>79
「Fortranを」と言うより、「Fortranのどの機能が良いから新言語に取り入れよう」と提案した方が議論が進むと思うよ。

82 ：

みんなロングパス受け取ってくれたみたいだな

83 ：

>>81
この流れでは並列演算に決まってるでしょ

84 ：

>>83
それが決まってるのは結構なことだけど、それがどう良いのかの説明があればもっと議論が深まるのにね。

85 ：

素直にFortran知りませんと言えばいいのに

86 ：

別に知らないことは無理に表明しなくてもいいんだよ。
それぞれが知っていること、成し遂げたいことを語ったほうが前向きだからね。
だから、Fortranの並列演算に価値を見出している人がいるなら、その人がどう良いのかを説明して仲間を増やせばいいと思うよ。

87 ：

Fortranの並列演算なんてライブラリで出来んじゃねえの
どうせならOccamとかの方が面白いだろ

88 ：

行列に関しては、clapakでだめなの？
並列演算(SSE2/VelocityEngineほか)を直接制御したいというのは別だろうか。

89 ：

>>87-88
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

90 ：

マルチコアのプロセッサが今後主流になるだろうから、並列処理の構文はあったほうがいいだろう。
整数の四則演算だってライブラリで提供することは可能だが、多くのプログラミング言語にはしっかり構文があるわけだし。

91 ：

脊髄反射すんなよ
高速演算ライブラリの必要性や配列の演算出来るって話は否定しないが
言語の話するなら並列実行構文の方が面白くねえかっつってんの

92 ：

あ、89に書いたのよ
お前みたいな凡人が寄り集まってんだから既存の言語を参考にすんのは当然だろうがよ

93 ：

並列実行構文の方が面白いと思う。

94 ：

並列に実行して！という構文より
並列化コンパイラが作りやすい構文にした方が

95 ：

並列実行構文 と 並列演算構文 を両方議論を進めよう。

96 ：

>>94
自動で並列化してくれるのはもちろん嬉しいけど、プログラマがある程度制御できるようにもしておきたいかも。低レベルを目指しているので。

97 ：

並列に実行して！
ってだけじゃなく、出来れば並列に実行して！みたいなのが面白そう

98 ：

並列化を考えるなら、OpenMPのforの分担みたいにデータを並列化するんじゃなく、
普通のマルチスレッドアプリみたいな処理を分担するものを自動生成できるといいなあ
思いつかないけど
並列度は、明に指定も出来るし、デフォルトはシステムのプロセッサ数とかから
自動的にチューニングできるといいね。
あと、同期とかスレッド間通信もある程度は検討したい。
goのchannelはシンプルながら面白いよね

99 ：

channel面白いね
でもやはり同期と排他と共有メモリは欲しくなるね

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲