JMP instruction

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

I noticed the words in the actual intel hex file are in reverse of how the AVR Instruction Set Manual describes them.

 

Per "AVR Instruction Set Manual"

32bit opcode instruction for JMP is

1001 010k kkkk 110k

kkkk kkkk kkkk kkkk

 

seems like opcode and address intermingle...

1001 010k kkkk 110k   kkkk kkkk kkkk kkkk  
OOOO OOOA AAAA OOOA   AAAA AAAA AAAA AAAA   O=Opcode  A=AbsoluteWordAddress (OpCode is JMP)

 

opcode is 10 bits

address is 22 bits

 

I am assuming the k's will slide together to form a 22 bit address? doing a >>3 for the 5 upper bits that need to move over because of the opcode being between the bits?

 

 

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

12oclocker wrote:
I noticed the words in the actual intel hex file are in reverse of how the AVR Instruction Set Manual describes them.
That's an issue of endianness (in print, not in the device).  When I write a 16-bit word, I write it with the MSB on the left, and the LSB on the right.

 

The AVR hardware, however, is little-endian, so a 16-bit word in byte-oriented addressing is stored with the 8 LSB before the 8 MSB.  Since Intel hex files are byte-oriented, the 16-bit instruction word appears to you to have the high byte and the low byte swapped.

 

As an example, if I take an AVR hex file I have lying around, the first line looks like this:

:100000000C9463000C948B000C948B000C948B006C

... with the first 32-bits of the payload highlighted.

 

If I disassemble that hex file with avr-objdump -Dzmavr:

Disassembly of section .sec1:

00000000 <.sec1>:
       0:       0c 94 63 00     jmp     0xc6    ;  0xc6

Note how the order is presented the same way.  However, since this is little endian, the actual two 16-bit instruction words are written as 940c0063, written with MSB on the left.

 

This is a bit pattern of:

1001 0100 0000 1100 0000 0000 0110 0011

1001 010k kkkk 110k kkkk kkkk kkkk kkkk

 

So you see a match with the Instruction set manual.

 

The constant is a bit complicated.  22 bits is enough to address 4M words.  Devices with 128K of flash (or less) need only address 64K words (or less), and use only 16 of those bits.  They are the 16 bits in the 2nd 16-bit instruction word.  In our example above, that's 0x0063.  When taken as a byte-address that points to 0x00C6, which avr-objdump confirms above.

 

See:

http://web.csulb.edu/~hill/ee346/Lectures/16%20AVR%20Instruction%20Encoding.pdf

 

EDIT:  typos

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Jan 25, 2019 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks, looking around it seems their is many opcodes which intermingle the opcode bits, I supposed it's probably the way the mcu reads the bits to process the instruction.

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

it seems their is many opcodes which intermingle the opcode bits

Yes.  My suspicion was that the AVR was one of the first microcontrollers designed with "Software tools" to do the logic creation - earlier chips would have some person laying out fields in the instruction word that would "make sense" even if you had to program the chip in binary.  The AVR looks more like someone input design equations like "this operand has this many possible source and destination registers" and let a logic minimization program figure out an efficient way to arrange the bits in the final instruction word...

 

(BTW, if the AVR were really consistently little-endian, the low bits of the destination address would be in the first word of the instruction...)