Inconsistent SPIN addressing scheme with BYTE[@...]?

FMMT666

Simple question:
I hacked this in a few weeks ago and it is working perfectly.

But why? ;-)

VAR
  word  rawSens[3]
  byte  tmpBuf[6]


PUB Blabla

  ...

  repeat i from 0 to 5
    byte[tmpBuf][i] := i2c.read_byte( TRUE ) 
  
  ...

  word[@rawSens][0] := ( byte[tmpBuf][0] << 8 ) + byte[tmpBuf][1]
  word[@rawSens][1] := ( byte[tmpBuf][2] << 8 ) + byte[tmpBuf][3]
  word[@rawSens][2] := ( byte[tmpBuf][4] << 8 ) + byte[tmpBuf][5]

As you hopefully may have noticed, there are no "@"s in front of "tmpBuf".

Initially "tmpBuf" indeed was a LONG variable, containing the address of a buffer,
but later on, I replaced it with the solution you see above and forgot to change the code.

Why is this working?
Is the BYTE[@...][...] notation only defined for DAT sections
and my success is based on pure luck?

Leaving out the "@"s in front of "rawSens" does not work
(same for putting in "@"s in front of "tmpBuf...), so there has to be a difference
or inconsistence.


Am I overlooking something?
Thanks for any hint on this...

*confused*

===
P.S.:

Yes, I am aware that I can just write

  repeat i from 0 to 5
    tmpBuf[i] := i2c.read_byte( TRUE ) 
 
  ...

  rawSens[0] := ( tmpBuf[0] << 8 ) + tmpBuf[1]
  ...

but I like to know what's wrong with the byte[@...] notation.

kuroneko

tmpBuf is equivalent to tmpBuf[0], IOW whatever byte value is in there at the time you start using it (e.g. byte[tmpBuf] := ...) determines the address which gets overwritten. For example, starting with 0 you'd corrupt the clkfreq location ...

MagIO2

Just for saying it in slightly other words:
It currently works, but it does not do what you expect it to do!

It is NOT using the buffer tmpBuf! It writes into the location where tmpBuf POINTS to. It simply works because you use the same at the place where you write into the buffer and where you read the buffer and because by good luck you did not overwrite something important so far.

Using @tmpBuf should work (and is the right thing to do!) as long as you use it in both locations (the write loop and the read-block).

Nothing is wrong with byte[@tmpBuf][...]!

FMMT666

Oh yes, of course! *facepalm*

Thanks for getting me back on the track...

---
BTW:
This also solves another problem with - well - the usage
of the CLKFREQ register )