Re: Stealing a Great Idea from the 6600

BGB wrote:

On 6/19/2024 11:11 AM, MitchAlsup1 wrote:

BGB wrote:
 

 

>
For example::
>
     for( i = 0; i < max, i++ )
          a[i] = b[i];
>

In this case, it would often be something more like:
   maxn4=max&(~3);
   for(i=0; i<maxn4; i+=4)
   {
     ap=a+i;    bp=b+i;
     t0=ap[0];  t1=ap[1];
     t2=ap[2];  t3=ap[3];
     bp[0]=t0;  bp[1]=t1;
     bp[2]=t2;  bp[3]=t3;
   }
   if(max!=maxn4)
   {
     for(; i < max; i++ )
       a[i] = b[i];
   }

 That is what VVM does, without you having to lift a finger.
 

If things are partially or fully unrolled, they often go faster.

>
And ALWAYS eat more code space.
 

Granted, but it is faster in this case, though mostly due to being able
 to sidestep some of the interlock penalties and reducing the amount of cycles spent on the loop itself.

The loop does not have any dependencies, except on the loop index
variable
and a possible alias between a and b.
Now, if &b[1] happens to = &a[0], then your construction fails while VVM
succeeds--it just runs slower because there IS a dependency checked by
HW and enforced. In those situations where the dependency is
nonexistent,
then the loop vectorizes--and the programmer remains blissfuly unaware.

Say, since branching isn't free, more so if one does an increment directly before checking the condition and branching, as is typically the case in a "for()" loop.

Note: the ADD, CMP, BC of the LOOP instruction runs in a single cycle.
ADD is performed by a 2-input adder
ADD-CMP is performed by a 3-input adder
BC is performed by predicting a return to the top of the loop while
leaving the decoder decoding the instruction following LOOP.
Most of the time, and especially in wider machines, the instructions
of the loop remain in their instruction queues, and instruction FETCH-
DECODE is not performed while processing the LOOP. Each iteration has
the queue spit out its instructions to its FU as dependencies resolve.