The Hardware Loop Feature

[Hoernchen]

Mind telling us more* about that, now that it's been mentioned in a few places and is slightly less of a secret? (who knows, I might feel like it's time for another premature optimization pass..)


* All the technical details.

[aolofsson]

Hoernchen,
Here is the technical detail regarding the hardware loops. It was intended as a "benchmarking feature"... A working example is attached.

* HARDWARE LOOP REGISTERS:
* LS=Loop start register that holds a "PC" to match indicating start of loop
* LE=Loop end register that holds a PC to match indicating end of loop
* LC=Loop counter register that counts down to zero.
*
* USE:
* Program up the LC, LS, LE using the movts instruction before the hwloops start.
*
* Restrictions (many!!!):
* 1.) No interrupts inside hardware loop (must mask all interrupts)
* 2.) No branching inside hardware loop
* 3.) Start of HW loop must be aligned on word line in memory
* 4.) All instructions in loop need the (.l) notation to specify 32 bit
* instruction.
* 5.) Need .align instruction before last instruction in loop.

Andreas

[shodruk]

Very interesting.
It is like a DSP.
Maybe useful for realtime signal processing.

[Hoernchen]

[aolofsson]

Yes, that should have read "double word aligned".
Andreas

[timpart]

Thanks for providing this extra information Andreas. Can you tell us please at which instruction LC is decremented? The emulator code seems to have it happening, along with a test for being zero, at the loop end address but that might just be software convenience.
Also have you tried a varient of the code with an odd number of registers so that the align instruction before loop end generates some NOPs?

Hardware loops must be fairly tricky to get right and I imagine you came up with the criteria you state to simplify matters and avoid lots of complicated edge cases. Now that you have made a design, I take it that the conditions are sufficient for the loop to work. I do wonder though if they are all necessary for all of the loop code. Basically I'm looking for loopholes in the conditions if you'll excuse the pun.

If you indulge me for a bit, let me state what I think might be the conditions...

1) The loop must start on a double word boundary. (This is a full line for instruction fetch)
2) The loop end register value must be on a word boundary but not a double word boundary. That is a design choice that has been made. (There might be a lack of enforcement and a slackness that could be exploited, but let's not go there.)
3) The instruction at the loop end address must exactly fit inside the double word that loop end is in so the loop ends at a double word boundary, and smoothly goes onto the loop start instruction. Thus it probably must be a single whole word instruction.

There is an important series of instructions before loop end for which strict rules apply. The length of this sequence I'm not sure about but it must be enough so that the approach of the loop end address can be detected and the loop counter can be decremented. Not sure how far back this is as pipeline is probably irrelevant. Might be as simple as 4 bytes before loop end which is easy to do by masking out a bit in loop end's address. Or could be further back, or even as far forward as loop end itself. Dual scheduling of FP instructions could potentially require more distance to allow for possible rapid consumption of data, but the hardware loop is positioned early enough in pipeline this won't matter?

4a) The PC (program counter) must equal a particular critical address in the loop end series. At this point the counter is decremented. This address is word aligned and a defined distance before loop end.
4b) There might be another critical address the PC must equal to check if counter is zero. A choice of which instruction line to fetch next is made.
4c) At loop end address the next value of PC is either loop start or if end of loop reached the address that follows loop end. (This might be same as 4b.)
5) There may not be jumps into the loop end series. (This could stop PC equaling a critical address and approach of loop end not noticed.)
6) There may not be interrupts during the loop end series. These would upset the fetching of lines of instructions.

I speculate, perhaps wildly, that between the start of the loop and the start of the loop end series that there might be far more freedom, such as:
Half word instructions and word instructions not on full word boundary. I notice that the code you have supplied aligns to a double word boundary by inserting NOPs, a halfword instruction without a .l version.
Jumps (and routine calls) so long as not into loop end series
Perhaps even enabling interrupts if you really have to. (Though the enabling and then disabling before getting near loop end would add overhead.)

Thanks for reading all this,

Tim

[aolofsson]

Tim,

Thanks for the in impressive in depth black box analysis Unfortunately, I know where the bugs are buries, so it's unlikely we will be able to loosen the restrictions.

Restrictions 3-5 were added because we had a hard tapeout date and ran out of time(they cover up bugs). It should be possible to loosen up the restriction on .l instructions in the bulk of the loop (but if the loop is that big, then I would suggest just staying with regular branch loops).

Restrictions 1-2 were there from the beginning to simplify the design. I have seen too many DSPs get into serious trouble trying to implement "general purpose" hardware loops. That being said, the design "should" support branching or interrupt-vectoring out of the loop as long as there is no need to return into the loop.

Andreas

[timpart]

Thanks for the prompt reply Andreas.

I'm not sure how long the end sequence has to be, but it might be handy to be able to change a couple of full word instructions in the start of the loop to half words so the loop becomes an exact multiple of a double word without having to resort to padding out with time consuming NOPs.

Even if the loop takes 100 cycles offering the chance of squeezing 5 cycles off that by eliminating a subtract and BNE might be tempting in some applications. Wrecks the interrupt latency of course.

Perhaps in a future chip there could be some relaxation, but I fully agree you want something that works. Make the compiler do the hard work of fitting things into the restrictions rather than the other way around.

Thanks,

Tim

[shodruk]

[Hoernchen]