RDCOG/WRCOG instruction - is it possible?

Peter Jakacki

It seems that there is no simple instruction to read indirectly from cog memory as we can with RDLUT/WRLUT for LUT memory and RDLONG/WRLONG etc for hub memory. Of course we can use SETS/SETD plus a two instruction delay or else use the awkward ALTDS instruction but either way none of these are clean and simple or efficient.

What is really begging is a RDCOG and WRCOG instruction which can use a register as an indirect register.

@Chip: is it possible and practical to include those instructions in P2?

Roy Eltham

ALTDS is clean and efficient.

Peter Jakacki

Roy Eltham wrote: »

ALTDS is clean and efficient.

Your terse statement is quite contrary to what I have stated but also does not answer the question (is it possible?) neither does it demonstrate how you have come to your conclusion.

evanh

Potatohead made an attempt to explain that ALTDS is already the fastest solution (For the current architecture), and more flexible to boot. Basically, two instruction timing slots would be needed even if it was a single instruction.

Alternatively, I think, a longer pipeline would be needed ... just for indirection.

Peter Jakacki

Well I'm guessing nobody really knows much as of yet then as I still have not seen many examples of where it is clean and efficient but I threw this question out there not in ignorance of ALTDS or the pipeline but more out of my dislike of such an awkward instruction which seems at odds with the rest of the instruction set. It will not be apparent from the coding of the fields as to what the instruction is doing unless you refer back to the "manual". I mentioned that at the very least it was in need of some macros which would help a little in that regard.

It's just that I have written a mountain of code for the P2 and this one instruction and the lack of the other really stands out. Well, maybe I will change my mind but that's my feelings about it at this point anyway.

ozpropdev

I think a RDCOG/WRCOG would require an additional instruction cycle clock to squeeze in the additional cog ram access.
While I agree that ALTDS is a little awkward it more than compensates I think in its efficiency.
Foe example

'copy 16 cog regs from .src to .dest

copy_cogram	mov	.myreg,##.dest << 9 | .src
		rep	@.copy_end,#16
		altds	.myreg,#%000_111_111
		mov	0-0,0-0
.copy_end	

Nice and compace and efficient.
Perhaps Pnut can be enhaced later on with some additional syntax tweaks to allow easier config of the ALTDS modes.

Peter Jakacki

If the source field does indeed change the behaviour of the instruction then maybe we just need aliases for these "instructions". I just don't know about some of you guys and while I am very used to machine code bit twiddling I am not loving ALTDS, it's a beast.

cgracey

ALTDS is a bit of a beast, bit it does completely handle indirection and pointer incrementing/decrementing.

Given the pipeline architecture, ALTDS is probably about as efficient a mechanism as can be expected.

jmg

Peter Jakacki wrote: »

If the source field does indeed change the behaviour of the instruction then maybe we just need aliases for these "instructions". I just don't know about some of you guys and while I am very used to machine code bit twiddling I am not loving ALTDS, it's a beast.

ALTDS is a low level patch, and I agree needs mnemonics for what would become 64 bit opcodes.

In an ideal environment, mnemonics would be generic and smart enough to select the smallest form, but that needs multi pass and an intelligence level not yet in the tool chains.
Generic, as well as explicit small/large names, could be defined now, and the improvement applied over time.