Good way to do table indexing?

ManAtWork

I need a state machine to handle the auto-calibration of multiple ADC pins. I plan to use a table where the pin modes (ain/gio/vio switching), source/destination indexes for calculations, duration and next state and possibly some skip masks to influence behaviour of the code are stored for each of the states.

As I don't have much experience coding in P2 assembler I wonder what could be the best way to handle indexing of the pins and table data. As I have to iterate both through the table entries and through the pin numbers I need some sort of double indirection for some operations.

I've seen there are the ALTS/D/R instructions for that purpose. I think I could place the table in hub RAM and do a burst transfer (SETQ+RDLONG) to read the table entries to variables in cog RAM whenever the state changes. Then, once per sampling period I coult iterate through the pin numbers. Unfortunatelly, due to hardware constraints the pins don't have consecutive numbers so I have to use a second table. This would result in almost every instruction in my loop having at least one preceding ALTS/D instruction. But the only alternative I see would be a hardcoded unrolled loop with almost identical code repeated 10 states * 6 pins = 60 times.

In spite of the name of the LUT RAM I think it's not suited very well for my purpose. I don't know if the RDLUT command supports indexing (PTRA[]...) as RDLONG/WORD/BYTE does. And the $200 address works for code execution only and not for data access if I read the docs correctly.

Has anybody already done something similar and could give me some advice?

ozpropdev

RDLUT/WRLUT does support PTRA/B indexing om Rev B silicon.

ersmith

In general COG RAM is more flexible for data accesses, so despite the names I think it's best to use LUT memory for code and COG memory for dat. IIRC RDLUT is slower (3 cycles) than MOV (2 cycles), so that's another reason to keep data in COG rather than LUT.

ManAtWork

Good to know. I'll try to code it and come back when it works or if I encounter problems.

BTW, doing both ALTS and ALTD on one instruction doesn't work, does it. The first ALTS would modify the source of the ALTD instead of the following instruction intended for the actual data transfer.

However, two consecutive ALT instructions could also be useful the way they work now. It could be used for adding three instead of two values (index1 + index2 + base address) for two dimensional arrays.

Wuerfel_21

ersmith wrote: »

In general COG RAM is more flexible for data accesses, so despite the names I think it's best to use LUT memory for code and COG memory for dat. IIRC RDLUT is slower (3 cycles) than MOV (2 cycles), so that's another reason to keep data in COG rather than LUT.

However, if what you're doing is accessing data between a pointed-to location and a register, ALTS+MOV is actually 1 cycle slower than RDLUT (and RDLUT can do the fancy PTRA/PTRB adressing modes). So it actually depends.

evanh

The v33(Rev changes for RDLUT definitely improved its livelihood. I hadn't paid RDLUT much attention until Roger was using it for his do everything display driver. It is longword only though.

evanh

ManAtWork wrote: »

BTW, doing both ALTS and ALTD on one instruction doesn't work, does it. The first ALTS would modify the source of the ALTD instead of the following instruction intended for the actual data transfer.

However, two consecutive ALT instructions could also be useful the way they work now. It could be used for adding three instead of two values (index1 + index2 + base address) for two dimensional arrays.

I think that has to be true. The ALTx prefixes do an early instruction field insertion rather than the later ALU operand insertion. They have no need and therefore no way to delay the changes the way some others can, like SETQ. On that note, the AUGx instructions must also have a special hidden register each.

Wuerfel_21

evanh wrote: »

I think that has to be true. The ALTx prefixes do an early instruction field insertion rather than the later ALU operand insertion.

Hmm, does that mean that

alts a,b
mul c,#0

means "c *= (a+b)&$1ff"? That sounds quite useful.

evanh

Yep, normal indirection use wouldn't have the #.