> Not sure exactly what you mean by the "hardware support" part, Yes I should have been clearer, and said no penalty or minimal penalty, support for base+offse

> Not sure exactly what you mean by the "hardware support" part, Yes I should have been clearer, and said no penalty or minimal penalty, support for base+offset address calculation. A fair number of machines a couple decades ago, had additional latency or throughput penalties for addressing modes that required address calculation. This is still true in some cases for more complex calculations. So the use of pointer arithmetic was in many cases noticeably faster than using array syntax even though they are functionally the same. This was also partially due to the compilers not being smart enough (or not having enough registers) to dedicate one explicitly for the resulting address (and using register indirect) if the programmer was using a base[offset] calculation. For example, the ARM I'm using at the moment has a 1 cycle latency penalty for certain scaled displacements. This means that if your looping over an array of 16 bit ints it will be faster to use a pointer to the integers if the compiler fails to increment the index by 2 and instead uses a (base+offset * 2) load/store. This means the compiler has to be fairly smart about code that uses the index's absolute value as well as its "offset" value in an array. (BTW the particular ARM in question does base+offset*4 or 8 at full speed).