Is it possible to select multiple memory regions for global variables?

The compiler uses gp relative addressing for data items in the .sdata.* (etc) sections (small data section). As well as the immediate reduction in code size, using gp relative addressing significantly reduces the register pressure on the compiler - making it much less likely that other variables will have to be spilled to the stack.

IIRC, by default the compiler puts anything 8 bytes or smaller into the 'small' section.

For external data the actual data must be in the small data segment if any of the external references are (otherwise the linker gives a 'relocation won't fit' error).

For some reason Altera changed things between gcc3 and gcc4 so that external items are never (in ggc4) assigned to the sdata segment.

Another problem with multiple segments is that (last time I looked at least) the linker script puts the their initialisation data immediately following the .code, and adds code to copy them to the required place. This is all hopeless when your code is a small tightly coupled memory block.

There are also some issues with GP relative addressing, the altera build won't ever us it for 'symbol + constant' - eg if you put a 'struct' in the sdata segment. There are fixes for that on the wiki.

It can also be worth assigning a 'global register variable' to base of a large struct that contains (up to 32k) of variables. The compiler will actually generate better code for this than the GP relative addressing used for 'small' data items.

(The small data code uses the gcc feature designed for 'page 0' addresses - so gcc doesn't know there is a register involved, so array accesses (in particular) could be optimised further.)

The other Altera gcc4 fubar is that they forced switch statement jump tables into the .code segment rather than using a .rodata segment.

If you have tightly coupled code and data you need to link the .rodata with the .data, not the .code. If you boot method doesn't need it, you don't need read/write access to code memory (and it would be horribly slow as well).