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.
I believe software should use the same terminology that the chip manufacturers use. The 8051 is about the simplest micro I have used recently (others were DSPs, coldfire, and other 32 bit processors) but I find Keil's manuals and on-line documentation mostly don't supply the information I'm looking for. I have also gotten unreliable information from Keil tech support recently - I think the guy was guessing when he answered my question. So I tend to rely on the chip manufacturer's manuals. Keil's docs are good at explaining simple things but there is also a lot of ambiguous information.
I believe software should use the same terminology that the chip manufacturers use.
But whose terminology, among the dozens of 8051 manufacturers, would that be? And let's assume that they picked a different one than you're using --- how would that help you in any way?
But it has already been established that there is no standard terminology for this used throughout all manufacturers!
It has also been established that Keil followed Intel's lead on this - and Intel was the inventor and original manufacturer of the 8051. You can't get much closer to "the horse's mouth" than that! So, if anyone's got their terminology "wrong", it's those new, upstart "derivative" manufacturers...
"I find Keil's manuals and on-line documentation mostly don't supply the information I'm looking for"
That's because you're starting from a false assumption, and then trying to find stuff to back it up!
Keil very clearly and unambiguously define what they mean by "interrupt numbers" in the context of their proprietary 'interrupt' keyword.
As already noted, SDCC follows the same meaning; but it's open-source - so you could create your own version, if you wanted, that would work the way you like it...
"I think the guy was guessing when he answered my question"
Probably trying to guess what on earth you were on...
;-)
I don't know whether you get paid by Keil to be their shill or just have a lot of time on your hands but in any case there is no need for insults. If you didn't presume so much and were not always trying to come up with snot-nosed insults, you might learn a few things.
OK, sorry - that was a cheap joke.
Oh, for goodness sake, grow a thicker skin and grow up.
You've posted a ridiculous load of nonsense in this thread yet several people have made quite an effort find out what you're trying to do so they can offer you some useful advice. The conclusion is that the facilities to achieve what you want already exist, yet you are still adamant that things ought to be organised a little bit differently to suit you.
What a complete and utter waste of time.
"I find Keil's manuals and on-line documentation mostly don't supply the information I'm looking for" This is, of course, not 'love' but I could not help quoting the old song.
Keil, by default can NOT document anything more than the behaviour of their tools. I can hardly think of one thing in the '51 architecture that some derivative does not do differently. Thus there can be no expectation whatsoever that Keil document anything about the behaviour of the hardware in reaction to the code produced by Keil.
It is not uncommon for those that has not understood that "the '51 ain't no PC" to expect a congruence between hardware and software documentation (let alone look for one in the manual of the other). However with the plethora of manufacturers of '51s that each put their own spin on the chip to separate them from the competition it would be ridiculous to expect any such congruence (do you remember the '751 that did not decode ljmps or the derivative where the T2 IE bit was located elsewhere). In the case of single manufacturer chips such as the PIG, congruence will, of course, be possible as well.
Erik