Data tables for a software tool

[Ludis Langens]

"John S. Gwynne" wrote:
> 
> I don't see how const data types
> (in .rodata and .text sections) could access or be stored that differently
> than data on the stack or heap.

I'm concerned with how they get initialized in memory.  There are
systems where the (on disk) executable could be very bloated - and where
more time might be spent setting up my data than the "normal" run time
of my program.

> What environment is the limit and how big is
> it? (i.e., is there really a problem here?)

It appears that there is an old 680x0 "standard" that limits the data
space to 32K.  This "standard" creates the data space off the stack by
making a special stack frame "around" the entire program.  This data is
referenced by signed 16 bit offsets off of a pointer register.

> Something similar can be accomplished by compiling "const int test=10;".
> In elf, "test" will be placed in the .rodata section (in coff, I
> believe the .text section). The linker script and loader will do the
> right thing... this will not use heap nor data space.

That's exactly what I want to happen.  However, the compiler I'm using
right now won't do this!  "test" will end up in data space.

> For a limited data type, I bet we can make an
> awk/sed/perl script (these are supported on most platforms I believe)
> to translate your data tables into C/C++ code that will do the right thing
> on all platforms.

The "data compiler" that I would like to use has a syntax almost the
same as C data initialization.  A script to change it to real C should
be trivial.  However, the pseudo-C will be filling in lots of fields
automagically for me.  I think I know of a way to "retrieve" those
fields for the true-C version.

> | The data is static.  The program will never change it.
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  => const ??

Yup.

> | The data might eventually grow to > 64K.
> 
> Under what OS would that be a problem?

Heh!  The very OS I'm developing on!  (See above.)  I'm currently
compiling for the Macintosh 680x0 runtime which inherited the data space
setup I mentioned above.  The data space can actually be bigger than 32K
(or 64K), but this requires making the compiler/linker/libraries jump
through lots of hoops.

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/


----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org