Information on stack winding/unwinding

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

Hi all,

I am thinking about modifying the ChibiOS AVR port to work with the xmega. One thing I need to do is put the initial value of the program counter (either two or three bytes) onto the stack so "ret" can be called.

Looking at the AVR Instruction Set PDF this is what it gives for "RET"

PC(15:0) <- STACK, SP <- SP + 2 (16 bit PC)
PC(21:0) <- STACK, SP <- SP + 3 (22 bit PC)

This does not really tell me what order the bytes of the PC are stored on the stack when "CALL" or variants are executed. Is there another manual I should be reading? I could look at examples but I would rather find the source of the information.

Thanks!

Sam

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

AVR is pretty consistently little-endian. High byte of address goes in the higher address on the stack.

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

Would the Atmel simulator be "official enough"? You can easily observe stack operation in that.

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

clawson wrote:
Would the Atmel simulator be "official enough"? You can easily observe stack operation in that.
I think the question is about a first-hand specification from the hardware vendor, not about how to reverse-engineer by whatever tool.

avrfreaks does not support Opera. Profile inactive.

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

Which is EXACTLY why I asked if it would be "official enough"!

That tool is written by Atmel after all.

Presumably if this is documented by Atmel you know where? Perhaps you could enlighten OP?

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

westfw wrote:
AVR is pretty consistently little-endian. High byte of address goes in the higher address on the stack.

This is one of the reasons I am asking. Using the simulator I found that it is stored big-endian (the high byte is the first one popped off the stack, therefore residing at the lowest memory address). This seems like it may a architecture vs compiler difference seeing that GCC (or insert your favorite compiler here) must be responsible for keeping track of byte order in multi-byte data types when using an 8-bit architecture while the architecture itself is responsible for pushing and popping the PC.

Hrmm, I was just hoping there was a document that covered the internals more clearly.

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

clawson wrote:
Would the Atmel simulator be "official enough"? You can easily observe stack operation in that.

I used the simulator and found out the highest byte of the PC is store first out (lowest address) on the stack. This is sort of backwards to the way most multi-byte "stuff" is done on the AVR in my experience.

I guess I can just accept it and move on. I was hoping there was some hidden document that discussed the internals of the instructions a little more cleanly.

Thanks,
Sam

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

westfw wrote:
AVR is pretty consistently little-endian. High byte of address goes in the higher address on the stack.
No, addresses are stored "low byte first". As stack grows downwards, this means that the addresses are stored big-endian effectively.

clawson wrote:
That tool [simulator] is written by Atmel after all. Presumably if this is documented by Atmel you know where?
I am not aware of such a documentation.

Some facts I know are from reading GCC or binutils sources. Even more knowledge could be drawn from reading the atmel simulator sources...

avrfreaks does not support Opera. Profile inactive.