RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561

[Mark E. Scott Jr.]

I'd be overjoyed to have any solution for the 2560 :)  It sounded to me
like the option #2 (GCC mods) was a non-starter.

Mark E. Scott, Jr.
address@hidden
AWS, Inc.
512-478-7727 x 122

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Bjarne Laursen
Sent: Tuesday, September 13, 2005 1:59 AM
To: address@hidden
Subject: Re: [avr-gcc-list]
ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561

Chip Webb wrote:

> It seemed as though there were two proposed methods to handle this:
>
> 1) Align functions (and labels?) to 4-byte boundaries so that  gcc can

> continue to use 16-bit
>   values to represent function pointers.  This isn't so different from

> the method that is
>   already used for the Mega128.
>
> 2) Modify GCC to support longer pointers (PSImode?)

3) Make any function, where the address is put into a pointer, start  
below 64K, using a jump if neassesary.

Also: If these functions, and any program memory strings could be forced

into a memory range like 32K<=adr<64K, it would be possible to determine

if a pointer points to ram or flash at runtime. This could be very
useful.

I know these things have limits too, like when using more than 32K ram, 
or more than 32K program memory strings.



_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list