Speculative backend operations - page 1

A backend circuit, being independent of the frontend, can run continuously, updating its frontend register whenever necessary. Or, it can run only when accessed by a frontend instruction, triggered by the read or write pulse from the frontend register's RCL. Or, it can run sporadically, perhaps whenever some external event occurs. Or, of interest to us here, it can be triggered to run when accessed, return some sort of value immediately, AND THEN KEEP RUNNING IN PREPARATION FOR AN EXPECTED NEXT ACCESS.

For example, we can build a counter circuit that returns its current value immediately, with no delay. And then, AFTER the instruction is completed, kicks into action and increments its value. The next time the frontend reads the counter, it will likely have already incremented to the next value. (And if not, will introduce a delay, but reduced by however far it got so far.) In this manner, the counter is running in parallel to the rest of the program, and if the time between accesses is sufficient, will always be ready and so introduce no delays to the main program. Essentially it costs the main program zero "cpu time".

This would be applicable to many kinds of backend circuits. It would apply to backend WIZes as well. For example, a list processing algorithm running in another WIZ could immediately return the next value in a list, and then in the background, after the instruction is done, begin finding the next value to be returned. If the main program is looping on this, and the time spent in that loop is greater than the time it takes the list processor to find the next value, it too would be a "zero cpu time" operation.

Or it could accept a value for storage into the list, and after the instruction completes actually go on to store it, with possible tree-balancing and list restructuring and garbage collection and whatever, all done in parallel to the main WIZ's operation.