[avr-libc-dev] [RFC] avr mega256 considerations

[Theodore A. Roth]

Hi,

I went to one of the Atmel seminar's this week and they talked about a
mega256 coming out at the end of the year.

I've been thinking about this and what gcc and gdb are going to have
to do to handle it. Even if the code generated for it is identical to
that for a mega128, gdb will still need to know the target device
type.

This is because of the way the PC is pushed on the stack. The mega128
can access all flash using a 16 bit addr, but the mega256 will have to
use a 17-bit addr. Thus a call or rcall instruction will have to push
3 bytes onto the stack instead of 2 like existing devices.

Since gdb needs to be able to read the PC off of the stack, it needs
to know how many bytes to read. The easiest way for gdb to know that
is via the bfd machine arch value. Right now we have 5 marches, which
gdb currently examines as such (basically a reminder no-op):

  /* If we ever need to differentiate the device types, do it here. */
  switch (info.bfd_arch_info->mach)
    {
    case bfd_mach_avr1:
    case bfd_mach_avr2:
    case bfd_mach_avr3:
    case bfd_mach_avr4:
    case bfd_mach_avr5:
      break;
    }

Adding a new march for devices with more than 128KB of flash would
allow me to do something like this in gdb:

  /* Examine machine arch to see how many bytes are pushed onto the
     stack during execution of a call/rcall.  */
  switch (info.bfd_arch_info->mach)
    {
    case bfd_mach_avr6:
      tdep->pc_push_size = 3;
      break;
    case bfd_mach_avr1:
    case bfd_mach_avr2:
    case bfd_mach_avr3:
    case bfd_mach_avr4:
    case bfd_mach_avr5:
    default:
      tdep->pc_push_size = 2;
    }

This would require changes to binutils and gcc and possibly avr-libc
too. I haven't looked into what the changes would be though.

Of course the mega256 is still vaporware. I just sow some seeds of
thought early on.

Anyone have any thoughts or comments on this?

Ted Roth