warning : 'JMP' not supported on this device

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems like I suddenly starting getting these messages from the assembler. I'm using an ATMEGA8 and I believe it supports that opcode. Any ideas why I get this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there's no need for a jmp opcode because the smaller rjmp could reach the whole address space of a mega8.

cya
denny

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess I "suddenly" started getting these because I "suddenly" started using JMP ops. RJMP seems to take care of it. Interesting that it is only a warning, not an error.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the assembler tests if jmp is really necessary, if not it will be replaced bei rjmp.
this saves one cycle per instruction.

cya
denny

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know the exactly background. I just know the difference between rjmp and jmp ;-)
and that the assembler corrects the jumps if needed....

sorry
denny

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

de.ste wrote:
the assembler tests if jmp is really necessary, if not it will be replaced bei rjmp.
this saves one cycle per instruction.

cya
denny

This is a BAD practice. The assembler should NEVER substitute opcodes. The whole point of using assembly is to have direct and complete control over the genrated code. The assembler has no way of determining if the programmer purposly chose jmp instead of rjmp for a particular reason. This type of substitution should never be made by an assember automatically.

If the substitution is made because the instruction is not supported, then that's a different story. But the assembler should then include the statement "using rjmp instead" or something along those lines, to inform the user that a substitution has been made, and their code may no longer work as initially intended.

SteveN wrote:

Obviously this isn't code that can be run on a real mega8 to test if it really runs but why would the assembler produce this warning:

Quote:
K:\SNUTTALL\AVR Projects\Temporary projects\Jump experiment\Jump experiment.asm(8): warning: jmp k: Unsupported instruction on ATmega8

but go ahead and place the (apparently) correct opcode for jmp??

Sorry if I am making a mountain out of a mole hill but I am just curious.

I agree totally, and believe this is an issue that needs to be addressed. It should either warn, and inform of the substitution, or it should generate an error, and fail to complete. (my preference is for the latter, I don't like the assembler doing any changes to my code, be it silently or verbosely)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another post, had me curious abouut the availability of jmp & call on the mega 8. When I checked the archived datasheet I have on my PC (dated 06/02) It does list jmp and call as valid instructions, while in the latest on downloaded form Atmel (12/03) has them removed form the list. (note that they are not needed on the m8 to reach the entire flash, rjmp & rcall are capable of accessing the entire 4kwords of flash)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
de.ste wrote:
the assembler tests if jmp is really necessary, if not it will be replaced bei rjmp.
this saves one cycle per instruction.

cya
denny

This is a BAD practice. The assembler should NEVER substitute opcodes.

Well, it doesn't. Never. This is true for both AVRASM and AVRASM2.

glitch wrote:
I agree totally, and believe this is an issue that needs to be addressed. It should either warn, and inform of the substitution, or it should generate an error, and fail to complete. (my preference is for the latter, I don't like the assembler doing any changes to my code, be it silently or verbosely)

The current policy is to issue warnings about unsupported instructions, and not substitute any instructions. There are other instructions that are unsupported on some devices as well, like some variants of LPM and LD/ST where no substitution is readily available.

I agree to some extent that this should maybe cause an error and not a warning, but the current policy has been in place for a long time, and we decided not to change it at this point. I will consider making this an option in a future AVRASM2 version.

As for the original question in this thread ("suddenly" getting warning about JMP on a mega8): When implementing AVRASM2, I reviewed all the data sheets to make sure it was correctly implemented, and discovered some discrepancies in the old AVRASM as well, which were corrected in AVRASM 1.76. This is the reason why this warning "suddenly" appeared.

Generally, all assembler warnings should be taken seriously, as they usually indicate some problem with your program. Like for other programming languages, the goal should be to eliminate all errors and warnings before the program goes into production.

Roland Kruse
Atmel AVR Tools

Please don't report bugs in private forum messages.
--
Roland Kruse
Atmel AVR Tools

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SteveN wrote:
Hi Roland,

I reread your post above several times and I am still curious if the mega8 will execute a jmp instruction. I do not have any mega8's so I cannot try some experimental code on an actual device myself. The assembler and simulator seem to think the mega8 can execute the opcode for a jmp instruction (see my >>very<< simple experiment in my post above and the resulting .lst output).

To be perfectly honest: I don't know for sure. I don't have a mega8 readily available for testing this either at the moment, and no time to track one down.

The simulator, like the assembler, is a creature of software and should not be entirely trusted in this matter. The reference for implementing the tools is the same as yours: the data sheets.

What I do know is the following:

- Devices with 8kB or less flash don't need JMP/CALL, because the entire flash can be reached with RJMP/RCALL.
- The latest data sheet (dated 12.09.2003) does not mention JMP/CALL as supported
- When the AVR encounters an unsupported instruction, it executes as a NOP.

I'll have to ask one of the IC guys to be really sure, but you should assume the data sheet is correct.

Roland Kruse
Atmel AVR Tools[

Please don't report bugs in private forum messages.
--
Roland Kruse
Atmel AVR Tools

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kruse wrote:
glitch wrote:
de.ste wrote:
the assembler tests if jmp is really necessary, if not it will be replaced bei rjmp.
this saves one cycle per instruction.

cya
denny

This is a BAD practice. The assembler should NEVER substitute opcodes.

Well, it doesn't. Never. This is true for both AVRASM and AVRASM2.

I had never tested for this myself, was only responding to the other users comments. I'm glad to hear that it indeed does not make substitutions. though I still feel that this should be an error, and not a warning. (Though I do understand the reasoning behind the decision that was made, I just disagree with it ;) )

As for the jmp/rjmp, call/rcall. I have an old datasheet that does list them as supported instructions, while the latest versions do not. My guess is that it's still in the decoder, but is subject to be removed at any time in a future revision of the chip. In other words don't use it.

Thanks for your comments Roland.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
kruse wrote:
glitch wrote:
de.ste wrote:
the assembler tests if jmp is really necessary, if not it will be replaced bei rjmp.
this saves one cycle per instruction.

cya
denny

This is a BAD practice. The assembler should NEVER substitute opcodes.

Well, it doesn't. Never. This is true for both AVRASM and AVRASM2.

I had never tested for this myself, was only responding to the other users comments. I'm glad to hear that it indeed does not make substitutions. though I still feel that this should be an error, and not a warning. (Though I do understand the reasoning behind the decision that was made, I just disagree with it ;) )

You'll probably be happy to hear that we've decided to change AVRASM2's behaviour in this respect in the next release. IOW, use of unsupported instructions will cause an error, not a warning. There will also be a command-line option and #pragma directive to change this behaviour, but the default will be error.

This decision only affects AVRASM2, the old assembler will not be changed.

Roland Kruse
Atmel AVR Tools

Please don't report bugs in private forum messages.
--
Roland Kruse
Atmel AVR Tools

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again Roland, for the reply and update. It's good to know that user feedback actually means something :)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SteveN wrote:
I reread your post above several times and I am still curious if the mega8 will execute a jmp instruction. I do not have any mega8's so I cannot try some experimental code on an actual device myself.

I've just stumpled over this relatively old discussion, but I have an answer to this one.
I have a few Mega8's, and they can execute jmp and call instructions with no problems. I know that because I have some shared code, that runs fine on both Mega8 and Mega16 (and I know for sure that I use at least call's and probably also jmp's in that code).

The Mega8's I have are mostly from one of the first full-volume runs when Mega8 first appeared in larger numbers. But I also have one dated early this year (can't remember the exact week number right now).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Mega8515 has the same issue, I've been using call and jmp instructions for some time. Now with the latest assmbler I get warning message. Does this mean that new batches of mega8515s will not support a call instruction & I have to recode all my projects for the last couple of years?
By the way a relative jump cannot access all of program memory its range is plus or minus 2K. So if you have a call at the bottom of memory it can't access passed the 2k limit. I tried changing my "call" to "rcall" now I get "out of range error" (which is probably why I started using call in the first place)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found this at Atmel AVR's FAQ site:
http://atmel.com/dyn/products/fa...

Quote:
AT90S8515 JMP and CALL

Question: The AT90S8515 has got 8kB of program memory. As the RJMP and RCALL commands can take me 2K locations backwards or forwards, how can I reach the entire program memory. According to the Instruction Set Summary, this part has no JMP or CALL

Answer: The program memory is organized as 4K x 16, so there are only 4k program memory locations. In the assembler, select "Options >> Wrap Relative Jumps". This will enable you to jump over the boundary of the program memory.

As an example, if you do a relative jump from $FFE back to $00A, the program counter will be incremented by 12, and wrap around the boundary of the program memory.

This feature is only applicable to 8K devices, as 4K devices do not require
wrap-around, and 16K devices need JUMP and CALL.

Applies To: AVR 8-Bit RISC

Post Date: 10/21/97