将使用 Files.readAllBytes 加载的字节打印到数组中

Question

我正在尝试使用 java 编写一个 Chip8 仿真器，但我在 ZD52387880E1EA22817A72D375921389 Files中遇到了readAllBytes function 的问题。 当我将用于测试的 ROM 中的字节加载到模拟器的“内存”数组中时，我尝试打印这些字节以查看它们是否正确进入 memory。 我使用Integer.toHexString将这些字节视为十六进制值并将它们与我使用十六进制编辑器加载的实际文件进行比较，但它给我的 output 很奇怪：

文件的第一个字节：

00 e0 a3 4c

Output 来自测试：

0 ffffffe0 ffffffa3 4c

代码：

public void loadToMem(byte[] program) {
    for(int i = 0; i < program.length; i++) {
        this.memory[i+512] = program[i];
        System.out.println(Integer.toHexString(this.memory[i+512]));
    }
    this.initializeComponents();
}

这些值只是Integer.toHexString给出的表示中的一个错误，并且这些值正在正确加载，或者它们是否真的被错误地加载？ 为什么用 f 填充？

Answer 1

Java 中的byte值是带符号的 8 位值。 因为e0和a3都设置了它们的高位（它们的值 >= 80 hex），所以它们代表负值。 然后，当您将它们传递给Integer.toHexString时，这些值将扩展为 32 位值。 您看到的是这些负 8 位值的等效 32 位十六进制表示。 这称为二进制补码表示，它最常用于表示计算机 memory 中带符号的 integer 值。

使用二进制补码，具有十六进制值e0的有符号 8 位（单字节）integer 具有十进制值 -32。 十进制 -32 的有符号 32 位 integer 表示为十六进制的ffffffe0 。 当您将二进制补码正值扩展到更广泛的表示时，您将使用0填充。 当你扩展一个负二进制补码值时，你用ff值填充。 将二进制补码值扩展到任意数量的字节时，其工作方式相同。

我们大多数人可能都同意你的观点，这是我们第一次看到负整数在计算机的 memory 中是如何解释的“有点奇怪”。

这是一个对二的补码的更简单解释的链接