RE: [avr-gcc-list] RFC: ATmega256x and 16-bit function pointers

[HutchinsonAndy]

I have RTL prolog written if that would be any help - it simplifies logic.


Marek Michalkiewicz <address@hidden> wrote:

>Hi,
>
>I think I've just come up with a potential solution for the ATmega256x
>problem with function pointers (16 bits not enough), at the cost of
>reasonable overhead (no shift by 6 with 128-byte function alignment).
>
>The idea: output each function in two parts, in different sections:
> - JMP instruction, pointing to the function body
> - function body
>
>Now, the first section must be in the lowest 128K of program memory
>(so you can take the 16-bit program memory address of the jump),
>but it's just 4 bytes for each function in the program (unlikely to
>run out of space).  JMP can reach anywhere in the 8 MB address space,
>so there are no restrictions where function body can be located.
>
>This means small runtime overhead (JMP) for each function call, but
>we can still have 16-bit function pointers (larger pointers would
>result in much more overhead, and are a lot of work to implement).
>
>One possible speed optimization would be to only go through the jump
>for indirect calls (in CALL, use the function body address directly)
>if we figure out how to do this (probably some deep linker magic:
>detecting a CALL to a JMP and changing it to point to JMP target).
>
>And, one possible size optimization would be to remove unnecessary
>JMP instructions (for functions whose address is never taken), but
>this hack is only for >128K devices anyway so it's low priority.
>
>I'm not sure what to do with -ffunction-sections - both the jump
>and the function body should be in their own unique sections?
>(The linker script must recognize section names so that the jumps
>go into the "below 128K" section in this case, too.)
>
>And, the same problem we have with -mcall-prologues in C++ exists
>here, too (worse, because -mcall-prologues is just an option):
>the function body must have a label with a name constructed from
>mangled function name, but I haven't yet figured out the mangled
>equivalent of current_function_name() in GCC.
>
>I'm not yet sure about section naming convention to use: put the jumps
>in a special "low" section and function body in .text as usual, or the
>jumps in .text and function body in a special "high" section.
>
>Interrupt/signal functions are often time critical, so there should
>be some way to avoid jumping to another jump.  Taking the address of
>an interrupt handler (if supported at all) probably should give us
>the vector address (2, 4, 6, ...) directly.
>
>There are some caveats with indirect function calls in bootloaders:
>EIND must be initialized to point to the last 128K, and EICALL must
>be used instead of ICALL.  As long as we are not switching between
>different 128K pages (like indirect calls to bootloader functions
>from the application), EIND doesn't need to be changed.
>
>Right now, this looks like the easiest way toward supporting ATmega256x
>and possibly larger devices (without a major redesign, likely necessary
>to make pointers larger).  Comments?
>
>Thanks,
>Marek
>
>
>
>_______________________________________________
>AVR-GCC-list mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>


-- 
Andy Hutchinson


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp