http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868
--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-10-20
15:18:51 UTC ---
(In reply to comment #5)
> Hi Johann,
>
> I would prefer if the name of the address space for program memory be named
> "__flash" so that way it is the same name as what the IAR compiler uses. Using
> the same name as the IAR compiler assists users who wish to migrate from the
> IAR to the GCC toolchains. Like so:
>
> + c_register_addr_space ("__flash", ADDR_SPACE_PGM);
I chose __pgm because it is different to __flash. Even though I know nothing
about IAR's __flash I can hardly imagine that __pgm does 100% the same.
It's implementation defined and using the same identifier would give rise to
the incorrect assumption that both imlementations behave exactly the same,
which most probably is not the case.
Moreover, the problem of > 64k flash is not yet addressed. As far as I can see,
there are three approches:
1.
Don't do anything about it.
2.
Implement bunch of ASes like __pgm1, __pgm2 for each 64k chunk.
This is easiest to implement and has least side effects on avr back end.
These AVRs are segmented architecture and at some points an implementation
cannot hide that to the user.
This would require changes in default ld script or user would have to supply
his own ld script to locate the 64k chunks/sections.
3.
Implement thing like __pgmx that is attached to 24 bit address.
This is way more complicated because a new machine mode PSI must be supported
or else the AS has to hitchhike SImode.
When crossing section boundaries ELPM Z+ changes RAMPZ, leading to messy code
in the general case.
Notice that it is not possible to split additions in the AVR BE because there
is still cc0. And there is *no* address register that can hold pointers > 16
bits. X cannot because Y might be FP, Y cannot because it might be PF, Z cannot
because there is no register R32 whouch would then be RAMPZ. Dunno if treating
RAMPZ as GPR instead of as SFR is doable and sane.
