【超高速】C/C++に代わる低級言語を開発したい 8
肉体労働向け言語に進化しましたから、超高級とかいってるのは 高級言語だから定休知能では扱えないということはなく
むしろ反比例の関係にある マ板に高級=デラックスと勘違いしてるやつがいるとは。 >>2->>3を読む限り>1の望みを満たして居るのはかつてとは段違いに美しく高水準に整えられた今時のアセンブラと思われる 配列を表現する場合無限にメモリーなりCPUなりが利用できる場合リストになるよね
数値の表現も
色々な型がサポートされている時点で低級言語じゃないか
細かいリストや配列の加工操作がしたいんじゃなくて
もっと抽象的に状態に対する結果が欲しい
高級言語と呼ばれるものも抽象化で捉えると低級言語? PCは15年ぐらい前から、スマホは5年ぐらい前から、ギガヘルツ超えのCPUが載ってるけど
電子レンジもWi-FiもBluetoothも2〜5ギガヘルツの電波出してるけど
正気か? とおもうか? >>183
衛星とかFWA無線とかもっと速かった気が 低級言語って
言語の基本機能だけじゃまともなアプリ作るの苦労するって言語ってこと? 低いレイヤにアクセスすることが前提の言語な
プログラミングにおける低級高級は優劣の話ではなくレイヤの話だから 低レイヤってOSやハードウェアと直接やり取りするって感じ? このスレとは違うが
一般に、低級言語はアセンブリ、C言語以上の言語は高級言語。 超高級言語クレとは言わないけど
高高級言語くらい欲しいって思ってたら有ったっぽい
通常パターンマッチてif文の羅列やネストで重複した論理演算を省略して速度他を稼ぐんだけど
パターンマッチ指向はその常識がないw
なんて恐ろしい子
その代わりマッチする条件をダラダラ例記すればよいから
直感的にこの組み合わせおかしいとか修正が楽
なんか条件の検出に正規表現?使っている様な雰囲気ワロタw
最適化なしの高級っぽい言語ってマクロの親玉みたいな感じだから
実装は楽じゃないの
デバッグ環境もセットで用意しろと言われるといきなり敷居があがるけど 僕が考えた最強の言語Swift
各言語の構文てんこ盛りで、LLVM介してコンパイルで、>>1が望むものじゃねーか? どっかのC/C++コンパイラは一度アセンブリのソースに変換してからオブジェクトコードにするって聞いたな >>193
Swiftってデバドラを実用的に書けたりするの? まっくのでばどらはぜんぶ Swift でかかれるよ C言語用のVMを作ればいいじゃん
GCCがVMの役割を持てばいい LLVMは大体分かった。GCや例外が大変。
テンプレートを型推論したくてHaskellの型推論読んでみたりしたけど難しい。
Yacc慣れするために、OCamlYaccでトランスレータ書いたりしてて、
今は文法を洗練させようとしてOCamlの別シンタックスを考えてる。
マクロはPHP的な物も検討中だな。
Swiftは悪くないけど、仕様を自分で弄れないからなぁ。 組み込みの構文と違和感なく構文を拡張できればいいね。 大事なのはエラーメッセージが適切な内容になる構造を持たせることと
実用的なデバッガサポートがあること
作るのを優先するとその辺が落とし穴になる DylanとNemerleや、天才高校生プログラマの言語とか参考になると言えばなるんだけど
結構難しそうなので、Lisp的な式レベルでどうにか簡単な仕組みが作れれば良いなと思ってます。
エラーメッセージやデバッガは、言語機能がしっかり出来上がってからですね。
位置情報埋め込むと構文木が煩雑になるし、デバッガの為の位置情報の埋め込みも同じ。
その辺頑張ると、それだけで大変なので結局今の言語と同じ物しか作れなくなってしまう。
納得いかない文法で、エラーメッセージとか詰めても結局捨てる事になってしまうし。
エラーメッセージも出来れば、グローバライゼーションして、日本語と英語くらいは用意してあると良いけど。
それも含めて、構文拡張が出来て、うまくデバックできてっていうのは難しい。 エラーメッセージは特に、エラー発生箇所と、エラー内容が作っている箇所からは
特定出来ない事が多いので、エラーが発生するようなテストケース作って
エラー内容のテストをしていけば、良くなるんだろうけど、1つ1つ作り込む感じにしないと
出来なさそうなので大変だけど、ちゃんと作ると、それなりに成果があっていいんでしょうねぇ
Rubyが成功している理由ってそういう所もあったのかなぁ? >>206
それを実現するのに有効な言語的な特性は?
具体的に提案があるとわかりやすい。 おうお前らがモタモタしてるうちにRustが1.0になったぞ
ランタイム&GC不要のメモリ管理、メタプログラミングのための各種機能をゼロ・オーバーヘッドで用意、パターンマッチもついて中々のイケメンに仕上がってるぞ
>>209メジャーな言語と似たものなら大体はいいぞ。関数型はエラーメッセージが分かりにくくて有名だからそれは避けてね フルスクラッチでcを実装するブログ読んで思わず自分もって感じで始めた
まずは、物凄くシンプルなc言語っぽい仕様書をシコシコ書いてる
実装するまでは中二病に浸れて気持ちいいなこれww
あと、ここの
http://homepage1.nifty.com/herumi/prog/x64.html
c言語でのレジスタの扱いとか読むと
行儀の良さげなレジスタの扱い方とか参考になる
だけど、一番目の整数引数rcxの下り
一番目が実数だった場合はxm0と言う排他的にrcxもしくはxm0で受け渡すって言う意味なのは
サンプルコードを見るまで理解できなかったww
vs2013も入れたけどコンパイルしたあとのアセンブラのコード何処で見るのか不明w .NETでどうでもよくなったよなー
ていれべるなことなんてほんとしなくなったわ このスレは言語について議論するスレである。
「.NETでていれべるなことしなくなった」というのはこのスレでは的外れな発言である。 ほんとにいい時代になったよな
>>213 マ板へお帰り 求めたのは低級言語
出来上がったのは低脳言語
無能が開発すると(以下略
vc++とかgccの吐き出すコードってそんなに酷いかな?
吐き出されたコードがアセンブラレベルで手を加えやすいと助かる
そんな感覚はあるけど、小さい規模なら問題ないけど
規模が膨らむと放棄するしかないような このスレは言語仕様を議論するスレであって、処理系が吐き出すコード(バイナリ?)に関しての議論はスレ違い。 低級言語ってアセンブラレベルでお手入れができたり
アセンブラに近い処理ができたりCに近い感覚じゃダメなのかね
言語仕様のなかにこれはアセンブラに近い記述でありコードもそれに近いコード
この部分の記述はガベージコレクタを含む重い処理を暗黙で行っていますって感じで
ソースを一見するだけで明確なのが良いのいでは?
変数の宣言でint型をINTと大文字で書いて[0...100]とか範囲指定がある場合とか
var I:INT[0..100]
I=I+101
//一見したときの明確さは変数は大文字、型指定も大文字
//ああ、厳格な範囲検査してるから遅くなるってわかるみたいな >>220
Objective-C がそんな感じで c / c++ の文法に加えて
コスト大なメッセージパッシングの仕組みを混在させてる Objective-Cは文法のセンスが致命的に悪い。 >>220
>低級言語ってアセンブラレベルでお手入れができたり
>アセンブラに近い処理ができたりCに近い感覚じゃダメなのかね
それでいいよ。
で、その時に、それをどのような文法で実現するのか、がこのスレの主題。
いま、Cと同じことができる言語を1から考えたら、Cと全く同じ文法にはならないだろう。
それを考えるのがこのスレの趣旨。 >>224
Luaいいね
色々考えるとLuaの再定義っぽい感じかな
Luaってスクリプト言語に分類されるアセンブラみたい
低級言語だから高級っぽい文法でプログラムを書き下して
コンパイルして一旦アセンブラのソースの形で出力
必要ならここで編集
最後にアセンブラさんにお任せみたいな
アセンブラって基本ラベルとメモリー空間があって
そこにどんな形式のどんなデータが格納されているのかは自己責任って世界だから
ここら辺を援護してくれるマクロアセンブラっぽい物が良いのかな スレ立てから3年が経った今、時は動き出す
ってことではよ何か作ろうや 最近の名前だけ高級言語スクリプトを見てると仕様も技術者もアホの極地にしか見えん。
その技術者の得意言語でもやっちゃいけないって事を平気でやる 逆に超高級言語を作りたいな(´・ω・`)
今一番超高級な言語って何がありますか? ここは勉強になるスレだぬ
>>233聞いたこと無いので検索してみるw
>>232キチぴーご用達なww マイナーな言語は習得が大変なことと、わからないことがあったとき情報やノウハウがないので
全部自分で何とかしないといけない。普及している言語の中から好きなのを選んで使いこなすのが一番いいよ。 マイナーだけどメジャーになりそうなら本書いて印税うはうは 高級言語を使いこなすってC++を使いこなすより大変じゃないのか?
で結局パワーではC++に敵わない >>238
C++ほど大変な高級言語はなかなか無いと思うぞ c++のunsigned long 型の変数を >=0で評価するとーの値が存在しないので必ずTureになって
forループが無限ループになるバグの説明が面白かった
アセンブラならループのインデックスを引いたあとキャリーフラグ調べて分岐じゃないか
ループ離脱の条件が単純比較じゃなくて条件式を容認してるからだろうけど Cの骨にテンプレートの肉を詰め、OOの毛皮を被った化物だよ
骨だけ使った料理もできるし肉を焼いてもいいし、毛皮からコートを作ったっていいが、
他人が作ったものはまだ蠢いているかもしれないから怖い。 >>242
そもそもループカウンタにunsignedを使うこと自体、バグと言うべき話なのでわないかと・・・ while(true)で評価するとーの値が変化しないので必ずTureになって
whileループが無限ループになるバグの説明が面白かった
ループ離脱の条件が条件式だけじゃなくてbreakやreturnを容認してるからだろうけど 高級な変態というと・・・女体盛りで大トロとかヒラメの縁側を使う感じか。 >>244
増えていくカウンタなら問題はない
減っていくカウンタでも 0 でループアウトするように組むのなら問題ない、a >= 0 とするから問題になる >>249
それはそうなんだが、勘違いしやすかったり、注意しないとバグの温床になりやすいことはしないのが基本だと思うんだが。
ループカウンタとして使うなら普通に int 使えよと。 C++/CLIはC++の顔してて勝手にスレッド作りやがる FORTHという>>1の要件をほぼかなえる言語がある
これをベースにすればよい while( c )
{
...
c -= 2;
} 好き / “アセンブリ言語のみで言語処理系を作った話 // Speaker Deck”
ttps://speakerdeck.com/nineties/bootstrap
これ見て元気だせ
自分でも出来そうな気がするだろ
実際、大学あたりではcコンパイラの実装までやらせてるんじゃないの? >>254
簡単そうに書いてるけど、これ相当わかってる人でレベルが高い。
俺には1段階理解するだけで大変。自分で実装できる気がしない。 >>254
たぶんこの人だね
ttps://www.s.u-tokyo.ac.jp/ja/rigakuru/3384/ あー、ドアドアの人? と思ったら違ったヽ(´ー`)ノ
むかーし(20年ちょっと)、アセンブラに構造化マクロを追加して『生産性が超上がる!』って
謳ったPDS(今で言うフリーソフト)があったけれど、当時意味分からなかったなあ。
と言うかGCCの吐くアセンブラコードを読んで、自分で書くより綺麗でスッパリ諦めた(^^; 少し前、x265のエンコードダーをアセンブラで記述してる人達の話題で
プログラムを組む上で何が問題なのかって話題があって
OSのシステムコールを行うとレジスターが壊れるのが気に入らないって事だった
オレは重要なアルゴリズムに係わる高度なコーディング作業をしているのだから
システムコール如きへの配慮で煩わしい事をさせるなってことかな
システムコール用のレジスタ退避マクロなり
システムコールをラップしてレジスタを退避復旧したり
もう少し便利なアセンブラの処理系を作ってみたりしないのかな〜
既存コードとの互換性問題とかあるのかな
アセンブラ関係のTool類はかなり保守的で目新しい道具類がガンガン使われる様子は少な目??
>>254の記事を読むと、コンパイラ系統ってリストへの変換ー>実行コード(アセンブラ)への還元って事が凄くよく判るんだよね
物凄く大雑把に言うと、LISP処理系への構文糖衣≒コンパイルする対象(プログラム塊) な構図 >>54
どこがスレ違いなんだ。
それどころか、このスレを建てること自体が間違ってるだろ。
それを指摘するのは正しいことだろ。 54 :デフォルトの名無しさん [sage] :2013/04/07(日) 22:40:29.84 VS2013のC++x64でアセンブラコードみてるんだけど
かなり良さそうなコード吐き出している
問題はC++の仕様が大きいので他人の書いたコードが理解できないこと
C++の仕様の大きさが問題ならC++のコードを吐き出すプリプロセッサ?
みたいなものを企画してあとはC++にお任せが一番楽そうだね
unionを使った偽装もキャストって呼ぶんだな
&を使うリファレンスも別名とか名称変更とか説明があってやっと理解できた
C++もC並みにフリーダムだからお行儀の悪いコードが書けてしまう
提案になってないな
アイデアとしては、cpuやハードを直接叩く記述をする場合明確に宣言させて隔離とか
_low_level_fuc みたいなキーワード導入してその内部のみ色々悪さが出来るとか
これは運用の問題なので今のC++でも可能なんだろうけど
pythonのサブセット、お行儀の悪いpythonとかpychonとかoppayとかwww
C++の複雑さって仕様が大きくなって新たなキーワードを導入して何でもかんでも
詳細にテキストで記述しようとした結果じゃないかな
本来ライブラリなりフレームワークなりにお任せすべき部分までやらかしていると Cの複雑さってint,char,とか扱う型の種類とサイズが多い事も理由っぽいので
ここはきっぱりアルゴリズムを記述する為に扱える数値の種類を1,2種類に限定して
そのほかはデーターベースの記録管理みたいに色々なコストをかけて
型変換なりレンジチェックなり圧縮なり手間隙かければ良いのでは?
いっそ64bitサイズの何かで統一してしまう
charもintも実数も全部64bitの何かw >>261
単に型なしのオブジェクト言語使えばいいのでわないかと 型無しのオブジェクト言語って言えばluajitがかなり高速なんだよな、確か。
あれの仕様を上手く転用できないかな。 Rustいつのまにかstableリリース出てたのか・・・
Swiftみたいな負の遺産に塗れたクソ言語に比べりゃ大分>>1の理想に近いと思うんだけど
モジラってOSSの見切り早いし将来性が不安だわ void*最強って話か?w
コンパイラが勝手にトレードオフして機能の一部をFPGAに突っ込んでくれよ 高速とは無縁だけど多倍長整数ってあるよね
これをビット単位でやるの、管理も緩く1ビットで1バイト使って管理
速度で無いけど全部の計算表現できるよね
文字列とかは考慮してないけど
色々考えた結果、変数の精度、byte,word,duble word,q...
ここら辺がいかにCPUの効率都合に合わせた制限だってよく判る
制限して精度に条件が付いても効率と速度が欲しいって言う
たった1ビットの多倍長数が扱えるだけで何でも表現できるなと思った。ww RustがC++に並ぶぐらい速くなってるみたいだけどRustのサブセットみたいなの作ったら良いのかね 修理するより買い換えた方が安いって話は多いが
もはや解読不可能になったコードのメンテナンスに金は出すくせに
新しく作り直すのはNGってのは恐ろしいな
大手では比較的作り直しもするようだが もしあらゆる面でC++に勝る言語が出来たとしても、それが流行るかどうかは怪しい ネタがないんだね
Cに代わるっておそらく劣化Cになるだろうし
C++は現状仕様が巨大過ぎて大変な状態らしい
最後は、ライブラリーを移植するとき仕様差による移植性の低下をどうカバーするか問題がでる
(ライブラリーなんて一から書いてられないから)
ー> 結果現行のC++でも良いじゃん
設計とかコード書くときの作法が問題じゃねーのみたいに収束するのかな
あとは、コードの様子を解析するツールやAIっぽい機能を備えた解析などを行うアシストツールが必要になりそう
10進数の需要って金銭関係や丸め切り捨ては四捨五入で行いたい方面に需要があるんかな、やっぱ 最近のC++は何を勘違いしたか高級言語気取っててウザイ。 >>3
>◆新言語でのリソース管理方針◆
>
>・確保したリソースを明示的に後始末しなくても問題が発生しない
>・何らかのメリットのために確保したリソースを明示的に後始末してもよい
こういう魔法みたいなことってどうやったらできるんだろうね
もちろん効率重視なのは言うまでもない前提条件として
数十〜数百マイクロ秒単位で使用元・使用先スレッドがガチャガチャ入れ替わる環境で 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
BTGPU Cは8進10進16進数が扱えるのに、何で2進数が扱えないんだろう。
ちょっとの工夫でどうとでもなるけど、やっぱ標準であると嬉しいなあ。 16進数の方が分かりやすいからじゃないの
1010000とか書かれても1の位置がどこかすぐに分からないし
0x50なら一目で分かるけど gccはじめメジャーなコンパイラなら大抵は2進数リテラルは扱えるから
よく使う処理系基準でいいでしょ C++では0bが使えるようになったけど、Cはまだなのか
つか素直にC++使おう 最近のc++は糞化拡張が止まらないから。
あくまでアセンブラの代替として使いたいのであって、ハード寄りのコードを書きたいのであって、
速度重視、メモリ効率重視が根底にあるのに、c++の仕様拡張してる奴らはただの言語オタクでうざい。 Rustが正解に近い。
メジャー化してエコシステムが充実すればいける。 armcc, armclang, Linaro GCC
ARMR コンパイラ armcc ユーザガイド
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472jj/index.html
armcc は、標準 C および標準 C++ のソースコードを ARM アーキテクチャベースプロセッサのマシンコードにコンパイルする、最適化 C および C++ コンパイラです。 Rustが正解であることが確認されました。
10年弱に渡りお付き合いいただきありがとうございました。 言語が
理解習得し易い
誤認間違い難い
というのもお願いしたい MIT「えっまた俺なんかやっちゃいました?」
julia、軌道に乗る >>277
大本の思想がランタイム速度落とさずにできるかぎり高級機能入れてこう
ってなところがあるんで自然といえば自然。
ある種の人体実験場みたいなところがc++の意義って気もする。 c++が示したことってのは結局
ランタイム速度
高級機能を追加
の2点だけ追求すれば馬鹿プログラマは寄ってくるってことなんだわ。 どうみても今はコード書かない言語オタクが好き勝手に拡張してる。
C++にくだらん機能追加したいなら名前変えろよ。
C++系言語で普及した言語はJavaやC#などいっぱいある。 Low* (Low star)という言語は型システムがすごいのでぜひ取り入れていくべき まあ、もともとCは最適化はあまりやらなくて、プログラマの意思をなるべく素直に伝えるという思想だしな。だから、a=a+1;とa++;は演算後の値は同じでもプログラマの意図は違う。前者は加算命令、後者はインクリメント命令に落ちてほしい。
コンパイラのエラーチェックも最小限で、チェックはlint使えって感じだし。
Rust屋の主張するメモリ安全なんかも「うっせえわ!黙って言う通りにやれ!」って感じ。
あぁ、キャリー/ボローフラグが使えたら良いなあって時はあるかな。 >>299
>キャリー/ボローフラグが使えたら良いなあ
ですよね、ローテート/シフトのときは特に int と size_t がいつも混在して面倒になる 勝手な整数拡張をやめてくれるある意味cより低級なcが欲しい
パフォーマンス的にワード長で扱うのが良いというのもわかるが
あえてintより小さい型で計算したい時というのはそれなりの理由があるからやるわけで
その型内でオーバーフローしたら切り詰めずに素直に落ちろ しかしそこまで低級なところに降りていくとマクロアセンブラみたいなのが使いやすい感じになっちゃうんだよね。
言語上の表現がどういう機械語に対応付くのか意識するともう直接書いた方がええわ……となる。 呼び出し前後のレジスタ退避と回復だけやってくれれば意外とアセンブラはほぼforthだよね forthは言語とマクロ用言語が同一言語なアセンブラだな
gforthみたいなリッチ実装はコンパイル済の定義を参照するとx86の標準文法を曝け出しちゃってなんだかなぁ、と思う >>304
forthは呼び出し規約の抽象化じゃなくて、型と引数という概念を捨てて自由になった
マシン依存性を排除するためにレジスタを抽象化した汎用dスタックに全ての命令が型と個数の解釈をモラルを守って作用することで成り立ってる
(暗黙の)引数渡しに関してはオーバーヘッドは大きくないので普通はマシンの最大スカラー型
floatはさすがにfスタックがあるけど
dスタックだけで複雑なデータ操作は厳しいから、最大スカラー型である事が保証されてるrスタック(生ハードウェアスタック)が一時領域に便利なのが闇
制御構造も戻りアドレスや添字を積むだけだから、うっかり積み残しがあると戻りアドレスやデータが添字代わりにインクリメントされ続けたり不可解な事に
あとは拡張性が売りの癖に制御構造のポータブルな拡張が難しいのがな…
もちろん制御構造と整合性のある単純な命令くらいは添えられてるのであくまで例だけど
指定回数ループをbreakするには最低で添字と戻りアドレスをpopする必要があるけど、たいてい実装拡張として積まれてるデータは不定、何回popしたらセグフォるか試すことになる
規格の制御構造には不備があるから(これは本当)うちの拡張を推奨ってのが普通の世界
制御構造すら定番がなくて、同じ言語といえるのかという疑問すら湧く >>305
コメント無くなってたり、埋め込んだ定義が等価な表現に置き換わってたりするから、seeは既存のコードを参照してるのでなくて、ブロブからforthコードへのディスアセンブラ(再構築)
ワードを渡せば' でそのワードの指すアドレスは取れるけど、そこから何バイト読むかのオフセット指定をseeは取らない、かなりヒューリスティックだと思う
seeで標準される開始-終了アドレスに、読みすぎてそうなら適当に足すか、途中で切れてるようなコードなら適当に足してaddr nbyte discloseと呼べば大体復元できると思う
dis、+disとかも入ってたっけ
まあ、具体的なレジスタやメモリの名前が分かるだけでforthコードとそんな変わらないという悲しさはあるが 低級言語ならx64特化して構造化アセンブラみたいな感じで
ちょっとオシャレだけどやってる事はほぼむき出しのレジスタ操作みたいな? 例えばループが多重化してループカウンタが複数必要な場合
作法としてRCXを使うけど、処理系が最適化で空いてるレジスタを割り当てたり
退避復帰をしつつRCXを使うとか
固定領域を確保してカウントに使用するとか自動でやってくれるみたいな
プログラムコードは雰囲気コーディングだけど最終出力は忖度された何かみたいな感じ 最近のCPUのアセンブラはほとんどCと変わらないようだけど 昔のCはアセンブラとほとんど変わらなかったから
差は縮まっていない
なにも変わってない 最近はむしろC標準が直接サポートしてない命令が増えてるからな
ローテイトなんていまだにないし >>294
Aカップが好きなアセンブラ君、食わず嫌いはいけません高級言語は恐くありませーん
Bカップが好きなBASIC君、少しは毛が生えたけどまだまだ修行が足りません関数に興味はないのですか
Cカップが好きな君は正解に限りなく近い。有象無象の言語はたくさん出てきたけれど結局Cが手ごろサイズで限りなく正解に近いです
Jカップが好きな君は煩悩に振り回されっぱなしです。たまには太陽だけでなく月にも興味を持ちなさい >>1
仮想アセンブラを作ることになるが、かえって誤ったハードウェアと勘違いしそうw >>317
アセンブラがわからないのに語る変なやつw >>321
どうでもいい話だけど、J が Java のことを言ってるようにも見えるので
実際には J 言語てのがあるんだけどね
J はJava や JS とは全く関係ない、APL (という言語) の派生言語で
APL と違って特殊キャラクタを使用せず ASCII のみで記述可能にしたもの