[過去ﾛｸﾞ] Qiita 6 - キータぞ、来たぞ、キータだぞー (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
906: 08/30(土)14:42 ID:vxiJTEr3(1/2) AAS
> 比較したいいところ
> 1. 命令フォーマットが規則的で読みやすい
> x86版では
>
> cmp al, [si+1]
> jl common
> xchg al, [si+1]
> mov [si], al
> のように「レジスタ＋メモリ」「メモリ＋メモリ」が混ざっていて、例外的なルール (xchg は直接使えないから mov に分ける) があります。
と解説してて、記事中のコードの該当部分は
> cmp eax, ebx
> jle no_swap
> mov [array + esi*4], ebx
> mov [array + esi*4 + 4], eax
となってるのが味わい深い。
投稿者がコードと記事の両方を理解して書いてたらこうはならないと思うのでAIにやらせてんだろうなあ。
907: 08/30(土)14:47 ID:vxiJTEr3(2/2) AAS
他にも
> print_int:
> push ebp
> mov ebp, esp
> push ebx
> push ecx
> push edx
> push esi
> push edi
>
> jmp .convert_digits
>
> .convert_digits:
フレームポインタ使ってないのにebpにespコピーしたりすぐ下のラベルに無意味なjmpしたり、正確な理解のもとで書かれたコードである気がしない。
908: 08/30(土)18:02 ID:cASASKMm(3/4) AAS
よく見てはいないが、全体的にx86のアセンブラっぽくないんだよなあ。
909(1): 08/30(土)18:12 ID:cASASKMm(4/4) AAS
他人のC言語のコードを引用しているが、関数の戻り値がvoidなのもプロっぽくない。
int型の配列に値を入れて関数に渡すという仕様も、わざわざ配列にいったん格納して、同じメモリ領域を上書きしてしまうというのも実務では考えられない。
910: 08/30(土)18:41 ID:UWTi2w+M(1) AAS
>>909
それについてはおまえがおかしい
その仕様が最も正しい
おまえの間違った仕様を書いてみろ
911: 08/30(土)19:45 ID:vMLCyXV5(1) AAS
＞関数の戻り値がvoidなのもプロっぽくない。
＞int型の配列に値を入れて関数に渡すという仕様も、わざわざ配列にいったん格納して、同じメモリ領域を上書きしてしまうというのも実務では考えられない。
標準関数のqsort知らない人かな
912: 08/31(日)02:12 ID:jsrmdu/r(1) AAS
アセンブラのおかしな記事が挙がるとよくわかってないわかったつもりの奴が叩きに参戦してくんの面白れぇなｗ
913(1): 08/31(日)10:55 ID:8dn8jVHL(1) AAS
知らないならレスしないでください
うざいだけです
914: 08/31(日)11:24 ID:7aNyV0yu(1) AAS
>>913
>>913
915: 08/31(日)12:41 ID:n+VCdOyt(1) AAS
cコンパイラにアセンブリコード吐かせてからいじったんやろ察してやれ
916: 08/31(日)14:05 ID:bv7ZXR4f(1/7) AAS
記事のコードをNASMでアセンブルして実行できるんだが
外部ﾘﾝｸ:godbolt.org
同じロジックをCで再現してgccでコンパイル、実行しても
外部ﾘﾝｸ:godbolt.org
結構違うコード吐くし
> cコンパイラにアセンブリコード吐かせてからいじったんやろ察してやれ
こんな訳はないんだよなあ。
この記事について「よくわかってないわかったつもりの奴」が次から次へと湧いてくんの何なの。
917(1): 08/31(日)14:10 ID:bv7ZXR4f(2/7) AAS
ちなみに記事のアセンブリコードの10進数出力であるprint_intルーチンは値0を出力する実装にバグがある。
外部ﾘﾝｸ:godbolt.org
918: 08/31(日)14:14 ID:bv7ZXR4f(3/7) AAS
自己レス:
> ちなみに記事のアセンブリコードの10進数出力であるprint_intルーチンは値0を出力する実装にバグがある。
修正案1
外部ﾘﾝｸ:godbolt.org
修正案2
外部ﾘﾝｸ:godbolt.org
919: 08/31(日)14:16 ID:XglzWhVJ(1) AAS
アセンブラのコード量が減っても、それが速く動かなければ意味がない。
920(1): 08/31(日)14:26 ID:bv7ZXR4f(4/7) AAS
アセンブラを使う理由は場合によりけりで
・アーキテクチャの学習を行いたい場合
・ブートローダーなど、使用できるコードサイズが限られる場合
・コンパイラが吐いてくれない命令を使用したい場合
・コンパイラで吐いてくれるコード以上に最適化したい場合
> それが速く動かなければ意味がない。
てのはひとつの視点でしかない。
921: 08/31(日)14:32 ID:bv7ZXR4f(5/7) AAS
修正案3
外部ﾘﾝｸ:godbolt.org
記事のコードは無駄が多すぎる。AI出力によるツギハギ臭が酷い。
922: 08/31(日)14:40 ID:TCgrNpEA(1/2) AAS
>>920
その記事を書いた人間はアセンブラのコード量が少なくなるという記事を書きたかったかったんだぞ？
923: 08/31(日)14:42 ID:TCgrNpEA(2/2) AAS
いまどきメモリが少なすぎてマシン語がまともに入らない機器なんてごくわずか
924(1): 08/31(日)14:50 ID:bv7ZXR4f(6/7) AAS
> その記事を書いた人間はアセンブラのコード量が少なくなるという記事を書きたかったかったんだぞ？
あなた:
この記事（外部ﾘﾝｸ:qiita.com）の内容に「アセンブラのコード量が少なくなる」という要素はありますか?
ChatGPT:
ご提供いただいたQiita記事「バブルソートでわかるRISC‑Vのきれいさ」（2025年8月28日投稿）について確認しました。
結論から言うと、この記事内に「アセンブラのコード量が少なくなる」という記述はありません。以下、内容のポイントを整理します：
記事内容の要約
C言語版・x86アセンブリ版・RISC‑Vアセンブリ版 のバブルソート実装を比較しています。
Qiita
比較されている観点は以下の通りです：
命令フォーマットの規則性・読みやすさ
→ x86はレジスタ＋メモリ、メモリ＋メモリなど混在し、例外的なルールも多いのに対し、RISC‑Vでは一貫性ある命令構成（ロード→比較→ストア）で構成されており、可読性に優れている。
Qiita
メモリ演算の明確な分離
→ x86では複雑な複合命令（例：cmp al, [si+1]）がある一方、RISC‑Vでは命令が分割されている（ロード → 比較 → 分岐）ため、理解しやすい。
Qiita
拡張性と移植性
→ x86は歴史的に多くの拡張を抱えているのに対し、RISC‑Vはシンプルで必要な機能を拡張指令として付与できる設計になっており、将来的な拡張にも対応しやすい。
Qiita
「コード量が少なくなる」という記述はあるか？
いいえ。 記事では「命令の規則性」や「構造の分かりやすさ」などが強調されている一方、「アセンブラのコード量が少なくなる」といった記述は一切ありません。
ご質問の「アセンブラのコード量が少なくなる」という要素は、この記事の中には含まれていないことをお伝えします。他に気になる点や別の記事についての確認も可能ですので、どうぞ気軽にお知らせください！
925: 08/31(日)16:42 ID:CVjGHqHc(1) AAS
>>924
「バブルソートでわかるRISC-Vのきれいさ」
きれいになると彼は言っている
実際に示しているコードはきれいになっているのではなく、コード量が減っているだけ
926(1): 08/31(日)17:20 ID:wng97XEx(1/6) AAS
＞「バブルソートでわかるRISC-Vのきれいさ」
＞実際に示しているコードはきれいになっているのではなく、コード量が減っているだけ
記事のバブルソートのコードはx86では14命令なのに対してRISC-Vでは16命令なのでRISC-Vでコード量が減ってるということは全くない。
927: 08/31(日)17:31 ID:wghiPy+O(1/4) AAS
>>926
CISCとRISCのCPUの違いがわからないのか？
1クロックでやることが多いCISCは命令が少なくなるのはあたりまえ。
彼の問題はRISCだときれいになるとの主張。
それにC言語のint型が64ビットという前提で説明しているのもおかしい。
928: 08/31(日)17:36 ID:wng97XEx(2/6) AAS
記事のRISC-Vのコード見るとコメントになんでかx86のレジスタ書いてんだよなあ。
x86からRISC-Vに移植したか、x86との対応わかるようAIに指示したかどっちかか。
こんなクソコードクソ記事からなんか有意なこと読み取ろうとしても無駄だぞ。
929(1): 08/31(日)17:39 ID:wng97XEx(3/6) AAS
＞1クロックでやることが多いCISCは命令が少なくなるのはあたりまえ。
スーパースカラーも知らない人は黙ってた方良いよ。
930(1): 08/31(日)17:52 ID:wghiPy+O(2/4) AAS
>>929
CPUの性能の進化でそれをやる必要がなくなってRISCの方がよいということになってあの記事があるんだぜ？
931: 08/31(日)17:53 ID:wng97XEx(4/6) AAS
＞それにC言語のint型が64ビットという前提で説明しているのもおかしい。
どこ見てそう思ったか知らんけどx86のコードではe?xの32ビットレジスタ使ってるしRISC-Vはlw/swで読み書きしてるから32ビットだね。
何いってんのという感じ。
932: 08/31(日)17:55 ID:wghiPy+O(3/4) AAS
x86は16ビットか32ビットだよ？
x64と書いてあれば64ビット
933: 08/31(日)17:56 ID:wghiPy+O(4/4) AAS
キータのレベルは理解不能
934: 08/31(日)18:02 ID:wng97XEx(5/6) AAS
>>930
「バブルソートでわかるRISC-Vのきれいさ」と題して十分に最適化されてないコードで「きれい」なんて主観を語ってる記事はナンセンス。
「シンプル」や「簡潔」と言ってるならまだ擁護の余地はあった。
935: 08/31(日)18:54 ID:5OVq2s7z(1) AAS
彼はアセンブリでマクロ機能も使ってないしな
上下前次1-新書関写板覧索設栞歴
あと 67 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s