1 files changed, 32 insertions, 0 deletions
diff --git a/results/classifier/108/other/995758 b/results/classifier/108/other/995758
new file mode 100644
index 000000000..f04b18815
--- /dev/null
+++ b/results/classifier/108/other/995758
@@ -0,0 +1,32 @@
+graphic: 0.838
+device: 0.835
+semantic: 0.817
+performance: 0.809
+other: 0.789
+permissions: 0.709
+socket: 0.651
+boot: 0.648
+files: 0.634
+network: 0.632
+vnc: 0.619
+PID: 0.575
+debug: 0.541
+KVM: 0.448
+
+Possibly inaccurate statement in PC Platform Docs
+
+The documentation at:
+
+http://wiki.qemu.org/Documentation/Platforms/PC
+
+Contains the statement that the processor, after reset, executes code starting from address 0xFFFFF, corresponding to the last byte of the single megabyte of memory in the old 8086 address range.
+
+From my recollection of working in the microcomputer industry in the late 1980's, execution actually starts in real mode at the start of the last 16 bytes of addressable memory, at 0xFFFF0.  Think about it - if it's the last byte there's no room for an address operand to accompany a 1-byte opcode.
+
+Oh, and if I recall correctly, on the 80286 and 80386 and 80486, on reset the amount of addressable memory was 16MiB, 4GiB and 4GiB respectively, and IBM made the choice to map the BIOS ROMs to both the top of addressable memory and at the top of the first MiB.  The CPU's themselves always reset to near the top of their address range, and the BIOS writers promptly jumped back down to somewhere near the top of the first MiB.
+
+
+As far as I can see, the wording on the page only says that the BIOS ends at address 0xFFFFF, not that it starts execution at exactly that address. So I think that page is ok.
+
+OK, I just read the text again, and the sentences before the one with the 0xfffff indeed sounded like the the start address was at the last byte. I've reworded the text now a little bit so that it should be more accurate.
+