Help with non-blocking delay

[apostolakisl]

I don't see why that would be true.  ORB 0xFFFFFFFF 0 VAR1 should set VAR1 to -1.
 

PACKOPS:
    ANDB VAR1 0xFFFFFF00 VAR1
    ORB VAR1 OP1 VAR1
    ROTL OP2 1 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP3 2 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP4 3 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP5 4 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP6 5 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP7 6 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP8 7 RAM1
    ORB VAR1 RAM1 VAR1
RET
 

 
I didn't personally test it.  But I asked tjf to run 0xFFFFFFFF and it didn't work per his report.  Have you tested it?  It logically doesn't make sense since the actual number it represents is 4294967295, not a negative number.  You would need to use two's compliment math to get it to work.

 

[rossw]

0xFFFFFFFF and it didn't work per his report.  
 
It logically doesn't make sense since the actual number it represents is 4294967295, not a negative number.  You would need to use two's compliment math to get it to work.

 
A great many things assume if the MSB is set the number is negative (ie, MSB is often called the "sign bit").

 

[apostolakisl]

The "Absolute Value" program I wrote should have worked in that case.  While I didn't load into one of my CAI's, according to TJF it didn't work on his.

 

[az1324]

 
I didn't personally test it.  But I asked tjf to run 0xFFFFFFFF and it didn't work per his report.  Have you tested it?  It logically doesn't make sense since the actual number it represents is 4294967295, not a negative number.  You would need to use two's compliment math to get it to work.

Represents is relative. Type it into windows calc then convert to decimal. 4294967295. But wait that is assuming it is stored using a 64bit signed value. Click on dword.
 
4294967295 (uint32) = -1 (int32) = 0xFFFFFFFF
 
The bits are always the same just when it's converted to ascii it is either taken as signed or unsigned.
 
When you say SET VAR1 -1 then the decimal number is converted to 0xFFFFFFFF before it is stored.  But if you say SET VAR1 0xFFFFFFFF it is stored as that exact binary value.
 
Instead of thinking of the MSB as a sign bit flag you have to think about it as the top half of the range is negative.  But for continuity those are shifted down to be right before zero.
 
In base10, if we started out with [0-42967295] and then split that in half we get [0-2147483647] & [2147483648-4294967295].  Now we don't want to move zero, so we say the top half are going to be negative values.  But when we add 1 to 4294967295 in binary math we get 0 so that has to be -1.  So now on a traditional number line we would have [2147483648-4294967295][0-2147483647].

 

[TJF1960]

The "Absolute Value" program I wrote should have worked in that case.  While I didn't load into one of my CAI's, according to TJF it didn't work on his.

I am sorry, I am confused. What is the absolute value program and when did I run it?

 

[apostolakisl]

I am sorry, I am confused. What is the absolute value program and when did I run it?

 
My bad, it was saifu.

 

[TJF1960]

haha, whew. I thought I was losing my mind!

 

[apostolakisl]

I just put one of my boards online.  Indeed you can set the 32 bit.
 
The reason the absolute value program didn't work is because I did the 2's compliment wrong.  I was hoping for a single line of code way to execute an absolute value of a number, but I don't think it can be done.

 

[TJF1960]

PACKOPS:
    ANDB VAR1 0xFFFFFF00 VAR1
    ORB VAR1 OP1 VAR1
    ROTL OP2 1 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP3 2 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP4 3 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP5 4 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP6 5 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP7 6 RAM1
    ORB VAR1 RAM1 VAR1
    ROTL OP8 7 RAM1
    ORB VAR1 RAM1 VAR1
RET
 

 
az1324, Thank you for the example. I am still working on understanding it, and I am getting there thanks to you guys.
 
When I code this up and test it, it was doing some weird things.
Turning op1 on var1=1  expected
turning op1 off var1=0   expected
turning op2 on var1 =2  expected
turning op2 off var1 =2  ? not expected
turning op1 on var1=3   ?
turning op1 off var1=2   ?
turning op6 on var1=34 ?
turning op6 off var1=32 ?
turning op2 on var1=34 ?
 
After looking at the code it looked like ram1 values were being reused and not being reset. Using the code as is but adding "set ram1 0" at the beginning of the subroutine seemed to correct var1 output. Would this be an acceptable way or is there a better way.
 
Also if I may ask, why is var1 bits 9-32 set to 1 and not just all 0's at the beginning of the subroutine, just curious?
 
The last question I have is if I want to pack all the input values into this same sub, I would change 0xFFFFFF00 to 0xFFFF0000 then increase the ROTL incrementally correct? Like ROTL IP1 8 RAM1....

 

[az1324]

That is strange that RAM1 is not cleared when storing the result of a ROTL with an output value.  Manually clearing it is fine.  VAR1 bits 9-32 are not set to 1, their value is preserved.  Yes you are correct on the rest.

 

[TJF1960]

Hi Tim,
 
Bitwise is not too hard.  Basically, you decide which bit position represents which state.  Say you have 8 emails, using bit 8-15 to represent them.  You will first get each bit value using scientific mode X^y:
2^8 = 256
2^9 = 512
...
2^15 = 32768
Say you have VAR8 to store the flags, to check email 1 sent or not on bit 8, you can do:
ANDB VAR8 256
You don't have to store the result, since ANDB will update the zero bit.  If you use zero meaning "email not send yet", then
BZ sendmail1
...
BZ will jump to the sendmail1 section code to send email. You could in that
section do a
XOR VAR8 256 VAR8
to update that bit 8 on VAR8.
 
You can use RAM instead of VAR. VAR has one advantage during debugging, you can see on screen then put that value into calculator programmer mode, change the display to binary, you can see immediately which bit is set.
 
You can use CZ instead of BZ for call the subroutine, which will return back to next line of your code after the subroutine finished.

 
I am trying to set a flag on var3 bit 8 when a subroutine has run but it keeps running the subroutine, I expected the sub to run once only. I must have mis understood the above comments.
So
1) what am I doing wrong.
2) will non-block delay work with bitwize?
 
START
   ANDB VAR3 256
   BZ IO
END   
IO:
   XOR VAR3 256 VAR3
   ADD VAR4 1 VAR4
RET
  
 
 
 
Thanks,
Tim

 

[az1324]

LOOP:
   ANDB VAR3 256
   CZ IO
   GOTO LOOP
END   
IO:
   ORB VAR3 256 VAR3
   ADD VAR4 1 VAR4
RET

 

[TJF1960]

Thanks az1324, that made all the difference in the world!
 
If using var3 bitwise as a number of flags is there a way to use non-blocking delay on each bit seperately? In other words set bit 1 to 1 for 2 seconds then revert back to 0...without affecting the non-block delay of the other bits?

 

[apostolakisl]

Thanks az1324, that made all the difference in the world!
 
If using var3 bitwise as a number of flags is there a way to use non-blocking delay on each bit seperately? In other words set bit 1 to 1 for 2 seconds then revert back to 0...without affecting the non-block delay of the other bits?

 
I haven't tried it, but according to the manual you can use non-blocking delay on the output of all the bitwise operators.
 
From the manual:
 
ANDB a[] b[] (d[]) Bitwise AND's a with b and optionally puts bitwise AND 
result into d. Zero bit updated. 
OR a[] b[] (d[]) Logical OR's a with b and optionally puts Boolean result 
into d. Zero bit updated. 
ORB a[] b[] (d[]) Bitwise OR's a with b and optionally puts bitwise OR result 
into d. Zero bit updated. 
XOR a[] b[] (d[]) Logical XOR's a with b and optionally puts Boolean result 
into d. Zero bit updated. 
XORB a[] b[] (d[]) Bitwise XOR's a with b and optionally puts bitwise result 
into d. 
 
The [] indicates non-blocking delay function works for input values on the bitwise operators and output values.  I doubt the zero bit reverts.

 

[az1324]

without affecting the non-block delay of the other bits

 
no you can't have a separate delay for each bit.