標準化委員会が気にするエキゾチックなアーキテクチャ
CおよびC++標準では、他の特性を備えたアーキテクチャが存在する場合、標準に準拠するコンパイラを作成するのが非常に困難または不可能であるため、言語の実装の多くの側面が定義されていることを知っています。
40年前、どのコンピューターにも独自の仕様があったことを知っています。ただし、今日使用されているアーキテクチャについては知りません。
CHAR_BIT != 8signedは2の補数ではありません（Javaに問題があると聞きました）。- 浮動小数点はIEEE 754に準拠していません（編集：「IEEE 754バイナリエンコーディングではない」という意味です）。
私が尋ねる理由は、C++が固定サイズ型のような他の低レベルの側面を義務付けていないことは良いことだと人々にしばしば説明するからです†。 「他の言語」とは異なり、正しく使用するとコードを移植できるので良いです（編集：符号+大きさのアーキテクチャの2の補数演算など、マシンの低レベルの側面のエミュレーションを必要とせずに、より多くのアーキテクチャに移植できるため） 。しかし、自分で特定のアーキテクチャを指すことができないのは気の毒です。
質問は次のとおりです。どのアーキテクチャが上記の特性を示していますか？
†uint*_tsはオプションです。
これを見てください
すべてのUnivacソフトウェアをまだ移行していない人に下位互換性を提供します。
キーポイント：
- 36ビットワード
CHAR_BIT == 9- 補数
- 72ビットの非IEEE浮動小数点
- コードとデータ用の個別のアドレス空間
- ワードアドレス
- 専用スタックポインターなし
ただし、C++コンパイラを提供しているかどうかはわかりませんが、couldです。
そして今、彼らのCマニュアルの最近の版へのリンクが浮上しました：
nisys Cコンパイラプログラミングリファレンスマニュアル
セクション4.5には、9、18、36、および72ビットのデータ型の表があります。
メインフレームに当てはまる仮定はありません。まず第一に、IEEE 754を使用するメインフレームについては知りません。IBMはベース16の浮動小数点を使用し、Unisysメインフレームは両方ともベース8を使用します。アーキテクチャですが、MPSアーキテクチャはさらに奇妙です。48ビットのタグ付きワードです。 （Wordがポインターであるかどうかは、Wordのビットに依存します。）また、数値表現は、浮動小数点と整数演算の間に実際の区別がないように設計されています。それは正規化を必要とせず、私が見た他のすべての浮動小数点とは異なり、左ではなく仮数の右側に小数を置き、指数に符号付きの大きさを使用します（仮数に加えて）。整数浮動小数点値が符号付き絶対値整数とまったく同じビット表現を持つ（または持つことができる）という結果になります。また、浮動小数点演算命令はありません。2つの値の指数が両方とも0の場合、命令は整数演算を行い、それ以外の場合は浮動小数点演算を行います。 （アーキテクチャのタグ付けの哲学の続き。）つまり、intは48ビットを占有しますが、そのうち8ビットは0でなければなりません。そうしないと、値は整数として扱われません。
浮動小数点実装では、IEEE 754に完全に準拠することはまれです。その点で仕様を弱めると、多くの最適化が可能になります。
たとえば、サブノルムはx87とSSEの間で異なるサポートを提供します。
乗算と加算の融合などのソースコードで分離された最適化も結果をわずかに変更しますが、一部のアーキテクチャではニース最適化です。
または、x86では、IEEEに厳密に準拠するには、特定のフラグを設定するか、浮動小数点レジスタと通常のメモリ間の追加の転送で、内部80ビット浮動小数点の代わりに指定された浮動小数点型を強制的に使用する必要があります。
また、一部のプラットフォームにはハードウェアフロートがまったくないため、ソフトウェアでエミュレートする必要があります。また、IEEE 754の要件の一部は、ソフトウェアに実装するのに費用がかかる場合があります。特に、丸め規則が問題になる場合があります。
私の結論は、厳密なIEEE準拠を常に保証したくない状況に陥るのに、エキゾチックなアーキテクチャは必要ないということです。このため、厳密なIEEE準拠を保証するプログラミング言語はほとんどありませんでした。
このリンクはいくつかのシステムをリストしています where CHAR_BIT != 8。彼らが含まれます
一部のTI DSPには
CHAR_BIT == 16BlueCore-5チップ（Cambridge Silicon Radio製のBluetoothチップ）には
CHAR_BIT == 16。
そしてもちろん、スタックオーバーフローに関する質問があります。 8ビット文字以外のものがあるプラットフォーム
非2の補数システムについては、 comp.lang.c ++。moderated で興味深い読み物があります。要約：1の補数または符号と大きさの表現を持つプラットフォームがあります。
VAXシステムはまだ使用されていると確信しています。 IEEE浮動小数点をサポートしていません。独自の形式を使用します。 Alphaは、VAXとIEEEの両方の浮動小数点形式をサポートしています。
T90などのCrayベクトルマシンにも独自の浮動小数点形式がありますが、新しいCrayシステムはIEEEを使用しています。 （私が使用したT90は数年前に廃止されました;まだアクティブに使用されているものがあるかどうかはわかりません。）
T90には、ポインターと整数の興味深い表現もありました。ネイティブアドレスは、64ビットWordのみを指すことができます。 CおよびC++コンパイラにはCHAR_BIT == 8（UnixのフレーバーであるUnicosを実行し、他のシステムと相互運用する必要があるため）が必要でしたが、ネイティブアドレスは64ビットWordのみを指すことができました。すべてのバイトレベルの操作はコンパイラによって合成され、void*またはchar*は、Wordの上位3ビットにバイトオフセットを格納しました。そして、いくつかの整数型にはパディングビットがあったと思います。
IBMメインフレームも別の例です。
一方、これらの特定のシステムは必然的にで言語標準の変更を排除する必要はありません。 Crayは、CコンパイラをC99にアップグレードすることに特に関心を示しませんでした。おそらく同じことがC++コンパイラにも当てはまります。 might CHAR_BIT == 8、完全なセマンティクスでない場合はIEEE形式の浮動小数点、符号付き整数のパディングビットのない2の補数など、ホストされる実装の要件を厳しくすることが合理的です。古いシステムは以前の言語標準をサポートし続けることができ（C99が登場したときにC90は死ぬことはありませんでした）、DSPなどの自立型実装（組み込みシステム）の要件はより緩やかになる可能性があります。
一方、futureシステムが今日エキゾチックと見なされることを行うのには、十分な理由があるかもしれません。
CHAR_BITS
gccソースコードによると：
CHAR_BITは、1750a、dsp16xxアーキテクチャの16ビットです。CHAR_BITは、dsp56kアーキテクチャの24ビットです。CHAR_BITは、c4xアーキテクチャの32ビットです。
以下を実行することで簡単に詳細を見つけることができます
find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"
または
find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"
CHAR_TYPE_SIZEが適切に定義されている場合。
IEEE 754準拠
ターゲットアーキテクチャが浮動小数点命令をサポートしていない場合、gccはデフォルトで標準に準拠していないソフトウェアフォールバックを生成する可能性があります。さらに、特別なオプション（-funsafe-math-optimizations witchなどもゼロの符号保存を無効にします）を使用できます。
IEEE 754バイナリ表現は、最近までGPUでは一般的ではありませんでした。 GPU Floating-Point Paranoia を参照してください。
編集：GPU浮動小数点がグラフィックスとは無関係の通常のコンピュータープログラミングに関連するかどうかについてのコメントで質問が提起されました。もちろん！今日工業的に計算された最も高性能なものはGPU上で行われます。リストには、AI、データマイニング、ニューラルネットワーク、物理シミュレーション、天気予報などが含まれます。コメント内のリンクの1つに理由が示されています。GPUのオーダー浮動小数点の利点。
私が追加したいもう1つのことは、OPの質問により関連しています。GPU浮動小数点がIEEEではなく、GPUをプログラムするための今日のOpenCLやCUDAなどのAPIがなかった10年から15年前に人々は何をしましたか？信じられないかもしれませんが、初期のGPUコンピューティングの先駆者は、APIを使用せずにGPUをプログラミングできました！私は会社で彼らの一人に会いました。彼がやったことは次のとおりです。彼は計算に必要なデータを、作業中の値を表すピクセルを持つ画像としてエンコードし、OpenGLを使用して必要な操作を実行しました（「ガウスぼかし」などの正規分布の畳み込みを表す）など）、結果の画像をデコードして結果の配列に戻します。そして、これはCPUを使用するよりも高速でした！
そのようなことが、NVidiaに最終的に内部データバイナリをIEEEと互換性を持たせ、画像操作ではなく計算指向のAPIを導入するきっかけになりました。