"Phil Lamoreaux" <[EMAIL PROTECTED]> wrote in message
news:28916@palm-dev-forum...
>
> Does anyone know why const data is placed in the (very limited) heap
instead
> of code space?
I'll try to shed some light on this, at least from the compiler writer's
point of view.
All code and data in a PRC is in the form of resources. Some resources are
read-only, like code. Others are templates for data elsewhere -- the global
data section, for example.
Consider this code fragment, built with CW Palm 6 with PC-relative strings
turned on:
const char *q = "happy";
void s();
char *r()
{
s();
return "not so happy";
}
First, you would assume that all strings here are constant. However, when
disassembled, you get
Hunk: Kind=HUNK_LOCAL_IDATA Name="@69"(1) Size=6
00000000: 68 61 70 70 79 00 'happy.'
Hunk: Kind=HUNK_GLOBAL_IDATA Name="q"(2) Size=4
00000000: 00 00 00 00 '....'
XRef: Kind=HUNK_XREF_32BIT Name="@69"(1) #Pairs=1
Offset=$00000000 Value=$00000000
Hunk: Kind=HUNK_GLOBAL_CODE Name="r__Fv"(3) Size=38
00000000: 4E56 0000 link a6,#0
00000004: 4EAD 0000 jsr s__Fv
00000008: 41FA 000E lea *+16,a0 ; 0x00000018
0000000C: 4E5E unlk a6
0000000E: 4E75 rts
00000010: 8572 5F5F 4676 dc.b 0x85,'r__Fv'
00000016: 000E 6E6F 7420
0000001C: 736F 2068 6170
00000022: 7079 0000
The string "happy" is sitting in global data storage, while the string "not
so happy" is in a code section. The problem here is scope. The bare string
in r() is accessed by code, so its easy to stick it in the code section as
an offset from the program counter. The string referenced by global
variable q is referenced by relocations that get fixed when the program is
executed. These relocations are done by the operating system in
SysAppStartup. The scheme apparently allows references from data into code,
since you can have a global variable initialized to the location of a
function.
So, based on this knowledge, it should be possible for anonymous global data
to live in code space. How about something like
const int foo[5] = { 1, 2, 3, 4, 5 };
For this to work, it would need to be possible to have relocations in code.
This case seems simple, but consider:
static void a() { }
static void b() { }
static void c() { }
typedef void (*VoidFuncPtr)();
const VoidFuncPtr foo[3] = { a, b, c };
You would agree that foo is constant at runtime, therefore should be a
candidate for being put in the constant data pool that is part of the code
segment. However, the data in foo changes depending on where the code
segment gets locked into memory. Therefore, foo could not be put in the
code segement, since it cannot be written into by the system relocator (it
could be in flash, for example).
So, in order to put some safe data into code space, you would need to have
an analysis routine in the compiler that could detect when the data
structure would need an internal relocation. If it needed relocation, then
it would have to stay in global space that can be modified at program launch
time. If it didn't, then it would be safe to put the data into read-only
space, which like code, doesn't get modified.
Hmmm, I'm going to pass this on to my friends at Metrowerks -- maybe with
this analysis, better read-only data support can make its way into a future
release.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
