【超高速】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

**デフォルトの名無しさん** · 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 のみで記述可能にしたもの

**デフォルトの名無しさん** · 2024/12/11(水) 21:59:47.09

>>1
そうして生まれたのがRust
Cと同じことが出来つつCの諸問題を解決した
インラインアセンブラも備えているのでCを置き換えられるようになった

**デフォルトの名無しさん** · 2025/03/24(月) 12:24:27.59

>>325
let bits = vec![false; 32];
これでbitsのサイズが4バイトになってくれるような仕組みはRustにありますか？

**デフォルトの名無しさん** · 2025/03/24(月) 13:15:17.83

>>326
https://docs.rs/bit-vec/ がいいかな

use bit_vec::BitVec;

fn main() {
　// 32bit全てfalseで作成
　let mut bv = BitVec::from_elem(32, false);
　// 7bitおきにtrueセット
　for index in (0..32).step_by(7) {
　　bv.set(index, true);
　}
　// 0, 7, 14 , 21, 28番目のbitがtrueになった
　assert_eq!(bv.get(0), Some(true));
　assert_eq!(bv.get(1), Some(false));
　assert_eq!(bv.get(7), Some(true));
　assert_eq!(bv.get(28), Some(true));
　// イテレータでtrueになってる位置のリスト
　let v = bv.iter().enumerate().filter_map(|(i, bit)| bit.then_some(i)).collect::<Vec<_>>();
　assert_eq!(v, [0, 7, 14, 21, 28]);
　
　// 内部構造は標準でVec<u32>を使っているのでu32が1つ分
　assert_eq!(bv.storage(), [0b_10000001000000100000010000001]);
　// バイト列にすると4バイト
　assert_eq!(bv.to_bytes().len(), 4);
　assert_eq!(bv.to_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001000]);
}

**デフォルトの名無しさん** · 2025/03/24(月) 13:30:34.57

CはPDP-11のアセンブラの高級言語化でしたっけ？
消えたアーキテクチャとは言え未だ有用ではありますが、現役アーキテクチャの8086-64やARMのソレとかの命令セットはどうなっているんでしょ？
多分基本命令そのものは大差ないと思うけど、マルチメディア拡張？　MMXみたいな専用命令はCで直接記述出来ないですよね。
他にも、最近のナウいアーキテクチャは文字列をそのまま扱えるとか聞いて想像の範疇超えてます。
高級言語も楽で良いけど、そういうのは楽なアセンブラの上に構築出来ればそれで良いなあ。

**デフォルトの名無しさん** · 2025/03/24(月) 19:01:49.54

25年位前のレスのコピペかよω

**デフォルトの名無しさん** · 2025/03/25(火) 03:40:11.48

>>327
なんか左右逆で気持ち悪い(bigendian/littleendianともちょっと違う)
bv.set(31, true);
bv.set(32, true);
assert_eq!(bv.to_bytes(), [
0b_10000001, // 0-
0b_00000010,
0b_00000100,
0b_00001001,
0b_10000000]); // 32-
assert_eq!(bv.storage(), [
0b_10010000001000000100000010000001,
0b_1]);

**デフォルトの名無しさん** · 2025/03/25(火) 08:18:52.12

>>329
すまない、オッサン通り越してお爺さんだから思想も古いんだ。

**デフォルトの名無しさん** · 2025/03/25(火) 08:41:39.56

>>327
ありがとう。参考になりました。

多倍長整数の論理演算でbit立てる方法があったので、
それを使ったら簡単で速度もそこそこ出たので満足しました。
>>327 さんのものは不採用です。

**デフォルトの名無しさん** · 2025/03/25(火) 09:02:37.24

>>330
ビットはそういうものだよ
普通にビット演算すればわかる

let mut bits: u32 = 0;
for n in [0, 7, 14, 21, 28, 31] {
　　bits |= 1 << n;
}
// u32に詰めているからこうなる
assert_eq!(bits, 0b_10010000_00100000_01000000_10000001);

// bit順(index=0..)にバイトで得る
assert_eq!(bits.reverse_bits().to_be_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001001]);

**デフォルトの名無しさん** · 2025/03/25(火) 12:13:35.71

assert_eq!(bits.storage(), [0b_10010000_00100000_01000000_10000001]);
の結果から想像するに
assert_eq!(bits.reverse_bits().to_be_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001001]);
ではなく
assert_eq!(bits.to_be_bytes(), [0b_10000001, 0b_01000000, 0b_00100000, 0b_10010000]);
の方を期待するのは可笑しいのかなー
正直びっくりエンディアンですわ

**デフォルトの名無しさん** · 2025/03/25(火) 19:08:05.91

byteやword単位のリトルエンディアンじゃなくて
1bit単位のリトルエンディアンだと思えば自然

**デフォルトの名無しさん** · 2025/03/27(木) 07:21:00.91

Rustのオペレーターオーバーロードについて質問です
とりあえずtraitを使って
let a: X = X::new();
let b: X = X::new();
let c = a + b;
は出来たのですが
let a = &X::new();
let b = &X::new();
let c = a + b;
だと定義が無いと言われるのでtraitに&のバージョンを追加したら出来ました
ところが
let a = &mut X::new();
let b = &mut X::new();
let c = a + b;
だとまた出来ないのでtraitに&mutバージョンを追加したら出来ました
ところが
let a = &X::new();
let b = &mut X::new();
let c = a + b;
や
let a = X::new();
let b = &mut X::new();
let c = a + b;
や
let a = &X::new();
let b = X::new();
let c = a + b;
が全部出来ません
こういうのはすべての組み合わせをtraitで作っておく必要があるのでしょうか？
それとも一つの表現で全部定義してくれる仕組みは？

**デフォルトの名無しさん** · 2025/03/27(木) 09:14:29.90

これかな
https://stackoverflow.com/questions/57911001/how-to-combine-all-operator-overloading-combinations-into-a-single-trait-in-rust

**デフォルトの名無しさん** · 2025/03/27(木) 09:22:10.62

>>336 >>337
ここに回答があるよ
https://stackoverflow.com/questions/38811387/how-to-implement-idiomatic-operator-overloading-for-values-and-references-in-rus

**デフォルトの名無しさん** · 2025/03/27(木) 09:56:58.93

ああこれinternalなのね
macro_rules! add_impl とか
macro_rules! forward_ref_binop
(unop とか op_assign とかもあるけど)

**デフォルトの名無しさん** · 2025/03/27(木) 09:59:54.17

これでいいのかな
https://crates.io/crates/forward_ref_generic

**デフォルトの名無しさん** · 2025/03/27(木) 10:02:25.16

ああこっちか
https://crates.io/crates/forward_ref

>>328
それは >>327 の中にリンクがあったので既視です㌧㌧

**デフォルトの名無しさん** · 2025/03/27(木) 11:15:21.43

よさげだったけど&mutのが出来なかったorz

**デフォルトの名無しさん** · 2025/03/27(木) 11:35:25.37

結局自前でmacroコピペして&mutの定義も追加したらいけたわthx

**デフォルトの名無しさん** · 2025/03/27(木) 11:46:57.39

Copyトレイトは無闇に付けたくないな

**デフォルトの名無しさん** · 2025/03/27(木) 11:59:13.89

Trait爆発ですね判ります

**デフォルトの名無しさん** · 2025/03/27(木) 12:14:45.69

>>342
Addでは不変参照しか使わないから& mutは不要
& mutが必要となるのはAddAssignだがこれは& mut selfになる

**デフォルトの名無しさん** · 2025/03/28(金) 09:26:28.67

Rust使ってても暗黙のCopyとかに無関心だと【超高速】名乗れなくない？

**デフォルトの名無しさん** · 2025/04/05(土) 10:41:53.71

包丁も食材も上手く使えないと料理は不味い

**デフォルトの名無しさん** · 2025/04/06(日) 07:52:19.40

料理が上手なヤツはRustは使わない

**デフォルトの名無しさん** · 2025/04/06(日) 23:21:04.80

>>347
暗黙のコピーが発生しまくる諸言語とは異なり
RustではCopyトレイト実装型のみ暗黙のコピーが行われるので最もRustが好ましい

具体的にCopyトレイト実装型とは整数値やポインタおよび不変参照であり
それらを用いた複合型は明示的にCopyトレイト実装することもできる

ちなみに整数値などがなぜ暗黙のコピーが起きても構わないかというと
CPUにとってそれらをポインタ経由で間接的に扱う方が遅くなるからであり値をコピーして用いたほうが速いため

**デフォルトの名無しさん** · 2025/04/07(月) 10:58:45.39

はあ…

**デフォルトの名無しさん** · 2025/04/07(月) 12:23:44.19

>>349
マにだって料理が得意な奴はいるだろ

**デフォルトの名無しさん** · 2025/04/07(月) 14:31:02.06

>>350
お前レベル低過ぎ
黙ってろ

**デフォルトの名無しさん** · 2025/04/07(月) 14:50:26.71

>>350で合ってるでしょ
コストの係るものは明示的に.clone()しないとコピーできないし
コストの係らないものはCopyトレイトのおかげで.clone()しなくてもコピーされるよ

**デフォルトの名無しさん** · 2025/05/02(金) 09:39:27.39

Rustの最大の教訓は、どんな言語でも有名になればバカ(必ずしも頭が悪いわけではなく、本来その言語が想定しない用途に使おうとする奴も含む)が使うってことだろう
Rustの仕様はそれほど効率が重要でない分野でテキトーに使おうとすると無駄なコピーが増えたりしてかえって非効率になりがちな面がある

**デフォルトの名無しさん** · 2025/05/02(金) 18:23:29.41

>>355
Rustは明示的にclone()を呼んだりCopy実装しないとコピーされないから大丈夫だよ
暗黙にコピーされないから無駄なことをしていればコード見るとすぐバレちゃう
まともなコードは必要な極一部を除いてほとんど参照で渡されるね
ちなみに数値や不変参照(ポインタ)はCopy実装されてるため暗黙にコピーされるけどそれが一番速いから問題なし

**デフォルトの名無しさん** · 2025/05/03(土) 12:05:28.26

最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか

**デフォルトの名無しさん** · 2025/05/03(土) 13:36:23.13

>>357
頭悪いから違いを理解できないのか？
まずCPUのMOVE命令は全てコピーだ
だから数値や参照(アドレス)がCopy実装されていても何のペナルティも存在しない
むしろ数値や参照を参照で扱う方が間接となり遅い
次にCPUのMOVE命令は全てコピーだがコピー元が使われてなければ純粋なムーブと見なすことができる
そのため最適化が可能で例えば2回のムーブは1回に減らすことができる
これはスタック上の変数を扱う場合も同様でレジスタへMOVEした後にレジスタ間の演算で終わるならスタック上の領域は不要で最適化できる

**デフォルトの名無しさん** · 2025/05/03(土) 13:38:21.80

RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ

**デフォルトの名無しさん** · 2025/05/03(土) 13:39:26.21

したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる

**デフォルトの名無しさん** · 2025/05/04(日) 11:58:45.22

区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる

一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない

**デフォルトの名無しさん** · 2025/05/05(月) 10:09:59.16

RustはC++より描き易いけどC++からの置き換えには不適
RustはCより面倒だけどCからの置き換えには最適

**デフォルトの名無しさん** · 2025/05/06(火) 06:06:18.29

低レベル言語の開発だよね？
皆さんの会話が高級すぎて戸惑いを隠せない。
OS記述も十分に低レベルだけど、ハードウエア操作はもっと低レベルじゃないかな？

**デフォルトの名無しさん** · 2025/05/06(火) 10:06:47.77

Rustで低レベルするとunsafeだらけになる
(悪いとは言ってない面倒臭いとは思う)