Could we do it better?

So I was looking at vector dispatch. In part because I was looking at the half dozen or so startup files and multitude of pre-encoded vector files in the library.  I wondered if all the processors of a given family could have a single startup file.

The answer is yes if you were willing to give up a bit of flash and a bit or RAM. So for the ST family their 'chip specific' IRQs are numbered IRQ0 - IRQ239. In the vector table they consume potentially 240x4 or 960 bytes. The current scheme uses weak aliasing on pointers to override the pre-defined vector in vector.o but on more than one occasion I've screwed up when used usartx_isr when I needed to use uartx_isr. What I really wanted was something like nvic_attach_interrupt(USART6, uart_interrupts); I could give it a signature like nvic_attach_interrupt(enum NVIC_SOURCE src, (void)(*vector)(void)) and do some type checking of the validity of the interrupt configuration at compile time. And I wouldn't have to remember the exact names for the isr's as defined in the vector.o binary.

I was looking at plumbing it directly, by pre-filling all IRQ vectors with the same handler function, but the Cortex M doesn't seem to put the IRQ source on the stack so what you probably end up doing is something like this at say IRQ0 -> irq0_isr and in the startup file it has

void
irq0_isr() {
    *(ram_vectors[0])();
}

Which will add another call frame to the stack. Or one could just branch to the address held in the table using assembly but being careful not to screw up the LR value on the stack (thus leaving exception mode early).

The challenge is of course that that with the exception vectors in flash you can't just poke them to change them, you need something in RAM to do that, and moving the exception table to RAM using the SCB makes other issues (like what if a wild pointer overwrites the reset handler? Etc)

On even days I think this will be really helpful and on odd days I think its overkill even for the psuedo OS I'm building because the system configuration will be largely static.

Thoughts?
--chuck