> Old 8bit processors just start with the instruction pointer at a known value (e.g. 0x0000).

So do new 8bit processors and almost all processors, x86 cpus still have a reset vector, its 0xFFFFFFF0.

Wouldnt 0 cause problems? You accidentally branch to null, machine reboots.

In C, a "null pointer" (NULL, (void *)0, etc.) does not necessarily correspond to an address with all bits zero.[1] The compiler translates any pointer constants with a value of 0 to an invalid address appropriate for that machine.

I haven't verified this, but I could see this being used by microcontroller compilers, where address 0x0000 is often a memory-mapped register.

[1] http://c-faq.com/null/index.html

Also the C null pointer on modern system is the logical (virtual memory) address which is not necessarily mapped to 0x0 physical address - in fact, to trap the null pointer access, this page would be left unmapped so the OS receives a page fault. This means that before virtual memory is set up (or if a page is mapped for logical address 0x0), 0x0 is a perfectly valid memory location, both for data storage and executing instructions from. Basically, the null pointer "error" is trapped by the OS at a higher level.

In fact, there's an entire class of kernel exploits where if you know a certain kind of behavior will cause the kernel to dereference 0x0, and that system allows you to mmap the lowest page in your virtual address space, you can take over the machine.

See https://blogs.oracle.com/ksplice/entry/much_ado_about_null_a... and https://blogs.oracle.com/ksplice/entry/much_ado_about_null_e...

(dkersten, I assume you know this, I'm pointing it out for the benefit of others.)

I used 0 as the example because the 8bit chip I was thinking of (the Z80) used that. But the exact address isn't too relevant, the basic idea is that the CPU has a default state for the instruction pointer, and can get things going from there.

http://lateblt.tripod.com/z80proj1.htm

"What's Happening?

The computer begins with the CPU. When the CPU starts running (which basically happens as soon as it receives power and is reset with the RESET pin), it begins to pull instructions from memory and execute them. Where it starts in memory depends on the individual CPU, but in the case of the Z80, it simply begins at memory address 0, instead of using a reset vector like many other CPUs do. This means that any computer using the Z80 must have a ROM chip at memory address 0 which gives the initial start-up instructions to the Z80."

Also - the memory map during boot time is broadly unrelated to the per-process memory map during OS runtime. Also, if you branch to unexpected memory addresses, you deserve all you get. Also, on a processor with privilege isolation, your ring3 user process can't just cause a reboot.

Wouldn't accidentally branching to null always cause problems?

No, it may be just a memory address like any other (it can also be a register or other special address). The reason it's a problem in normal programs is because there usually isn't code there (and with memory protection, you probably aren't allowed to access that space, which is the error you often see).

The CPU doesn't care if the address is all 0s, that's not special to the CPU. So when it turns on it just starts executing at some hard-wired address. That could be 0x0000, 0x8000, or it could be something really random like 0x48C4. Somewhere in the chip's documentation it says what the address is. Once the CPU has power, it loads the first instruction from that address, and then it executes everything as normal.

So you wire up the computer so that some little piece of ROM (for example the BIOS) sits at that address. When the chip turns on, you know what instructions it will start executing.

Once things are going, you could set things up to be more complicated (such toggling pins to signal the ROM chip to stop listening so you could map normal RAM into that address), but that's the basic idea.

I am aware of the finer details, I am just assuming that branching to somewhere you didn't want to go is generally a Bad Thing (tm) ;)

(Unless you get lucky, and it's a branch-predict, that turns out to be an incorrect predict, and then flushes and re-branches into valid memory...)