accessing byte arrays with word and long datatypes

Peter Verkaik

If I pass a byte address to a method, does
word[noparse][[/noparse]address] := value & $FFFF

do the same as
byte[noparse][[/noparse]address] := (value & $FF)
byte[noparse][[/noparse]address+1] := (value >> 8) & $FF

or does it do
byte[noparse][[/noparse]address*2] := (value & $FF)
byte[noparse][[/noparse](address*2 + 1] := (value >> 8) & $FF

In other words, is the index used with word[noparse]/noparse and·long[noparse]/noparse used as byte index,
or as word index or long index?

regards peter

Nick Mueller

> In other words, is the index used with word[noparse]/noparse and long[noparse]/noparse used as byte index,
> or as word index or long index?

In SPIN, the address is always in bytes. No matter wether you took the address of a byte, word or long.
[noparse][[/noparse]Edit]
Unlike in C, SPIN is not type-aware when dealing with pointers. In C, you could increment a pointer to int32 by one and it points to the next int32. In SPIN, you have to add the size of an element (1, 2, 4).
[noparse][[/noparse]/Edit]

Multiplying an address is almost never a good idea. The pattern is "address + offset".


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Post Edited (Nick Mueller) : 12/18/2007 2:08:51 PM GMT

Peter Verkaik

So it is the first variant. even if address is not even (eg. word aligned)?

regards peter

CardboardGuru

Peter Verkaik said...
So it is the first variant. even if address is not even (eg. word aligned)?

WORD[noparse][[/noparse]address] will only read/write from word aligned addresses. The least significant bit of the address is ignored.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Peter Verkaik

So
word[noparse][[/noparse]address] := value
really means
byte[noparse][[/noparse]address & $7FFE] := value & $FF
byte[noparse][[/noparse]address | $0001] := (value >> 8) & $FF

and for longs, I assume the 2 least significant bits in address are ignored?

regards peter

CardboardGuru

Nearly. You're being slightly too clever with the bit mask. WORD[noparse][[/noparse]address] will read from ROM too. And WORD[noparse][[/noparse]$8000]:=$FF will fail to write to the ROM, not overwrite location $0000.
So it's:

byte[noparse][[/noparse]address & $FFFE] := value & $FF
byte[noparse][[/noparse]address | $0001] := (value >> 8) & $FF

Yes, LONG ignores the least significant 2 bits.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Peter Verkaik

Thanks. Now I know I must split up my code
as address may or may not be word/long aligned.

regards peter

deSilva

Using byte numbers is common with other architectures.
The Propeller RAM (and ROM) is 32 bit however, same as the COG memory. A "true" address is always the number of a LONG. The two LSBs of what you always think is an "address" are secondarily (!) used to extract a byte or "word" if required. This is terribly expensive, and I still wonder how Chip has accomplished this in two ticks....