[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/
Mark E. Scott Jr.
RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561
Tue, 13 Sep 2005 14:19:45 -0500
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.
512-478-7727 x 122
[mailto:address@hidden On Behalf Of
Sent: Tuesday, September 13, 2005 1:59 AM
Subject: Re: [avr-gcc-list]
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
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
|[Prev in Thread]
||[Next in Thread]|
- RE: [avr-gcc-list] ATMega640/ATMega641/ATMega1280/ATMega1281/ATMega2560/ATMega2561,
Mark E. Scott Jr. <=