標準化委員会が注目するエキゾチックなアーキテクチャ

CおよびC ++標準では、言語の実装の多くの側面が定義されたままであることを知っています。それは、他の特性を持つアーキテクチャがある場合、その標準に準拠するコンパイラを作成することが非常に困難または不可能だからです。

40年前は、どのコンピュータにも独自の仕様があったことを知っています。ただし、今日使用されているアーキテクチャについては知りません。

• CHAR_BIT != 8
• signed は2の補数ではありません（Javaでこれに問題があったと聞きました）。
• 浮動小数点はIEEE 754に準拠していません（編集：「IEEE 754バイナリエンコーディングではない」という意味です）。

私が尋ねている理由は、C ++が固定サイズの型などの他の低レベルの側面を義務付けないのは良いことだと人々によく説明するためです^†。「他の言語」とは異なり、正しく使用するとコードが移植可能になるので良いです（編集：符号+大きさのアーキテクチャでの2の補数演算など、マシンの低レベルの側面のエミュレーションを必要とせずに、より多くのアーキテクチャに移植できるため） 。しかし、私は自分が特定のアーキテクチャを指すことができないのは残念です。

だから問題は：どのアーキテクチャが上記の特性を示すのか？

† uint*_tはオプションです。

これを見てください

Unisys ClearPath Doradoサーバー

まだすべてのUnivacソフトウェアを移行していないユーザーに下位互換性を提供します。

キーポイント：

• 36ビットワード
• CHAR_BIT == 9
• 補数
• 72ビットの非IEEE浮動小数点
• コードとデータ用の個別のアドレス空間
• ワードアドレス
• 専用スタックポインタなし

ただし、C ++コンパイラを提供しているかどうかはわかりませんが、可能です。

そして今、彼らのCマニュアルの最新版へのリンクが浮上しました：

Unisys Cコンパイラプログラミングリファレンスマニュアル

セクション4.5には、9、18、36、および72ビットのデータ型の表があります。

メインフレームに当てはまる想定はありません。手始めに、IEEE 754を使用するメインフレームについては知りません。IBMはベース16浮動小数点を使用し、両方のUnisysメインフレームはベース8を使用します。Unisysマシンは他の多くの点で少し特殊です。Boは2200について言及していますアーキテクチャですが、MPSアーキテクチャはさらに奇妙です。48ビットのタグ付きワードです。（単語がポインターであるかどうかは、単語内のビットに依存します。）そして、数値表現は、浮動小数点と整数演算の間に実際の違いがないように設計されています。浮動小数点は8を基数とします。それは正規化を必要としません、そして私が見た他のすべての浮動小数点とは異なり、それは小数を左ではなく仮数の右に置き、指数に符号付きの大きさを使用します（仮数に加えて）。整数の浮動小数点値が符号付きの大きさの整数とまったく同じビット表現を持っている（または持つことができる）という結果。また、浮動小数点演算命令はありません。2つの値の指数が両方とも0の場合、命令は整数演算を行い、それ以外の場合、浮動小数点演算を行います。（アーキテクチャにおけるタグ付けの哲学の継続。）つまり、int 48ビットを占有する場合があり、そのうちの8ビットは0でなければなりません。そうでない場合、値は整数として扱われません。

IEEE 754に完全に準拠することは、浮動小数点実装ではまれです。その点で仕様を弱めると、多くの最適化が可能になります。

たとえば、サブノルムサポートはx87とSSEで異なります。

乗算と加算の融合のような最適化は、ソースコードで個別でしたが、結果もわずかに変更しますが、一部のアーキテクチャでは優れた最適化です。

または、x86では、IEEEに厳密に準拠するために、特定のフラグを設定するか、浮動小数点レジスタと通常のメモリの間で追加の転送を行って、内部の80ビット浮動小数点数ではなく、指定された浮動小数点タイプを強制的に使用する必要があります。

また、一部のプラットフォームではハードウェアフロートがまったくないため、ソフトウェアでそれらをエミュレートする必要があります。また、IEEE 754の要件の一部は、ソフトウェアでの実装にコストがかかる場合があります。特に、丸め規則が問題になる場合があります。

私の結論は、IEEEへの厳密な準拠を常に保証する必要がないという状況に陥るために、エキゾチックなアーキテクチャを必要としないということです。このため、厳密なIEEE準拠を保証するプログラミング言語はほとんどありませんでした。

私が見つかりました。このリンクは、いくつかのシステムをリスト場所CHAR_BIT != 8。彼らは含まれています

一部のTI DSPは CHAR_BIT == 16

BlueCore-5チップ（ケンブリッジシリコンラジオのBluetoothチップ） CHAR_BIT == 16。

そしてもちろん、スタックオーバーフローに関する質問があります。 ますどのプラットフォームに8ビット文字以外の何かがあります

2の補数以外のシステムについては、 comp.lang.c ++。moderatedに関する興味深い記事があります。要約：1の補数または符号と大きさの表現を持つプラットフォームがあります。

VAXシステムがまだ使用されていると私はかなり確信しています。IEEE浮動小数点をサポートしていません。彼らは独自のフォーマットを使用しています。AlphaはVAXとIEEEの両方の浮動小数点形式をサポートしています。

新しいCrayシステムはIEEEを使用していますが、T90のようなCrayベクトルマシンにも独自の浮動小数点形式があります。（私が使用したT90は数年前に廃止されました。まだアクティブに使用されているものがあるかどうかはわかりません。）

T90には、ポインターと整数の興味深い表現もいくつかありました。ネイティブアドレスは64ビットワードのみを指すことができます。CおよびC ++コンパイラーはCHAR_BIT == 8（UnixのフレーバーであるUnicosを実行し、他のシステムと相互運用する必要があったために必要）を備えていましたが、ネイティブアドレスは64ビットワードしかポイントできませんでした。すべてのバイトレベルの操作はコンパイラによって合成され、void*またはchar*ワードの上位3ビットにバイトオフセットを記憶されています。そして、私はいくつかの整数型にパディングビットがあったと思います。

IBMメインフレームは別の例です。

一方、これらの特定のシステムは必ずしも言語標準の変更を排除する必要はありません。Crayは、CコンパイラをC99にアップグレードすることに特に関心を示していませんでした。おそらくC ++コンパイラにも同じことが当てはまります。可能性があり、このような符号付き整数のビットをパディングすることなくCHAR_BIT == 8、IEEE形式の浮動小数点でない場合、完全なセマンティクス、及び2の補数を必要としてホスト実装のための要件を厳しくすることは合理的です。古いシステムは以前の言語標準をサポートし続けることができ（C99が出たときにC90は死にませんでした）、DSPなどの自立型実装（組み込みシステム）の要件は緩和される可能性があります。

一方で、将来のシステムが今日ではエキゾチックと見なされることを行うには、十分な理由があるかもしれません。

CHAR_BITS

gccソースコードによると：

CHAR_BITである16ためのビット1750A、dsp16xxのアーキテクチャ。
CHAR_BITである24ためのビットDSP56kののアーキテクチャ。
CHAR_BITである32ためのビットc4xアーキテクチャ。

次のようにして、簡単に詳細を見つけることができます。

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魔女もゼロの符号保存を無効にするなど）を使用できます。

IEEE 754バイナリ表現は、最近までGPUでは一般的ではありませんでした。GPU 浮動小数点パラノイアを参照してください。

編集：GPU浮動小数点がグラフィックスとは関係なく、通常のコンピュータープログラミングに関連しているかどうかの質問がコメントで発生しました。もちろん！今日、工業的に計算されている最も高性能なものはGPUで実行されます。リストには、AI、データマイニング、ニューラルネットワーク、物理シミュレーション、天気予報などが含まれます。コメントのリンクの1つは、理由を示しています。GPUの桁違いの浮動小数点の利点。

私が付け加えたいもう1つのことは、OPの質問により関連しています。GPU浮動小数点がIEEEでなく、GPUをプログラムするための今日のOpenCLやCUDAなどのAPIがないときに、10〜15年前に人々は何をしましたか？信じられないかもしれませんが、初期のGPUコンピューティングのパイオニアは、APIなしでGPUをプログラミングすることができました。私は会社でそれらの1人に会いました。彼がやったことは次のとおりです。彼は、計算に必要なデータを、作業中の値を表すピクセルを含む画像としてエンコードし、OpenGLを使用して必要な操作を実行しました（「ガウスぼかし」など）。など）、結果の画像をデコードして結果の配列に戻します。そして、これはまだCPUを使用するよりも高速でした！

そのようなことが、NVidiaに最終的に内部データバイナリをIEEEと互換性を持たせ、画像操作ではなく計算指向のAPIを導入するきっかけとなりました。