3.1 - Header length clarification question about book HOT 5 CLOSED

I'm treating this as as assumed knowledge bug, but to answer right now:

(and why is this in decimal and not hex, even though 0 is 0 regardless of number system)?

Just a mistake, cc #86

but size of what exactly? Is the amount of memory the magic number and protected mode code take up? is it the size of the total instructions in the file? I feel like this is a core idea of assembly I'm missing here.

It's the size of this whole structure. See more below....

But what are header_end and header_start

When we define the two labels in this file, they can be used like addresses. So header_start, being at the beginning, is going to be the address at the beginning, and header_end, being a label at the end, is going to be the end.

And what is in between these two addresses, just 0xe85250d6 and 0, or something else?

We have four dd statements, which _d_efine _d_oubles, which means 32-bit values. So 4 * 32 = 128 bits is going to be the difference.

from book.

Ok, I understand now. What really cleared it up was getting a hexeditor via brew install hexedit

And then compiling the file just with

nasm multiboot_header.asm -o multiboot_header.o

From there I was able to see that the value of dd header_end - header_start is just 0x00000010 which is 16 in decimal. Which means that the value of header_end - header_start is just 16 bytes.

I think that the text would be improved by spelling that out a bit (maybe as a comment in the code), but I can also see how it might be too much extra information for some maybe.

from book.

I'm also not sure if this just isn't too complicated for something that's never getting changed; the reason that you do it this way is so that things automatically update when you change the definition, but we're not planning on doing so.

from book.

This is also confusing for me. I also asked myself

is header_start going to be 0x00000000?

The labels are addresses - but addresses in what? Byte offsets in the ELF/.o file? The linked kernel.bin? Or is it dynamically resolved at runtime?

from book.

I'm not working on the first edition anymore, so I'm going to give this a close. This stuff isn't in the second edition yet, and it's not likely to make it exactly. If someone wants to send in a PR to fix up the first edition, please feel free!

from book.