11

CIL コンパイラで type が許可されていることがわかりましたnative float。ただし、CLR では許可されません。用途はありますか？そのサイズは？対応する .NET タイプはありますか? 疑似プリミティブ型として実装しようとしました:

.class public sequential ansi serializable sealed beforefieldinit NativeFloat
  extends System.ValueType
{
  .field assembly native float m_value
}

ただし、この型は CLR ではサポートされていません。ご協力ありがとうございました。

編集：あなたが興味を持っているなら、そのCorElementTypeは26（0x1a、R）です。

4

2 に答える 2

5

CIL ECMA 仕様、I.12.1.1 ネイティブ サイズ: ネイティブ int、ネイティブ unsigned int、O および & から:

ネイティブ サイズ型 (ネイティブ int、ネイティブ unsigned int、O、お​​よび &) は、値のサイズの選択を延期するための CLI のメカニズムです。これらのデータ型は CIL 型として存在します。ただし、CLI はそれぞれを特定のプロセッサのネイティブ サイズにマップします。(たとえば、データ型は Pentium プロセッサでは int32 にマップされますが、IA64 プロセッサでは int64 にマップされます。) したがって、サイズの選択は、CLI が初期化され、アーキテクチャが判明している JIT コンパイルまたは実行時まで延期されます。 . これは、コンパイル時にフィールドとスタック フレームのオフセットも不明であることを意味します。

とは言っても、ECMA仕様ではnative float（とは対照的に）は一度も言及されていません。native int私が見つけた唯一の証拠は、一部のオープン ソース CIL アセンブラーで、native float.

Microsoft の CIL コンパイラが実際にこの型を受け入れる場合、これは Microsoft が実装することを意図していた機能でしたが、最終的に MSIL (CIL の前身) には組み込まれなかったと思います。さらに、アセンブラが実際にエラー メッセージの代わりにオペコードを生成する場合、Microsoft の CLR (おそらく .NET Micro Framework または特定のバージョンの Silverlight、または何か）オペコードをサポートします。

上記の仕様では、CLI について言及されていることにも注意してください。CLR は、Microsoft による CLI の単なる実装です。

ECMA 仕様では、ネイティブの浮動小数点型について言及されていますが、そうではありませんnative float。

F、浮動小数点値 (float32、float64、または基盤となるハードウェアでサポートされているその他の表現)

于 2012-12-19T21:37:08.427 に答える
5

CLI 仕様の Ecma 335 では、3 つの浮動小数点型が定義されています。Float32、float64、および F。最初の 2 つは公称型で、3 番目は表現型であり、IL の「ネイティブ float」型です。

セクションI.12.1.3「浮動小数点データ型の処理」では、次の理由が説明されています。

浮動小数点数 (静的、配列要素、およびクラスのフィールド) の格納場所は固定サイズです。サポートされているストレージ サイズは、float32 と float64 です。それ以外の場所 (評価スタック、引数、戻り値の型、およびローカル変数) の浮動小数点数は、内部浮動小数点型を使用して表現されます。そのような各インスタンスでは、変数または式の公称型は float32 または float64 のいずれかですが、その値は追加の範囲や精度で内部的に表すことができます。内部浮動小数点表現のサイズは実装に依存し、変化する可能性があり、表現される変数または式と少なくとも同じ精度を持つ必要があります。

これは現在のジッター実装には実際には存在せず、引数とローカル変数は実際には float32 または float64 のいずれかです。しかし、それにはいくつかの前例があり、彼らが最初にこれを考慮した考えられる理由は、Intel プロセッサの内部 FPU レジスタが 80 ビットであることです。これは、Intel が 8087 コプロセッサを設計した何ヶ月も前に下された設計上の決定でした。

紙の上では非常に良いアイデアに思えますが、中間計算結果をより正確に保存できるようにすることで、計算の最終結果をより正確にすることができました。しかし、間違いなく Intel の 10 億ドルの間違いでした。FPU を最適化することは不可能であり、それでも一貫した浮動小数点の結果を可能にします。問題は、内部 FPU レジスタが限られたリソースであり、8 つしかないことです。また、スタックとして実装されているため、扱いが非常に厄介です。計算が関係する場合、必然的に中間結果をメモリにスピルする必要があります。80 ビット値を 64 ビットに切り捨てます。計算で多くの有効桁数が失われる傾向がある場合、コードに小さな変更を加えると、計算結果に大きな違いが生じます。または、16 桁目が「

さて、大きな間違いであり、SO での膨大な数の質問の原因です。Intel が次世代の浮動小数点ハードウェアを実装したときに、このアイデアは破棄されました。XMM および YMM レジスタは 64 ビットです。スタックではなく、真のレジスター。x64 ジッターはそれらを使用します。プログラムを 64 ビット モードで実行すると、32 ビット モードで実行した場合とは異なる結果が生成されます。痛みがなくなるまでには、さらに10年かかります。

于 2012-12-19T21:45:08.880 に答える