Universal Representation of Real numbers

コンパイラを書くのであれば、本当は浮動小数点実数はソフトウェア演算しなければなりません…たぶん。
x86は80ビット浮動小数点実数が使え、BorlandやDigitalMarsのコンパイラはそれをサポートしていますが、Microsoftなんかはlong doubleでも64ビットに割り当てられてるため、80ビット浮動小数点実数を扱える処理系を作る処理系では直接サポートが絶対ではない場合インラインアセンブラ(に準じる外部ルーチン)かソフトウェア演算が必要です。クロスコンパイラとか夢見るならソフトウェア演算が必要です。
コンパイラを書くのに向いていると言われるOCamlでさえ浮動小数点実数は64ビットまでなんですよね…。
で、IEEE-754のソフトウェア演算を書こうとして、なぜかURR変換ルーチンができました。
http://panathenaia.halfmoon.jp/alang/ase.7zの中のase-numerics-urr.ads/adb
URRについては他でも見かけたような気はするもののとりあえずhttp://homepage2.nifty.com/m_kamada/docsproc/asmurr.htm参照。なお掲載されている表は一部間違ってるような気が…。
D言語のWalter様の主張ではx86では理由が無い限り原則全部FPUの最大精度の80ビット浮動小数点実数で計算するのが妥当です。あえて最大精度を避ける理由としましては、DirectXのAPIが32ビットだのOpenGLのAPIが64ビットだのでそれ以上のデータサイズで持っておく意味が無い場合と、容量の問題があります。特に80ビットは、80ビットという中途半端なサイズが、アライメントしますと、2バイトずつ無駄になっていくのが耐えられないという方もいるかもしれません。
そこで保存はもっと小さいサイズで行うことが考えられますが…とか言って無理やり使いどころを捻り出してます。URRは小さい数は目を細かく、大きい数は目を粗く、という形式ですので、上記URLによりますと、同じサイズの浮動小数点実数とURRエンコードされた実数を比較した場合、極端に大きな数以外はURRのほうが精度が良いという話です。他にも様々な利点が書かれていますが、IEEE-754では沢山ある特殊な値がURRではマイナス無限大ぐらいしか無いのと、デコードせずに計算を行う方法がさっぱりさっぱりなのが大きな特徴でしょう。IEEE-754が数値解析の分野で破綻していても、代わりにURRで計算ってどうやるの状態…。私の理系失格ぶりは棚が無いのでとりあえず捨て置くとして、浮動小数点とは異なり極端に少ないビット数でも表現可能ですので、4ビットURR実数とか3ビットURR実数とか表にしてみると面白いです。
それでなんか力尽きたのでIEEE-754は諦め…そもそもクロスコンパイラとか実力不相応な気がしてきましたし…ってホント私テンションだけでコード書いてんな。なお実数を大量に保存しなければならないようなニーズは今のところ無いです…。