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

**デフォルトの名無しさん** · 2012/08/23(木) 23:03:00.69

70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。

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

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 7
http://toro.2ch.net/test/read.cgi/tech/1275235018/l50

**デフォルトの名無しさん** · 2017/04/03(月) 00:14:37.85

もしあらゆる面でC++に勝る言語が出来たとしても、それが流行るかどうかは怪しい

**デフォルトの名無しさん** · 2017/04/03(月) 00:53:32.18

>>272
なんでサブセット？

**デフォルトの名無しさん** · 2017/08/25(金) 04:46:53.19

ネタがないんだね
Cに代わるっておそらく劣化Cになるだろうし
C++は現状仕様が巨大過ぎて大変な状態らしい
最後は、ライブラリーを移植するとき仕様差による移植性の低下をどうカバーするか問題がでる
(ライブラリーなんて一から書いてられないから)
ー＞結果現行のC++でも良いじゃん

設計とかコード書くときの作法が問題じゃねーのみたいに収束するのかな

あとは、コードの様子を解析するツールやAIっぽい機能を備えた解析などを行うアシストツールが必要になりそう

10進数の需要って金銭関係や丸め切り捨ては四捨五入で行いたい方面に需要があるんかな、やっぱ

**デフォルトの名無しさん** · 2017/08/25(金) 11:22:12.03

最近のC++は何を勘違いしたか高級言語気取っててウザイ。

**デフォルトの名無しさん** · 2017/08/25(金) 21:39:31.76

高級っぽく見える言語だな

**デフォルトの名無しさん** · 2017/08/26(土) 11:55:56.79

トンキンではC++関係者は不審者に見えるらしいw

**デフォルトの名無しさん** · 2018/03/25(日) 14:11:56.44

>>3
>◆新言語でのリソース管理方針◆
>
>・確保したリソースを明示的に後始末しなくても問題が発生しない
>・何らかのメリットのために確保したリソースを明示的に後始末してもよい

こういう魔法みたいなことってどうやったらできるんだろうね

もちろん効率重視なのは言うまでもない前提条件として
数十～数百マイクロ秒単位で使用元・使用先スレッドがガチャガチャ入れ替わる環境で

**デフォルトの名無しさん** · 2018/05/23(水) 20:03:50.70

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

BTGPU

**デフォルトの名無しさん** · 2018/07/05(木) 01:37:35.74

DKB

**デフォルトの名無しさん** · 2018/10/20(土) 20:00:04.70

Cは8進10進16進数が扱えるのに、何で2進数が扱えないんだろう。
ちょっとの工夫でどうとでもなるけど、やっぱ標準であると嬉しいなあ。

**デフォルトの名無しさん** · 2018/10/21(日) 14:55:24.25

16進数の方が分かりやすいからじゃないの
1010000とか書かれても1の位置がどこかすぐに分からないし
0x50なら一目で分かるけど

**デフォルトの名無しさん** · 2018/10/21(日) 17:25:58.13

gccはじめメジャーなコンパイラなら大抵は2進数リテラルは扱えるから
よく使う処理系基準でいいでしょ

**デフォルトの名無しさん** · 2018/10/21(日) 20:17:45.60

C++では0bが使えるようになったけど、Cはまだなのか
つか素直にC++使おう

**デフォルトの名無しさん** · 2018/10/21(日) 21:24:49.94

最近のc++は糞化拡張が止まらないから。
あくまでアセンブラの代替として使いたいのであって、ハード寄りのコードを書きたいのであって、
速度重視、メモリ効率重視が根底にあるのに、c++の仕様拡張してる奴らはただの言語オタクでうざい。

**デフォルトの名無しさん** · 2019/05/25(土) 11:08:30.63

Rustが正解に近い。

メジャー化してエコシステムが充実すればいける。

**デフォルトの名無しさん** · 2019/06/03(月) 11:49:30.62

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++ コンパイラです。

1 · 2019/08/13(火) 23:00:51.64

Rustが正解であることが確認されました。

10年弱に渡りお付き合いいただきありがとうございました。

**デフォルトの名無しさん** · 2019/08/21(水) 20:28:24.91

言語が
理解習得し易い
誤認間違い難い
というのもお願いしたい

**デフォルトの名無しさん** · 2019/08/31(土) 17:50:09.35

MIT「えっまた俺なんかやっちゃいました？」

julia、軌道に乗る

**デフォルトの名無しさん** · 2019/08/31(土) 22:20:26.54

>>277
大本の思想がランタイム速度落とさずにできるかぎり高級機能入れてこう
ってなところがあるんで自然といえば自然。
ある種の人体実験場みたいなところがc++の意義って気もする。

**デフォルトの名無しさん** · 2019/09/01(日) 01:01:46.09

>>288
バスト占い思い出した

**デフォルトの名無しさん** · 2019/09/01(日) 13:35:22.25

c++が示したことってのは結局
ランタイム速度
高級機能を追加
の２点だけ追求すれば馬鹿プログラマは寄ってくるってことなんだわ。

**デフォルトの名無しさん** · 2019/09/14(土) 20:38:11.35

どうみても今はコード書かない言語オタクが好き勝手に拡張してる。

C++にくだらん機能追加したいなら名前変えろよ。
C++系言語で普及した言語はJavaやC#などいっぱいある。

**デフォルトの名無しさん** · 2020/02/17(月) 23:02:27.37

Low* (Low star)という言語は型システムがすごいのでぜひ取り入れていくべき

**デフォルトの名無しさん** · 2021/10/27(水) 10:06:43.69

演算子オーバーロードって難読化だよね

**デフォルトの名無しさん** · 2021/10/28(木) 12:18:05.54

まあ、もともとCは最適化はあまりやらなくて、プログラマの意思をなるべく素直に伝えるという思想だしな。だから、a=a+1;とa++;は演算後の値は同じでもプログラマの意図は違う。前者は加算命令、後者はインクリメント命令に落ちてほしい。

コンパイラのエラーチェックも最小限で、チェックはlint使えって感じだし。

Rust屋の主張するメモリ安全なんかも「うっせえわ！黙って言う通りにやれ！」って感じ。

あぁ、キャリー/ボローフラグが使えたら良いなあって時はあるかな。

**ハノン** ◆QZaw55cn4c · 2021/10/30(土) 16:29:48.11

>>299
＞キャリー/ボローフラグが使えたら良いなあ
ですよね、ローテート／シフトのときは特に

**デフォルトの名無しさん** · 2021/11/06(土) 14:48:01.13

int と size_t がいつも混在して面倒になる

**デフォルトの名無しさん** · 2021/11/26(金) 11:52:34.78

勝手な整数拡張をやめてくれるある意味cより低級なcが欲しい
パフォーマンス的にワード長で扱うのが良いというのもわかるが
あえてintより小さい型で計算したい時というのはそれなりの理由があるからやるわけで
その型内でオーバーフローしたら切り詰めずに素直に落ちろ

**デフォルトの名無しさん** · 2022/04/19(火) 01:58:13.78

しかしそこまで低級なところに降りていくとマクロアセンブラみたいなのが使いやすい感じになっちゃうんだよね。
言語上の表現がどういう機械語に対応付くのか意識するともう直接書いた方がええわ……となる。

**デフォルトの名無しさん** · 2022/04/19(火) 14:30:56.58

呼び出し前後のレジスタ退避と回復だけやってくれれば意外とアセンブラはほぼforthだよね

**デフォルトの名無しさん** · 2022/04/21(木) 17:35:30.02

forthは言語とマクロ用言語が同一言語なアセンブラだな
gforthみたいなリッチ実装はコンパイル済の定義を参照するとx86の標準文法を曝け出しちゃってなんだかなぁ、と思う

**デフォルトの名無しさん** · 2022/04/21(木) 20:15:20.64

>>304
forthは呼び出し規約の抽象化じゃなくて、型と引数という概念を捨てて自由になった
マシン依存性を排除するためにレジスタを抽象化した汎用dスタックに全ての命令が型と個数の解釈をモラルを守って作用することで成り立ってる
(暗黙の)引数渡しに関してはオーバーヘッドは大きくないので普通はマシンの最大スカラー型
floatはさすがにfスタックがあるけど

dスタックだけで複雑なデータ操作は厳しいから、最大スカラー型である事が保証されてるrスタック(生ハードウェアスタック)が一時領域に便利なのが闇

制御構造も戻りアドレスや添字を積むだけだから、うっかり積み残しがあると戻りアドレスやデータが添字代わりにインクリメントされ続けたり不可解な事に

あとは拡張性が売りの癖に制御構造のポータブルな拡張が難しいのがな…
もちろん制御構造と整合性のある単純な命令くらいは添えられてるのであくまで例だけど
指定回数ループをbreakするには最低で添字と戻りアドレスをpopする必要があるけど、たいてい実装拡張として積まれてるデータは不定、何回popしたらセグフォるか試すことになる

規格の制御構造には不備があるから(これは本当)うちの拡張を推奨ってのが普通の世界
制御構造すら定番がなくて、同じ言語といえるのかという疑問すら湧く

**デフォルトの名無しさん** · 2022/04/21(木) 21:15:26.12

>>305
コメント無くなってたり、埋め込んだ定義が等価な表現に置き換わってたりするから、seeは既存のコードを参照してるのでなくて、ブロブからforthコードへのディスアセンブラ(再構築)

ワードを渡せば' でそのワードの指すアドレスは取れるけど、そこから何バイト読むかのオフセット指定をseeは取らない、かなりヒューリスティックだと思う

seeで標準される開始-終了アドレスに、読みすぎてそうなら適当に足すか、途中で切れてるようなコードなら適当に足してaddr nbyte discloseと呼べば大体復元できると思う
dis、+disとかも入ってたっけ

まあ、具体的なレジスタやメモリの名前が分かるだけでforthコードとそんな変わらないという悲しさはあるが

**デフォルトの名無しさん** · 2022/07/30(土) 16:21:32.91

Nim++

**デフォルトの名無しさん** · 2022/08/03(水) 08:36:38.78

低級言語ならx64特化して構造化アセンブラみたいな感じで
ちょっとオシャレだけどやってる事はほぼむき出しのレジスタ操作みたいな？

**デフォルトの名無しさん** · 2022/08/03(水) 11:55:01.67

masm64でinvokeしまくれば

**デフォルトの名無しさん** · 2022/08/04(木) 05:27:08.29

例えばループが多重化してループカウンタが複数必要な場合
作法としてRCXを使うけど、処理系が最適化で空いてるレジスタを割り当てたり
退避復帰をしつつRCXを使うとか
固定領域を確保してカウントに使用するとか自動でやってくれるみたいな
プログラムコードは雰囲気コーディングだけど最終出力は忖度された何かみたいな感じ

**デフォルトの名無しさん** · 2022/08/04(木) 18:25:34.25

アセンブリ並みの変態低級言語作る?

**デフォルトの名無しさん** · 2022/08/06(土) 14:07:02.72

Nim++

**デフォルトの名無しさん** · 2023/09/21(木) 12:59:48.22

もうそろそろ、おしで祭りや

**デフォルトの名無しさん** · 2023/11/01(水) 03:29:10.04

Nim#

**デフォルトの名無しさん** · 2023/11/05(日) 10:42:59.68

Rust++

**デフォルトの名無しさん** · 2023/11/05(日) 16:32:02.05

最近のCPUのアセンブラはほとんどCと変わらないようだけど

**デフォルトの名無しさん** · 2023/11/06(月) 06:07:34.02

昔のCはアセンブラとほとんど変わらなかったから
差は縮まっていない
なにも変わってない

**デフォルトの名無しさん** · 2023/11/06(月) 16:20:14.87

最近はむしろC標準が直接サポートしてない命令が増えてるからな
ローテイトなんていまだにないし

**デフォルトの名無しさん** · 2023/11/11(土) 12:31:46.21

>>319
良いのが入荷
https://www.youtube.com/watch?v=P6KRbjoFdwY

**デフォルトの名無しさん** · 2024/02/11(日) 03:12:32.56

>>294
Aカップが好きなアセンブラ君、食わず嫌いはいけません高級言語は恐くありませーん
Bカップが好きなBASIC君、少しは毛が生えたけどまだまだ修行が足りません関数に興味はないのですか
Cカップが好きな君は正解に限りなく近い。有象無象の言語はたくさん出てきたけれど結局Cが手ごろサイズで限りなく正解に近いです
Jカップが好きな君は煩悩に振り回されっぱなしです。たまには太陽だけでなく月にも興味を持ちなさい

**デフォルトの名無しさん** · 2024/04/19(金) 10:13:34.89

>>1
仮想アセンブラを作ることになるが、かえって誤ったハードウェアと勘違いしそうw

**デフォルトの名無しさん** · 2024/04/19(金) 10:14:46.38

>>317
アセンブラがわからないのに語る変なやつw

**デフォルトの名無しさん** · 2024/05/02(木) 01:06:39.68

>>321
どうでもいい話だけど、J が Java のことを言ってるようにも見えるので
実際には J 言語てのがあるんだけどね
J はJava や JS とは全く関係ない、APL (という言語) の派生言語で
APL と違って特殊キャラクタを使用せず ASCII のみで記述可能にしたもの