I have noticed that the Kiel compiler doesn't produce the correct interrupt vector if 8051 interrupt numbers are used. For example for external interrupt 0 (IE0), the interrupt number has to be 0, instead of 1 to produce a jump at location 1. Example:
void edge1 (void) interrupt 0{ /*produces correct code
while
void edge1 (void) interrupt 1{ /*produces wrong code
This is the case with all the interrupts I have used. My questions is what do you have to do to produce a reset vector? Reset is interrupt number 0 in 8051 numbering. Using -1 or 255 both produce a compile error.
Atmel 8-bit Flash Microcontroller AT89C51RD2 page 73
That table lists all of the vectors from which code execution starts after some hardware generated event. I think it is perfectly reasonable to view reset as an interrupt, although it differs from the other interrupts in at least two ways - it is non-maskable and has no flag through which it can be invoked in software.
The C runtime does not need to take any action in response to a non-reset interrupt occurring, but you might. So, the compiler provides a 'C' mechanism (the 'interrupt' qualified function) for you to provide code that will be invoked following a non-reset interrupt.
The C runtime does need to take action in response to a reset. It therefore does its level best to make sure that it places code at location zero that jumps to it's startup code.
However, given that this is an embedded environment full of people with peculiar requirements it does provide you with a mechanism to defeat its normal bahaviour: startup.a51. Yes, it isn't C, but if you are programing in C Keil assume that there is some expectation on your part that you would like your C program to behave as a correct C program.
In other words, the compiler does not provide you with a C mechanism to prevent the C environment from functioning correctly.
If you actually want to receive any useful advice may I suggest that rather than proceed with your assertion that it's all wrong, poorly documented and generally no good you explain what you are trying to achieve and why.
Another - possibly more fundamental difference - is that interrupts by definition interrupt normal program execution and return where they left off afterwards
That describes the normal usage of an interrupt, but at the risk of getting into another intractable and pedantic discussion you might say that:
"interrupts by definition interrupt normal program execution"
and that:
"the return from interrupt instruction by definition returns to where execution was interrupted by the last interrupt provided that there was no messing with the stack in the intervening period"
I'm sure you'll now point me to some document that defines interrupt as precisely what you've written. above, though.
Now you're just being needlessly pedantic...!
;-)