Lockset/Lockclr and par

ksltd

The ID of the lock for the Lockset/lockclr instructions comes from the destination register. Using a "read only" register as a destination register usually doesn't work. In the follow examples, if par contains a 3, do these instruction operate on lock 3 or lock 0?

lockset par
lockclr par

kuroneko

par as source can never contain 3. I never bothered to determine whether - despite destination slot being used - source or shadow are used. My guess would be shadow.

Update: the shadow register is indeed being used as the parameter.

So to answer your question, unless shadow[par] changed you get lock #0.

msrobots

I never grooked why par is restricted like that.

Sure nulling the last two bits makes sure a address passed thru par is long aligned. But I do not always want to pass a address thru par.

So why is that so? @Chip usually has some reason behind what he does.

Curious!

Mike

tonyp12

> But I do not always want to pass a address thru par.

You can send a 30bit value
just <<2 it first and then >>2 at the receiving end

msrobots

tonyp12 wrote: »

> But I do not always want to pass a address thru par.

You can send a 30bit value
just <<2 it first and then >>2 at the receiving end

Sure, I do, but why do I need to? par ends up in a cog long register. Why just 30 bit? There is some reasoning behind it I guess.

Still Curious!

Mike

altosack

PAR is a parameter to COGINIT (PASM), in which the destination is a single long comprised of PAR (bits 31-18), code address (bits 17-4), and COGID (bits 3-0), so while you can <<2 / >>2 to send something other than a long address, there are only 14 bits available, not 30.

tonyp12

>there are only 14 bits available, not 30.

Right and that must be the answer
the address is >>2 (internally) as to give 64KB address space as that is more important than getting us precise byte address.

msrobots

tonyp12 wrote: »

>there are only 14 bits available, not 30.

Right and that must be the answer
the address is >>2 (internally) as to give 64KB address space as that is more important than getting us precise byte address.

@tonyp12 and @altosack,,

yes. Now it makes sense to me. Instruction encoding. No bits left. Hindsight is easy.

stupid me!

Mike

msrobots

kuroneko wrote: »

...So to answer your question, unless shadow[par] changed you get lock #0.

Du immer mit den Shadow Registern. Kaum glaube ich was zu verstehen, kommt eine schwarze Katze daher und verwirrt mich.

As far as I know par is read only. Now comes that black cat again stating that - unless the shadow register has changed - lock#0 will be used.

#kuroneko always does things like that.... mov cnt, cnt ... for example

Just to confuse me.

So is par read only or not? Can I shift par in PASM and access the shifted value later? Or can't I?

Mike

tonyp12

>So is par read only or not? Can I shift par in PASM
The real PAR is read only (a good thing as if it get scrambled the cog have no way to reset it)
The Destination side (shadow) is the one that is writable.
mov par,par
shr par, #2 is OK
But there is limit what can you do with shadow par, you could use it for test cmp waitcnt etc instructions, but you could never read it.

msrobots

tonyp12 wrote: »

>So is par read only or not? Can I shift par in PASM
The real PAR is read only (a good thing as if it get scrambled the cog have no way to reset it)
The Destination side (shadow) is the one that is writable.
mov par,par
shl par, #2 is OK
But there is limit what can you do with shadow par, you could use it for test cmp waitcnt etc instructions, but you could never read it.

Thanks @tonyp12,

I think here is where my knowledge is leaving me. The concept of shadow registers. What are they there for and how to use them properly.

So if I get this right now - some (all?) of the special registers deliver different results if used in the destination part of a instruction compared to the source part of the instruction? This is where @kuroneko always gets me in his examples. Other code too. I am fairly fine with Spin and PASM. But them shadow registers just go over my head. I miss some basic information here, I guess.

more input,

please.

Mike

LoopyByteloose

I may be wrong, but I suspect 'shadow registers' are not really duplicate registers in any physical sense.

The so-called true register in the Cog map is just hardwired to some specific functional purpose and is not completely under the control of the Cog -- thus read only.

msrobots

Back to OPs question. Providing the lock number right shifted by two, to avoid truncation...

So I guess

mov par, par
shl par, #2
lockset par
lockclr par

will still not work.

@ksltd you need a cog register I guess.

mov locknumber, par
shl locknumber, #2
lockset locknumber
lockclr locknumber
...
locknumber res 1

kuroneko

msrobots wrote: »

Back to OPs question. Providing the lock number right shifted by two, to avoid truncation...

mov par, par
shl par, #2
lockset par
lockclr par

Did you mean (cognew(@entry, ID << 2)):

mov     par, par
[color=red]shr     par, #2[/color]
lockset par
lockclr par

kuroneko

tonyp12 wrote: »

But there is limit what can you do with shadow par, you could use it for test cmp waitcnt etc instructions, but you could never read it.

You could always write it to hub though ...

Phil Pilgrim (PhiPi)

Actually, you can read the shadow register:

        mov     mask,#1
loop    test    par,mask wc
        rcr     subpar,#1
        shl     mask,#1 wc
  if_nc jmp     #loop

... or ...

        mov     count,#32
loop    ror     par,#1 wc
        rcr     subpar,#1
        djnz    count,#loop

-Phil

tonyp12

> special registers deliver different results if used in the destination part of a instruction compared to the source part of the instruction?

Yes.
You have 512longs RAM as the base for the cog to use.

Special Read-Only registers, when its address is on the source side it goes not to the ram but muxed away to special hardware.
It makes sense that the counters are not writing to ram but to their own flipflop and latches.

PAR is not a counter, but due to keeping it safe it is also stored in a special source side latch. (or it could be that coginit hardware could not pass in on to ram?)

There is no Shadow Register (destination side), you are just getting the RAM as usual.

It's the compiler that let you substitute $1F0 with the word PAR, it does not care that you use that word on the destination side.
I would make the complier force you to use the word sPAR sCNT etc for destination side. (little to late now)

PHSx is a little different, as this counter can be reset to a value you supply, when you write to it behaves like it was a single location.
RAM and PHSx both get set to this value, but like all counters it's only PHSx source side that start ticking away once the counter is running

>Actually, you can read the shadow register:
There is always a way
Like on a C64's 6510 you can not read address 0 and 1, but video hardware can and if you move a single pixel sprite over it you can read the collision-register one bit at a time.
There should never be a need to read shadow register, should only use it as a free long if we are OK with it being on destination side only, if not don't use it
Using it for WRxx is the exception, as with this quirky instruction the destination side is the value you are sending to hub (e.g you are reading it)

Dave Hein

So you could read a shadow register as follows:

    wrlong par, scratch
    rdlong subpar, scratch

scratch would contain the address of a long in hub RAM that would be used for temporary storage.