どのプラットフォームに8ビット文字以外のものがありますか？

時々、SOの誰かがchar（別名「バイト」）が必ずしも8ビットではないことを指摘します。

8ビットcharはほとんど普遍的なもののようです。主流のプラットフォームではchar、市場での実行可能性を確保するために8ビットが必要であると私は思っていました。

現在と歴史の両方で、どのプラットフォームcharが8ビットではないを使用していますか？なぜそれらが「通常の」8ビットと異なるのですか？

コードを記述し、クロスプラットフォームサポート（たとえば、汎用ライブラリ）について考えるとき、8ビット以外のプラットフォームにどのような考慮を払う価値がありますcharか？

過去に、char16ビットのAnalog Devices DSPに出くわしました。DSPは、私が想定しているニッチなアーキテクチャのビットです。（そして、当時、手動でコード化されたアセンブラーは、利用可能なCコンパイラーができることを簡単に打ち負かしたので、そのプラットフォームでのCの経験はあまりありませんでした。）

charTexas Instruments C54x DSPでも16ビットで、たとえばOMAP2で表示されます。他にも16ビットと32ビットのDSPがありますchar。24ビットDSPについて聞いたこともあると思いますが、何を覚えているかわからないので、想像してみました。

もう1つの考慮事項は、POSIXが義務付けていることCHAR_BIT == 8です。したがって、POSIXを使用している場合は、それを想定できます。誰かが後でコードをPOSIXに近い実装に移植する必要がある場合、たまたま使用する関数が異なるサイズになりますがchar、それは彼らの不運です。

しかし、一般的には、問題を回避する方が、考えるよりも、ほとんど常に簡単だと思います。入力するだけですCHAR_BIT。正確な8ビットタイプが必要な場合は、を使用しますint8_t。コードは、予期しないサイズを暗黙的に使用するのではなく、コードを提供しない実装で騒々しくコンパイルできなくなります。少なくとも、私がそれを仮定する正当な理由がある場合に当たれば、私はそれを断言するでしょう。

コードを記述し、クロスプラットフォームサポート（たとえば、汎用ライブラリ）について考えるとき、8ビット以外の文字を使用するプラットフォームにどのような考慮が必要ですか？

ルールで遊んでいるので、何かを「考慮する価値がある」ほどではありません。たとえば、C ++では、すべてのバイトに「少なくとも」8ビットが含まれると標準で規定されています。バイトが正確に8ビットであるとコードが想定している場合は、標準に違反しています。

これは今ではばかげているように見えるかもしれません-「もちろん、すべてのバイトは8ビットです！」しかし、多くの非常に賢い人々は、保証ではない仮定に依存しており、それからすべてが壊れました。歴史はそのような例でいっぱいです。

たとえば、ほとんどの90年代初頭の開発者は、ほとんどのコンシューマCPUの電力はほぼ同等であるため、特定の何もしないCPUタイミング遅延が一定のサイクル数を取ると、固定量のクロック時間がかかると想定していました。残念ながら、コンピューターの速度は非常に速くなりました。これにより、「ターボ」ボタンが付いたボックスが登場しました。皮肉なことに、その目的はコンピューターをスローダウンして、時間遅延技術を使用したゲームを妥当な速度でプレイできるようにすることでした。

あるコメンターは、標準のどこにcharは少なくとも8ビットでなければならない、と言っています。セクション5.2.4.2.1にあります。このセクションではCHAR_BIT、アドレス指定可能な最小のエンティティのビット数を定義し、デフォルト値は8です。

それらの実装定義の値は、表示されている値と同じ符号で、絶対値（絶対値）以上でなければなりません。

したがって、8以上の任意の数は、への実装による置換に適していCHAR_BITます。

36ビットアーキテクチャのマシンには9ビットバイトがあります。Wikipediaによると、36ビットアーキテクチャのマシンには次のものが含まれます。

• デジタル機器株式会社PDP-6 / 10
• IBM 701/704/709/7090/7094
• UNIVAC 1103 / 1103A / 1105/1100/2200、

私が知っているもののいくつか：

• DEC PDP-10：可変ですが、ほとんどの場合、7ビット文字は36ビットワードごとに5つパックされます。そうでなければ、9ビット文字、ワードごとに4つパックされます。
• コントロールデータメインフレーム（CDC-6400、6500、6600、7600、Cyber​​ 170、Cyber​​ 176など）6ビット文字、60ビットワードごとに10個パック。
• Unisysメインフレーム：9ビット/バイト
• Windows CE：単に `char`タイプをまったくサポートしていません-代わりに16ビットのwchar_tが必要です

完全に移植可能なコードなどはありません。:-)

はい、バイト/文字のサイズはさまざまです。はい、非常に変わった値のCHAR_BITおよびを持つプラットフォーム用のC / C ++実装がある場合がありUCHAR_MAXます。はい、時々文字サイズに依存しないコードを書くことが可能です。

ただし、ほとんどすべての実際のコードはスタンドアロンではありません。たとえば、バイナリメッセージをネットワークに送信するコードを記述している可能性があります（プロトコルは重要ではありません）。必要なフィールドを含む構造を定義できます。それをシリアル化する必要があるよりも。構造体を出力バッファーにバイナリコピーするだけでは移植性がありません。通常、プラットフォームのバイトオーダーも構造体メンバーの配置もわからないため、構造体はデータを保持するだけで、データのシリアル化方法については説明しません。

OK。バイト順変換を実行し、構造体のメンバー（uint32_tまたは類似のもの）を使用memcpyしてバッファーに移動できます。なんでmemcpy？ターゲットアドレスが適切に配置されていない場合、32ビット（16ビット、64ビット、違いはありません）を書き込むことができないプラットフォームがたくさんあるためです。

したがって、移植性を実現するためにすでに多くのことを行っています。

そして最後の質問です。バッファがあります。そこからのデータはTCP / IPネットワークに送信されます。このようなネットワークは、8ビットバイトを想定しています。問題は、バッファのタイプをどうするかです。あなたの文字が9ビットなら？16ビットの場合はどうでしょうか。24？たぶん、各文字はネットワークに送信される1つの8ビットバイトに対応し、8ビットのみが使用されますか？それとも、複数のネットワークバイトが24/16/9ビット文字にパックされているのでしょうか？それは問題であり、すべてのケースに当てはまる単一の答えがあるとは信じがたいです。多くのことは、ターゲットプラットフォームのソケット実装に依存しています。

だから、私が話していること。通常、コードはある程度簡単に移植できます。別のプラットフォームでコードを使用する場合は、そうすることが非常に重要です。ただし、実際のコードはほとんど常に他のコード（上記の例のソケット実装）に依存しているため、この方法を超えて移植性を向上させることは、多くの労力を必要とし、多くの場合ほとんど効果がありません。8ビットにバインドされた環境を使用するため、8ビット以外のバイトを使用するプラットフォームで機能するコード機能の約90％はほとんど役に立たないと私は確信しています。バイトサイズを確認し、コンパイル時間のアサーションを実行するだけです。非常に珍しいプラットフォームでは、ほぼ確実に多くのことを書き直す必要があります。

しかし、コードが高度に「スタンドアロン」である場合は、なぜでしょうか。異なるバイトサイズを許可する方法でそれを書くかもしれません。

倉庫からIM6100（つまりチップ上のPDP-8）を購入できるようです。これは12ビットアーキテクチャです。

多くのDSPチップには16ビットまたは32ビットがありcharます。たとえば、 TIは日常的にそのようなチップを製造しています。

たとえば、CおよびC ++プログラミング言語は、バイトを「実行環境の基本文字セットのメンバーを保持するのに十分な大きさのアドレス可能なデータの単位」（C標準の3.6節）として定義します。C char整数データ型には少なくとも8ビットが含まれている必要があるため（5.2.4.2.1節）、Cのバイトは少なくとも256の異なる値を保持できます。CおよびC ++のさまざまな実装では、バイトを8、9、16、32、または36ビットとして定義します

http://en.wikipedia.org/wiki/Byte#Historyからの引用

他の言語についてはわかりません。

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

そのマシンのバイトを可変長に定義します

DEC PDP-8ファミリには12ビットワードがありましたが、通常は出力に8ビットASCIIを使用しました（ほとんどのテレタイプでは）。ただし、1つの12ビットワードに2文字をエンコードできる6ビット文字コードもありました。

1つは、Unicode文字が8ビットより長いことです。先に述べたように、C仕様ではデータ型を最小サイズで定義しています。データ型を調べて、構成とアーキテクチャーのデータサイズを正確に調べる場合sizeofは、との値を使用limits.hします。

このため、uint16_t特定のビット長のデータ型が必要なときなどに、データ型にこだわるようにしています。

編集：申し訳ありませんが、私は最初にあなたの質問を誤解しました。

C仕様によると、charオブジェクトは「実行文字セットのメンバーを格納するのに十分な大きさ」です。 limits.hは8ビットの最小サイズをリストしていますが、定義はcharオープンの最大サイズを残しています。

したがって、a charは少なくとも、アーキテクチャの実行セットの最大の文字（通常、最も近い8ビット境界に切り上げられる）と同じ長さです。アーキテクチャのオペコードが長い場合、charサイズが長くなる可能性があります。

歴史的に、x86プラットフォームのオペコードは1バイト長charでしたので、最初は8ビット値でした。現在のx86プラットフォームは1バイトより長いオペコードをサポートしますが、charプログラマー（および既存のx86コードの大容量）が条件付けするものであるため、長さは8ビットに保たれます。

マルチプラットフォームのサポートについて考えるときは、で定義されているタイプを活用してくださいstdint.h。あなたが（例えば）uint16_tを使用する場合は、16ビットの値に相当するものかどうか、この値は、どのようなアーキテクチャ上の符号なし16ビット値であることを確認することができchar、short、int他の、または何か。困難な作業のほとんどは、コンパイラ/標準ライブラリを作成した人々によってすでに行われています。

を必要とするchar低レベルのハードウェア操作を行っているためにaの正確なサイズを知る必要がある場合、私は通常、charサポートされているすべてのプラットフォームで（通常は16ビットで十分です）を保持するのに十分な大きさのデータ型を使用して実行します。convert_to_machine_char正確なマシン表現が必要な場合のルーチンによる値。そうすれば、プラットフォーム固有のコードはインターフェース関数に限定され、ほとんどの場合、通常のを使用できますuint16_t。

8ビット以外の文字を使用するプラットフォームにはどのような考慮事項がありますか？

マジックナンバーは、例えばシフト時に発生します。

これらのほとんどは、CHAR_BITや、8や255（または同様のもの）の代わりにUCHAR_MAXを使用することで、非常に簡単に処理できます。

うまくいけば、あなたの実装はそれらを定義します:)

それらは「一般的な」問題です.....

別の間接的な問題は、あなたが持っていると言うことです：

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

これは、1つのプラットフォームで（最善の場合）24ビットを取るだけですが、他の場所ではたとえば72ビットかかる可能性があります。

各ucharが「ビットフラグ」を保持し、各ucharに現在使用している2つの「重要な」ビットまたはフラグしかなく、それらを「明確さ」のために3つのucharに編成した場合、比較的「より無駄」になる可能性があります。 24ビットucharを備えたプラットフォーム.....

ビットフィールドで解決できないものはありませんが、他にも注意する必要があるものがあります....

この場合、1つのenumだけで、実際に必要な「最小」サイズの整数を取得できます。

おそらく実際の例ではないかもしれませんが、このようなものは、コードを移植/再生するときに私に「ビット」を与えます。

ucharが「通常」予想されるものの3倍の大きさである場合、100のそのような構造は、一部のプラットフォームでは大量のメモリを浪費する可能性があるという事実だけです。 。

そのため、あるプラットフォームでは、利用可能なRAMと比較して、ucharは別のプラットフォームよりも「それほど無駄ではない」という仮定のため、物事はまだ「壊れている」可能性があります。 ..

問題は、たとえばintや他のタイプの場合にさらに顕著になる可能性があります。たとえば、15ビットを必要とする構造があるため、intに貼り付けますが、他のプラットフォームではintは48ビットなどです。 。

「通常」は2つのucharに分割する可能性がありますが、たとえば24ビットのucharでは1つだけ必要です。

したがって、列挙型の方が「一般的な」解決策になる可能性があります。

ただし、これらのビットにアクセスする方法によって異なります。

そのため、ucharやuintのサイズに関係なく、コードがまだ正常に動作する場合でも、「設計上の欠陥」が発生する可能性があります...

コードに「マジックナンバー」がなくても、このようなことに注意する必要があります...

これが理にかなっていると思います:)

以前は16ビットであったint（pdp11など）。32ビットアーキテクチャに移行するのは困難でした。人々は良くなっています：ポインターがこれ以上長く収まるとは誰も想定していません（正しくありませんか？）。またはファイルのオフセット、またはタイムスタンプ、または...

8ビット文字はすでに多少時代遅れのものです。世界のすべての文字セットを保持するために、すでに32ビットが必要です。