Wishing for a timed-branch (quasi-interrupt) instruction

pjv

Hi All;

I know I'm going to get a barrage of flack for suggesting this because most folks here are not in favor of interrupts because of the complexity and grief it can bring, but on the other hand I LOVE the capability for the perfect determinism it can give in many situations -(you don't HAVE to use it you know!)

Sure, I have followed the rationale that 'you don't need' an interrupt, as there are other ways to implement something similar in the Propeller, and with 8 cogs who needs it?

Well, the other ways are not neccessarily so efficient, and for those who like to get top performance by continually trying to squeeze more out of a cog,·an instruction that would continually monitor the system counter, and, on a match, save the PC and·branch to a destination, would be a godsend. Kind of like a WAITCNT plus CALL without the wait. Call it a BRANCHCNT or JMPCNT. That's all it would do; any further context saving and restoring would be up to the programmer.

While it would not enhance all applications,·such a capability could frequently effect is a much more efficient use of each cog for those situations where WAIT based instructions or polling loops·are currently used. Now that I have messed with the Prop in assembly a bit, and have·a multi-threading-per-cog capability functioning nicely, it's clear how much more responsive a cog could be with such an 'interrupt'. Yes, it may not be for everyone, but on the same basis, I have no use for the built-in video helper, and am not complaining about that.

So, dare I say, without malice,·that if you have not seen the need·or·advantage of a timed interrupt, then you are not pushing the prop·to anywhere near its limits.

Just some thoughts..... not looking to start a fight. But I so wish that PropII could have this feature.


Cheers,

Peter (pjv)

P.S. Really looking forward to the next Prop Expo in Rocklin!

Bill Henning

Interrupts are easy to simulate if you dedicate a cog to them - see below

You can expand the code below for more than 4 interrupts.

Use 'if_z' for active-low interrupts
Use 'if_nz' for active-high interrupts

timing interrupts would also work by comparing against cnt instead of anding a mask

... but I am sure you knew of this approach already ...

I am looking forward to the next UPEW as well

int1  and ina,mask1 nr,wz
 if_z  jmp #service1
int2  and ina,mask2 nr,wz
 if_z jmp #service2
int3  and ina,mask1 nr,wz
 if_z jmp #service3
int4  and ina,mask1 nr,wz
 if_z jmp #service3
      jmp #int1

service1
      jmp #int2

service2
      jmp #int3

service3
     jmp #int4

service4
     jmp #int1

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller

Phil Pilgrim (PhiPi)

Peter,

I take your point. It would also be "nice" if the waitpxx instructions could be set to time out. But I've always been able to find "workarounds" to these sticky timing issues, when necessary. (I use "workaround" advisedly, since it's only a workaround in the context of more traditional processors. In the Prop's own context, it's just "how things are done".) I think the whole design philosophy of the Propeller is that task switching needs to be cooperative to preserve determinism, rather than preemptive. Even the Prop II which, apparently, will have built-in multithreading support, requires cooperative switching (if I understand Chip's post on the subject correctly, and if his plans haven't changed). What kind of latency do you require that, say, coroutines couldn't solve?

-Phil

pjv

Hi Bill;

Right..... exactly the kind of polling loop inefficiency I'm procaiming about, but workable in non demanding situations.

Cheers,

Peter (pjv)

Sapieha

Hi Phil, pjv.

I mentioned that posiblites to Chip for WAIT instructions to have TimeOut posiblites.
We will see if He implement it ?.

Regards
ChJ

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

pjv

Phil;

I'm happy with co-operative routines. In fact that is the basis of my multi-threading method.

The latency I wish for is that of an SX..... very fast, but somewhat more important a VERY deterministic (actually consistent) delay from event to running the appropriate code, and a simple return to the interrupted routine. I'm always pushing the envelope, and strive for the ultimate in the concept of 'virtual peripherals'....... Scenic/Parallax has taught me well in this regard, so much so, that generally I consider micros with built-in peripherals (some obvious exceptions omitted) a lesser breed,
and I shy away from them.

It is amazing what one can squeeze out of an SX because of this interrupt feature. But then I DO very much like all the other things a Prop offers. Just this tiny little piece is missing in my opinion.

Cheers,

Peter (pjv)

Phil Pilgrim (PhiPi)

Peter,

If the event can set or clear a pin (non-intermittently), you can always couple it to a counter, so the next time you check it you'll know how long ago it was set and how long you have to wait to service it with a consistent latency. Of course, the trick for doing this efficiently is to minimize the wait, which is a function of the polling frequency.

-Phil