While snarky, I see where you're coming from. Sometimes a lot of the fun is in the building of a thing to understand how it works. Learning how a thing works from the user-facing side of the control panel is, for some of us, less rewarding.
If anything though, I want to go build a physical relay computer mechanism myself now (if even just a 4-bit adder or something).
Ha, I really get the sentiment! I do recommend perusing the Book 1 manual [0], towards the end there are a number of small problems (on page 30). They're worth tinkering with :-)
The program in the boot sector is run similar to other software: the code is loaded into memory, and then the processor is jumped to the first instruction. This loading and jumping is done by the firmware, which is included in your hardware, separate from your disks.
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.
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.
Ben Eater's "computer from scratch" series is phenomenal for going from that "building on black box APIs" level to "this is what's physically happening in the real world inside that black box"
The BIOS will look at all attached disks for a magical value at the end of first sector. that determines it's a 'bootable' disk. Then if there's only one, it will run it. If there's more, generally you can use BIOS menu to select the one you want. (it will pick 'first' by default which depends on how its all 'wired up' - likely lowest ID or ide/sata port etc.).
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.
CPU starts executing instructions from firmware (BIOS or UEFI). It performs some complicated computer-specific initialisation, discovers RAM, somewhat initialises PCI-E, USB, other peripherals and finally transfers control to the user-specified code. It's either instructions located at specific address of configured disk (old BIOS computers with MBR) or just a file in FAT32 partition (UEFI).
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.
As I see it, the point of bootstraping a compiler is to develop a compiler in stages and that it doesnt require you to implement the full compiler in the original language.
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.
Are symptoms not the sole means of diagnosis? So if girls present less symptoms then aren't they therefore less autistic? Or, alternatively, if they present different symptoms then perhaps they have something else?
No. That's the whole point of masking. It's doing social behavior 'in software' instead of doing it 'in hardware' like everyone else. An alcoholic who is high functioning is still an alcoholic.
reply