Stu Bell schrieb:
The root of the problem is that GCC's architecture does not lend itself
to 24-bit entities. As you noted, function pointers are 16 bits, which
limits the range to 128K of flash (since all AVR instructions are 2
bytes wide, the program counter addresses 2 byte words).
GCC could be modified to run with 32-bit (4 byte) pointers, but the
ATTiny folks would yell like mashed cats if that were done universally.
I suppose that a switch could be placed telling GCC whether to use 16
bit or 32 bit pointers, but then the avr-libc library would need to be
compiled both ways leading to problems of making sure that the correct
library is linked with the correct compiled source.
The multilib would be no problem, same for introducing a new compiler
option. The hard part would be to rework the backend. At the moment,
Pmode is HImode. You would have to set Pmode to SImode, but note that
gcc knows just /one/ pointer mode. So both data and code pointer stuff
would be in 32-bit arithmetics, load and stores.
Believe me, this would certainly trigger a flood of "optimization
regression" bugs from the same folks that requested such a feature...
The E-registers are sometimes chenged by the hardware, and sometimes
not. The E-regs are no GPRs, yet they would need handling as if they
were R32. Any pointer arithmetic would involve clobber registers to hold
and modify the E-part of the address.
You really want that?
Georg-Johann
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
