I still don't understand what's "running" the boot sector.
Let's back up to the start. When you switch on a computer, the power rails on a bunch of the chips come up. As this happens, the chips enter a "reset" state with initial data that is baked into the circuitry. This is the power-on reset (PoR) circuitry. When the power is up and stable, the "reset" is over and the processor starts executing. The initial value of program counter / instruction pointer is called the reset vector, and this is where software execution begins. On an x86 PC, this is something like 0xFFFFFFF0. The memory controller on the system is configured for reads from this address to go NOT to the main RAM, but to a flash memory chip on the board that holds the firmware software. From there the firmware will find your bootable disks, load the bootloader, and pass control to it.
In practice, systems vary wildly.
Is there any resource you could point me to where I can learn?
I’m mostly used to working at a higher abstraction level and taking as “magic” everything below that.
I’d like to bridge the gap with lower level stuff now, it’s about time.
For individual hardware stacks, there are processor and system documentation that explain exactly the memory addresses, the state of registers, the location on a drive where the firmware tries to find your bootloader, and all that.
so the BIOS transfers execution to the address. 0x7c00. That is where it also loads your bootsector. After that, your code runs.
For UEFI it's different. And in light of modern PC platforms with things like platform security processors, there's actualyl a lot that happens even before that stage, to verify BIOS and try to aid secure-booting / trusted boot.
The process of bootstrapping a compiler (not an operating system) is really interesting and the method used is ingenious.
I had read about it some years back.
Basically, at high level, it's a kind of chicken and egg situation:
After writing a compiler for language A (in language A), where A is a new language, how can you compile that compiler to an executable, so that you can compile application programs written in A?
Because there is not yet any runnable compiler for A.
I might not have described the issue very well.
And the concept of cross-compiling also comes into the picture, depending on the situation.
I don't remember the details perfectly now.
If somebody else who knows, describes it, I think it would be interesting for many people here.
Some links:
For example, let's say you create a new language called Brute. You decide to write it in C (original language).
Stage 1: Create a Brute compiler in C, which can compile only a small subset of Brute language. Lets call it bruteC compiler.
Stage 2: Implement a compiler in Brute lang and compile it using your bruteC compiler. This produces brute-compiler executable.
Stage 3: Add new feature to your brute compiler source code and compile it using your brute-compiler executable, which produces new brute-compiler executable.. .
And so on... At the end your brute-compiler supports all language features and thus is self hosted.
I knew the bootstrapping expression and origins, but as a second language speaker it had never occurred to me that “boot” as verb was related.