modifying the ARM generation behavior?

[Josh Fryman <fryman at cc dot gatech dot edu>]

hi all,

i've got a problem with the way the ARM code is being generated. i'm
wondering if there is any way around this problem that already exists,
or if i'm going to have the priveledge of writing some hacks... i 
asked on gcc-help first, but since that struck out, it's on to the this
dev list.

here's the problem.  gcc generates code with "data" values interspersed 
in the text segment.  that is, it might generate something like this:

      in C
      ----
      void foo( void )
      {
         int myvar=42;
         printf("myvar=%d\n",myvar);
      }

      in ARM-ASM  (edited to make shorter)
      ----------
      .section        .rodata
      .LC0:
              .ascii  "myvar=%d\012\000"
      .text
      foo:
         .....
              ldr     r0, .L4
              ldr     r1, [fp, #-16]
              bl      printf
              b       .L3
      .L4:
              .word   .LC0
              ,word   myvar
      .L3:      
              ldmea   fp, {fp, sp, pc}

note how gcc has "stuck" into the middle of the instruction stream 
some data values at .L4. it would make my life much easier (for research 
purposes) if i could move these little random scattered data segments 
into the main data segment or an alternate data segment...

i realize that the ARM doesn't support a decent load-immediate size 
(only 12 bits signed) for addresses or data, and that was probably
why this approach was taken.  however ... i'd like to make a fundamental
change.

with a few registers already pinned for other uses, like lr, sp, etc,
i'd like to reserve "another" register for being a pointer to a 
special data segment of these values - say r11.  then, at the very 
beginning of the program, r11 gets loaded with a pointer to the data
segment containing all these address offsets, and we no longer have to
mix data into the instruction stream.  this is almost what happens now
with "r3" throughout the program.  it spends most of its life as a 
pointer to a block of these variable addresses...

we also avoid having the dozens of "ldr r3,<some-var-block>" throughout
the code generation.  this would make for more efficient code.

i'd be happy to field any queries on more specifics or suggestsions on
existing ways to get around this...

thanks for your time,

josh fryman