Question for PASM Guru

RS_Jim

I am a bit unsure about the correctness of the following asm instructions:
[code]
if_z movi lable1,#%0010_0100_1 'rol
if_nz movi lable1,#%0010_0000_1 'ror

[code/]
Have I interpreted the book correctly? and yes there are interveining lines of code before the instruction is exicuted.
Jim

kuroneko

RS_Jim wrote: »

I am a bit unsure about the correctness of the following asm instructions

Why is that? But yes, those two are rotate left and right. Maybe writing them like %001001_001/%001000_001 makes them easier to read/figure out.

FWIW, if those two are the only instructions ending up there you could also use a muxz and just un/set bit 26.

tonyp12

Looks correct.
This is an example where muxz could come in (though would still use up two longs)

replace those two lines with this:
muxz lable1,_bit26

_bit26 long |<26

RS_Jim

Kuroneko and tony,
I never thought to use MUXZ! Yes those are the only two instructions that end up at that lable.Code it as ROR and use muxz bit 26 to make it ROL. Thanks for the pointers.
Jim

tonyp12

Jim I'm pretty sure you mean in general you will have to code it as a ROR and muxz will change it if z=1

Muxz is not doing a 'or' (or 'andn'), as a long streatch maybe you can say it's doing one of them based on z

So you can either code lable1 it with rol or ror, it does not mater
Unless you come to this part of the code first and you want a default state.

muxz lable1,_bit26 will change it to ror/rol each time this line is run independent of that the lable1 was already a ror/rol

RS_Jim

Tony,
I was making some notes prior to coding and I realized that, yes I need to hard code it to ror and then at the end of the routine, before exiting back to the calling code, I will have to code in an andn lable,b_26 to return the code to ror for the next time the routine is called. I will use the shl intruction in my set up routine at the begining to establish b_26.I am not sure if I will be usint MUXZ or MUXNZ until I actually start coding.
Jim

tonyp12

If you want a 3st state: ror-nothing-rol

Example:
code wc
muxc lable1,_confield {turn it in to a NOP or back to non-NOP}

_confield long %1111<<18 {adjust it if you use a if_ x at lable1} or auto adjust it before cognew by: _confield := lable1 & %1111<<18 {'<<' has higher priority}


Or you could just turn the intermediate value at source in to a zero (example ror dest, #1)
this will make it a NOP in its behavior: muxc lable1,#%000000001

You don't have to turn value in to a zero, if you want 3 in to 1 vs 1 it to a 3: mask = %10
Values that change two bits in opposite directions like 2 to a 1 can not be done with a single mux,
in those cases might as well use:
if_c movs lable1, #1
if_nc movs lable1, #2

RS_Jim

Tony,
At the moment, I have no reason to tristate the instruction. My thought was to hard code the ROR instruction. Next in a set up that invokes the loop containing the ror/rol instruction code the MUXZ b_26 instruction to change it to ROL. Next, when I exit the loop use ANDN b_26 to turn the instruction back to ROR. This being done, the next time I envoke the loop, the process then makes the decision of ROR or ROL again before invoking the loop. In my mind using MUXZ to toggle the bit at the end of the loop requires an extra step and is confusing to this old brain. It seems to me that the ANDN instruction to turn the bit off is the better way to go. Agree/disagree?
Jim

kuroneko

RS_Jim wrote: »

My thought was to hard code the ROR instruction. Next in a set up that invokes the loop containing the ror/rol instruction code the MUXZ b_26 instruction to change it to ROL. Next, when I exit the loop use ANDN b_26 to turn the instruction back to ROR.

As Tony hinted at already, there is no need to turn back the instruction to ror. The muxz will take care of that for you. Another way of looking at muxz is:

muxz location, mask     ' Z: 0, andn location, mask
                        ' Z: 1, or   location, mask

Which in turn means that the following is true:

muxz insn, b_26

current           next

  ror  ' [COLOR="orange"]Z: 0 --> ror[/COLOR]  -
       ' [COLOR="blue"]Z: 1 --> rol[/COLOR]  swap direction

  rol  ' [COLOR="orange"]Z: 0 --> ror[/COLOR]  swap direction
       ' [COLOR="blue"]Z: 1 --> rol[/COLOR]  -

IOW, Z = 0/1 will always produce ror/rol regardless of what was selected before. HTH

RS_Jim

Kuroneko,
got it! thanks for the explaination of muxz as andn,or . I eliminate a step and always endup with the state of ror/rol that matches the input data!
Jim