| Author |
Message |
|
|
 Posted: Jan 01, 2012 - 01:24 PM |
|
Joined: Jan 01, 2012
Posts: 3
|
|
I've recently been disassembling some hex files and I've come across a problem in the AVR Studio disassembler. It's interpreting the instruction code 9580 as "LAT R24":
9580 LAT R24 Load and Toggle
9590 LAT R25 Load and Toggle
According to the AVR instruction set manual, LAT R24 would be 9307. 9580 is actually one's complement of R24 (ie COM R24) which (a) is supported by the chip (ATMega168), and (b) makes sense in the context of what the code is doing. The AVR simulator performs COM R24 when it gets to this point in the code, so it does appear that this is just a bug in the disassembler.
I'm using AVR Studio 4.18-684, if that makes any difference. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 01, 2012 - 01:49 PM |
|
Joined: Feb 12, 2005
Posts: 16547
Location: Wormshill, England
|
|
Just what exactly should "Load and Toggle" do?
Most cores have some instructions that do the same thing.
The assembler simply translates to the opcode it thinks most suitable.
A disassembler has a problem. Which mnemonic should it use when there are several alternatives?
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 01, 2012 - 02:59 PM |
|
Joined: Jul 18, 2005
Posts: 62944
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| LAT is an Xmega instruction. You shouldn't see it for a mega168. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 01, 2012 - 05:42 PM |
|
Joined: Nov 17, 2004
Posts: 13960
Location: Vancouver, BC
|
|
|
Quote:
A disassembler has a problem. Which mnemonic should it use when there are several alternatives?
But LAT is not an "alternative" for 0x9580, so there should be no such confusion. |
_________________
Regards,
Steve A.
The Board helps those that help themselves.
|
| |
|
|
|
|
|
|
Posted: Jan 02, 2012 - 11:57 AM |
|
Joined: Jan 01, 2012
Posts: 3
|
|
|
david.prentice wrote:
Just what exactly should "Load and Toggle" do?
According to the programming manual, it's:
(Z) ← Rd ⊕ (Z), Rd ← (Z)
That is to say, the element at location Z (Z = R31:R30) is XORed with Rd and stored back to location Z and Rd.
As far as I can tell, the Mega168 doesn't have anything that does this instruction. You'd have to do it as a couple of separate instructions.
david.prentice wrote:
A disassembler has a problem. Which mnemonic should it use when there are several alternatives?
In this case there shouldn't be any confusion. Here are what the functions should be, from the programming manual:
Code:
LAT: 1001 001r rrrr 0111
0x9580: 1001 0101 1000 0000
COM: 1001 010d dddd 0000
You can see that the 0x9580 instruction cannot possibly match the specification for LAT.
I've been through the entire programming manual and no instruction other than COM can match that bit sequence.
clawson: is LAT actually an Xmega instruction? I can't find it in the instruction set listing. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 02, 2012 - 01:44 PM |
|
Joined: Jul 18, 2005
Posts: 62944
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
clawson: is LAT actually an Xmega instruction? I can't find it in the instruction set listing.
Yes (I guess your copy is out of date?): |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 02, 2012 - 05:51 PM |
|
Joined: Nov 22, 2002
Posts: 12196
Location: Tangent, OR, USA
|
|
Just checked because my "Instruction Set" is grossly out of date (2003). Had never heard of LAT. The document says nothing about where it is used. It is not listed as supported in the Mega168 document.
I wonder if the disassembler even takes the processor model into account? After all, a particular instruction does not encode to different code bytes in different devices.
The one place I have seen the disassembler have trouble is in data tables. It does not know anything about data tables and valiantly attempts to disassemble them, often making a mess of code that follows the table. But, once the PC is past the table, everything is OK. This suggests that the disassembler starts disassembling at the top of the display. If you shift the view to start on the second half of a double-word instruction, it will misinterpret everything. Could this be the problem, here?
Jim |
_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA
"The only thing standing between us and victory is defeat" P.G.Wodhouse in Wooster & Jeeves series
|
| |
|
|
|
|
|
|
Posted: Jan 02, 2012 - 07:52 PM |
|
Joined: Jul 18, 2005
Posts: 62944
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Interestingly the "instruction set summary" in the Xmega-A manual makes no mention of these. I then wondered if they were "braindead AVR" instructions but the summary in the tiny4/5/9/10 manual doesn't mention them either. However I'm 99.9% certain they are Xmega instructions.
In theory they use an "unused" part of the instruction decode matrix so the disassembler should be at liberty to decode tem always as they shouldn't occur in atmega168 code.
Previously there were only two instructions that would decode with 1001 001x ...:
Code:
1001 001d dddd 0000 sts i,r 2
1001 001r rrrr 1111 push r 1
While LAT is:
Code:
1001 001r rrrr 0111 lat Z,r
The 0111 in the lowest nibble should make it unique.
For an R16..R13 use of the opcode it should be 0x93 not 0x95 as mentioned in the first post - so this looks like an instruction decode error. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 03, 2012 - 02:23 PM |
|
Joined: Jan 01, 2012
Posts: 3
|
|
Thanks for all the replies.
clawson wrote:
Interestingly the "instruction set summary" in the Xmega-A manual makes no mention of these. I then wondered if they were "braindead AVR" instructions but the summary in the tiny4/5/9/10 manual doesn't mention them either. However I'm 99.9% certain they are Xmega instructions.
Yes, that was where I got confused.
My copy of the full AVR instruction set includes it, but I know that each AVR only implements a subset of those instructions. I couldn't find it in the Xmega's own instruction set listing (in the Xmega manual) so I assumed that it wasn't supported on those chips.
clawson wrote:
Previously there were only two instructions that would decode with 1001 001x ...:
Code:
1001 001d dddd 0000 sts i,r 2
1001 001r rrrr 1111 push r 1
While LAT is:
Code:
1001 001r rrrr 0111 lat Z,r
The 0111 in the lowest nibble should make it unique.
For an R16..R13 use of the opcode it should be 0x93 not 0x95 as mentioned in the first post - so this looks like an instruction decode error.
ka7ehk wrote:
I wonder if the disassembler even takes the processor model into account? After all, a particular instruction does not encode to different code bytes in different devices.
Based on this example, it does not appear to check the processor type. I guess this makes sense since it allows the disassembler to handle hex files built for newer CPUs without needing to know exactly what instructions they support.
ka7ehk wrote:
The one place I have seen the disassembler have trouble is in data tables. It does not know anything about data tables and valiantly attempts to disassemble them, often making a mess of code that follows the table. But, once the PC is past the table, everything is OK. This suggests that the disassembler starts disassembling at the top of the display. If you shift the view to start on the second half of a double-word instruction, it will misinterpret everything. Could this be the problem, here?
I don't think this would be the problem. I've found a couple of odd things in the code (like copying SREG into TCCR1B and clearing registers by subtracting them from themselves) but overall most of the code seems to make sense. I would have expected a complete mess if it was having major problems.
The AVR simulator seems to interpret the instruction correctly; it's just the disassembler that gets it wrong. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 29, 2012 - 08:02 PM |
|
Joined: Jul 18, 2005
Posts: 62944
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
