In ARM architecture there is one low vector address0x0 and high vector address 0xFFFF0000.
I was wondering why two vector addresses might be needed ?
In Intel microprocessors and microcontrollers there is one vector address.
Is there any particular reason to have 2 vector addresses ?
Some microcontroller families have more than one to a number of different start addresses and/or they use the same address and switch in and out address decoding based on strap pins so that you can boot from one bootloader created say by the vendor, or the users bootloader or the users application. (allowing you to recover what would normally be a bricked system).
You could envision the same thing. Think of how these microcontrollers work by having to do the work outside the core to change the flash bank being used to boot from. By using this strap pin on the core, you could have an alternate bootloader at a different address, this bootloader could be used to re-write/manage/develop/rescue the primary application.
You can also possibly avoid the rom/ram vector address thing. say for example you boot from flash on the high vector and have ram at 0, you could then load the program into ram or at least a runtime specific vector table, then switch the bit (might have to bounce off of a trampoline to get there, I dont remember we didnt use the high vector in our chip).
Not saying that is why ARM did it, but if nothing else it makes for a simple rescue scheme for vendors. some of the vendors rescue schemes or alternate boot methods are overcomplicated. I would actually like to see arm and others have several, at least two signals giving four addresses maybe 0x00000000, 0x40000000, 0x80000000, 0xC0000000, that kind of thing or 0x00000000, 0x80000000, 0xFFFF0000, 0xFFFF8000. Do something like that on a number of cores, esp the cortex-m, and you might see the chip vendors start to use that instead of their own schemes and it would be less of a pain when moving from one chip to another between vendors or within the same vendors product line.
As dwelch says, this avoids address decoding in hardware. Especially important is the case of booting from Flash/ROM and switching to run from RAM. Although this is most important without an MMU.
In a real-time OS such as vxWorks, at least prior to version 4, all code ran at the system level and without an MMU. This minimizes latency. However, your physical code must map to either to a low or high address. Typically, a low address is most convenient and typical SOC hardware has chip selects for external memory allowing for a flexible layout of memory. However, having your vector table at 0x0 has some down sides. The most obvious being the use of a NULL pointer. Some hardware will allow read-only protection of an address range through SOC functionality; generating a BUS FAULT when a write happens to these addresses. If you are so unfortunate as to not have this type of SOC, and not have the Protection Memory System Architecture (Chapter B5.1 ARM ARM), then remapping the vector table to high memory maybe a nice thing to do; otherwise a single NULL write can take your system down.
Also note that the ARM ARM says that there is no ARM instruction that depends on a high or low vector table. It is an optional co-processor register which most, if not all, ARM's have. It is probably not as useful in modern ARM systems where we use an MMU. Even ARM has some baggage; it is still useful in the case of a bootloader or deeply embedded systems. With an active MMU, there is probably no need for this feature unless sections (1MB pages) are in use to minimize TLB pressure.
On newer ARM processors with TrustZone controllers, there are actually three vector tables. The secure world vector table is like the traditional high / low memory version. The monitor mode and non-secure world vector tables are set via a co-processor register and can be placed anywhere in memory.
