Single Vs Multidimensional Arrays and the Pic

[Tom Jetland]

Hi,

Is there a reason to use a multidimensional array over a single other than just good readability of code? Are they stored differently in the PIC?

Also, I have read that when using a multidimensional array, it is better to increment the second set of elements more frequently than the first, i.e.

[asmboy]

The array you show in your example will use fully 3/4 of all the SRAM in an 18f4620 , whether it is used as shown or crammed into a single dimension of [3000]

Using dimensions of less than 256 will be faster to resolve than int16's.

BUT
having more than one dimension, and using variables as the element selectors will slow access, compared to a larger single dimension array with the same storage capacity. But again, in your example, its a choice of one int16 or two int8's ........

Depending on compiler optimization, using a defined constant for one of the dimensions in a specific function, "might" be faster than two vars as dimension "pointers" in run time. you would have to check the .LST file to see.

In your specific example - best optimization for your CCS version may well be " 6 of 1 , half dozen of the other".

I'd compile both ways and decide with the .LST file be my guide .

[Tom Jetland]

[Ttelmah]

There is always the penalty of multiplication.

If you have (for instance), an array of 20 * 4byte values, then the multiplication to find the location of a value is just *4, which is very efficient (done by shift). If you have a multi dimensional array with 'non binary' indexes (like 30), then you are multiplying by 30 (in the order you show), to 'find' the location in memory. Since the array is over 256bytes, this implies a 16bit multiply (not too bad on a PIC18 or higher). If you can keep the array indexes, or the product of indexes and element size, to a binary value, it saves both code space, and time.
Multi-dimensional arrays, with non binary indexes, made up of of odd sized structures, are 'worst' here....

[Tom Jetland]

Thanks once again for your input guys.

Tom