Updates to Manual: I might have missed something, but this seems odd

Bobb Fwed · 2011-07-18 14:08

So, I don't know when I missed this, but I did.
Why (according to the v1.2 Propeller Manual -- I just downloaded it today) do wait instructions take 6+ cycles now (instead of 5+), and Hub instructions are 8 - 22 cycles instead of 7 - 21.

Nothing actually changed, right? We just changed how we are counting. And what is the logic behind the change? Does it have to do with which cycle in the pipeline we are saying these things occur?

In my projects I did the math to calculate minimum cycle time with the old wait and hub numbers, and never had a problem. Should I be adding a cycle to the math now?

Mark_T · 2011-07-18 15:39

The changes document explicit lists all these changes, this is clearly a fix to the manual.

Bobb Fwed · 2011-07-18 15:42

What I'm wondering is, was it wrong before? And if so, why was it considered correct for so long by so many experienced users?

Cluso99 · 2011-07-18 18:52

Bobb: This was discussed long ago. The manual was incorrect. There is no such thing as 5 clocks - it was always 6 minimum.

BTW I haven't checked the manual for the Jump type instructions, but originally there was an impression that non-taken jumps took 8 clocks. However, if you are using the condition-code on the jumps, they only take 4 clocks because the instruction is actually converted to a nop if the condition (c & z flags) is not met and so the non-taken jump is still 4 clocks.
DJNZ & TJZ/TJNZ do take 8 clocks if not taken, unless you are checking the flags.

Ale · 2011-07-19 04:07

Cluso99 wrote:

BTW I haven't checked the manual for the Jump type instructions, but originally there was an impression that non-taken jumps took 8 clocks. However, if you are using the condition-code on the jumps, they only take 4 clocks because the instruction is actually converted to a nop if the condition (c & z flags) is not met and so the non-taken jump is still 4 clocks.

8 clocks ? conditional jumps ? when was that ? I really do not remember any discussion about it... it wouldn't make that much sense *if* it is the same logic the one that treats as NOPs other instructions that do not meet the current status of the flags...

Note: We found out some time ago that the waitxxx instructions required 6+ cycles. I didn't know about the HUB ones, though.

Cluso99 · 2011-07-19 04:19

Ale: The shortform datasheet says a non-taken jumps/calls takes 8 clocks because it has to flush the cache. But, the way conditional jumps/calls work, if you are using the conditions (c & z) they are decoded first and the jumps/calls are treated as nops and so only 4 clocks is required. This is because the nop case is determined before the prefetch of the next instruction takes place, whereas normal jumps/calls would prefetch the taken jump next instruction, and so would have to be discarded, and the next sequential instruction fetched.

Ale · 2011-07-19 04:22

That is what I thought, that c and z are processed first and thus it wouldn't matter what kind of instruction we skip over... maybe I missed some discussion...

ericball · 2011-07-20 06:39

Ale wrote: »

That is what I thought, that c and z are processed first and thus it wouldn't matter what kind of instruction we skip over... maybe I missed some discussion...

Any not executed instruction (due to if_flag condition) is 4 cycles, including instructions which would be more than 4 cycles if executed (e.g. WAIT, HUBOP).

Bobb Fwed · 2011-07-20 08:46

Hm, interesting. Now that I look, I had the "new" correct timing in my programs.
Where I have some minimum time, I would test it, and I actually had the correct timing... well cool. For example, in my ADC driver I have this:

:wait                   RDLONG  cmd, cmd_addr   WZ      ' if no command yet
              IF_Z      WAITCNT waitlen, p1             ' wait for a time (longer the less power)
              IF_Z      JMP     #:wait

and I had the minimum timing at 32 cycles.

I'll have to check all my numbers, but for most of the important things, I tested the minimum timing, and I probably ended up with the corrected timing anyway.

Ale · 2011-07-20 08:54

eric: exactly. That is why I thought I may have missed some discussion because it was for me always clear that any not executed instruction would only take 4 cycles.

kuroneko · 2011-07-20 17:03

Bobb Fwed wrote: »

:wait                   RDLONG  cmd, cmd_addr   WZ
              IF_Z      WAITCNT waitlen, p1
              IF_Z      JMP     #:wait

and I had the minimum timing at 32 cycles.

Out of curiosity, how did you arrive at 32 cycles? With the old timing this loop would have used 7+5+4 = 16 cycles which fits into one hub window (provided you use a minimum waitcnt).

Bobb Fwed · 2011-07-20 17:49

Well, my original math said it should actually be 30 minimum cycles 21 + 5 + 4. But after I tested it at 30, the routine would freeze in this loop, so i just increased the minimum until it didn't freeze, which ended up being 32. Which now I see works with the corrected timing (22 + 6 + 4).

kuroneko · 2011-07-20 17:56

Bobb Fwed wrote: »

Which now I see works with the corrected timing (22 + 6 + 4).

Why do you involve what looks like worst case hub timing? Once you are in the loop you are in sync. So it's 8+6+4 = 18 which means we just missed our hub window by 2 cycles and have to sit there for 14. Which gives you the total of 32 (2 hub windows).

Of course if you consider 22 as hub related time then we are on the same page

After re-reading this it sounds unnecessarily picky. 22 cycles are spent for the hub op (14 wait, 8 execute) if you look at the loop from the other end. Apologies.

Bobb Fwed · 2011-07-20 18:36

The idea is that the "minimum value" is entered by the programmer/end user so it needs to be larger rather than smaller. This wait loop is to put the cog into a "low power mode" so the idea is to have longer waits, rather than shorter anyway.

Updates to Manual: I might have missed something, but this seems odd

Comments