问题标签 [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 文件的前 12 位应全为 1，用于 mp3 同步字。但是，仅前 8 位我就收到了不同的东西。这对我来说是个问题。

作为旁注，我有一个通过 fopen 附加的有效 mp3 文件

我正在尝试解决编程测试中的一个谜语。

免责声明：这是对工作的测试，但我不是在寻找答案。我只是想了解如何做到这一点。测试要求我在 2 周内对一组问题提出一套解决方案，并且没有要求我孤立地得出解决方案。

所以，问题：

我有一个 32 位数字，其位排列如下：

在哪里：

• s 是符号位（1 == 负）
• i 是 16 个整数位
• f 是 15 个小数位

任务是编写将 32 位整数解码为浮点数的内容。给定以下输入，它应该产生以下输出：

我在获取符号位或数字的整数部分时没有问题。我得到这样的标志：

我得到这样的整数和小数部分：

我遇到问题的部分是获取最后 15 位中的数字以匹配预期值。我得到的不是 3.14，而是 3.4587，等等。

如果有人可以提示我做错了什么，我将不胜感激。最重要的是，我在搞砸了几个小时后还没有弄清楚这一点，这让我发疯了。:-)

我正在尝试生成一个随机的 160 位字符串，该字符串应该存储在一个名为 str[20] 的字符数组中。很明显，该数组包含 20 个字符。如何将 160 位更改为 20 个字符/数字？我正在尝试在 C 中做到这一点。非常感谢任何帮助，因为我已经没有想法了，然后我大学的帮助台不会帮助我..

找到包含 k 位集合的所有长度为 n 的二进制字符串的最佳算法是什么？例如，如果 n=4 且 k=3，则有...

在给定任何 n 和任何 k 的情况下，我需要一种生成这些的好方法，所以我希望它用字符串来完成。

我有一个字节数组，如下：

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

任务是找出其中出现“0xA”的数量。你能建议怎么做吗？答案是 6。

(Quick version: jump to paragraph next to the last one - the one beginning with "But")

I was happy in my ignorance believing that PVRTC images were 4 or 2 bits per channel. That sounded plausible. It would give 4+4+4+4 (16 bit) or 2+2+2+2 (8 bit) textures, that would have 2^16 (65536) and 2^8 (256) color depth respectively. But reading through some documents about PVRTC, I suddenly realized that it said 4 bpp (and 2 bpp), i.e. 4 bits per pixel. Confusion and madness entered my world.

What?! 4 bits? Per pixel? But that's just 1 bit per channel! (And don't even get me started on the 2 bit one, that one was far too weird for my brain to grasp at the moment.) Some moments into this agonizing reality, I came to understand this wasn't so real after all. Apparently, when saying 4 bpp, it's referring to the compression, and not the color depth. Phew, I wasn't not mad, after all.

But then I started to wonder: what color depth do these images have then, after decompression? I tried to look this information up, but apparently it's not considered important to mention (or I'm just bad at finding info).

The fact that PVRTC compressed images don't seem give any visible artifacts in OpenGLES with the pixel format RGBA4444 would suggest they're 16 bit (using 32 bit png images with the pixel format RGBA4444 in OpenGLES on the iPhone gives very visible artifacts).

我正在制作一个favicon.ico脚本，我需要知道可能的最大位数。