Well, I guess this qualifies as an introduction

[Octocontrabass]

The reason I originally used uint32_t was because of the fact that EBX is a 32-bit capable register.

If you choose any of these...

Code: Select all

uint8_t *a;
uint64_t *b;
void *c;

...the variable will be 32 bits. Pointers (at least for 32-bit x86) are always 32 bits. What you're telling the compiler is the type of the value being pointed to. While you can use a pointer to uint32_t, you'll find it's much easier to use the multiboot headers:

Code: Select all

int kernel_main (multiboot_info_t *_bootloc)

[blasthash]

The reason I originally used uint32_t was because of the fact that EBX is a 32-bit capable register.

If you choose any of these...ri

Code: Select all

uint8_t *a;
uint64_t *b;
void *c;

...the variable will be 32 bits. Pointers (at least for 32-bit x86) are always 32 bits. What you're telling the compiler is the type of the value being pointed to. While you can use a pointer to uint32_t, you'll find it's much easier to use the multiboot headers:

Code: Select all

int kernel_main (multiboot_info_t *_bootloc)

Again, there's two reasons why I originally did not want to use the multiboot headers -

1. I'd like to (this may sound a bit crazy) go about this the hard way. I'll learn more about reading into the data structure that way, and I can pick what I want to, and don't want to utilize in the header.

2. My computer situation is ambiguous at best, and I'd rather not install headers/libraries that aren't crucial. I know the multiboot files come with GRUB, but put simply I'm on a computer where I don't have the resources nor the horsepower to be doing simulation and testing, only writing. All things considered, I'd rather design a method, even if it is harder, that is more freestanding.

Put simply, I know I'll be needing to use GRUB as a bootloader and save from the point at which I write my own, there isn't much getting around that. However, I strongly want everything in the confines of my kernel to be of my own hand. If it's the only way to go, I'll bite the bullet here and go with it, but at the end of the day, I'd be happier with my code if I knew it was my own.

[Octocontrabass]

1. I'd like to (this may sound a bit crazy) go about this the hard way. I'll learn more about reading into the data structure that way, and I can pick what I want to, and don't want to utilize in the header.

In that case, uint32_t may not be the best choice since some of the values in the multiboot header are not 32 bits.

2. My computer situation is ambiguous at best, and I'd rather not install headers/libraries that aren't crucial. I know the multiboot files come with GRUB, but put simply I'm on a computer where I don't have the resources nor the horsepower to be doing simulation and testing, only writing. All things considered, I'd rather design a method, even if it is harder, that is more freestanding.

If you have Windows computers available to you, put MSYS on a flash drive. That way, when you have to move between computers, everything moves with you: your code, your compiler, the multiboot headers, and anything else you might want.

Put simply, I know I'll be needing to use GRUB as a bootloader and save from the point at which I write my own, there isn't much getting around that. However, I strongly want everything in the confines of my kernel to be of my own hand. If it's the only way to go, I'll bite the bullet here and go with it, but at the end of the day, I'd be happier with my code if I knew it was my own.

If you're writing your own bootloader, you don't have to make it compatible with multiboot, and can therefore avoid dependency on the multiboot headers. (The biggest downside is that it'll be more difficult to debug.)