Function addresses on the AVR

Function addresses on the AVR

[Jim Blandy]

Hey there.  I've been looking at uses of CONVERT_FROM_FUNC_PTR_ADDR
with an eye towards fixing up some related stuff, and I noticed two
things about avr-tdep.c:

- It provides a function for CONVERT_FROM_FUNC_PTR_ADDR that
  multiplies the address by two, and

- There's a comment saying:

     ...
     The problem manifests itself when trying to set a breakpoint in a
     function which resides in the upper half of the instruction space and
     thus requires a 17-bit address.
     ...

Both of these things caught my eye, and made me wonder if there
weren't a way to help the AVR port work better, and incidentally
remove your use of CONVERT_FROM_FUNC_PTR_ADDR altogether.

From looking at the AVR manual, I gather that code addresses are 16
bits wide, and refer to 16-bit words in the program memory.  So the
architecture can address 64k words (128k bytes), of code.
Instructions are always 16 or 32 bits long, so the processor never
addresses them by byte at all.  So as far as the processor is
concerned, code addresses are 16 bit long.  Is that right?

But GDB and the rest of the GNU toolchain all want to use byte
addresses for everything, so in the unified address space you use for
linking, your program memory appears as 128k bytes at addresses 0x0
through 0x1ffff.  Whatever SRAM the system has appears at 0x800000 in
this unified address space; a pointer value of 0x0 refers to the byte
at 0x800000 in the unified space.  Is that right?

I'll bet C programs represent data pointers as byte addresses, but
pointers to a functions as word addresses --- 16-bit values you could
load directly into the PC.  And I'll bet return addresses on the stack
are also just 16-bit values.

So this means that the toolchain is using 17-bit byte addresses, while
the running program is using 16-bit word addresses.  Right?

If so, I think this is exactly the program that POINTER_TO_ADDRESS and
ADDRESS_TO_POINTER are supposed to solve.  They're described in more
detail in gdb/doc/gdbint.texinfo, in the section called "Pointers Are
Not Always Addresses"; that even uses a Harvard architecture as an
example.

You're using them to add and remove the upper "prefix" bits, which is
partly what they're for, but they're also supposed to handle
converting between the word addresses that appear in the running
program, and the byte addresses that GDB uses to actually read and
write instruction memory.

The general idea is that CORE_ADDR values should always be byte
addresses, and if the processor's natural form for function pointers
and return addresses on the stack is not a byte address, then
POINTER_TO_ADDRESS converts the natural form to byte addresses, and
ADDRESS_TO_POINTER converts byte addresses to the natural form.

In other words, POINTER_TO_ADDRESS should shift the value left one bit
when the type is a pointer to function or method --- turning the word
address into a byte address --- and ADDRESS_TO_POINTER should shift
the value right one bit when the type is right --- turning the byte
address back into a word address.

If you change your methods to do this, and dedicate the full range 0x0
-- 0x1ffff for byte-addressed program memory (which I'll bet is what
gas, ld, and the binutils are doing already), and then get rid of the
definition of CONVERT_FROM_FUNC_PTR_ADDR, then I think a bunch of
stuff should start to work better.

Re: Function addresses on the AVR

[Theodore A. Roth]

On Wed, 11 Jun 2003, Jim Blandy wrote:

:)
:) Hey there.  I've been looking at uses of CONVERT_FROM_FUNC_PTR_ADDR
:) with an eye towards fixing up some related stuff, and I noticed two
:) things about avr-tdep.c:
:)
:) - It provides a function for CONVERT_FROM_FUNC_PTR_ADDR that
:)   multiplies the address by two, and
:)
:) - There's a comment saying:
:)
:)      ...
:)      The problem manifests itself when trying to set a breakpoint in a
:)      function which resides in the upper half of the instruction space and
:)      thus requires a 17-bit address.
:)      ...
:)
:) Both of these things caught my eye, and made me wonder if there
:) weren't a way to help the AVR port work better, and incidentally
:) remove your use of CONVERT_FROM_FUNC_PTR_ADDR altogether.
:)
:) >From looking at the AVR manual, I gather that code addresses are 16
:) bits wide, and refer to 16-bit words in the program memory.  So the
:) architecture can address 64k words (128k bytes), of code.
:) Instructions are always 16 or 32 bits long, so the processor never
:) addresses them by byte at all.  So as far as the processor is
:) concerned, code addresses are 16 bit long.  Is that right?

Yes, that is correct.

There is a device coming end of year (rumored) with 128k words (256k
bytes) of code space, but there isn't a datasheet available yet. Not
sure yet how that will affect the GNU toolchain though.

:)
:) But GDB and the rest of the GNU toolchain all want to use byte
:) addresses for everything, so in the unified address space you use for
:) linking, your program memory appears as 128k bytes at addresses 0x0
:) through 0x1ffff.  Whatever SRAM the system has appears at 0x800000 in
:) this unified address space; a pointer value of 0x0 refers to the byte
:) at 0x800000 in the unified space.  Is that right?

Yes.

:)
:) I'll bet C programs represent data pointers as byte addresses, but
:) pointers to a functions as word addresses --- 16-bit values you could
:) load directly into the PC.  And I'll bet return addresses on the stack
:) are also just 16-bit values.

True for now. The rumored 256k device will put a 24-bit return address
on the stack (pushes 3 bytes). One gotcha with the return addresses on
the stack is that they are in big-endian byte order in memory, but the
avr's are considered little-endian devices. A call instruction does
the pushes in hardware, so gcc has no control or knowledge of this as
far as I can tell.

:)
:) So this means that the toolchain is using 17-bit byte addresses, while
:) the running program is using 16-bit word addresses.  Right?

For the current devices, yes.

:)
:) If so, I think this is exactly the program that POINTER_TO_ADDRESS and
:) ADDRESS_TO_POINTER are supposed to solve.  They're described in more
:) detail in gdb/doc/gdbint.texinfo, in the section called "Pointers Are
:) Not Always Addresses"; that even uses a Harvard architecture as an
:) example.
:)
:) You're using them to add and remove the upper "prefix" bits, which is
:) partly what they're for, but they're also supposed to handle
:) converting between the word addresses that appear in the running
:) program, and the byte addresses that GDB uses to actually read and
:) write instruction memory.
:)
:) The general idea is that CORE_ADDR values should always be byte
:) addresses, and if the processor's natural form for function pointers
:) and return addresses on the stack is not a byte address, then
:) POINTER_TO_ADDRESS converts the natural form to byte addresses, and
:) ADDRESS_TO_POINTER converts byte addresses to the natural form.
:)
:) In other words, POINTER_TO_ADDRESS should shift the value left one bit
:) when the type is a pointer to function or method --- turning the word
:) address into a byte address --- and ADDRESS_TO_POINTER should shift
:) the value right one bit when the type is right --- turning the byte
:) address back into a word address.
:)
:) If you change your methods to do this, and dedicate the full range 0x0
:) -- 0x1ffff for byte-addressed program memory (which I'll bet is what
:) gas, ld, and the binutils are doing already), and then get rid of the
:) definition of CONVERT_FROM_FUNC_PTR_ADDR, then I think a bunch of
:) stuff should start to work better.
:)

I've changed the ADDRESS_TO_POINTER and POINTER_TO_ADDRESS methods to
do the bit shift for code addrs and removed the
CONVERT_FROM_FUNC_PTR_ADDR method. I can't see that it negatively
affects either what is in cvs or the new code I'm working on
(frame-ifying the avr), so it looks like your analysis is correct.

I'll commit the changes after I've done a bit more testing (I still
don't have the testsuite running for avr yet :-\ ). That will remove
one more instance of CONVERT_FROM_FUNC_PTR_ADDR for you.

Thanks for digging through the avr stuff.

Ted Roth

Re: Function addresses on the AVR

[Jim Blandy]

"Theodore A. Roth" <troth@openavr.org> writes:
> I've changed the ADDRESS_TO_POINTER and POINTER_TO_ADDRESS methods to
> do the bit shift for code addrs and removed the
> CONVERT_FROM_FUNC_PTR_ADDR method. I can't see that it negatively
> affects either what is in cvs or the new code I'm working on
> (frame-ifying the avr), so it looks like your analysis is correct.
> 
> I'll commit the changes after I've done a bit more testing (I still
> don't have the testsuite running for avr yet :-\ ). That will remove
> one more instance of CONVERT_FROM_FUNC_PTR_ADDR for you.

Great --- thanks!

> Thanks for digging through the avr stuff.

No problem!