Hi Kevin, > I am wondering if these two definitions are logically equivalent. LOGICALLY? Yes. IMPLEMENTATION-WISE? No. > Is the gnu c++ compiler smart enough to initialize these tables at > compile-time or are they actually initialized after the data is copied into > ram? The GNU C++ compiler is not "smart enough" to initialize these tables at compiler-time, because it CANNOT initialize these tables at compile times. The table is being initialized from the results of calling a function (the sConstruct constructor function). Such a function call might be inlined, but it still won't be executed during compile-time. > Background: I am writing some boot code that has the task of configuring > and initializing some SDRAM. The boot code has a limited amount of SRAM to > play with. Since these tables are constants I would like to store them in > ROM. > How do I force the linker to put them in ROM? Depends on your platform. Doing the const sAggregate table1[] should be adequate to make the table marked as read-only (assuming your platform supports that). But depending on your platform, you may need to use __attribute__ to put the data in a section that is designated to be loaded in a special way. Or if you are creating an image intended to be burnt onto a ROM (PROM, EPROM, whatever), you'll likely need to finesse GCC to tell it exactly what you want it to do. (I assume you have an assembly background suitable for your target platform, and as such are approaching GCC as a nice "macro assembler". I can do that for C, but have a much harder time conceptualizing C++ as a macro assembler wrapper.) > How do I ensure that the table is initialized? Look at the assembly code produced by the compiler. Use the -S switch to produce a .s file. Use -fverbose-asm to annotate the assembly code with lots of compiler comments. HTH, --Eljay
