Timeline for Cycle counting with modern CPUs (e.g. ARM)
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 11, 2020 at 15:10 | history | edited | CommunityBot | Commonmark migration | |
| Jul 7, 2011 at 17:26 | comment | added | supercat | Note that for that approach to work well, one must have a pretty good idea of how long code is likely to take. The less precisely one knows that, the more overhead will be necessary for synchronization. | |
| Jul 7, 2011 at 17:22 | comment | added | supercat | The need for such precise timing may in some cases be alleviated by peripherals that offer buffering along with an indication of how full they are. For example, suppose one has an SPI port with a four-byte buffer and an almost-empty indicator, and blind writes would take 14-16 cycles. If the buffer is almost empty, one could blindly write 24 bytes (using 336-384 cycles, duing which at least 21 bytes would have gone out the port) before checking buffer readiness. Once the buffer is almost empty, one could write 24 more bytes. | |
| Jul 7, 2011 at 17:14 | comment | added | supercat | There are a lot of situations where one is interested in worst-case counts, and a fair number where one is interested in best-case counts (e.g. if an SPI port can output one byte every 16 cycles, generating each byte would take 14 cycles best-case, and checking for readiness would take 5 cycles, checking for readiness every byte would limit speed to once byte every 19 cycles best-case; writing blindly with two added NOPs would allow a speed of one byte every 16 cycles best-case). The cases where precise timing is needed aren't as common, but they can arise. | |
| Jul 7, 2011 at 16:07 | comment | added | Kevin Vermeer | Wow - I confess that I had only gone through simple worst-case cycle counts, rather than actually wrestled with the caveats beneath the table. My updated answer highlights some other ambiguities. | |
| Jul 7, 2011 at 16:06 | history | edited | Kevin Vermeer | CC BY-SA 3.0 | Updated with ambiguities |
| Jul 6, 2011 at 19:08 | comment | added | supercat | My guess would be that the IT could probably (truthfully) note something like, "In the absence of wait states or code-bus contention, IT folding is guaranteed if (1) the preceding instruction was a 16-bit instruction that did not access memory or the program counter; and (2) either the next instruction is a 16-bit instruction, or the preceding instruction was not the target of an "unaligned" branch. IT folding may also occur in other unspecified circumstances." Such a spec would allow one to write programs with predictable IT-instruction timing by ensuring the code was arranged as indicated. | |
| Jul 6, 2011 at 18:08 | comment | added | supercat | The "IT" timing would seem especially troubling, since that's an instruction that would often be used within a tight cycle-counted loop, and I'm pretty certain it can't always be folded. I would guess that if one always branches to the start of a timing-sensitive loop, forces the loop to start at a word boundary, avoids any conditional loads or stores within the loop, and one doesn't put any "IT" instruction immediately after load or register-updating store, the "IT" timings would be consistent, but the spec doesn't make that clear. | |
| Jul 6, 2011 at 17:59 | comment | added | supercat | I would consider the following to be vague: "Pipeline reload is longer when branching to unaligned 32-bit instructions in addition to accesses to slower memory" doesn't say whether it adds precisely one cycle, and "IT instructions can be folded" doesn't specify under what conditions they will or will not be. | |
| Jul 6, 2011 at 16:39 | history | answered | Kevin Vermeer | CC BY-SA 3.0 |