問題タブ [bits]

アドレスバスのサイズによって決まりますか？はいの場合、8086 は 20 ビット プロセッサでしたか? いいえの場合、プロセッサに 8 ビット、16 ビット、32 ビットなどのビット番号を割り当てる基準は何ですか?

ビットが「インターレース」された16ビット値があります。

次の順序でビットを格納する 8 つの項目 (値 0 から 3) の配列を取得したいと考えています。

• アイテム 0: ビット 7 と 15
• 項目 1: ビット 6 および 14
• 項目 2: ビット 5 および 13
• ...
• 項目 7: ビット 0 と 8

これは簡単な解決策です：

これを行うためのより良い（より速い）方法を知っている人はいますか？

編集：

ノート：

• 事前計算されたテーブルを作成することはオプションではありません。
• アセンブラーまたは CPU 固有の最適化を使用できない

TFTP の単純なクライアント実装を行っています。ここでは、次の形式で読み取り要求を送信する必要があります

間に1バイトのゼロビット値を挿入する必要があります。しかし、私はその価値を追加することができません。また、1つのゼロビットバイトを追加すると..実際には、適切なstrlen値を取得する方法よりも文字列終了文字を意味します。

誰かがこれで私を助けることができれば...

ファイルからmp3ヘッダーを抽出しようとしています。これはID3タグとは異なります。mp3ヘッダーには、MPEGバージョン、ビットレート、周波数などに関する情報が保持されます。

ここでmp3ヘッダー構造の概要を見ることができます：http：//upload.wikimedia.org/wikipedia/commons/0/01/Mp3filestructure.svg

私の問題は、ファイルをロードし、有効な（私が知る限り）バイナリ出力を受け取っているにもかかわらず、期待される値が表示されないことです。mp3同期ワードの場合、mp3ファイルの最初の12ビットはすべて1である必要があります。ただし、最初の8ビットだけで何か違うものを受け取っています。これは私に問題を示唆するでしょう。

ちなみに、有効なmp3ファイルがfopen経由で添付されています

プログラミングのテストでなぞなぞを解こうとしています。

免責事項: これは就職試験ですが、答えを求めているわけではありません。これを行う方法の理解を求めているだけです。このテストでは、一連の問題に対する一連の解決策を 2 週間以内に考え出す必要があり、単独で解決策に到達する必要はありません。

だから、問題：

次のようにビットが配置された32ビットの数値があります。

どこ：

• s は符号ビット (1 == 負)
• i は 16 整数ビット
• f は小数部の 15 ビット

割り当ては、32 ビット整数を浮動小数点数にデコードするものを書き込むことです。次の入力が与えられると、次の出力が生成されます。

数値の符号ビットまたは整数部分を取得するのに問題はありません。次のような符号ビットを取得します。

次のように整数部分と小数部分を取得します。

私が問題を抱えている部分は、最後の 15 ビットの数値を取得して、期待値と一致させることです。3.14 の代わりに、3.4587 などを取得します。

誰かが私が間違っていることについてヒントをくれたら、それを感謝します。何よりも、何時間もいじった後もこれを理解できなかったという事実は、私を一種の狂気に駆り立てます. :-)

str[20]という名前の文字配列に格納されるはずのランダムな160ビット文字列を生成しようとしています。配列が20文字を保持していることは明らかです。160ビットを20文字/数字に変更するにはどうすればよいですか？私はCでこれを行おうとしています。アイデアが足りなくなったので、どんな助けでも大歓迎です。その後、私のユニのヘルプデスクは私を助けません。

次のようなバイト配列があります。

byte[] array = new byte[] { 0xAB, 0x7B, 0xF0, 0xEA, 0x04, 0x2E, 0xF3, 0xA9};

タスクは、その中の「0xA」の出現数を見つけることです。何をすべきか教えていただけますか？答えは6です。

（クイックバージョン：最後の段落の隣の段落にジャンプします-「しかし」で始まる段落）

PVRTCイメージがチャネルあたり4ビットまたは2ビットであると信じていたので、私は無知で幸せでした。それはもっともらしく聞こえた。4 + 4 + 4 + 4（16ビット）または2 + 2 + 2 + 2（8ビット）のテクスチャが得られ、それぞれ2 ^ 16（65536）と2 ^ 8（256）の色深度になります。しかし、PVRTCに関するいくつかのドキュメントを読んで、突然、4 bpp（および2 bpp）、つまり1ピクセルあたり4ビットと表示されていることに気付きました。混乱と狂気が私の世界に入りました。

何？！4ビット？ピクセルあたり？しかし、それはチャネルごとに1ビットだけです！（そして、私が2ビットのものを始めようとさえしないでください、それは私の脳が現時点で把握するにはあまりにも奇妙でした。）この苦痛な現実へのある瞬間、私はこれが結局それほど現実的ではないことを理解するようになりました。どうやら、4 bppと言うとき、それは色深度ではなく、圧縮を指しているようです。ふぅ、結局、私は怒っていませんでした。

しかし、それから私は疑問に思い始めました：解凍後、これらの画像はどのような色深度になりますか？私はこの情報を調べようとしましたが、言及することは重要であるとは考えられていないようです（または私は情報を見つけるのが苦手です）。

PVRTC圧縮画像がピクセル形式RGBA4444のOpenGLESで目に見えるアーティファクトを与えないように見えるという事実は、それらが16ビットであることを示唆します（iPhoneのOpenGLESでピクセル形式RGBA4444の32ビットpng画像を使用すると非常に目に見えるアーティファクトが得られます）。

スクリプトを作成していfavicon.icoますが、可能な最大ビット数を知る必要があります。