Oh, I guess "Cogs" just came from how they first drew it out on paper, the "hub" and 8 sort of "gear wheels" running round, I imagine they looked
like cogs.
My "flying nutcase friends" tell me off for calling them propellors, apparently, technically, they are "Air Screws"! (I still don't believe them)
mctrivia said...
Deterministic timing means you can compute exact max and min time taken in cycles to run a piece of code. Interupts make this impossible since they can run for any length of time.
I still think interupts are a good option especially 1 waitpeq interupt that is optionaly engaged.
Interrupts don't necessarily make a system non-deterministic.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
As I suspected would happen this thread is getting stuck in that old "to have or not to have interrupts" argument. Which is NOT really where I was going. I'm quite happy without the full scale complexity of interrupts and stacks etc. I like that all the non HUB ops take the same number of clocks. Perhaps I should not have used the word "interrupt" in the title and just stuck to the reset idea.
Who said anything about saving state or context? I just want to be able to bailout, jump, somewhere. Forget about return addresses and pushing registers etc. A simple program counter reset would do.
Carl, what do you mean "has no general purpose registers" one way of looking at it is that it has 496 general purpose registers per COG! All of them are index registers. In MOV a, b BOTH a and b are indexes which can be set as required with MOVS and MOVD.
As far as I know all normal CALL instructions modify storage, the stack, and registers, the stack pointer. The Prop's CALL instruction actually does not exist, it is a use of JMPRET that the assembler automatically configures to put the return address at the end of your procedure. If you use JMPRET instead of CALL you can put the return address anywhere you like, i.e. you don't have to modify instructions in your stored program. But then of course it is up to your procedure to find its way "home" as it were.
Carl, "While I'm unconvinced that determionacy by that definition is actually achieved, nor that it is a particularly useful thing to achieve in any case," For sure it is actually achieved, you write your loop and that's it, you know EXACTLY how long it will take. Nothing can barge in and disturb that fact. For sure it is also VERY useful. High speed serial coms, video, USB etc would not be possible with out it.
I do take your point that some times one can find oneself using only a small fraction of a COGs power for some small task, however there are ways around that in many cases, depending on the real-time constraints. For example there are drivers for multiple serial lines in one COG.
The ability to execute code in HUB storage is there, it is called Large Memory Model (LMM) as used by ImageCraft C. There is a speed penalty to LMM, but if you need a lot of code in an app you have it + 7 "interrupt handlers" in the other free COGs, not bad.
I wish we had a "standard" LMM kernel to write to and tools that would make writing LMM in assembler easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon:
"Interrupts don't necessarily make a system non-deterministic."
Could you elaborate on that?
Seems to me that if an interrupt source is not synchronized to you CPU clock, i.e. real world events, then whatever is running can be disturbed at any time and I have no timing determinism. If the interrupts are synchronized to the CPU clock I probably don't need them anyway.
I guess it depends on what degree of determinism we are aiming for. For example in the case I opened the thread with I want an instant response to a pin no matter what I'm doing, I hate to say "like an interrupt". Does not need to be at any deterministic time. But then I want to get on with a cycle of events in a very deterministic way unless hit with that pin input again.
Perhaps you could give an example of deterministic use of interrupts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A deterministic way that a well known software company uses interrups (the BIG software company),
1: You get lots of interrupts going at once.
2: You fill up gigabytes of memory with stuff, that no one knows what it is, or what it's doing.
3: More interrupts.
4: Write memory to and from disk, a lot (because you filled all the gigabytes of RAM).
5: More interrupts.
This determines that the screen will turn blue and the computer will stop working!
See, very deterministic.
Heats, I see what you mean, a PC (program counter) reset to start point. Not an "interrupt", a "Jump To Origin", or if Chip could fit it on a "Jump To Point", where
point is a loaded (0-511) address. He would also need to build a loadable 32 bit mask so that you could assign a pin, this (I imagine) would need a "desired state"
bit, then in hardware he could mask of the state and compare to the desired. It's a neat idea for the interrupt hungry hoardes .
Your sacriligous, heretical suggestion, is the best idea I've heard of on this subject, and in a way Carl is agreeing with you in that he sees the rest of the Props
architecture as making interrupts easy to manage.
heater said...
Leon:
"Interrupts don't necessarily make a system non-deterministic."
Could you elaborate on that?
Seems to me that if an interrupt source is not synchronized to you CPU clock, i.e. real world events, then whatever is running can be disturbed at any time and I have no timing determinism. If the interrupts are synchronized to the CPU clock I probably don't need them anyway.
I guess it depends on what degree of determinism we are aiming for. For example in the case I opened the thread with I want an instant response to a pin no matter what I'm doing, I hate to say "like an interrupt". Does not need to be at any deterministic time. But then I want to get on with a cycle of events in a very deterministic way unless hit with that pin input again.
Perhaps you could give an example of deterministic use of interrupts.
The XMOS chip has interrupts and is fully deterministic.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Carl, agreed on the counters and agreed on there being very little to preserve.
On the matter of COGs, it made sense to me this way: If you imagine the thing as a network of software gears, said gears would mesh at specific ratios. This is COG to HUB transfer window. Code written with loop times that are a harmonic of that meshing, which is a result of the round robin access cycle, perform best in terms of throughput and consistency (deterministic behavior).
BTW: On multi-processing systems, where more than one instruction is being executed at the same moment in time, this round robin affair makes most communication problems timing problems, and that plays well with Phil's observations on Propeller behavior. This is why the locks see little use, IMHO. On multi-processor systems where this isn't true, there exists a lot more complexity in the communication between processors and use of shared resources. In that scenario, the number of possible states would be considerably higher, demanding a higher silicon cost, and software cost.
There is another factor in play here as well. We are talking determinism in the context of the code we write. Depending on what that code is, determinism might be in play or might not, as has been observed on this thread. At the silicon level however, it's always in play. (I think, and am interested in discussion on that element of things --the propeller is really simple in a lot of ways, and I'm not always sure why!) This keeps the silicon cost simple, in that the number of managed states is kept to a minimum. Given the comments I've seen Chip make on various, "what if?" threads, this is one of the primary goals surrounding the design of the propeller. Doing this means designing in a way that presents useful tools where software solves the problem, and it means very testable silicon in that states to be managed internally are kept to a minimum.
(And I don't know a lot about that element of things! Very interested in comments along those lines.)
Leon, if I may: This is a Propeller discussion. XMOS being deterministic was hashed out earlier, on another thread. I would rather not see this solid line of discussion devolve into Propeller -vs- XMOS at this time.
I too would be interested in seeing an example of deterministic use of interrupts. IMHO, doing that is actually a latched.. Could you compare and contrast those?
Did I understand the earlier part of the thread correctly, in that it is NOT possible to simply reset a COG, without reloading it?
If so, an addition to the existing instructions that permitted this would then enable a supervisor COG to perform that task, based on the existing pin state detect logic. Wouldn't just doing that solve the problem?
And that is setting aside, using a powerful CPU for a small task. Agreed on that, but was just wondering, if I understood the earlier conversation.
heater said...
Seems to me that if an interrupt source is not synchronized to you CPU clock, i.e. real world events, then whatever is running can be disturbed at any time and I have no timing determinism.
Precisely.· The same is true of any other way of responding to an external stimulus.· Neither the Prop nor any other processor, whether microprocessor or mainframe or anything in between, can respond in less than one instruction, or in an exact multiple of an instruction time.· To me, that's indeterminacy.
However, as Phil explained, "deterministic" timing as used in Prop literature really means "(pre)determinable within a range-of-variation of·one instruction time".· That's not a definition I would have used, but it's perfectly acceptable in technical discussion, as long as it's predefined.· Technical jargons, especially those confined to specific hardware designs, often predefine words in a way that's more specific than their meaning in the general language.· That's normal, and necessary.
In that sense, by the way, I think determinacy (in the special sense)·is easy to achieve with interrupts, too -- but only if they occur singly, which would imply that each processor can serve only one external device.· That's the case now with the Prop -- except that with interrupts it could also perform one nondeterministic background task at the same time.· Performing a background task in a cog, or serving more than one external device in a cog, would kill that determinism in serving exernal devices.· I think that's no loss.
In the few cases (someone mentioned display timing and serial communications) where such determinism is a useful technique, one could use timer interrupts to do the same thing, or simply not enable interrupts for that particular cog.
Re:· "airscrews" -- Kensong, your friends are making sport with you.·Propeller is the usual term, especially among pilots.·Propeller is less specific:· ships have propellers that are not airscrews.· Mariners often call their waterscrews simply screws.· Attack submarines, for example, ·listen for screw noises and are carefully designed to minimize their own screw noises.
Heater, your thread is an esecially interesting and (here anyway) somewhat controversial one.· It must be expected that it would wander a bit.· Interrupts are one way to do what you want, so interrupts would come into discourse even had you not used the word.· Another way would be to have a way to specify, or example,·that "if this pin goes high, this cog's program counter is reset".· It would be best if this condition would work only once -- more or less like an Airbus 320, which has a proven ability to land on water, but only once.· Then the cog whose PC was reset would have to set that condition again after (1) it had serviced the pin, and (2) the pin was low again.
heater, I agree there are situations where an interrupt would make things easier, particularly when it comes to synchronizing program execution to an external signal. Luckily those times are relatively few because I also agree with Mike in that interrupt handling is difficult to implement and can be a source of subtle bugs and reliability problems that are very difficult to find.
In regards to your other comment "It breaks by heart to use a whole 32 bit CPU for such a simple task!" I read an article (IEEE Transactions) years back about maximizing CPU utilization on mainframes and super minis. The authors response was to point out how much cars cost, and how many cars sit unutilized in a parking lot or garage for most of every day. Billions of dollars in equipment that is only utilized for an hour or two each day on average. While I do like to get the most use possible from any chip I use, I would rather use another cog or even add another prop to avoid the complexity of interrupts and re-entrant code. That may not be the way to go for a product that will sell in the thousands for $19.95 at Walmart, but it makes sense for higher value small volume use.
Your idea of having a pin start a cog at a specific location is a pretty good idea though. It avoids most of the complexity of interrupts, allows a high speed response to an external signal, and does not tie up an entire cog waiting for one pin. The problem is what else does the cog do, and how do you return to doing it without saving the state (at least the address where it was interrupted) of that process. While I wouldn't mind seeing something like this implemented, I would rather see more cog and hub ram, more I/O pins, higher speed, and more cogs in that order.
As kensong said "There is nothing in real time control that the Propellor wouldn't be capable of, but as a graphics, number crunching, high speed communicator of database machine we're really off it's original target playing field", I could not agree more. There are lots of chips available that are great for graphics, number crunching, and databases, but there is only one Propeller.
potatohead said...
Leon, if I may: This is a Propeller discussion. XMOS being deterministic was hashed out earlier, on another thread. I would rather not see this solid line of discussion devolve into Propeller -vs- XMOS at this time.
I too would be interested in seeing an example of deterministic use of interrupts. IMHO, doing that is actually a latched.. Could you compare and contrast those?
I was just responding to Heater's request for a deterministic system using interrupts!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I'am not for interupts. Not for Reset in that method You describe.
But for on Prop II.
1. Time slice register for al WAIT instructions.
2. One (JUMP XXXX on PIN,xx) instruction that solves most problems describe on this thread in my opinion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
I am maybe not enough skilled on "prop" but still I want to put my 2 cents.
I am with heater. What is wrong in asking for the program counter to be reset ? I will add something more:
why not have a register WO/RO that
when written can set a 8 bit mask, 8 bit edge selector and 8 pin group (eg. you can not choose any pin for vga just a group of them) enabling the function when it's not equal to zero
and when read give previous program counter value and the 8 pin group state (at the moment of the event)
No need for a stack (in case it will be user duty), possibility to jump back to where the main program was stopped, possibility to perform a jump based on event source.
How many of you crave for more cogs in the new prop? It seems that's never enough (same for me) so what's wrong in the opportunity to run some background tasks? At the end, it's up to the user to use this functions, no one will shoot the ones not using it. If it's cheep, it not require a full interrupt structure, easy to do in silicon why not?
Let me state again, I am NOT campaigning for interrupts. I am NOT campaigning for interrupts. I am NOT......
Perhaps I am campaigning for a pin to reset like functionality, no stack, no return address, no reloading of COG or counters just a jump.
However I think I'd prefer if the emphasis of the thread title and discussion were on "The case" that is, the fastest possible solution with the current Prop to the problem I presented. Phil has proposed something very nice with a minimum of external logic which I like. What about without hardware assistance ?
Then I would like to propose another problem:
1. Assume you have a bunch (4 to 8 say) of short routines (20 or 30 instruction say) that in a normal CPU would be interrupt handlers for some different devices.
2. Assume you don't have enough free COGs to put one routine in each waiting on a pin.
3. Or philosophically you don't want to waste an entire 32 bit CPU on hand full of instructions.
4. Assume that the real-time requirements are such that 1 COG can handle the processing/bandwidth of all routines combined.
5. Assume for simplicity that all these routines have the same priority.
What is the simplest PASM "framework" to fire off all these routines at appropriate moments giving each one a fair share of CPU time? Solution should of course be as fast as possible. Solution should probably use wait(something) so as to conserve power. Solution should probably allow for the easy removal of "handler"routine into its own COG if required.
I can think of some long winded naive solutions but I'm sure some PASM wizards here could do better.
Perhaps something with:
WAITPNE state, mask
MOVS vector, ina
NOP
vector JMP #0-0
Or such. If you arrange the "wait" inputs to be in the right pins.
Such a "frame work" could be generally useful and make those who miss interrupts happy[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The XMOS chip is interesting but I still don't get the determinism angle. If one of its cores is running flat out deterministically doing something, any interrupt will bugger that up. Unless the core is running in a multi-threading mode ie say 50% of it's cycles are deterministicly doing something while 50% are idle incase an interrupt happens. Then I believe you can do clever things with its timed inputs and outputs. BUT I believe pushed to the limit the problem is the same to keep determinism the event has to go to another core. Again it rather depends on what one define determinism to be.
For example, Carl, now I'm with you. You are pushing the idea of determinism down to the sub clock/instruction cycle level at which point there must be some latency (jitter) in response. So yes most CPUs can't beat that issue. However I was thinking, if your CPU was a fully static design one could stop its clock until the interrupting event occurs. Then you have a precisely known latency that is always the same. Of course you then need another CPU running to handle your background stuff.
@potatohead: As far as I can tell the conclusion here is that you cannot restart a COG with out a reload. That is also my reading of the manual now.
@Carl: "if this pin goes high, this cog's program counter is reset". Yeah that's what I proposed in the original post. You are right it would be neat if it only happened once on an edge. In my example problem that is not so important as when the pin is active things would stay reset or looping though reset until the input goes passive. Yes, I wish I never mentioned "interrupt". The interrupt discussion has been thrashed to death on this forum especially when any mention of the Prop II comes up. Usually, it seems, those who are new to the Prop are appalled at it's lack of stack and interrupts etc. and immediately start suggesting it should sprout them. Takes a while to get ones head around how things are done around here.
@Sapieha: Yep there must be other better ways solve the problem present in the top post. I'm sure Chip will come up with some surprises[noparse]:)[/noparse] Small, simple, elegant, and mind bendingly general in usefulness.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
The XMOS chip is interesting but I still don't get the determinism angle. If one of its cores is running flat out deterministically doing something, any interrupt will bugger that up. Unless the core is running in a multi-threading mode ie say 50% of it's cycles are deterministicly doing something while 50% are idle incase an interrupt happens. Then I believe you can do clever things with its timed inputs and outputs. BUT I believe pushed to the limit the problem is the same to keep determinism the event has to go to another core. Again it rather depends on what one define determinism to be.
It uses threads, as you have suggested.
Each XCore has eight event-driven hardware threads, each with its own set of 16 registers. A high performance XLink switch supports low latency and deterministic communication between the threads in each XCore, and between XCores. Threads operate as logical cores, communicating via the XLink switch. See the XMOS documentation for more details.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Here's how a generalized "interrupt" processor might be coded for the Propeller. This one will respond to low-going pulses on the active pins. The pulse widths have to be at least as long as the sum of all the ISR execution times, plus a little overhead. Otherwise, some external set/reset logic will have to be incorporated to make sure shorter pulses are captured and accounted for.
init mov state,ina 'Read the current state.
loop mov prev_state,state 'Transfer current state to previous state.
waitpne prev_state,mask 'Wait for state to change.
mov state,ina 'Read the new state.
mov flags,state 'Save it in interrupt flags register.
xor flags,prev_state 'Identify the bits that have changed.
andn flags,state wz 'Mask out changes from low to high.
if_z jmp #loop 'Loop back if there aren't any high-to-lows remaining.
test flags,mask0 wz 'Test each bit for an active interrupt,
if_nz call #isr0 ' and process if set.
test flags,mask1 wz
if_nz call #isr1
test flags,mask2 wz
if_nz call #isr2
test flags,mask3 wz
if_nz call #isr3
jmp #loop 'All have been processed, so loop back.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/3/2009 9:33:23 PM GMT
One of the uses of the WAITPxx instruction is to deal with this situation where you want a cog to react quickly to an external event. The cog is placed in a low power state and released within one system clock cycle of the requested event. What you're wanting to do is have the cog do two separate things at the same time, something repetitive (like reading an external SRAM) and "instant" reaction to some effectively unrelated external event. Note that "instant" reaction wouldn't necessarily be instantaneous with the reset scheme suggested since some reinitialization of the code would be needed assuming that whatever is being done repetitively doesn't need to be shut down somehow (like turning on or off external signals) before something new can be started. How much of a reset would have to be done? Just the PC? How about other special registers? How useful would just a PC reset be? How useful would it be if the whole cog were reset except for the memory? How about Sapieha's suggestion for a jump instruction of some sort that's conditional on an I/O pin state? That would save one instruction over a current TEST and conditional JMP. What if the handling of a SRAM or DRAM were simplified somehow with cog hardware using the counters perhaps? As others have mentioned earlier, part of the philosophy of the Propeller's design is to add a little extra hardware that does just what's needed in an neat, minimal fashion to allow one to do something difficult, usually from a speed perspective. The video generator is one good example of this and the cog counters are another, particularly in the case of A/D conversion and PWM generation. They do part of the task, enough that the rest of it can be done in ordinary software with a lot of flexibility. External memory access may be a similar task, enough that Chip brought up the issue in another thread.
Mike, actually you are the one that started me down this train of thought.
When I proposed using a Propeller as external RAM you suggested a scheme of using an 8 bit data bus, a clock and a "initiate" signal. SPI fashion. Whereby a command byte is clocked from Prop to Prop followed by address bytes followed by data bytes in which ever direction. All in all I like this idea better than my other multi control line effort and plan to implement it.
So far so good but that "initiate" signal is a problem. Not so much to initiate a transfer but to say to the remote Prop "let's start over no matter what we are doing now". After all the master Props COG doing this may have been just started or restarted and we want to be sure we are in sync with all those commands and addresses and data bytes at the other end. And we don't want to have to reset the entire remote Prop to do this.
Well, checking for that "initiate" signal requires instructions and time out of every data transfer cycle.
So you see now where the idea for a COG reset came from. It's not to get an ""instant" reaction to some effectively unrelated external event" as you say, its actually to speed up the data clocking rate. How long the reset actually takes is not an issue as it will not happen very often. It's exactly the opposite of "whatever is being done repetitively doesn't need to be shut down".
Then it occurred to me that this is, hopefully, a simple feature with a lot of uses. So I dared to suggest it. And by the way how bizarre is it to have a CPU that you cannot just reset?
All in all, I don't want a reset or interrupts as such. I just want to get my Prop as RAM working as fast as possible. Or indeed any Prop to Prop Command/Response system.
That boils down to a Prop to Prop communication issue. Which itself boils down to a COG to COG communication issue. After all I may want to communicate with a COG on my Prop using the same mechanism, whatever it is. Not just for RAM access but general command response stuff. And that is something I DO hope is looked at for Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I liked your solution to my reset problem with external hardware but aren't we missing something obvious here?
What if I wired by 8 bit command/data bus to pins P0 to P7. Then I connect the reset/initiate bit to BOTH pins P8 and P31 !
Now according to the manual MOVS sets sets Z if value = 0 so a simple "if_z jmp #reset" gets me a reset when decoding a command for free, where a NOP would be !!
Also according to the manual MOV sets C if the top bit of the source is set so "if_nc jmp #reset" gets me a reset when reading data/address bytes. Just one instruction as in your solution.
Am I thinking right here? Does MOVS set Z according to the 9 bit source value or the original 32 bit source. The latter would not work here.
'Read a command from the master Propeller
'Assume the data bits are on P0 to P7, P8 is the reset/initiate bit
waitpeq state,mask 'Wait for edge on the clock bit
movs command_vector, ina wz 'Read the command bits and "initiate/reset" bit, Z set if value = 0
if_z jmp #reset 'Reset if data and initiate bit are all 0
command_vector jmp #0-0 'Jump to the command handler,
... 'N.B. Commands are COG addresses of handlers
... 'and must be %1xxxxxxxx
...
...
a_command 'Read an address byte from the master
'Assume P31 is the reset/initiate bit
waitpeq state,mask 'Wait for edge on the clock bit
mov somewhere, ina wc 'Move that somewhere useful, carry set if bit 31 = 1
if_nc jmp #reset
...
...
'Read a data byte from the master
'As address above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Does MOVS set Z according to the 9 bit source value or the original 32 bit source.
Neither one. The z flag is set if and only if the entire resulting destination (all 32 bits) is zero. The explanation of the flag behavior in the manual is in error.
heater,
In the case you brought up, where the remote COG needs to be reset, I think this can be reasonably handled by using the existing COGINIT or COGSTOP / COGNEW mechanism. The 100us overhead, while long, is not terrible for a re-initialization operation and it ensures that the code and the variables in the cog are restored to a known state. I'm really not opposed to having an option to reset a cog without reloading its memory. I think it's reasonable though to have a "main" cog acting as a supervisor that can detect the circumstances for a re-initialization and initiate that programmatically rather than some kind of I/O initiated reset.
Do remember that Chip has discussed a whole variety of additional functions for Prop II including some kind of auto-increment addressing. I don't know how far along he is on those enhancements and how committed he is to them, but they would impact the implementation of the handling of external RAM as much as anything we're discussing here. Without some details on how Chip is enhancing the instruction set, it's hard to judge what would be useful to add and what would not.
Other enhancements that might be useful here, but might be hard to implement would be optional pullups, optional Schmitt trigger inputs, optional edge triggered inputs (although the counters do provide simple cases of the latter).
I like your idea of edge-triggered inputs a lot. It would simplify the capture of fleeting events without having to waste counters. Plus, it would keep the events mapped into the input registers where the waitpxx instructions can access them. From a programming standpoint, ina and inb could be made read/write, with "1" bits written there reset the sticky bits to zero.
Mike, After we have argued this case "all around the houses" your reason prevails. 100us for this particular case is not bad. The supervisory COG can also be doing something else if need be. On the scale of the Prop as RAM problem perhaps the time checking for a rest pin while clocking data won't even show up anyway, but I'll go with a supervisor COG.
I still think there may be circumstances where a rest or other JMP action as described (not full scale interrupt handling) may be useful but as you say with the Prop II enhancements basically unknown its hard to judge a neat suggestion from a duffer.
I have taken the liberty of removing "interrupt" from the this threads title. Trying to avoid firing up that debate again.
I think thats the end of this debate. Thank you all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've run into situations where it would be very handy to have one Cog set another Cog's PC,
not just to zero but any arbitrary value. That allows a Cog to be loaded up with a number of
task handlers and allows the required one to be executed without having to sit in a loop polling
hub memory for a trigger and a jump table to where it needs to go.
That wouldn't solve the issue of needing two Cogs though to quickly react to a hardware pin
while the Cog is waitpnxx'ing on other pins.
All in all, throughout this thread there as been a lot of hands up in favour of a "emergency jump" idea whether it be a "COG reset pin" as originally stated or "one COG forces anothers PC address" as Hippy suggests.
If there is any simple, low real-estate and general purpose way of doing this perhaps Chip should give it some consideration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I could see that being able to set the cog's start address and also the load length (which could be zero) would be a nice feature.
It would be faster to only load the required number of longs, rather than the whole 496 longs. The issue of the registers is still a point - should they be zero'ed ? - maybe this is an option also.
There would be another advantage to setting the cog's start address. A common piece of code could be used with a jump table at the start. Depending on the start address (meaning offset from the beginning address) you could define the code to be executed. This could also be useful without loading using the same concept - when a copg has completed its task it idles (waitpeq that never happens) waiting for a new start address to be "jammed" to execute a new routine which is already loaded in the cog.
Food for thought
Just thinking how you would do this...
A new "cogrestart" command with the "par" parameter specifying a start address and load length. Note the par register would now not have a pointer to a hub table. If the load length is "0" then nothing is loaded and the cog state remains unaltered (registers not changed, previous par unchanged, and flags not changed, only the program counter is jammed with a new value).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
like cogs.
My "flying nutcase friends" tell me off for calling them propellors, apparently, technically, they are "Air Screws"!
Interrupts don't necessarily make a system non-deterministic.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Who said anything about saving state or context? I just want to be able to bailout, jump, somewhere. Forget about return addresses and pushing registers etc. A simple program counter reset would do.
Carl, what do you mean "has no general purpose registers" one way of looking at it is that it has 496 general purpose registers per COG! All of them are index registers. In MOV a, b BOTH a and b are indexes which can be set as required with MOVS and MOVD.
As far as I know all normal CALL instructions modify storage, the stack, and registers, the stack pointer. The Prop's CALL instruction actually does not exist, it is a use of JMPRET that the assembler automatically configures to put the return address at the end of your procedure. If you use JMPRET instead of CALL you can put the return address anywhere you like, i.e. you don't have to modify instructions in your stored program. But then of course it is up to your procedure to find its way "home" as it were.
Carl, "While I'm unconvinced that determionacy by that definition is actually achieved, nor that it is a particularly useful thing to achieve in any case," For sure it is actually achieved, you write your loop and that's it, you know EXACTLY how long it will take. Nothing can barge in and disturb that fact. For sure it is also VERY useful. High speed serial coms, video, USB etc would not be possible with out it.
I do take your point that some times one can find oneself using only a small fraction of a COGs power for some small task, however there are ways around that in many cases, depending on the real-time constraints. For example there are drivers for multiple serial lines in one COG.
The ability to execute code in HUB storage is there, it is called Large Memory Model (LMM) as used by ImageCraft C. There is a speed penalty to LMM, but if you need a lot of code in an app you have it + 7 "interrupt handlers" in the other free COGs, not bad.
I wish we had a "standard" LMM kernel to write to and tools that would make writing LMM in assembler easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
"Interrupts don't necessarily make a system non-deterministic."
Could you elaborate on that?
Seems to me that if an interrupt source is not synchronized to you CPU clock, i.e. real world events, then whatever is running can be disturbed at any time and I have no timing determinism. If the interrupts are synchronized to the CPU clock I probably don't need them anyway.
I guess it depends on what degree of determinism we are aiming for. For example in the case I opened the thread with I want an instant response to a pin no matter what I'm doing, I hate to say "like an interrupt". Does not need to be at any deterministic time. But then I want to get on with a cycle of events in a very deterministic way unless hit with that pin input again.
Perhaps you could give an example of deterministic use of interrupts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1: You get lots of interrupts going at once.
2: You fill up gigabytes of memory with stuff, that no one knows what it is, or what it's doing.
3: More interrupts.
4: Write memory to and from disk, a lot (because you filled all the gigabytes of RAM).
5: More interrupts.
This determines that the screen will turn blue and the computer will stop working!
See, very deterministic.
Heats, I see what you mean, a PC (program counter) reset to start point. Not an "interrupt", a "Jump To Origin", or if Chip could fit it on a "Jump To Point", where
point is a loaded (0-511) address. He would also need to build a loadable 32 bit mask so that you could assign a pin, this (I imagine) would need a "desired state"
bit, then in hardware he could mask of the state and compare to the desired. It's a neat idea for the interrupt hungry hoardes
Your sacriligous, heretical suggestion, is the best idea I've heard of on this subject, and in a way Carl is agreeing with you in that he sees the rest of the Props
architecture as making interrupts easy to manage.
The XMOS chip has interrupts and is fully deterministic.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
On the matter of COGs, it made sense to me this way: If you imagine the thing as a network of software gears, said gears would mesh at specific ratios. This is COG to HUB transfer window. Code written with loop times that are a harmonic of that meshing, which is a result of the round robin access cycle, perform best in terms of throughput and consistency (deterministic behavior).
BTW: On multi-processing systems, where more than one instruction is being executed at the same moment in time, this round robin affair makes most communication problems timing problems, and that plays well with Phil's observations on Propeller behavior. This is why the locks see little use, IMHO. On multi-processor systems where this isn't true, there exists a lot more complexity in the communication between processors and use of shared resources. In that scenario, the number of possible states would be considerably higher, demanding a higher silicon cost, and software cost.
There is another factor in play here as well. We are talking determinism in the context of the code we write. Depending on what that code is, determinism might be in play or might not, as has been observed on this thread. At the silicon level however, it's always in play. (I think, and am interested in discussion on that element of things --the propeller is really simple in a lot of ways, and I'm not always sure why!) This keeps the silicon cost simple, in that the number of managed states is kept to a minimum. Given the comments I've seen Chip make on various, "what if?" threads, this is one of the primary goals surrounding the design of the propeller. Doing this means designing in a way that presents useful tools where software solves the problem, and it means very testable silicon in that states to be managed internally are kept to a minimum.
(And I don't know a lot about that element of things! Very interested in comments along those lines.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I too would be interested in seeing an example of deterministic use of interrupts. IMHO, doing that is actually a latched.. Could you compare and contrast those?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
If so, an addition to the existing instructions that permitted this would then enable a supervisor COG to perform that task, based on the existing pin state detect logic. Wouldn't just doing that solve the problem?
And that is setting aside, using a powerful CPU for a small task. Agreed on that, but was just wondering, if I understood the earlier conversation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/3/2009 6:08:11 PM GMT
However, as Phil explained, "deterministic" timing as used in Prop literature really means "(pre)determinable within a range-of-variation of·one instruction time".· That's not a definition I would have used, but it's perfectly acceptable in technical discussion, as long as it's predefined.· Technical jargons, especially those confined to specific hardware designs, often predefine words in a way that's more specific than their meaning in the general language.· That's normal, and necessary.
In that sense, by the way, I think determinacy (in the special sense)·is easy to achieve with interrupts, too -- but only if they occur singly, which would imply that each processor can serve only one external device.· That's the case now with the Prop -- except that with interrupts it could also perform one nondeterministic background task at the same time.· Performing a background task in a cog, or serving more than one external device in a cog, would kill that determinism in serving exernal devices.· I think that's no loss.
In the few cases (someone mentioned display timing and serial communications) where such determinism is a useful technique, one could use timer interrupts to do the same thing, or simply not enable interrupts for that particular cog.
Re:· "airscrews" -- Kensong, your friends are making sport with you.· Propeller is the usual term, especially among pilots.· Propeller is less specific:· ships have propellers that are not airscrews.· Mariners often call their waterscrews simply screws.· Attack submarines, for example, ·listen for screw noises and are carefully designed to minimize their own screw noises.
Heater, your thread is an esecially interesting and (here anyway) somewhat controversial one.· It must be expected that it would wander a bit.· Interrupts are one way to do what you want, so interrupts would come into discourse even had you not used the word.· Another way would be to have a way to specify, or example,·that "if this pin goes high, this cog's program counter is reset".· It would be best if this condition would work only once -- more or less like an Airbus 320, which has a proven ability to land on water, but only once.· Then the cog whose PC was reset would have to set that condition again after (1) it had serviced the pin, and (2) the pin was low again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 2/3/2009 4:52:49 PM GMT
In regards to your other comment "It breaks by heart to use a whole 32 bit CPU for such a simple task!" I read an article (IEEE Transactions) years back about maximizing CPU utilization on mainframes and super minis. The authors response was to point out how much cars cost, and how many cars sit unutilized in a parking lot or garage for most of every day. Billions of dollars in equipment that is only utilized for an hour or two each day on average. While I do like to get the most use possible from any chip I use, I would rather use another cog or even add another prop to avoid the complexity of interrupts and re-entrant code. That may not be the way to go for a product that will sell in the thousands for $19.95 at Walmart, but it makes sense for higher value small volume use.
Your idea of having a pin start a cog at a specific location is a pretty good idea though. It avoids most of the complexity of interrupts, allows a high speed response to an external signal, and does not tie up an entire cog waiting for one pin. The problem is what else does the cog do, and how do you return to doing it without saving the state (at least the address where it was interrupted) of that process. While I wouldn't mind seeing something like this implemented, I would rather see more cog and hub ram, more I/O pins, higher speed, and more cogs in that order.
As kensong said "There is nothing in real time control that the Propellor wouldn't be capable of, but as a graphics, number crunching, high speed communicator of database machine we're really off it's original target playing field", I could not agree more. There are lots of chips available that are great for graphics, number crunching, and databases, but there is only one Propeller.
I was just responding to Heater's request for a deterministic system using interrupts!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I'am not for interupts. Not for Reset in that method You describe.
But for on Prop II.
1. Time slice register for al WAIT instructions.
2. One (JUMP XXXX on PIN,xx) instruction that solves most problems describe on this thread in my opinion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I am with heater. What is wrong in asking for the program counter to be reset ? I will add something more:
why not have a register WO/RO that
when written can set a 8 bit mask, 8 bit edge selector and 8 pin group (eg. you can not choose any pin for vga just a group of them) enabling the function when it's not equal to zero
and when read give previous program counter value and the 8 pin group state (at the moment of the event)
No need for a stack (in case it will be user duty), possibility to jump back to where the main program was stopped, possibility to perform a jump based on event source.
How many of you crave for more cogs in the new prop? It seems that's never enough (same for me) so what's wrong in the opportunity to run some background tasks? At the end, it's up to the user to use this functions, no one will shoot the ones not using it. If it's cheep, it not require a full interrupt structure, easy to do in silicon why not?
Heater, in my opinion it's a useful idea.
Perhaps I am campaigning for a pin to reset like functionality, no stack, no return address, no reloading of COG or counters just a jump.
However I think I'd prefer if the emphasis of the thread title and discussion were on "The case" that is, the fastest possible solution with the current Prop to the problem I presented. Phil has proposed something very nice with a minimum of external logic which I like. What about without hardware assistance ?
Then I would like to propose another problem:
1. Assume you have a bunch (4 to 8 say) of short routines (20 or 30 instruction say) that in a normal CPU would be interrupt handlers for some different devices.
2. Assume you don't have enough free COGs to put one routine in each waiting on a pin.
3. Or philosophically you don't want to waste an entire 32 bit CPU on hand full of instructions.
4. Assume that the real-time requirements are such that 1 COG can handle the processing/bandwidth of all routines combined.
5. Assume for simplicity that all these routines have the same priority.
What is the simplest PASM "framework" to fire off all these routines at appropriate moments giving each one a fair share of CPU time? Solution should of course be as fast as possible. Solution should probably use wait(something) so as to conserve power. Solution should probably allow for the easy removal of "handler"routine into its own COG if required.
I can think of some long winded naive solutions but I'm sure some PASM wizards here could do better.
Perhaps something with:
WAITPNE state, mask
MOVS vector, ina
NOP
vector JMP #0-0
Or such. If you arrange the "wait" inputs to be in the right pins.
Such a "frame work" could be generally useful and make those who miss interrupts happy[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For example, Carl, now I'm with you. You are pushing the idea of determinism down to the sub clock/instruction cycle level at which point there must be some latency (jitter) in response. So yes most CPUs can't beat that issue. However I was thinking, if your CPU was a fully static design one could stop its clock until the interrupting event occurs. Then you have a precisely known latency that is always the same. Of course you then need another CPU running to handle your background stuff.
@potatohead: As far as I can tell the conclusion here is that you cannot restart a COG with out a reload. That is also my reading of the manual now.
@Carl: "if this pin goes high, this cog's program counter is reset". Yeah that's what I proposed in the original post. You are right it would be neat if it only happened once on an edge. In my example problem that is not so important as when the pin is active things would stay reset or looping though reset until the input goes passive. Yes, I wish I never mentioned "interrupt". The interrupt discussion has been thrashed to death on this forum especially when any mention of the Prop II comes up. Usually, it seems, those who are new to the Prop are appalled at it's lack of stack and interrupts etc. and immediately start suggesting it should sprout them. Takes a while to get ones head around how things are done around here.
@Sapieha: Yep there must be other better ways solve the problem present in the top post. I'm sure Chip will come up with some surprises[noparse]:)[/noparse] Small, simple, elegant, and mind bendingly general in usefulness.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I like the reset the COG PC without reloading it idea also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
It uses threads, as you have suggested.
Each XCore has eight event-driven hardware threads, each with its own set of 16 registers. A high performance XLink switch supports low latency and deterministic communication between the threads in each XCore, and between XCores. Threads operate as logical cores, communicating via the XLink switch. See the XMOS documentation for more details.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 2/3/2009 8:31:48 PM GMT
Here's how a generalized "interrupt" processor might be coded for the Propeller. This one will respond to low-going pulses on the active pins. The pulse widths have to be at least as long as the sum of all the ISR execution times, plus a little overhead. Otherwise, some external set/reset logic will have to be incorporated to make sure shorter pulses are captured and accounted for.
init mov state,ina 'Read the current state. loop mov prev_state,state 'Transfer current state to previous state. waitpne prev_state,mask 'Wait for state to change. mov state,ina 'Read the new state. mov flags,state 'Save it in interrupt flags register. xor flags,prev_state 'Identify the bits that have changed. andn flags,state wz 'Mask out changes from low to high. if_z jmp #loop 'Loop back if there aren't any high-to-lows remaining. test flags,mask0 wz 'Test each bit for an active interrupt, if_nz call #isr0 ' and process if set. test flags,mask1 wz if_nz call #isr1 test flags,mask2 wz if_nz call #isr2 test flags,mask3 wz if_nz call #isr3 jmp #loop 'All have been processed, so loop back.-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/3/2009 9:33:23 PM GMT
When I proposed using a Propeller as external RAM you suggested a scheme of using an 8 bit data bus, a clock and a "initiate" signal. SPI fashion. Whereby a command byte is clocked from Prop to Prop followed by address bytes followed by data bytes in which ever direction. All in all I like this idea better than my other multi control line effort and plan to implement it.
So far so good but that "initiate" signal is a problem. Not so much to initiate a transfer but to say to the remote Prop "let's start over no matter what we are doing now". After all the master Props COG doing this may have been just started or restarted and we want to be sure we are in sync with all those commands and addresses and data bytes at the other end. And we don't want to have to reset the entire remote Prop to do this.
Well, checking for that "initiate" signal requires instructions and time out of every data transfer cycle.
So you see now where the idea for a COG reset came from. It's not to get an ""instant" reaction to some effectively unrelated external event" as you say, its actually to speed up the data clocking rate. How long the reset actually takes is not an issue as it will not happen very often. It's exactly the opposite of "whatever is being done repetitively doesn't need to be shut down".
Then it occurred to me that this is, hopefully, a simple feature with a lot of uses. So I dared to suggest it. And by the way how bizarre is it to have a CPU that you cannot just reset?
All in all, I don't want a reset or interrupts as such. I just want to get my Prop as RAM working as fast as possible. Or indeed any Prop to Prop Command/Response system.
That boils down to a Prop to Prop communication issue. Which itself boils down to a COG to COG communication issue. After all I may want to communicate with a COG on my Prop using the same mechanism, whatever it is. Not just for RAM access but general command response stuff. And that is something I DO hope is looked at for Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I liked your solution to my reset problem with external hardware but aren't we missing something obvious here?
What if I wired by 8 bit command/data bus to pins P0 to P7. Then I connect the reset/initiate bit to BOTH pins P8 and P31 !
Now according to the manual MOVS sets sets Z if value = 0 so a simple "if_z jmp #reset" gets me a reset when decoding a command for free, where a NOP would be !!
Also according to the manual MOV sets C if the top bit of the source is set so "if_nc jmp #reset" gets me a reset when reading data/address bytes. Just one instruction as in your solution.
Am I thinking right here? Does MOVS set Z according to the 9 bit source value or the original 32 bit source. The latter would not work here.
'Read a command from the master Propeller 'Assume the data bits are on P0 to P7, P8 is the reset/initiate bit waitpeq state,mask 'Wait for edge on the clock bit movs command_vector, ina wz 'Read the command bits and "initiate/reset" bit, Z set if value = 0 if_z jmp #reset 'Reset if data and initiate bit are all 0 command_vector jmp #0-0 'Jump to the command handler, ... 'N.B. Commands are COG addresses of handlers ... 'and must be %1xxxxxxxx ... ... a_command 'Read an address byte from the master 'Assume P31 is the reset/initiate bit waitpeq state,mask 'Wait for edge on the clock bit mov somewhere, ina wc 'Move that somewhere useful, carry set if bit 31 = 1 if_nc jmp #reset ... ... 'Read a data byte from the master 'As address above.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
In the case you brought up, where the remote COG needs to be reset, I think this can be reasonably handled by using the existing COGINIT or COGSTOP / COGNEW mechanism. The 100us overhead, while long, is not terrible for a re-initialization operation and it ensures that the code and the variables in the cog are restored to a known state. I'm really not opposed to having an option to reset a cog without reloading its memory. I think it's reasonable though to have a "main" cog acting as a supervisor that can detect the circumstances for a re-initialization and initiate that programmatically rather than some kind of I/O initiated reset.
Do remember that Chip has discussed a whole variety of additional functions for Prop II including some kind of auto-increment addressing. I don't know how far along he is on those enhancements and how committed he is to them, but they would impact the implementation of the handling of external RAM as much as anything we're discussing here. Without some details on how Chip is enhancing the instruction set, it's hard to judge what would be useful to add and what would not.
Other enhancements that might be useful here, but might be hard to implement would be optional pullups, optional Schmitt trigger inputs, optional edge triggered inputs (although the counters do provide simple cases of the latter).
I like your idea of edge-triggered inputs a lot. It would simplify the capture of fleeting events without having to waste counters. Plus, it would keep the events mapped into the input registers where the waitpxx instructions can access them. From a programming standpoint, ina and inb could be made read/write, with "1" bits written there reset the sticky bits to zero.
-Phil
Mike, After we have argued this case "all around the houses" your reason prevails. 100us for this particular case is not bad. The supervisory COG can also be doing something else if need be. On the scale of the Prop as RAM problem perhaps the time checking for a rest pin while clocking data won't even show up anyway, but I'll go with a supervisor COG.
I still think there may be circumstances where a rest or other JMP action as described (not full scale interrupt handling) may be useful but as you say with the Prop II enhancements basically unknown its hard to judge a neat suggestion from a duffer.
I have taken the liberty of removing "interrupt" from the this threads title. Trying to avoid firing up that debate again.
I think thats the end of this debate. Thank you all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
not just to zero but any arbitrary value. That allows a Cog to be loaded up with a number of
task handlers and allows the required one to be executed without having to sit in a loop polling
hub memory for a trigger and a jump table to where it needs to go.
That wouldn't solve the issue of needing two Cogs though to quickly react to a hardware pin
while the Cog is waitpnxx'ing on other pins.
If there is any simple, low real-estate and general purpose way of doing this perhaps Chip should give it some consideration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It would be faster to only load the required number of longs, rather than the whole 496 longs. The issue of the registers is still a point - should they be zero'ed ? - maybe this is an option also.
There would be another advantage to setting the cog's start address. A common piece of code could be used with a jump table at the start. Depending on the start address (meaning offset from the beginning address) you could define the code to be executed. This could also be useful without loading using the same concept - when a copg has completed its task it idles (waitpeq that never happens) waiting for a new start address to be "jammed" to execute a new routine which is already loaded in the cog.
Food for thought
Just thinking how you would do this...
A new "cogrestart" command with the "par" parameter specifying a start address and load length. Note the par register would now not have a pointer to a hub table. If the load length is "0" then nothing is loaded and the cog state remains unaltered (registers not changed, previous par unchanged, and flags not changed, only the program counter is jammed with a new value).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
Post Edited (Cluso99) : 2/5/2009 12:31:41 AM GMT