byte/word/long boundarys ?

Don Pomplun

Suppose I define a table in a DAT area thusly:

DAT
Head byte 0
Tail byte 0
Buf long 0[noparse][[/noparse]20]

If I then pass a pointer to the table ( i.e. @Head ), to a new method as HeadPtr, I envision getting bit (if not careful) by boundarys.
I can read Head & Tail like this:
H := byte [noparse][[/noparse]HeadPtr]
T := byte [noparse][[/noparse]HeadPtr]
But since the rest of the table is Longs, I'll speculate that there are 2 bytes unused between Tail and the beginning of the Longs(?)

To access the first Long in the table it seems that I would use:
N := long [noparse][[/noparse]HeadPtr]
Am I getting it?

TIA
-- Don

Mike Green

Don,
Yes, the compiler will guarantee that Buf is indeed on a long word boundary by adding 2 bytes between Tail and Buf. To access the first long in Buf, do "long[noparse][[/noparse]HeadPtr+4]" since the first long (index zero) consists of Head/Tail/padding. To access the k'th long (zero relative) do "long[noparse][[/noparse]HeadPtr+4][noparse][[/noparse]k]".
Mike

Tracy Allen

Also, if it happens that the argument that is not a multiple of 4, the compiler will round down to the nearest multiple of 4.
long[noparse][[/noparse]headPtr+5]
will round down to
long[noparse][[/noparse]headPtr+4]
and for absolute addresses,
word[noparse][[/noparse]$E001] ' in the HUB rom, sine table
will round down to
word[noparse][[/noparse]$E000]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Don Pomplun

"Yes, the compiler will guarantee that Buf is indeed on a long word boundary by adding 2 bytes between Tail and Buf. To access the first long in Buf, do "long[noparse][[/noparse]HeadPtr+4]" since the first long (index zero) consists of Head/Tail/padding. To access the k'th long (zero relative) do "long[noparse][[/noparse]HeadPtr+4][noparse][[/noparse]k]".


I was waiting for a correction to the above, but I guess it isn't coming ;=)

HeadPtr points to an absolute address, regardless of byte/word/long (?)
Buf starts 1 Long = 4 bytes offset from HeadPtr.
So I would think that the first Long entry in Buf would be long [noparse][[/noparse]HeadPtr]
Since this statement is only dealing in Longs, I would think that HeadPtr+4 would take me 4 Longs past HeadPtr.
(?)
-- Don

Mike Green

Don,
The square brackets that follow BYTE/WORD/LONG are not quite subscript brackets. The LONG[noparse]/noparse syntax treats the value in the brackets as a byte address. I think Tracy is wrong in that the compiler doesn't look at the value at all. It just generates code to compute it. I know (from Chip) that the RDLONG/WRLONG instructions ignore the lower two bits of Hub address given which effectively rounds down to the nearest long word boundary. The RDWORD/WRWORD instructions similarly ignore the lower bit of the Hub address given which effectively rounds down to the nearest word boundary.

If you give a second set of square brackets after the BYTE/WORD/LONG[noparse]/noparse, the value given is a true subscript. You could write "LONG[noparse][[/noparse]HeadPtr][noparse][[/noparse] 1]" to access the 2nd long word in the work area which would be the first long word in Buf.

I hope this has cleared things up a little.
Mike

Post Edited (Mike Green) : 1/30/2007 6:55:02 PM GMT

rokicki

Correct. The computations are as follows:

byte[noparse][[/noparse] a ] -> accesses byte at address a
word[noparse][[/noparse] a ] -> accesses word at address (a & ~1)
long[noparse][[/noparse] a ] -> accesses long at address (a & ~3)

byte[noparse][[/noparse] a ][noparse][[/noparse] b ] -> accesses byte at address a + b
word[noparse][[/noparse] a ][noparse][[/noparse] b ] -> accesses word at address (a & ~1) + 2 * b
long[noparse][[/noparse] a ][noparse][[/noparse] b ] -> accesses long at address (a & ~3) + 4 * b

You can also use the @ operator (although this won't truncate bits) so if you want to
compute

c := a + 4 * b (7 bytes of spin)

a "faster" way to do it might be

c := @long[noparse][[/noparse] a ][noparse][[/noparse] b ] (4 bytes of spin)

Of course you must really be desparate for space in order to perform such obfuscation.