ちょっと遅いですが、これに抵抗することはできません。未来を予測するのは難しい。コンピューターの未来を予測することは、時期尚早の最適化よりも、コードにとってより危険な場合があります。
簡単な回答
9 ビット システムが 8 ビット バイトの移植性をどのように処理したかでこの記事を締めくくりますが、この経験から、9 ビット バイト システムが汎用コンピューターに再び登場することはないと信じています。
私の予想では、将来の移植性の問題は、CHAR_BIT を少なくとも 16 にする、最低 16 ビットまたは 32 ビット アクセスを持つハードウェアで発生することです。ここでの注意深い設計は、予期しない 9 ビット バイトに役立つ可能性があります。
/への質問。読者: 9 ビット バイトまたは 1 の補数演算を使用して、現在生産されている汎用 CPU を知っている人はいますか? 組み込みコントローラーが存在する可能性がある場所はわかりますが、他にはあまりありません。
長い回答
1990 年代のコンピューターのグローバル化と Unicode により、UTF-16 またはそれ以上の文字あたりのビット数 (C の CHAR_BIT) の拡張を推進することを期待するようになりました。少なくともコンピュータがバイナリを使用している限り、業界標準のままです。
BYTE_BIT: 1 バイトあたりのビット数 (一般的ですが、私が知っている標準ではありません)
BYTE_CHAR: 1 文字あたりのバイト数
C 標準は、複数バイトを消費するcharに対応していません。それはそれを可能にしますが、それに対処しません。
3.6 バイト: (最終草案C11 標準 ISO/IEC 9899:201x )
実行環境の基本文字セットの任意のメンバーを保持するのに十分な大きさのデータ ストレージのアドレス可能な単位。
注 1: オブジェクトの個々のバイトのアドレスを一意に表すことができます。
注 2: 1 バイトは連続したビットのシーケンスで構成され、その数は実装定義です。最下位ビットは下位ビットと呼ばれます。最上位ビットは上位ビットと呼ばれます。
C 標準が 1 より大きい BYTE_CHAR 値を処理する方法を定義するまで、そして私は「ワイド文字」について話していませんが、移植可能なコードの主要な要素はこれに対処する必要があり、より大きなバイトではありません。CHAR_BIT が 16 または 32 である既存の環境を検討する必要があります。ARM プロセッサはその一例です。開発者が選択する必要がある外部バイト ストリームを読み取るための 2 つの基本モードが表示されます。
- アンパック: 1 つの BYTE_BIT 文字をローカル文字に。符号の延長に注意してください。
- Packed: BYTE_CHAR バイトをローカル文字に読み取ります。
移植可能なプログラムには、バイトの問題に対処する API レイヤーが必要になる場合があります。その場でアイデアを作成するために、私は将来攻撃する権利を留保します。
#define BYTE_BIT 8 // バイトあたりのビット数
#define BYTE_CHAR (CHAR_BIT/BYTE_BIT) //文字あたりのバイト数
size_t byread(void *ptr,
size_t size, // BYTE_BIT バイト数
int パッキング、// 文字ごとに読み取るバイト数
// (符号拡張の場合は負)
FILE *ストリーム);
size_t bywrite(void *ptr,
size_t サイズ、
イントパッキング、
FILE *ストリーム);
sizenumber BYTE_BIT バイトを転送します。packingchar文字ごとに転送するバイト数。通常は 1 または BYTE_CHAR ですが、外部システムの BYTE_CHAR を示している可能性があり、現在のシステムよりも小さい場合も大きい場合もあります。- エンディアンの衝突を決して忘れないでください。
9 ビット システムへのよき皮肉:
9 ビット環境用のプログラムを書いた以前の経験から、どこかで実際に古いレガシー システムで実行するプログラムがたまたま必要でない限り、そのようなものは二度と見られないと思います。32/64 ビット システムの9 ビット VMで発生する可能性があります。2000 年以来、古い 9 ビット システムの現在の子孫への参照を時々手早く検索しますが、見たことはありません。
私の見解では非常に予想外ですが、将来の汎用 9 ビット コンピュータには、プログラムを実行するための 8 ビット モードまたは 8 ビット VM (@jstine) が搭載される可能性があります。唯一の例外は、汎用コードがとにかく実行される可能性が低い特別な目的で構築された組み込みプロセッサです。
昔は、9 ビット マシンの 1 つに PDP/15 がありました。この獣のクローンとの 10 年間の闘いから、9 ビット システムが再び登場することは決して期待できません。理由についての私のトップピックは次のとおりです。
- 余分なデータ ビットは、コア メモリ内のパリティ ビットを奪ったものです。古い 8 ビット コアには、隠しパリティ ビットが含まれていました。どのメーカーもそうでした。コアが十分に信頼できるようになると、一部のシステム設計者は既存のパリティをデータビットに切り替えて、MMU 以外の弱いマシンの時代にもう少し数値パワーとメモリアドレスを得るために簡単な策略を講じました。現在のメモリ技術にはそのようなパリティ ビットはなく、マシンはそれほど弱くなく、64 ビット メモリは非常に大きいです。これらすべてが、当時の変更よりも設計変更の費用対効果を低下させるはずです。
- 他のシステムだけでなく、既製のローカル I/O デバイスを含む 8 ビット アーキテクチャと 9 ビット アーキテクチャの間でデータを転送することは、継続的な苦痛でした。同じシステム上の異なるコントローラーが互換性のない手法を使用しました:
- 18 ビット ワードの下位 16 ビットを使用します。
- 9 ビット バイトの下位 8 ビットを使用します。余分な上位ビットは、パリティに敏感なデバイスから読み取られたバイトのパリティに設定される可能性があります。
- 3 つの 8 ビット バイトの下位 6 ビットを組み合わせて、18 ビットのバイナリ ワードを作成します。
一部のコントローラでは、実行時に 18 ビットと 16 ビットのデータ転送を選択できました。将来のハードウェアやサポートするシステム コールがどのようなものになるかは、事前に予測することはできません。
- 8 ビットのインターネットに接続すること自体が恐ろしいことで、誰かが持つ 9 ビットの夢を台無しにしてしまいます。当時はマシンが相互接続されていなかったので、彼らはそれを回避しました。
- バイトアドレスのストレージに 2 ビットの偶数倍以外のものがあると、あらゆる種類の問題が発生します。例: 8 ビット バイトで数千ビットの配列が必要な場合は、
unsigned char bits[1024] = { 0 }; bits[n>>3] |= 1 << (n&7);. 9 ビットを完全にパックするには、実際の除算を行う必要があり、パフォーマンスが大幅に低下します。これはワードあたりのバイト数にも当てはまります。
- 9 ビット バイト ハードウェアで実際にテストされていないコードは、予想外の 9 ビット バイトの世界への最初の実際の冒険で失敗する可能性があります。 . 前の byread()/bywrite() がここで役立つかもしれませんが、転送モードを設定するために追加の CHAR_BIT モード設定が必要になる可能性が高く、現在のコントローラーが要求されたバイトをどのように配置するかを返します。
完全に言うと、教育経験のために 9 ビット バイトについて心配したい人は、自分の補体系が戻ってくることについても心配する必要があるかもしれません。当然の死を遂げたと思われる何か他のもの (2 つのゼロ: +0 と -0 は進行中の悪夢の原因です... 信じてください)。当時の 9 ビット システムは、多くの場合、1 の補数演算と対になっているように見えました。