Not sure exactly what you mean by the "hardware support" part, unless it is machine instruction support of some kind for C syntax. (But I thought that a basic level of support for that was present in most processors - things like base + offset addressing mode, indirect addressing via the value in a register, etc.)
But:
a[i] is equivalent to star(a + i) in C. (The K&R book says so somewhere, in either the original or the ANSI C edition.)
And star(a + i) is equivalent to star(i + a), by commutativity (a mathematical property) which is equivalent to i[a]. [1]
So you can write any of the above 4 expressions equivalently. I verified it by writing and compiling such code after reading this in the K&R book years ago; still remember being surprised until I saw the logic made sense.
[1] Or at least, it was so, some years ago, not sure about in C99 and such.
I used "star" instead of the asterisk symbol in code above because the actual asterisk turned following text to italics - HN markup.
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).
I firmly believe that book will teach you every bad habit you should never use in actual practice. 30 years ago, many of those "tricks" made sense given the compilers and computers of the time, but today your much better just writing straight clean C (for example using array indexes instead of pointers). Not only because its more maintainable, but because it often generates more efficient code due to hardware support for base+displacement addressing and compilers abilities to understand the intent and optimize the resulting code. Furthermore, code like what you find in that book is what has given C a bad name due to buffer overflows and the dozens of other things people think are the fault of "C" rather than the programming environment around it. Not the least of which is a formatting scheme that hides bugs.
So, PLEASE, if you are learning C, stay as far away from the K&R book as you can until you have gained enough proficiency to understand the pitfalls of may of the techniques taught in that book.