Can´t allocate multiple BYTE CONST tables

[julioc]

Hi,

I am using a 16F688 and I have a need for storing 64 tables of 17 bytes each one.
At first I tried to merge those 64 tables in single a big table like this:

BYTE CONST T_TMAP [64 * 17] =
{ /* ... */ };

But it didnt even compile, because the preamble code that the compiler automatically inserts to access table element can´t deal with more than 255 elements.
OK, then I tried to split the big table into 8 smaller tables, like this:

BYTE CONST T_TMAP0 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP1 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP2 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP3 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP4 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP5 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP6 [8 * 17] =
{ /* ... */ };
BYTE CONST T_TMAP7 [8 * 17] =
{ /* ... */ };

Well, it compiled fine, no errors or warnings, but... The compiler allocated adequately T_TMAP0 and T_TMAP1 in the ROM, but it simply didnt allocate T_TMAP2 .. T_TMAP7! It should have issued at least an error or warning!

I could notice that this line of my code:
return T_TMAP0 [index];
generates the following assembly table read call : "call 052"

return T_TMAP0 [index];
generates the following assembly table read call : "call 0DE"

and all the lines
return T_TMAPx [index]; // where x = 2, 3, ... 7
generate the same following assembly table read call : "call 0DE"
as if the 6 last tables were assimilated by the compiler to be identical to T_MAP1 !!

Please, folks, what am I doing wrong, or what workaround should I use to have those tables allocated ?
My compiler version is 3.235.

Thanks!

[Ttelmah]

The limitation on the size of constant arrays, is in the paper manual, but seems hard to find on the current electronic version.

Now I just generated a dummy set of tables like this. 8 in total, each with 136 elements. Tried with 'fixed' size declarations (array[136]), multiplication declarations (like yours, '8*17'), and no size declarations at all (the array will automatically be the size to hold the elements declared). All compiled correctly, and gave seperate tables, and access calls...
I tried with 3.234, 3.235, and 3.249.
Try not 'returning' the values, but instead writing them into a variable, and returning this. The compiler sometimes has this sort of 'oddity'...

Best Wishes

[julioc]

Well, I found what was happening. I am a little embarrassed I didn´t perceived it before.

In fact, I have those 8 tables of 136 bytes each one. But I am still collecting experimental data to fill all those tables. Only the first one has sound data. The other seven are preliminarily filled with zeroes.

The compiler (very clever) perceived that seven tables were of the same size and filled with the same data in the same positions and decided to allocate only one instance of table and make my function calls to the 6 last tables point to the second.

Well, the compiler did well his job of avoiding a waste of program memory, but I only wished it were a bit more friendly and issued a warning telling me of the tables "fusion"


Thank you, Ttelmah, for your help!

[Ttelmah]

That is rather brilliant!. Score one for the optimiser. :-)
Glad you have found the problem.

Best Wishes