VLSR documentation
John Strawn

9/21/87

We are required to calculate B[n] = A[n] >> 1, with no sign extension. 
Nominally, the code from vneg and vasr can be used as a basis.  
But due to the limiting feature of the ALU, the vasr code cannot 
be used blindly.  (I always check the tests in the test file by 
hand, and this is the kind of bug that comes up during such hand 
examination.)

Consider the tight inner loop from vasr, changing its asr's to lsr's:

          do x0,pf\_vasr_\ic\_l3
          lsr  b    sinp:(R_I1)+N_I1,a  a,sout:(R_O)+N_O
          lsr  a    sinp:(R_I1)+N_I1,b  b,sout:(R_O)+N_O
pf\_vasr_\ic\_l3                        

The problem is that when you load a negative number into a or b, 
then do the lsr, you still have 0xff in a2.  When you read out 
the shifted quantity from a (or b), limiting (that can't be 
turned off) will occur.

In the (futile) search for clever solutions, I examined setting 
the S1 and S0 bits in the status register so that you get the 
arithmetic right shift "for free" simply by moving into and out 
of, say, accumulator a.  But when you move a negative number into 
a, then again a2 is set to 0xFF, and the lowest-order bit of that 
0xFF is shifted *along with* the contents of a1.  So we've 
defeated the purpose.

Now since that solution involves just a double move, then maybe 
we could clear a2 on every move.  I examined the tfr instruction 
for that purpose, hoping to be able to do something like, say, 

          tfr  y1,a2     sinp:(R_I1)+N_I1,b  b,sout:(R_O)+N_O ; ILLEGAL
          tfr  y1,b2     sinp:(R_I1)+N_I1,a  a,sout:(R_O)+N_O ; ILLEGAL

with y1 guaranteed to be 0.  Not only would that not work, but 
also a2 and b2 are illegal destinations for the tfr instruction.

So I gave up. The inner loop of vlsr is therefore always at least 
four instruction cycles long.