【超高速】C/C++に代わる低級言語を開発したい 8YouTube動画>1本

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

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

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

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

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

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

◆新言語の要件 v0.1◆

（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。

◆新言語の前提 ver0.02◆

・言語仕様が小さい
・言語仕様に例外事項（但し書き）が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
　（オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい）
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
・既存のバイナリーオブジェクトをリンクして呼び出せる

◆新言語の位置づけ◆

Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。

◆新言語でのリソース管理方針◆

・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい

※GCは手段であって上記が満たされていれば必ずしも必須ではない。

チューリング完全になれば何でも良かったんだよ
高価な機能はいると訳分からなくなる低脳はC
そういうのがはいっても効率的に扱える奴はC++

既にすみわけは出来てるCとC++の中間くらいの言語が存在しないってだけで
そんなのあってもなくてもどちらでもいい
いま一番Cの代替になる可能性が高いのはGO

営利目的で言語は作ったほうがいいよ

Cの代替になる言語を作ったら金になるか？

ならないのであれば作る価値はないし、使われる価値もない

金金金金金金金金金金金金金金金金金金金金金金金金金金金金

本物のハッカーとかそんなもの関係ない、
金の力が人の学習意欲をかりたたせる
どんな雑魚でも生活のためならC++言語でもなんだろうと使いこなす
本物の天才が金を得るためにプログラムを組む
いくら優秀な言語があっても、金から遠ざかれば使われない

で、C/C++に代わる低級言語としての提案は？

ネイティブはけるruby

Objective C でいいだろ。

おれもObjectiveCでいいと思うね

＜ハードウェアを直接操作する低レベルの記述が可能
ってことは移植性は要らないんだよね
アセンブラでいいんじゃね

アセンブラを超進化させるのが近道じゃね？

おれもアセンブラでいいと思うね

マジレすすると、
しっかりとC++技術者を育てたらいい
C++が使えない は甘え

アセンブラに化け物なマクロ入れるだけでいいんじゃねぇの？
欲しい機能はマクロで定義

C言語の価値もプリプロセッサにあるんだよね
アセンブラにもマクロあるじゃないの
ただ、アセンブラ毎にマクロの仕様が違ったりするから
併合しようとした人はこれまで何人もいた
でも結局使わないんだわそんなの

CLASSは欲しいのかな？

uyが社畜みたいな発言をしていて雑魚くさい。

C++は、仮想関数テーブルがいまいち。

なんでC++は仮想関数使うと異様に遅くなるんだろう。

アセンブラマクロに強力な型機能を持たせて、ついでに多態性も付けて
単純な継承・カプセル化程度をサポートすればおｋ？

アセンブラマクロでイテレータつくれる？

どういう風に使いたいのか仕様 plz.

kuin最強伝説

プログラミングは最終的にはアセンブラになるかもしれないね
よく考えたら無理じゃない気がしてきた

せっかくよく考えたのなら、その考えを文章にしてみよう。
鉄は熱いうちに打て。

>>24
それは、高級言語プログラミングしてる時に、
頭の中でアセンブラが思い浮かぶような人だけだよ。

C/C++は高級じゃないと申すか

昔は知らんが
今はCは低級、C++でOOPすれば何とか高級？

恒久

制御対象が十分に抽象化されていれば高級、ベタに見えていれば低級
言語はそれほど関係ない

サーバーサイドjsが持てはやされるぐらいなんだから、
自社サービスを展開してるようなところではc/c++は使われなくなるんじゃないかしら
そういう企業じゃシステム言語はgolangが主流になると思うよ

WebでC/C++は珍しい。
goは当分ならねーよｗ

いまの言語とか制御構造や予約語の文法以前とか以前に
ライブラリーの便利さと豊富さが基本であって、言語の重要性はあまり関係ない。
同じコードを書くのに少ないコードで実現できる（内部が見えない）
類が抽象化の度合いでどれだけ高機能を呼び出すだけで実装できるかが
重要になっている。
低級なそれは多くの仕組みと手順を細かく表現しなければいけないのだが
高級になれば何も表現しなくても「あれ」「これ」な感覚で作れてしまう。
本当に低級ならば四則演算とか使わずにプログラム作れよサブルーチンという
概念も使うな！

魔法みたいなことが出来る関数があれば終わりですって

Webやスクリプト言語には興味ありません

ハードウェア制御・リアルタイム・マルチコアなどなど
抽象化のための「見えない」コードを書きたいのです

>>33
であれば、具体的にどのようなライブラリが必要と考えるのかを述べるのがこのスレッドの意義である。

「使うな」で終わるのは建設的ではない。前半は良い発言だから、頑張れ。

>>32
ラッパー経由で思いっきり使われてる。

>>37
スクリプト言語もHTTPサーバーもOSもCで書かれてるしな。おもいっきり使われてる。

ある程度モデルになる言語は要るだろ
Objective-C++をモデルにすることを提案する

モデルにすることを提案するだけではなく、どのようにモデルにするのかを提案するともっといいぞ

局所変数をすべて静的大局変数にするなんてどうだい？

41 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

>>41
その効果は？

ポストPHP/CGIを狙うような静的型付き言語を開発したいがそういうスレはないものか

（どうやら俺の他にはいないようだな…しめしめ、勝った）

C/C++なくても、型付Lispが開発されて、もっと遅かったであろう。

実用化されるまで10年以上遅れていたであろう。
ていうかPCという概念すら生まれなかったであろう。

概念ｗ

Cができるようになる前から安価なPCってあったんだっけか

ない

エレキてきバグでまくるだろ

41みたいなことをするとバグ、多発。

CもC++も高級言語で、スレタイがそもそも間違ってるのに、いつまで続けてるんだ。
マシンコードそのままなのと、アセンブリ言語だけが低級言語ということも知らないのか。
コンピュータの勉強して最初にわかることじゃないか。
それに開発したいのはどういう目的があってのことなのかね。

>>53
スレ違い

オブジェクト思考なんて何十年も前
今は最新なんなんだ？

ラムダ関数

>>55
アスペクト指向というのがあるがまだ実用化されてない

アスペルガー指向の方が多くないか？wwww

なるほろ
サンクス

アスペクト指向はソースコードのXML化といって差し支えない
XMLタグの量を増やせばできることも増えるがソースは冗長で不細工になる。
OWL推論でコンポーネント間が繋がれば、超冗長だが再利用しやすくなったりするかもな

<Entity name="DBTable">
class Persons {}
</Entity>

@Entity(name="DBTable")
class Persons

型付きlisp風言語作ればいいじゃんて話だろ、まとめると

関数コール時値やアドレス値をスタックやレジスタへ積み積みする暗黙に埋め込まれるコードもアスペクト
暗黙だけでなくあちこちにユーザーコードまで混ぜれるようにしちまう開放的且つカオス世界への招待を
有難いと感じるかどうかが別れめっスね

自分一人でやる分にはいいが複数人でやるとたちまち世界が破滅する

構文を工夫して文字数を減らしても仕方ないし、XML/アスペクト指向も終わった。
最近の新しい発想というとKVSぐらいだな。１人でプログラミングすると効率悪いが、
多人数での分業に向いている言語とかいんじゃね？

Javaのことですねわかります

>>59
なにか変だと思ったら DIとAOPを混同しているな

JPAとかEntityBeanはDIなのか？

>>54
スレ通りの発言だろうが

>>53 と >>67 って同一人物?
C++ はともかく, C って高級アセンブラだろ?
立派な低級言語じゃん

Cは読める低級

D言語でいいじゃん

E言語でEじゃん

>>70
似非システム言語はすっこんでてください

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 のオンパレードと同じだと言っているんだが
単にニーモニックが書けるだけでは不十分で
オペランドの装飾名やレジスタアサインまで最適化の影響も受けずにクリアする必要がある
高級言語でだぞ？　これを邪道だというのの、どこが個人的意見なんだ？

> ラップ関数で覆って見えなくして
日本語でおｋ

> その主成分を知ってる人に聞きたい
逆アセンブル読めよ、読めないならもう一度言ってやる「主成分を知らないやつめ」

>>78
asmがあるのはなぜって、俺に聞くのはお門違いだ
移植性を重視しながら sizeof(int) が処理系定義だしねえ

> システムアプリは大なり小なりシステム依存のコードを含むことになるので
そのとおりだが

> インラインアセンブラは大した問題にはなりません
なぜこうつながる？

> 私は外部のアセンブラを使っていました。
過去形ということは「あの問題」を知らないわけだね
このくだり、突っ込みどころ多すぎて投げたわ

>>80
なんだ、ただの知ったか君か、ご苦労w
もう来なくていいから

>>81
おいおい、>>78はD言語のFAQのコピペだぞ。つまり「私」というのはD言語の開発者だ。
どう見てもおまいよりコンパイラの内部に詳しい。
「あの問題」とかわけわかんないこと言ってんじゃないぞw
知ったか君はろくに文章も読めないから困る。話にならんな。

>>80
日本語不自由な人みたいなので wrap function と書けば理解できるのかな。在日君ですか？

Cがアセンブラより太る原因は逆アセなんかしなくてもわかるんだが。
おまいさあ、Cコンパイラのソース一度も読んだことないだろw
「低レベルなやつめ」

シッタカ君に権威主義君か
どんどんやれ

淫乱NISSENブラ

Cのファイルサイズサイズ語るならリンカだろ？
gcc読むにしてもCコンパイラ部分は読まねえよ。
コンパイラなら普通にアセンブリ吐くから逆アセンブルもしねえ。

>>84
いーや、逆アセよまなきゃ10倍にもなる理由は説明できない
コンパイラのソースとか何言ってるんだ？　頭が発狂したのか？

具体的な説明でもobjdumpで十分だろ。
逆アセンブルしたコードなんて読まねえよ低能。

逆汗読めねえ低脳でもリンカのマップくらい読めよせめて

ついに逆アセンブルに意味がないことを認めてしまった低能ｗ

は？　10倍という定量的な値に反論できないのはてめえだろうが

説明出来れば十分だろ？
構造とシンボル情報見せてlibcの初期化コードが含まれているで十分じゃん
サイズ知るためだけに逆アセンブルコード読む必要なんて全然ないだろｗ
どこに必要あるのか言ってみろよ低能ｗ

それは10倍にならないコードを示せれば充分だ
Hello World しかできねーバカにそれは無理だが

このまま逆アセンブルが必要である具体的な理由を示せないなら負けだぞ低能

別に負けで結構だ
有料なノウハウをただでぶちまける必要はない

具体的に言えないどころかあえて言わないだってｗ
ここまで否定してきて根拠も出せないｗ
まさに負け犬の遠吠えｗ

readmemoryとか
writememoryがどうなるのだろうか

なんの話？

ナンではありません

scalaみたいな、Cかアセンブラのコードに変換してくれる言語作れば？

そう。その具体的な仕様を決めようとしている。

PGはバカでいいという思想はCOBOLの轍そのもの

開発環境は言語のうち
つまりVisualStudioを超える開発環境を作れ

>>103
Javaも割とその思想が入ってる
まあJavaの場合はC++がPGを過信してることへのアンチテーゼもあるんだろうけど

PGはバカでいいというなどという突拍子もない捉え方は１ビット脳そのもの
なぜ中間がないのか

>>106
いいえ

Lazy kでよくね？

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

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

>>1

大事なのは俺TUEEE感に浸れるかどうかだから
既存のものを流用するなどというのは根本から間違っている

トランスコーダから始めよう。
謎言語toASMが最終目標だ！

>>110
既存の言語を使えと言って思考停止するのは間違っているが
既存のものを流用するのは間違っていない。

C言語が糞なのはヘッダファイルが原因だ
#includeが#importになれば全て解決する

ヘッダ面倒臭ぇ

相変わらず低レベルなところを這い回ってるな

上からモノ言う人って、すごい人なのかと思ってた。
でも意外とそうでもないんだね。

昨日、C言語スレで構文解析の話題があった時、上からモノを言ってくるので
凄い人だと思って話を聞いてたら、実は初心者だった。

人の話は板違いです。
ご遠慮ください。

ステートマシン風な言語でも作ればいいじゃん。

いいね。先ずは具体的なアイディアを聞かせて。

欲しい言語機能は全てRUSTに入っていた

RUSTは正解に近い感じがする。

RUSTってC++と比較されるけど低レベル組み込み系もいけんの？

C++、stlが許されるだけのリソースがあるなら大丈夫そうだ。

コンパイル時リフレクション(javaでいうアノテーション・プロセッサ）がほしいな
シリアライザーとか自動でつくってほしい

C++は低級言語なのか？

Dがもっと流行れば解決する。

Dはないわ。

LLVM IRみたいのでいいだろ。

vecterはc、c++から外して欲しい、元はjavaだろ、イテレータとか。

Javaは外した方がいいというのは、銅管だ。

低級言語はアセンブラと初期のCだけだろう

言語作ってるんだけど、
コンパイラ作る時って一旦アセンブラ出力してからmasmとかに機械語出力してもらった方がいいの？
masm自身はアセンブラコードの最適化とかはしてくれなそうだしそのまま機械語出力したいんだけど

アセンブラ介したほうが少なくともデバッグはしやすいと思うぞ

そのコンパイラで何ができるもしくは何をやらせるのかも
決めてないんだ

>>134
どれくらいしやすくなる？
命令のバイナリ列を理解しやすい(?)形でアセンブラに1対1で置き換えてデバッグする、っていう手間が省ける程度なら雀の涙という感じ
むしろデバッグするときは結局機械語読むことになるから最初から機械語で出力したほうが理解が早い気もする
それ以上のメリットってなにかあるのかな

>>135
一応決まってるよ
Windows8以降向けのUI・ゲーム開発言語

x86系の命令、１６進数で読めるんだ
なら、直接コード出して、ハマりまくったほうがいいかもね

>>136
用途からすると機械語やアセンブラへのコンパイルどころか
C言語+HLSLへのトランスレータが最適解な気もするなあ…
結局、何だかんだでDirectXの関数呼ぶことになりそう

んで関数呼び出して処理するなら、機械語とC言語の差は間の計算処理になるが
そこも巷のC処理系の最適化はノウハウ詰まってるから
下手なアセンブラコードより速かったりする

何れにしても何層かに処理を分けることにはなるだろうから
いきなり全部やろうとするより、やるべき層をひとつひとつ集中してやったほうが

>>137
わーい

>>138
そのとおりです
DirectXの関数は呼ぶよ。でもスレの主旨的にもC言語を介したくないのよね
GPUへの命令はさすがに手に余るからとりあえずHLSL出力することになると思うけど…

ううーん。とりあえずCに翻訳してコンパイルして、でてきたアセンブリを研究してみようかな
ありがとう

LLVMという選択肢は

本スレは、コンパイラをどのように作るか、ではなく、どのような言語仕様にするか、を重視しています。

コンパイラの話が終わったら、言語仕様の話をしましょう。

LLVM/Clang 実践活用 ハンドブック、出村成和、2014


LLVM 言語マニュアル(Language Reference Manual)
http://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
人工知能とか、ネタなのか本気なのか分からなかったので若干しつこく聞いたけど、本気ならその方針で面白いものへと広げてほしい。

といいながら、興味本位で聞いてしまうけど、人間はともかく、人工知能にとって「直感的」ってどういうことなの？
人工知能ってコンパイラだよね。コンパイラにとっての直感性というのが分からなかったので。

それと、作りたいのは「言語」でいいんだよね？コンパイル可能な自然言語とか。

しゃべればしゃべるほど非マの妄言と化していくな
板違いだべ

>>153
純粋なコンパイラというよりはコンパイラとインタプリタを統合した処理系だね。
Prologのような対話(厳密にはうちの言語のは対話ではないけど似たようなもの)を繰り返してプログラミングすることもできる。
その場合、処理系は対話によって学習できるし、学習したところから発話もするように考えてるから人工知能と呼んでいる。
人工知能にとって直感的っていうのは、手続き型の制御フローに沿った発話がそのままできるってこと。
たとえばうちの言語はそもそも語順がかなり自由だから、手続き型プログラミング的な構文をそのまま人間の言葉として理解できる、とか。

一言で言えば言語だね。芸術言語とプログラミング言語を足したようなものだよ。

>>155
OK。現状ではコンセプトを理解するのが難しいということがわかった。

早く具体的な言語仕様を知りたいので、ぜひその議論を進めてほしい。

>>155
実験言語で終わりそうな悪寒

エプロンおねえさん、めざしてるのかしら

Cは高級言語であって、スレタイがすでに間違ってるのに、お前ら
はあほか、こんなものを続けて何の意味があるんだ。

Cは低級言語だろ何言ってんだ

高水準言語の基準は人間がそのまま動作を読み取れる言語だろ
よってC言語は当然高水準言語

ハードウェアを直接操作できるのが低級、できないのは低脳

高級、低級の呼び名はどうでもいい。C言語を低級言語と呼びたくないならそれでも構わない。そのことに大した意味はない。

スレタイの意味は>>162がほぼ正しい。

>>162の言葉を借りれば、「ハードウェアをオーバーヘッド最小で直接操作できる言語」、それがこのスレで言うところの低級言語。

低級言語という言葉が嫌なら、ハナモゲラでもゲゲボでも好きな呼び方をすればよい。
但し、呼び方を使用する前に、定義を明確にすること。

Cは昔から「高級アセンブラ」と呼ばれていたと思ったが

>>157
どうやっても個人開発だから実験言語までいけばいいところだね。
それでむしろ実用的な最適化とかはちゃんとノウハウのあるところに開発してもらうのが一番いいんだけどな。

高級言語でも低級言語でもないから、中級言語である。
There are following reason that C is called Middle Level Language as:

C programming language behaves as high level language through function, it gives a modular programming and breakup, increased the efficiency for resolvability.
C programming language support the low level language i.e. Assembly Language.
C language also gives the facility to access memory through pointer.
Its combines the elements of high-level languages with the functionalism of assembly language.

So, C language neither a High Level nor a Low level language but a Middle Level Language.

C Programming: Middle level Language
http://cprogrammingcodes.blogspot.jp/2011/12/middle-level-language.html

諸説あるよ

"middle-level language"
Googleで検索

各CPUのアセンブラを勉強しなくていいから、Cは、高級な感じがするが、
オブジェクト指向言語ではないし、セキュリティが不足している（実際は、それもCで達成できるはず）ようにみえるから、
Cは、高級言語ではない。

ID:997Wnr2J には、このスレでCを「高級言語ではない」と呼ぶ権利を与えます。どうぞご自由に。

高級言語ではあるけど、メモリアドレスを直接指定しての書き込みや
必要とあらばインラインアセンブラも使える言語って意味だろ

更にC言語の場合、アドレスの抽象化があまりされていなくて
それらが必要でなくともアドレスを扱うことになるからそう言われるんだろう

高級言語って３０年前の言葉だからな。C/C++より上のいまどきの言語は超高級言語だろ。

肉体労働向け言語に進化しましたから、超高級とかいってるのは

高級言語だから定休知能では扱えないということはなく
むしろ反比例の関係にある

マ板に高級＝デラックスと勘違いしてるやつがいるとは。

ここム版ですが

マイッタ

>>2->>3を読む限り＞1の望みを満たして居るのはかつてとは段違いに美しく高水準に整えられた今時のアセンブラと思われる

あぼーん

配列を表現する場合無限にメモリーなりCPUなりが利用できる場合リストになるよね
数値の表現も
色々な型がサポートされている時点で低級言語じゃないか
細かいリストや配列の加工操作がしたいんじゃなくて
もっと抽象的に状態に対する結果が欲しい
高級言語と呼ばれるものも抽象化で捉えると低級言語？

各CPUを勉強するのが低級言語

ギガヘルツとか、正気か？　とおもうぞ

何の話？

PCは15年ぐらい前から、スマホは5年ぐらい前から、ギガヘルツ超えのCPUが載ってるけど
電子レンジもWi-FiもBluetoothも2〜5ギガヘルツの電波出してるけど
正気か？　とおもうか？

>>183
衛星とかFWA無線とかもっと速かった気が

ムーアの法則で想定内。

低級言語って
言語の基本機能だけじゃまともなアプリ作るの苦労するって言語ってこと？

低いレイヤにアクセスすることが前提の言語な
プログラミングにおける低級高級は優劣の話ではなくレイヤの話だから

低レイヤってOSやハードウェアと直接やり取りするって感じ？

このスレとは違うが
一般に、低級言語はアセンブリ、C言語以上の言語は高級言語。

超高級言語クレとは言わないけど
高高級言語くらい欲しいって思ってたら有ったっぽい
通常パターンマッチてif文の羅列やネストで重複した論理演算を省略して速度他を稼ぐんだけど
パターンマッチ指向はその常識がないｗ
なんて恐ろしい子
その代わりマッチする条件をダラダラ例記すればよいから
直感的にこの組み合わせおかしいとか修正が楽
なんか条件の検出に正規表現？使っている様な雰囲気ワロタｗ

最適化なしの高級っぽい言語ってマクロの親玉みたいな感じだから
実装は楽じゃないの
デバッグ環境もセットで用意しろと言われるといきなり敷居があがるけど

>>190
おまえ、ここで何言ってんの？

LLVMそのものやん

僕が考えた最強の言語Swift
各言語の構文てんこ盛りで、LLVM介してコンパイルで、>>1が望むものじゃねーか？

どっかのC/C++コンパイラは一度アセンブリのソースに変換してからオブジェクトコードにするって聞いたな

よく分からないならROMっとけよ

>>193
Swiftってデバドラを実用的に書けたりするの？

まっくのでばどらはぜんぶ Swift でかかれるよ

それはすごいね。

C言語用のVMを作ればいいじゃん
GCCがVMの役割を持てばいい

そういうのを言葉遊びという

なんでVMの話が出てくるんだよ。

で、どこまでできたの？

あ

LLVMは大体分かった。GCや例外が大変。
テンプレートを型推論したくてHaskellの型推論読んでみたりしたけど難しい。
Yacc慣れするために、OCamlYaccでトランスレータ書いたりしてて、
今は文法を洗練させようとしてOCamlの別シンタックスを考えてる。
マクロはPHP的な物も検討中だな。
Swiftは悪くないけど、仕様を自分で弄れないからなぁ。

組み込みの構文と違和感なく構文を拡張できればいいね。

大事なのはエラーメッセージが適切な内容になる構造を持たせることと
実用的なデバッガサポートがあること

作るのを優先するとその辺が落とし穴になる

DylanとNemerleや、天才高校生プログラマの言語とか参考になると言えばなるんだけど
結構難しそうなので、Lisp的な式レベルでどうにか簡単な仕組みが作れれば良いなと思ってます。

エラーメッセージやデバッガは、言語機能がしっかり出来上がってからですね。
位置情報埋め込むと構文木が煩雑になるし、デバッガの為の位置情報の埋め込みも同じ。
その辺頑張ると、それだけで大変なので結局今の言語と同じ物しか作れなくなってしまう。
納得いかない文法で、エラーメッセージとか詰めても結局捨てる事になってしまうし。
エラーメッセージも出来れば、グローバライゼーションして、日本語と英語くらいは用意してあると良いけど。
それも含めて、構文拡張が出来て、うまくデバックできてっていうのは難しい。

エラーメッセージは特に、エラー発生箇所と、エラー内容が作っている箇所からは
特定出来ない事が多いので、エラーが発生するようなテストケース作って
エラー内容のテストをしていけば、良くなるんだろうけど、１つ１つ作り込む感じにしないと
出来なさそうなので大変だけど、ちゃんと作ると、それなりに成果があっていいんでしょうねぇ
Rubyが成功している理由ってそういう所もあったのかなぁ？

>>206
それを実現するのに有効な言語的な特性は？

具体的に提案があるとわかりやすい。

おうお前らがモタモタしてるうちにRustが1.0になったぞ
ランタイム&GC不要のメモリ管理、メタプログラミングのための各種機能をゼロ・オーバーヘッドで用意、パターンマッチもついて中々のイケメンに仕上がってるぞ

>>209メジャーな言語と似たものなら大体はいいぞ。関数型はエラーメッセージが分かりにくくて有名だからそれは避けてね

フルスクラッチでcを実装するブログ読んで思わず自分もって感じで始めた
まずは、物凄くシンプルなc言語っぽい仕様書をシコシコ書いてる
実装するまでは中二病に浸れて気持ちいいなこれｗｗ
あと、ここの
http://homepage1.nifty.com/herumi/prog/x64.html
c言語でのレジスタの扱いとか読むと
行儀の良さげなレジスタの扱い方とか参考になる
だけど、一番目の整数引数rcxの下り
一番目が実数だった場合はxm0と言う排他的にrcxもしくはxm0で受け渡すって言う意味なのは
サンプルコードを見るまで理解できなかったｗｗ
vs2013も入れたけどコンパイルしたあとのアセンブラのコード何処で見るのか不明ｗ

>>1
低級なのはお前の頭だろ。

.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と全く同じ文法にはならないだろう。
それを考えるのがこのスレの趣旨。

Luaはどうよ？

どこのスレの誤爆ですか？

>>224
Luaいいね
色々考えるとLuaの再定義っぽい感じかな
Luaってスクリプト言語に分類されるアセンブラみたい

低級言語だから高級っぽい文法でプログラムを書き下して
コンパイルして一旦アセンブラのソースの形で出力
必要ならここで編集
最後にアセンブラさんにお任せみたいな

アセンブラって基本ラベルとメモリー空間があって
そこにどんな形式のどんなデータが格納されているのかは自己責任って世界だから
ここら辺を援護してくれるマクロアセンブラっぽい物が良いのかな

あえて言おう
rustでおｋ

スレ立てから3年が経った今、時は動き出す
ってことではよ何か作ろうや

最近の名前だけ高級言語スクリプトを見てると仕様も技術者もアホの極地にしか見えん。
その技術者の得意言語でもやっちゃいけないって事を平気でやる

>>229
具体的に知りたいな

逆に超高級言語を作りたいな（´・ω・｀）

今一番超高級な言語って何がありますか？

haskell

依存型のAgda、Coq、Idris、ATSとか

ここは勉強になるスレだぬ
>>233聞いたこと無いので検索してみるｗ
>>232キチぴーご用達なｗｗ

日本語かな

マイナーな言語は習得が大変なことと、わからないことがあったとき情報やノウハウがないので
全部自分で何とかしないといけない。普及している言語の中から好きなのを選んで使いこなすのが一番いいよ。

マイナーだけどメジャーになりそうなら本書いて印税うはうは

高級言語を使いこなすってC++を使いこなすより大変じゃないのか？
で結局パワーではC++に敵わない

>>238
C++ほど大変な高級言語はなかなか無いと思うぞ

C++ほど変態な高級言語はなかなか無いと思うぞ

C++ほど変変な高級言語はなかなか無いと思うぞ

c++のunsigned long 型の変数を >=0で評価するとーの値が存在しないので必ずTureになって
forループが無限ループになるバグの説明が面白かった
アセンブラならループのインデックスを引いたあとキャリーフラグ調べて分岐じゃないか
ループ離脱の条件が単純比較じゃなくて条件式を容認してるからだろうけど

Cの骨にテンプレートの肉を詰め、OOの毛皮を被った化物だよ
骨だけ使った料理もできるし肉を焼いてもいいし、毛皮からコートを作ったっていいが、
他人が作ったものはまだ蠢いているかもしれないから怖い。

>>242
そもそもループカウンタにunsignedを使うこと自体、バグと言うべき話なのでわないかと・・・

必ずTureになるのが1番の問題

×Ture
○True

while(true)で評価するとーの値が変化しないので必ずTureになって
whileループが無限ループになるバグの説明が面白かった
ループ離脱の条件が条件式だけじゃなくてbreakやreturnを容認してるからだろうけど

高級な変態というと・・・女体盛りで大トロとかヒラメの縁側を使う感じか。

>>244
増えていくカウンタなら問題はない
減っていくカウンタでも 0 でループアウトするように組むのなら問題ない、a >= 0 とするから問題になる

>>249
それはそうなんだが、勘違いしやすかったり、注意しないとバグの温床になりやすいことはしないのが基本だと思うんだが。
ループカウンタとして使うなら普通に int 使えよと。

C++/CLIはC++の顔してて勝手にスレッド作りやがる

FORTHという>>1の要件をほぼかなえる言語がある
これをベースにすればよい

while( c )
{
　...
　c -= 2;
}

好き / “アセンブリ言語のみで言語処理系を作った話 // Speaker Deck”
https://speakerdeck.com/nineties/bootstrap

これ見て元気だせ
自分でも出来そうな気がするだろ
実際、大学あたりではcコンパイラの実装までやらせてるんじゃないの？

>>254
簡単そうに書いてるけど、これ相当わかってる人でレベルが高い。
俺には1段階理解するだけで大変。自分で実装できる気がしない。

>>254
たぶんこの人だね
https://www.s.u-tokyo.ac.jp/ja/rigakuru/3384/

　あー、ドアドアの人？　と思ったら違ったヽ(´ー`)ﾉ

　むかーし(20年ちょっと)、アセンブラに構造化マクロを追加して『生産性が超上がる！』って
謳ったPDS(今で言うフリーソフト)があったけれど、当時意味分からなかったなあ。
　と言うかGCCの吐くアセンブラコードを読んで、自分で書くより綺麗でスッパリ諦めた(^^;

少し前、x265のエンコードダーをアセンブラで記述してる人達の話題で
プログラムを組む上で何が問題なのかって話題があって
OSのシステムコールを行うとレジスターが壊れるのが気に入らないって事だった
オレは重要なアルゴリズムに係わる高度なコーディング作業をしているのだから
システムコール如きへの配慮で煩わしい事をさせるなってことかな
システムコール用のレジスタ退避マクロなり
システムコールをラップしてレジスタを退避復旧したり
もう少し便利なアセンブラの処理系を作ってみたりしないのかな〜
既存コードとの互換性問題とかあるのかな
アセンブラ関係のTool類はかなり保守的で目新しい道具類がガンガン使われる様子は少な目？？

>>254の記事を読むと、コンパイラ系統ってリストへの変換ー＞実行コード(アセンブラ)への還元って事が凄くよく判るんだよね
物凄く大雑把に言うと、LISP処理系への構文糖衣≒コンパイルする対象(プログラム塊) な構図

Objective-ASM

>>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とかｗｗｗ
C++の複雑さって仕様が大きくなって新たなキーワードを導入して何でもかんでも
詳細にテキストで記述しようとした結果じゃないかな
本来ライブラリなりフレームワークなりにお任せすべき部分までやらかしていると

Cの複雑さってint,char,とか扱う型の種類とサイズが多い事も理由っぽいので
ここはきっぱりアルゴリズムを記述する為に扱える数値の種類を1,2種類に限定して
そのほかはデーターベースの記録管理みたいに色々なコストをかけて
型変換なりレンジチェックなり圧縮なり手間隙かければ良いのでは？
いっそ64bitサイズの何かで統一してしまう
charもintも実数も全部64bitの何かｗ

>>261
単に型なしのオブジェクト言語使えばいいのでわないかと

型無しのオブジェクト言語って言えばluajitがかなり高速なんだよな、確か。
あれの仕様を上手く転用できないかな。

多分スクリプトとアセンブラの悪いとこ取りじゃね

Rustいつのまにかstableリリース出てたのか・・・
Swiftみたいな負の遺産に塗れたクソ言語に比べりゃ大分>>1の理想に近いと思うんだけど
モジラってOSSの見切り早いし将来性が不安だわ

void*最強って話か？ｗ

コンパイラが勝手にトレードオフして機能の一部をFPGAに突っ込んでくれよ

高速とは無縁だけど多倍長整数ってあるよね
これをビット単位でやるの、管理も緩く1ビットで1バイト使って管理
速度で無いけど全部の計算表現できるよね
文字列とかは考慮してないけど
色々考えた結果、変数の精度、byte,word,duble word,q...
ここら辺がいかにCPUの効率都合に合わせた制限だってよく判る
制限して精度に条件が付いても効率と速度が欲しいって言う

たった1ビットの多倍長数が扱えるだけで何でも表現できるなと思った。ｗｗ

せめてBCDにしれｗｗｗ

何で10進数にしたがるかね

RustがC++に並ぶぐらい速くなってるみたいだけどRustのサブセットみたいなの作ったら良いのかね

修理するより買い換えた方が安いって話は多いが
もはや解読不可能になったコードのメンテナンスに金は出すくせに
新しく作り直すのはNGってのは恐ろしいな
大手では比較的作り直しもするようだが

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

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

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

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

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

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

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

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

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

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

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

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

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

BTGPU

DKB

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++の意義って気もする。

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

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

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

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コードとそんな変わらないという悲しさはあるが

Nim++

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

masm64でinvokeしまくれば

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

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

Nim++

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

Nim#

Rust++

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

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

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

>>319
良いのが入荷

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

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

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

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

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

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

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

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

>>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]);

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

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

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

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]);
の方を期待するのは可笑しいのかなー
正直びっくりエンディアンですわ

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

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で作っておく必要があるのでしょうか？
それとも一つの表現で全部定義してくれる仕組みは？

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

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

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

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

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

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

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

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

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

Trait爆発ですね判ります

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

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

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

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

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

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

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

はあ…

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

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

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

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

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

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

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

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

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

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

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

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

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

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