Re: AVR indirect_jump addresses limited to 16 bits

[Paul Schlie <schlie at comcast dot net>]

> From: Paul Schlie <schlie@comcast.net>
>> Marek Michalkiewicz wrote:
>> I'm looking into adding support for ATmega256x and larger devices to
>> the AVR port.  This means that program memory addresses no longer fit
>> in 16 bits - and I'm looking how to avoid making pointers larger.
> 
> - Fully agree, just can't keep from wondering if this may be most
>   efficiency accomplish by simply requiring the alignment of all
>   function entry points to be two instruction word aligned. Thereby
>   although there will be some more inefficiency than otherwise required
>   for code mapped @ <64K; apps with even as many as 1K or so functions
>   (which is likely a lot for even large avr apps), it would only imply
>   a worst-case inefficiency of 1K instruction words, but likely averaging
>   closer to 500 words, which seems like a small price to pay for an
>   additional 64K words of program space. (and would likely less than the
>   corresponding overhead of having to thread function entries to their
>   bodies otherwise).
> 
>   Thereby all function address pointers simply first set the extended
>   code address register bit to the logical high order address bit of the
>   16-bit code pointer. which technically is likely best physically mapped
>   into the low-order bit of the function pointer so that it does not need
>   to cleared prior to use (effectively implying that function entries <64K
>   are aligned to even word addresses, and those >64K are aligned to odd word
>   address.
> 
>   (no jump tables, etc, required)

- and likely continue to assume that the static-const progmem mapped data
  simply remains limited to a maximum of 64K-bytes mapped into the lower 32K
  words of program memory space to keep it's addressing and access simple,
  uniform and efficient within the constraints of AVR's ISA. (which seems
  likely reasonable?)