On Friday 20 November 2009, Øyvind Harboe wrote: > I'm very much against *forcing* interfaces to implement a queue > in memory. It should be possible to execute the commands > synchronously. The existance of a queue would make the code > *much* less efficient on embedded devices.
We saw contrary feedback not that long ago, though: that a lot of time was being wasted recreating the same command queues repeatedly. Why would running from a queue cause inefficiency? I've often seen the opposite. Minimally, having the commands already lined up and ready to go means there's not going to be time wasted between steps, calculating the next one. So there's an immediate latency win. At some level, executing from a prepared queue, rather than computing C[i] and executing X[i] the steps one at a time, is just time shifting: sigma(i, C[i]) + sigma(i, X[i]) == sigma(i, C[i] + X[i]) However, splitting the compute and execute stages lets them be individually optimized ... and also opens the door to the "reuse the queue" mode, reducing the time for subsequent queue runs to just sigma(i, X[i]). That means more of those operations can be performed in the same time ... e.g. polling a register. (If the C and X costs are the same, polling would be twice as fast.) - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
