PASM:RDBYTE,WRLONG # etc.

VIRAND

I just want to clear up some confusion about RD/WR+BYTE/WORD/LONG instructions specifically
when the 9-bit literal addressing mode would be used...

1.I assume that the 9-bit literal which usually addresses COG RAM is used to address HUB RAM with these instructions.
If So:
2.Are the first 512 bytes/words/longs "special" like the "zero page" of older microprocessors such as 6502, and if so:
A.What are they used for? (My assumption is that they are insignificant and probably contain the beginning of a SPIN app.)
B.Does the Spin interpreter or Compiler or Propeller logic or Anything Else reserve some of the first 512 addresses for its own use?
C.Does RDBYTE/WRBYTE address the same byte that RDLONG/WRLONG does, or does the latter address 512x4=2048 bytes as separated Longs?
D.Or, is the 9-bit literal addressing mode for these instructions just a simple artifact of orthogonality that is unintentional and of very limited usefulness?

Or am I thinking all wrong about this?

tonyp12

RD/WR using 9-bit literal is not used often as peek/poke at absolute addresses is not good programming.
You could readlong at hub address #0 to get the clckfreq value that is used for Spin.

As RDLONG ignore the lower two bits in address field, you can access the first 128 longs
or if rdbyte the first 512 bytes

kuroneko

@VIRAND: What's the final goal here? Chances are there is already another solution for your problem.

VIRAND

@kuroneko: Perhaps my question was too verbose but tonyp12's response lets me make it simpler...

Is the "WRLONG label1,#label2" instruction (and others like it) so limited as to be virtually useless, or when is it ever useful?
(This instruction can only access the first 128 longs of hubram which are usually occupied by the very beginning of a Spin app.)

kuroneko

VIRAND wrote: »

Is the "WRLONG label1,#label2" instruction (and others like it) so limited as to be virtually useless, or when is it ever useful?

As mentioned before, clkfreq (and clkmode) are usually accessed by absolute address (0/4). There are/have been block transfer implementations limiting themselves to the first 128 longs so an add $-1, d1s4 would work (block transfers can be from anywhere without penalty using indirect addresses, i.e. wrlong cog, hub). This however means that you have to relocate your SPIN program or use other means entirely (e.g. PASM only). I can't think of any other use right now except e.g. hardwired config/communication area access. Useful to a degree I'd say but too limited in general.

pjv

Hi All;

I use that area -that is hub from the end of the top object PUB definitions to hub $1FF- as mailboxes for rapid, direct access to to interface to PASM schedulers. The way it is set up, I can tranfer short bursts (up to 15 longs) from here to the scheduler very rapdily as the read/write D and S pointers in the scheduler can both be "incremented" with a single instruction by adding %1_000000100 to the instruction. Or, more eloquently as Kuroneko puts it, adding the constant D001S004. With the single instruction modifying the pointers, the transfer loop *just* hits the sweet spot of hub accesses, so no additional WAITs are encountered. Quite snappy really.

When making short bursts from/to that area, it speeds things up enough to make its use worthwhile. One does need to keep in mind however the beginning location of that space. Typically I define my TopObject as a NULL spin object, and reserve up to hub address $1FF with the DAT statement:

:code
DAT
Direct long 0[$80 - (Direct +$10]
:code/

That fills the balance of the directly accessible area up to $200 with zeros, and makes it inaccessible to Spin code.

Cheers,

pjv (Peter)

Cluso99

I use that as a vector decoding area in my faster spin interpreter. So there are some uses. But the P2 does not allow the immediate mode.

VIRAND

Ok, so RD/WR # is useful because it's limited accessible memory is easily protectable from Spin,
and it is used in a fast loop for transferring blocks to and from cogs,
because it fits nicely between hub access times due to incrementing it's S and D with a single instruction.
(which is more useful than only registering the clock mode)

Thank you very much.