0x100000000 - about book HOT 5 CLOSED

I was working out the math to try to figure out what the 0x100000000 did, and tried to write down an explanation for a pull request, but writing is hard and I couldnʼt quite figure out a way to word it that I was happy with. Hereʼs whatʼs going on, though:

The warning you get if you remove the 0x100000000 is this one:

multiboot_header.asm:7: warning: dword data exceeds bounds

0xe85250d6 is 3,897,708,758 in decimal, and the smallest number you can store as a 32-bit signed integer is −2,147,483,648, so we get an integer underflow. This doesnʼt matter for the checksum, since the spec really only says that (magic + mode_code + header_length + checksum) % 2^32 should be zero. A number that satisfies this is -(magic + mode_code + header_length) % 2^32, and thatʼs what we get if we just type -(magic + mode_code + header_length), but since underflows are usually a bug ([citation needed]) the assembler gives us a warning.

We can use the fact that the % 2^32 is there to our advantage, though. (x + y*n) % n == x, so we can add any multiple of 2^32 to our checksum and get the same number. 2^32 in hexadecimal is 0x100000000, so letʼs add that: (-(magic + mode_code + header_length) + 0x100000000) % 2^32. Rearranging it a bit we get (0x100000000 - (magic + mode_code + header_length))) % 2^32. This is still the same number, but the number before we do 2^32 now ends up being in the range of a 32-bit number, so the assembler no longer warns us.

from book.

I think this kind of thing might be a great candidate for an aside....

from book.

I agree this should be an aside. Here's my attempt at a simpler rewrite:

0xe85250d6 is 3,897,708,758 in decimal, and the smallest number you can store as a 32-bit signed integer is −2,147,483,648, so we get an integer underflow. This doesnʼt matter for the checksum, but since underflows are usually a bug the assembler gives us a warning.

Remember that the modulo operation finds the remainder after division of one number by another. One consequence of this is that if you have the series n % k and you keep increasing n by 1, it'll repeat its values every k steps. For example, if k is 3:

3 % 3 = 0
4 % 3 = 1
5 % 3 = 2
6 % 3 = 0
7 % 3 = 1
8 % 3 = 2
etc...

We can generalize this by saying n % k = (k + n) % k. In this case, our k is 2^32 or 0x10000000, so adding 0x10000000 to our checksum will give us an equivalent modulo test, but with the advantage of reassuring the assembler that it's not an underflow since the number is now in the range of values that a 32-bit signed integer can represent.

from book.

👍

from book.

Awesome stuff! @dariusk @henrikhodne do either of you want to attempt to take this explanation and put it into a pull request?

We're currently using block quotes as our format for asides. For example:

> By the way...
>
> TEXT GOES HERE

from book.