vfmaddrnd231pdとは誰ですか？

2026年10月13日原文(purplesyringa.moe)

概要

vfmaddrnd231pd 命令は、FMA命令セットに属するはずの特異な命令。 SDM（Software Development Manual）2024年版 で記載されていたが、2026年版では削除。 ラウンド制御 を命令単位で可能にする設計だったが、実装・サポートは未確認。 アセンブラやコンパイラ もこの命令を認識せず、実行すると未定義命令例外が発生。 Intel内部で計画されたが、最終的に撤回された可能性が高い。

vfmaddrnd231pd命令の謎

vfmaddrnd231pd は、FMA命令セットの一部として SDM 2024年版 に記載
命令名の "rnd" は、ラウンド制御機能を意味
即値バイト で、ラウンドモード・DAZ・FTZ・例外抑制などを個別制御
従来のx86浮動小数点命令 はグローバルなラウンドモードを使用し、切替は低速
vfmaddrnd231pd は命令単位でラウンドモードを指定でき、 AVX-512不要 で高速な丸め制御を実現
- FMA命令の性質上、加算・減算・乗算のエミュレーションも可能
アルゴリズム実装 で丸め制御が求められる場面で有用なはず

実装・サポート状況

GNUアセンブラ はvfmaddrnd231pdを認識しない
Intel C/C++ Compiler や Clang にも、該当するintrinsics（_mm_fmaddround_pd等）が存在しない
SDMに記載の オペコード（VEX.DDS.128.66.0F3A.W1 B8 /r /ib） を手動で組み立てて実行しても、 #UD（未定義命令例外） が発生
DDS という接頭辞はSDM内でこの命令のみ登場し、後のSDMでは削除
他のバリエーション （pd/ps/sd/ssや132/213/231）も存在せず、異例の記述

SDMでの扱いと消失

2024年版SDM には詳細なテーブルや独自の擬似コード付きで掲載
2026年版SDM では完全に削除
単なる記載ミス とは思えない独自構成
Intelが 実装直前で撤回 した可能性が高いが、公式な説明はなし

まとめと疑問

vfmaddrnd231pd命令 は、 SDM2024年版限定の幻の命令
実際のCPUやツールチェーン でサポートされていない
設計段階での撤回 が濃厚
Intel内部事情 や撤回理由は不明
情報提供を希望 する呼びかけ

Hackerたちの意見

さっき書いたコメントに似てるな。人が何かに直接触れないと、何かが失われてる気がするんだよね。今日の話題はAIについてが多いけど、俺も何度かこの経験をしたことがある。これらの指示は一見すると理解しづらくて、理解するためには頭の中で翻訳するステップが必要なんだ。でも、特定のケースでの使い方には影響しないし、コンパイラはプログラムされた指示をそのまま使うから、指示やその名前に根本的な問題はないと思う。ただ、まるで鍵のように見えるだけなんだよね。もしもっと多くの人がアセンブリ言語でプログラミングしてたら、指示に対してもっと多くの人が関わって、より良い表現をデザインする能力があったかもしれない。そういうレベルでのデザインが、隣接するレベルでの思考を固めるのに役立つと思う。例えば、指示の表現について、指示がどう指定されるかを考える良い方法があれば、チップデザイナーやコンパイラ作成者の認知負荷を減らせるかもしれない。こういうことは新しい方法に移行するたびに繰り返されていて、現代でも役立つアーティファクトが残っているけど、それは昔の原則がもっと一般的に使われていた時代にデザインされたからなんだよね。音楽ボックスや正規表現がその例だよ。どちらも新しい使い方が見つかるし、いくつかのタスクには良い解決策だけど、もし今誰かがそのニッチを埋めるものをデザインしたら、そんなに持続的なものはできないと思う。音楽ボックスの方が正規表現の有限オートマトンより理解しやすいけど、どちらもデザインの驚異だよね。この特定のアイデアや方法が考慮されない問題は、AIの時代にはそれほど問題にならないかもしれない。AIが多くのことを考慮してつなげる能力があれば、今は人間が注目していない技術を現在の問題に適用するかもしれない。今のAIがその特定のタスクに対応できるかはわからないけど、面白い問題だと思う。現代の複雑な命令セットを持つ機械のためのアセンブラをデザインして、アセンブリでのプログラミングがもっと理解しやすいタスクになるようにするのは興味深いことだよね。そういうオープンなタスクがモデルにどんな影響を与えるのか見てみたいな。

└

そんなに深いことじゃないと思うよ。IntelのベクターISAは、いつも奇妙な意味や理解しにくい名前の命令でいっぱいだし。彼らは多分、ラウンド処理の深いコーナーケースでミスをして、新しい命令を間違った意味でリリースするか、「チキンビット」を引っ込めてこの世代のCPUではその命令を使えなくするかの選択をしたんだろうね。次回はもっと運が良いといいけど。

└

あなたはasmの構文が人間の可読性を重視していると思ってるけど、実際にはアセンブラやディスアセンブラの複雑さを軽減するためでもあるんだよね。もしFMA命令の構文が可読性のためにデザインされてたら、4引数構文を使って2つのレジスタが一致する必要があったはずなのに、1/2/3のエンコーディングを使ってるのはその理由じゃない。むしろ、命令エンコーディングや他のほとんどのベクター命令のフォーマットと一貫性があるからなんだ。レジスタ/メモリアーギュメントは最後に来るんだよね。同様に、x86のベクター命令で即値バイトを使うと、シャッフルマスクや操作オプションなどのオプションがそのバイトに詰め込まれるけど、アセンブリ構文はそのバイトを構築するのには全く役立たない。これは、命令エンコーディングに直接マッピングされることを目的としていて、手動で読み書きしやすくするためじゃないからなんだ。ARMアセンブリはもう少し一貫性があるけど、似たような quirks もあるよ。ARM命令の大部分はdst,srcだけど、ストア命令はsrc,dstと逆になっていて、メモリアーギュメントが2番目に来るのはロード命令と同じだね。

└

これに関しては意図についての質問があるんだ。もしasmプログラミングが本当に人間にとって失われた技術になったら、誰がLLMSにこのアイデアをつなげる意図や使命を伝えるんだろう。1ヶ月前に読んだ面白い記事を思い出すよ。LLMが「アンチミーム生成器」になれるっていう内容だった。 https://www.jernesto.com/articles/anti_meme_explosion

└

私のsymbolasmプロジェクトは、まさにその通りで、プログラミングをもっと頭で理解しやすくするためのアセンブラ構文なんだ。人間のコーダーにもLLMコーダーにも役立つと思ってるよ。リポジトリがスカスカでごめんね、まだちゃんとしたREADMEを書いてないんだ。この構文では（まだx86_64をターゲットにしてないけど）、例えば「a = round(fma(a, b, c))」みたいに見えるよ。変数は適切なベクトル型で、最初に割り当てられたときに@zmm1構文でレジスタに配置される感じ。言語のデザインは完全に手作業で、実装も始めたときはそうだったけど、最近はAIを使って実装を早めてるよ。[1] https://github.com/raphlinus/symbolasm

└

あなたの不満はバイナリエンコーディングについてなの、それともアセンブラ構文についてなの？すべてのベクトル命令に良いバイナリエンコーディングを与えて、後方互換性を保つなんて無理だよ。新しい命令セットでやり直すこともできるけど、成功したらAMDのようにゴチャゴチャになっちゃうよ。

└

x64は設計されたものとは真逆だよ。全体のデザインは進化と妥協の産物なんだ。まるで40年間毎年塗り直されたアパートみたい。重ね塗りがどんどん増えて、時々剥がしてみると蓄積された厚みが見えるんだ。

RISC-V拡張の名前みたいだね。編集: 記事を確認したら、なんと… x86だ。

└

RISC-Vはどこかからおかしな名前を持ってきたんだね。

https://www.felixcloutier.com/x86/vfmaddrnd231pd を見てみて。理論: ハードウェアの問題で削除されて、決して機能しなかった。

古いバージョンのbinutils [1] がDDSの意味を説明してるよ: VEX.vvvvをエンコードする方法: 0: VEX.vvvvは1111bでなければならない。1: VEX.NDS。レジスタのみのソースはVEX.vvvvにエンコードされ、ソースレジスタの内容が保持される。VEX.DDS。2番目のレジスタオペランドはVEX.vvvvにエンコードされ、最初のソースレジスタの内容が結果で上書きされる。VEX.NDD2。2つのデスティネーションレジスタオペランドを持つ命令のために、2番目のデスティネーションレジスタオペランドがVEX.vvvvにエンコードされる。アセンブラにとっては、VEX.NDS、VEX.DDS、VEX.NDD2の間に違いはない。2. VEX.NDD。レジスタデスティネーションは、1つのデスティネーションレジスタオペランドを持つ命令のためにVEX.vvvvにエンコードされる。3. VEX.LWP。レジスタデスティネーションはVEX.vvvvにエンコードされ、オペランドの1つがメモリ位置にアクセスできる。[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;...

その命令は、IntelがクライアントCPUでAVX-512に再コミットしたときに削除されたよ（確かEVEX形式で利用可能だったはず）。

Hacker Newsで議論の続きを見る

ハクソク