Has anyone considered how magical the coginit PASM instruction is?
In one instruction we can:
1) Find a spare processor to run some code on.
2) Return an error if there is none left.
3) Load the required code into the core.
4) Give it a parameter, which in turn can point to a whole array of parameters
5) Start the core executing.
Never really though about it before but is there any other processor that has such an instruction?
The xmos devices don't not have such a thing. Sure they can start threads but it's for sure not a single instruction affair. Also threads on xmos cannot arbitrarily start child threads on other cores. Cheifly because cores do not share RAM I guess.
What this means is that if I write some complicated object that wants to run in a number of threads then either it has to rely on being able to run all the threads in one core, in which case it can start them itself with the XC "par" construct. Or I have to leave it up to the user of my object to start the threads on which ever cores he chooses, which can only be done from the applications "main" function. Hmmm...well perhaps that's the only way to deal with that situation as multiple threads probably means using lots of I/O which the users gadget may have distributed around different cores. Again that limitation that xcores can only "see" their own pins, not the ones connected to there cores.
I think you really skipped on reading the XS1 architecture document. Your main mistake: threads on xmos can in fact start other threads at will. Your other claims, while true, are implying the wrong thing.
So, threads can easily start other threads at runtime. You should not confuse what's idiomatic in one programming language (XC) to what the architecture actually allows. How RAM factors into this I don't see, because when you start a thread you simply provide a working area for the code that you intend to run. For all you care, this can be allocated at runtime from the C heap. In typical cases you only need to carve a block of RAM for stack and data storage (indicated by SP and DP registers). The data access can be done relative to SP, DP, constant pool, and any register used as an index.
I have an implementation where one thread has a large library of subprograms stored in external EEPROM, and will start them as necessary on a dynamically allocated thread, using dynamically allocated RAM. There's no magic to it.
The finding of a spare processor is handled by the resource management hardware on XS1. The GETR instruction that gives you a "spare" unsynchronized thread, synchronizer, channel endpoint, timer or lock. After you acquire a thread by GETR, you use TINITxx family of functions to set thread's PC, SP, and other registers. Then you do a TSTART to get the thread running. While not a single instruction, the basic thread startup is done in 6 instructions (+ loads). When a thread wants to terminate itself, it uses TFREE to return itself back to the unused thread pool. To pass any number of parameters to the started thread, you either use RAM or registers via TSETR -- the latter lets you set any register, in any thread, to any value.
The threads on XS1 can be synchronized to start together by acquiring them with GETST instead of GETR, and they then have a master thread that can easily terminate them all at once.
The normal way of communicating between threads is via communication channels, so it's usually immaterial as to where exactly are your object's threads running. They can be on one core, or on many cores, and letting the user of your object take care of such allocations is the right thing to do. Only the end user has the knowledge needed to partition the system to fully utilize available resources in a given application, such as RAM, timers, etc.
So, idiomatic threads do not share RAM with other threads, and are self-contained in this respect. If you need to share constants/look up tables, or buffers, then your thread group should be launched from a common master thread, it will do so on one core, and this requirement should be well documented to the user of your code.
My take is that is a complication that may be usefull in some cases but in general messes up the determinism of the Prop. No longer could you just throw objects from OBEX or elsewhere into your project and be sure that they don't have bad timing interactions with each other.
It all depends on the programming style. If the object you're using is coded to depend on instruction timings, then yes, of course you're out of luck. This kind of coding is precisely what's NOT the way to do it on XS1, and would be IMHO the biggest mental leap to be taken when transitioning from a Prop or SX48 to XS1.
Even on the Prop, you could avoid it: sprinkle your code with WAITxxx instructions, so that every input or output happens at a predetermined time, and you don't have the problem anymore -- just like that. It may seem tedious on the Prop (or PIC/SX48, etc) since neither Spin nor any other high-level language that I know of lets you do it without the tedium. On a Prop it also will slow your code down, since the extra waits are not free.
On XS1, though, executing an input or output at a preset time (or with a timestamp) is a single line affair in the XC language, and it is free in the sense that the hardware timers drive the ports and you don't need any software for that, other than programming the registers to desired values.
One could port XC to Prop or other deterministic architectures (SX48, PIC12, eZ8) to provide this functionality in a high-level language setting, but the select statement that waits on multiple events can only be approximated in a tight loop since Prop cannot wait on more than one thing at once in a single COG. On architectures with interrupt support, like eZ8, there is a reasonably good approximation for XS1's WAIT instruction (or XC's select statement): you set up interrupt handlers, then enable interrupts and spin in a tight HALT loop. This usually provides for fixed latency (at the level of CPU clock cycles) between the occurrence of an external event, and your code handling it. At least on eZ8 it works as you'd expect it to. On many of my projects done on eZ8, the main loop is, in C, simply while (1) { asm("HALT"); }
It seems to me, the determinism in the propeller makes it extremely easy for a human to know what the chip will do at the instruction level, minus a few edge conditions we've identified as of late. In general, the rules for interaction with the HUB, knowing what goes fast and what does not are not that numerous, and code that is written to those rules will always perform as stated on the tin.
What I am hearing is that it is possible to also write code on XMOS devices that works in a similar way, but not anywhere as easy for humans to understand that at the instruction level, thus the tools provided.
Frankly, the ease with which code is compartmentalized and then re-used on the Propeller, is outstanding and well worth the other trade-offs mentioned here, most of which are simple matters of scale. Future Props will have a significantly increased scope of applicability, rendering some of these discussions moot.
Ale, you're right, it is amazing what has been squeezed into 496 longs, and more often a lot less!
Heater, yes, it does need to be 50MIPS as you don't know what the rest of the project is doing, unlike on the Prop, where one cog speed is not affected by anothers cogs app.
The idiomatic way of ensuring that it'd work on XCORE is to have timing requirements supplied with your code. That way the timing analyzer will bomb out and error for you when you compile the project. You're free to choose any requirements you want -- there is definitely no reason to limit yourself to 50MIPS. You simply set your code up so that it requires X MIPS, and then the timing analyzer will ensure this for you. If the user's project can only supply less MIPS, then they can't use your object, or they can use another version of the object that trades off MIPS for some performance metric.
Now of course the timing analyzer doesn't have any magical insight into your code's runtime thread creation, so you could potentially shoot yourself in the foot if you wanted to. But if you stay within XC, you'll be plenty safe. That's how it's set up: XC was designed so that there can be statically proven assurances as to code's safety and performance. Once you mix in C/C++ or assembly code, you're on your own in some respects -- mainly if you create threads at runtime, have memory bugs in C/C++, or share memory between threads.
Wow! Did I miss something overnight? Has XMOS bought out Parallax?
Leon will be pleased!
Ross.
Nope. I merely want to dispel whatever myths/misconceptions are here. I personally would be most happy if PII's analog circuitry for the pin drivers was integrated on XMOS die. I don't care much for Propeller's code-executing core, but the circuitry supplied with each pin driver is nothing to sneer at. On the contrary, it's probably why many of my projects will use PII as soon as it comes out for some fixed-function filtering, and for interfacing with the world out there. The XMOS pins are your bog-standard digital I/O lines, not even very modern ones in the sense that buffered ports are pretty much stuck at having all constituent bits being either inputs or outputs, not individually configurable. So if you have a 4 bit port, there's no way AFAIK to change directions of individual pins. Of course you have plenty of single-bit ports, and if you want, you can collect all related outputs in a single, wider port, as long as you only access it from one thread at a time so that the resource protection exception won't undercut you.
Nope. I merely want to dispel whatever myths/misconceptions are here.
Ok. I guess you don't realize it, but large parts of your posts are covering ground that has been discussed in these forums before (ad nauseum!). I saw at least one post earlier in the thread asking to be pointed to some XMOS reading material - perhaps posting a link might also be the best way to correct any perceieved misconceptions.
It seems to me, the determinism in the propeller makes it extremely easy for a human to know what the chip will do at the instruction level, minus a few edge conditions we've identified as of late. In general, the rules for interaction with the HUB, knowing what goes fast and what does not are not that numerous, and code that is written to those rules will always perform as stated on the tin.
What I am hearing is that it is possible to also write code on XMOS devices that works in a similar way, but not anywhere as easy for humans to understand that at the instruction level, thus the tools provided.
Frankly, the ease with which code is compartmentalized and then re-used on the Propeller, is outstanding and well worth the other trade-offs mentioned here, most of which are simple matters of scale. Future Props will have a significantly increased scope of applicability, rendering some of these discussions moot.
The ease in which the code is compartmentalized and re-used on XS1 is same as on Prop, assuming the code was written by someone with understanding of the architecture. A lot of comments are done by people who have no such understanding, unfortunately. XS1 has only 64kb of RAM per core, so it's limited not unlike Prop is. Yet the benefit of XS1 is that you are not "wasting" RAM on a COG/thread -- any unused RAM is available to other threads.
Otherwise, XS1 and Propeller are very similar, and I can't fathom why people have such wild misconceptions and behave like there were some significant barriers to code compartmentalization and reuse on XS1. I'm using XMOS-provided "objects" without any issues, they are simply given with a spec as to how many threads they use and how many MIPS the threads need to have available, and what is the format of data that I exchange with them. I communicate with the "objects" via communication channels, and can do so from threads running on physically separate chips, too. On a Propeller you have to communicate via the HUB, so if the code you run doesn't share a HUB with the object you're using, you need to devote a yet another COG to communicating. On XS1, the hardware handles communications between cores, and there's no difference between communicating between cores on same chip vs. cores on physically separate chips. The latter of course need some pins, but that's same with Prop.
To give just one example of excellent code reuse on XS1: their USB library, called XUD, provides an entire USB device stack in a single thread. It requires your application to provide one thread to handle each device endpoint, and communicates with them via channels and shared memory variables. The shared memory is needed to support the bandwidth called for by high-speed (480MHz) USB. The setup of the library is very simple, all you need is to correctly attach the PHY to your XS1-L or XS1-G chip, and to link your project with the library. The API provided is as simplistic as it gets. I've got it to work with no problems other than bugs in my code related to the device-specific functionality.
I have been able to tweak this library to limit it to full speed (48MHz), and then it doesn't even need any shared memory for communications, the endpoint threads can be elsewhere on the network. For example the control endpoint (EP0) can be on one chip, whereas the bulk endpoint that streams the data can be on another chip, some inches away from the USB PHY and adjacent XS1 device.
Ok. I guess you don't realize it, but large parts of your posts are covering ground that has been discussed in these forums before (ad nauseum!). I saw at least one post earlier in the thread asking to be pointed to some XMOS reading material - perhaps posting a link might also be the best way to correct any perceieved misconceptions.
Maybe, if so I apologize. The real issue is that XMOS documentation sucks so bad that I can't really point to a single PDF file and say "that's it". Any insight I have has been gathered from collating (in my head) perhaps hundreds of pieces together -- forum posts, source code samples, "formal" documentation, etc. That's a real barrier to entry, and that's why it's so easy to be misinformed. I wish they cleaned up their act in this respect.
Ok. I guess you don't realize it, but large parts of your posts are covering ground that has been discussed in these forums before (ad nauseum!). I saw at least one post earlier in the thread asking to be pointed to some XMOS reading material - perhaps posting a link might also be the best way to correct any perceieved misconceptions.
Some of these misconceptions may have been discussed in earlier threads, but not to the level of detail and clarity that Kuba's provided here. Anyone wanting to understand the differences (and similarities!) between XMOS and the Propeller will be wise to read his posts.
In my opinion, his posts are much clearer and more informative than much of the XMOS documentation (hence my earlier comment that perhaps he himself should write the overarching book he's looking for.)
Ok. I guess you don't realize it, but large parts of your posts are covering ground that has been discussed in these forums before (ad nauseum!).
This thread is specifically about XMOS vs. P2, isn't it? People who are not interested can easily ignore it. I don't think I'm really stealing any customers from Parallax.
I'm inclined to make the same case against such priority schemes in xcore thread scheduling. Possibly usefull for some cases where you want to push the thing over the current limits by a little but in general messy and complicating.
The two are not mutually exclusive, in what I was proposing. (really just a few registers to steer the thread-allocate state engine; the hard stuff is already there.)
You can easily default to operate as now, but allow users the choice, for when that is important to them.
This thread is specifically about XMOS vs. P2, isn't it? People who are not interested can easily ignore it. I don't think I'm really stealing any customers from Parallax.
Mods if you are watching (I know you are) then please move this thread to general discussion forum where it belongs. P2 (codename) to my knowledge, does not exist and therefore it is not relevant to this forum.
(hence my earlier comment that perhaps he himself should write the overarching book he's looking for.)
It seems as though it would be a very nicely informed book that actually adds value for those who care.
While I'm not really interested in promoting competing solutions on this forum, I do think that the "invisible hand of the market" (Adam Smith 1776) is at work for raising the bar. This will eventually lead to more equally nice expose's for the Propeller by those independents who actually understand the product and best practices.
The real issue is that XMOS documentation sucks so bad that I can't really point to a single PDF file and say "that's it". Any insight I have has been gathered from collating (in my head) perhaps hundreds of pieces together -- forum posts, source code samples, "formal" documentation, etc. That's a real barrier to entry, and that's why it's so easy to be misinformed. I wish they cleaned up their act in this respect.
Easy to agree there.
If Sw is as invisible as you seem to be claiming, perhaps you can give some code to demonstrate this ?
Here are two simple tasks / benchmarks : (Prop 1, Prop 2 or Xmos code all qualify)
a) Pulse width measurement.
Target is 32 bit time result, <= ~10ns LSB, Pulse widths OR time-interval, from 10ns+, to >1s, with 10ns precision.
Should work one-shot, and on repetitive waveforms, without false/uncertain returns.
b) Reciprocal Frequency Counter. With a ~100MHz timebase, ideally you should be able to resolve 10ppb/second.
ie 8 digits of frequency accuracy per second, for any frequency from ~1Hz to 20/40/50/100/100+MHz (specify the upper limit)
Simpler designs can include a range-set; more polished designs will include self-range abiity, when polled 100ms-1s intervals, but doing that usually requires a 64 bit capture.
I don't see this thread as XMOS promotion at all. It's more in the line of reconnaissance or intelligence gathering, and kuba is providing some damn good intelligence. Just remember: Eisenhower's wanting to know everything he could get his hands on about Adoph Hitler didn't exactly make him a Nazi fanboy. In the words of C. Montgomery Burns, "I like to keep my friends close and my enemies closer."
Dave, a great idea! Just wouldn't be as big an audience
That's quite correct. The audience here is much larger than the one on the XMOS forums. This may be due to the positioning of the two products.
The Propeller was (originally) targeted at the hobbyist market. In this market, people tend to congregate and discuss their issues and projects and share their code. In fact, the sharing of code with others is one of the primary motivators for hobbyists.
The XMOS chips are targeted at a more professional market. Although there is some technical discussion on the XMOS forums, most of the serious work being done with these chips is by companies targeting commercial applications. These people tend to regard their work as IP and are more loath to share it with others.
Some commentators here are so parochial! Please, we're one big choir loving the propeller (duh) but do we have to be so blind as to the merits of any other solutions, especially when more appropriate for a specific job? Does it boil down to some sort of deluded religion (like any other kind of religion, btw)? The question (quite legitimate and pertinent, Imho) was about comparing the tech aspects of P2 (P1, really) and Xmos. Interesting question to me, as I use both. I find the propeller much easier to use but the xmos more challenging and powerful. And complicated. The usual mob feasted on Leon, which was quite predictable, in the sense of the 5 or so same posters hitting the same nail over and over again. Yawn, Boring. It's almost a given now. The same ignoramus feasted on French as well, for good measure. Hope you feel better now that it's out your chest. Soon it will be called by some devout a Liberty Propeller, no doubt. However, I feel some comfort at seeing them squirming and being more careful with Kuba's postings, which speaks volume. Moving this thread to some remote outpost of the forum? At this point? Why not? It's always a good way to silence knowledge and plurarity. Especially when it become more inconvenient with each additional posting. Kudos to Kuba for his very detailed, objective, and technically validated insights. I learned much, thank you Kuba. As for the other negative-minded posters, perhaps their insecurity shows their lack of technically-grounded knowledge outside the Propeller church. Breaking news: The propeller is not a new golden calf, it's just a chip! Get over it. I really miss the time when this forum had more respect, civility and open-mindness. Cheers, Alex
I also considered XMOS for awhile, but i didn't like the choice of programming languages(C or nothing)... There didn't seem to be any projects built with it and it seemed like the company only had a few boards to choose from. Plus, the one tutorial video i saw, featured a man who acted more like he was tripping on acid, then giving a lesson about a microcontroller:)... All jokes aside, i don't really get the big deal about them? They are not very easy to learn, they aren't that powerful(When compared to a ARM) and i don't see much of a community for them... AS for being a British company, i can fully understand pride for your country. I think the Picaxe(Also British) is a excellent platform and i would highly recommenced it to beginner... Maybe i am still to much of a newbie?
I also considered XMOS for awhile, but i didn't like the choice of programming languages(C or nothing)... There didn't seem to be any projects built with it and it seemed like the company only had a few boards to choose from. Plus, the one tutorial video i saw, featured a man who acted more like he was tripping on acid, then giving a lesson about a microcontroller:)... All jokes aside, i don't really get the big deal about them? They are not very easy to learn, they aren't that powerful(When compared to a ARM) and i don't see much of a community for them... AS for being a British company, i can fully understand pride for your country. I think the Picaxe(Also British) is a excellent platform and i would highly recommenced it to beginner... Maybe i am still to much of a newbie?
Then by all means stick with the Propeller and Picaxe until you get more experience. Both are very easy to work with (at least compared to XMOS, which can be a real bear for a beginner.)
Got a link to the video of the XMOS guy tripping on acid? That I've got to see!
@Sal... The thing about the guy tripping on acid was a slight exaggeration:) I don't remember the exact video, but i think the dude was on the older side. I am not sure?.... I don't really use Picaxe's much anymore. Most projects i have are all Propeller driven. I do have a little C experience(And a tiny bit of PASM knowledge), but not to much. I could code a basic application, but nothing to fancy. I have a Arduino(That i occasionally toy around with) and a couple of MSP430's.. I also bought a few ATTINY85's to try out. My goal is to learn C eventually, but SPIN just looks so clean. C has a very cluttered appearance in my opinion... But, i will have to get over it. Contrary to what Dunkin Donuts says, "America runs on C"
*snip*
One could port XC to Prop or other deterministic architectures (SX48, PIC12, eZ8) to provide this functionality in a high-level language setting, but the select statement that waits on multiple events can only be approximated in a tight loop since Prop cannot wait on more than one thing at once in a single COG. On architectures with interrupt support, like eZ8, there is a reasonably good approximation for XS1's WAIT instruction (or XC's select statement): you set up interrupt handlers, then enable interrupts and spin in a tight HALT loop. This usually provides for fixed latency (at the level of CPU clock cycles) between the occurrence of an external event, and your code handling it. At least on eZ8 it works as you'd expect it to. On many of my projects done on eZ8, the main loop is, in C, simply while (1) { asm("HALT"); }
Actually I think the Prop CAN wait for multiple asynchronus events to happen on input pins. This would let a spare cog emulate an interrupt handler. With a spare pin and a counter in NCO mode setup as a one shot, you could even add a timeout.
mov temp, INA
waitpne temp, mask
xor temp, INA 'ones at any bit that changed
Should wait until any masked bit of INA changes. At that point code would be needed to figure out which bit changed and jump to the appropriate event handler. Should give less than a clock of timing jitter with 5-10 (or more) instructions of overhead before reaching event handler code. (assuming no events happen simultaneously...) It does require a pin for every software interrupt it needs to respond too. (or a soft interrupt pin, and an interrupt vector in hub.)
Lawson
P.S. XMOS vs Prop. biggest advantage I see for XMOS is the multiplier. Otherwise the XMOS seems more complex and harder to deal with. Vs the Prop 2 don't see any advantages for XMOS (other that xmos is avaliable now...)
You have enough experience and the capacity to learn C or another language, as well as other micro-controller architectures. However, if you want to learn those subjects, you need to put aside any biases against them.
David is one seriously cool dude and I'm pretty sure acid has got nothing to do with it. He even had time to chat with me on the forums about xcore determinism over the New Year break a couple of years back. He's also into motorcycles http://www.cs.bris.ac.uk/~dave/biking.html All of which which put's him in the list of heroes in my book.
OK now I am being a fan boy:)
Mays Law : "Software efficiency halves every 18 months, compensating Moore's Law."
David is also an FRS (Fellow of the Royal Society), which is the top scientific honour in the UK (Newton was one of the first members). His presentations to the occam User Group conferences were very entertaining when the transputer was in its heyday. One of the interesting things he mentioned was a technique for identifying Americans - the stripes on their ties usually slope down from right to left. I always look out for it on TV. Counter-examples seems to be Sam Waterston in Law and Order, his ties are usually European, and Reg Varney in On the Buses, he always wears a tie with stripes in the American direction.
@Kevin....Ahh, thanks for the vote of confidence. I have put off learning C for the longest time and i need to get over it.
@Heater... Like i said, it was kind of a joke:) But yes, i do think it was that man. I think in the video they went to go visit him somewhere and he was talking(Quietly) about the XMOS... It was a few years ago that i saw this video. I meant no disrespect for him, i just thought it was a little strange that's all:)
Comments
So, threads can easily start other threads at runtime. You should not confuse what's idiomatic in one programming language (XC) to what the architecture actually allows. How RAM factors into this I don't see, because when you start a thread you simply provide a working area for the code that you intend to run. For all you care, this can be allocated at runtime from the C heap. In typical cases you only need to carve a block of RAM for stack and data storage (indicated by SP and DP registers). The data access can be done relative to SP, DP, constant pool, and any register used as an index.
I have an implementation where one thread has a large library of subprograms stored in external EEPROM, and will start them as necessary on a dynamically allocated thread, using dynamically allocated RAM. There's no magic to it.
The finding of a spare processor is handled by the resource management hardware on XS1. The GETR instruction that gives you a "spare" unsynchronized thread, synchronizer, channel endpoint, timer or lock. After you acquire a thread by GETR, you use TINITxx family of functions to set thread's PC, SP, and other registers. Then you do a TSTART to get the thread running. While not a single instruction, the basic thread startup is done in 6 instructions (+ loads). When a thread wants to terminate itself, it uses TFREE to return itself back to the unused thread pool. To pass any number of parameters to the started thread, you either use RAM or registers via TSETR -- the latter lets you set any register, in any thread, to any value.
The threads on XS1 can be synchronized to start together by acquiring them with GETST instead of GETR, and they then have a master thread that can easily terminate them all at once.
The normal way of communicating between threads is via communication channels, so it's usually immaterial as to where exactly are your object's threads running. They can be on one core, or on many cores, and letting the user of your object take care of such allocations is the right thing to do. Only the end user has the knowledge needed to partition the system to fully utilize available resources in a given application, such as RAM, timers, etc.
So, idiomatic threads do not share RAM with other threads, and are self-contained in this respect. If you need to share constants/look up tables, or buffers, then your thread group should be launched from a common master thread, it will do so on one core, and this requirement should be well documented to the user of your code.
Even on the Prop, you could avoid it: sprinkle your code with WAITxxx instructions, so that every input or output happens at a predetermined time, and you don't have the problem anymore -- just like that. It may seem tedious on the Prop (or PIC/SX48, etc) since neither Spin nor any other high-level language that I know of lets you do it without the tedium. On a Prop it also will slow your code down, since the extra waits are not free.
On XS1, though, executing an input or output at a preset time (or with a timestamp) is a single line affair in the XC language, and it is free in the sense that the hardware timers drive the ports and you don't need any software for that, other than programming the registers to desired values.
One could port XC to Prop or other deterministic architectures (SX48, PIC12, eZ8) to provide this functionality in a high-level language setting, but the select statement that waits on multiple events can only be approximated in a tight loop since Prop cannot wait on more than one thing at once in a single COG. On architectures with interrupt support, like eZ8, there is a reasonably good approximation for XS1's WAIT instruction (or XC's select statement): you set up interrupt handlers, then enable interrupts and spin in a tight HALT loop. This usually provides for fixed latency (at the level of CPU clock cycles) between the occurrence of an external event, and your code handling it. At least on eZ8 it works as you'd expect it to. On many of my projects done on eZ8, the main loop is, in C, simply while (1) { asm("HALT"); }
Leon will be pleased!
Ross.
What I am hearing is that it is possible to also write code on XMOS devices that works in a similar way, but not anywhere as easy for humans to understand that at the instruction level, thus the tools provided.
Frankly, the ease with which code is compartmentalized and then re-used on the Propeller, is outstanding and well worth the other trade-offs mentioned here, most of which are simple matters of scale. Future Props will have a significantly increased scope of applicability, rendering some of these discussions moot.
Now of course the timing analyzer doesn't have any magical insight into your code's runtime thread creation, so you could potentially shoot yourself in the foot if you wanted to. But if you stay within XC, you'll be plenty safe. That's how it's set up: XC was designed so that there can be statically proven assurances as to code's safety and performance. Once you mix in C/C++ or assembly code, you're on your own in some respects -- mainly if you create threads at runtime, have memory bugs in C/C++, or share memory between threads.
Ok. I guess you don't realize it, but large parts of your posts are covering ground that has been discussed in these forums before (ad nauseum!). I saw at least one post earlier in the thread asking to be pointed to some XMOS reading material - perhaps posting a link might also be the best way to correct any perceieved misconceptions.
Ross.
The ease in which the code is compartmentalized and re-used on XS1 is same as on Prop, assuming the code was written by someone with understanding of the architecture. A lot of comments are done by people who have no such understanding, unfortunately. XS1 has only 64kb of RAM per core, so it's limited not unlike Prop is. Yet the benefit of XS1 is that you are not "wasting" RAM on a COG/thread -- any unused RAM is available to other threads.
Otherwise, XS1 and Propeller are very similar, and I can't fathom why people have such wild misconceptions and behave like there were some significant barriers to code compartmentalization and reuse on XS1. I'm using XMOS-provided "objects" without any issues, they are simply given with a spec as to how many threads they use and how many MIPS the threads need to have available, and what is the format of data that I exchange with them. I communicate with the "objects" via communication channels, and can do so from threads running on physically separate chips, too. On a Propeller you have to communicate via the HUB, so if the code you run doesn't share a HUB with the object you're using, you need to devote a yet another COG to communicating. On XS1, the hardware handles communications between cores, and there's no difference between communicating between cores on same chip vs. cores on physically separate chips. The latter of course need some pins, but that's same with Prop.
To give just one example of excellent code reuse on XS1: their USB library, called XUD, provides an entire USB device stack in a single thread. It requires your application to provide one thread to handle each device endpoint, and communicates with them via channels and shared memory variables. The shared memory is needed to support the bandwidth called for by high-speed (480MHz) USB. The setup of the library is very simple, all you need is to correctly attach the PHY to your XS1-L or XS1-G chip, and to link your project with the library. The API provided is as simplistic as it gets. I've got it to work with no problems other than bugs in my code related to the device-specific functionality.
I have been able to tweak this library to limit it to full speed (48MHz), and then it doesn't even need any shared memory for communications, the endpoint threads can be elsewhere on the network. For example the control endpoint (EP0) can be on one chip, whereas the bulk endpoint that streams the data can be on another chip, some inches away from the USB PHY and adjacent XS1 device.
Some of these misconceptions may have been discussed in earlier threads, but not to the level of detail and clarity that Kuba's provided here. Anyone wanting to understand the differences (and similarities!) between XMOS and the Propeller will be wise to read his posts.
In my opinion, his posts are much clearer and more informative than much of the XMOS documentation (hence my earlier comment that perhaps he himself should write the overarching book he's looking for.)
The two are not mutually exclusive, in what I was proposing. (really just a few registers to steer the thread-allocate state engine; the hard stuff is already there.)
You can easily default to operate as now, but allow users the choice, for when that is important to them.
Mods if you are watching (I know you are) then please move this thread to general discussion forum where it belongs. P2 (codename) to my knowledge, does not exist and therefore it is not relevant to this forum.
While I'm not really interested in promoting competing solutions on this forum, I do think that the "invisible hand of the market" (Adam Smith 1776) is at work for raising the bar. This will eventually lead to more equally nice expose's for the Propeller by those independents who actually understand the product and best practices.
Just saying.
--Steve
Easy to agree there.
If Sw is as invisible as you seem to be claiming, perhaps you can give some code to demonstrate this ?
Here are two simple tasks / benchmarks : (Prop 1, Prop 2 or Xmos code all qualify)
a) Pulse width measurement.
Target is 32 bit time result, <= ~10ns LSB, Pulse widths OR time-interval, from 10ns+, to >1s, with 10ns precision.
Should work one-shot, and on repetitive waveforms, without false/uncertain returns.
b) Reciprocal Frequency Counter. With a ~100MHz timebase, ideally you should be able to resolve 10ppb/second.
ie 8 digits of frequency accuracy per second, for any frequency from ~1Hz to 20/40/50/100/100+MHz (specify the upper limit)
Simpler designs can include a range-set; more polished designs will include self-range abiity, when polled 100ms-1s intervals, but doing that usually requires a 64 bit capture.
Dave, a great idea! Just wouldn't be as big an audience
-Phil
That's quite correct. The audience here is much larger than the one on the XMOS forums. This may be due to the positioning of the two products.
The Propeller was (originally) targeted at the hobbyist market. In this market, people tend to congregate and discuss their issues and projects and share their code. In fact, the sharing of code with others is one of the primary motivators for hobbyists.
The XMOS chips are targeted at a more professional market. Although there is some technical discussion on the XMOS forums, most of the serious work being done with these chips is by companies targeting commercial applications. These people tend to regard their work as IP and are more loath to share it with others.
You should consider writing a tech manual for the beast.
Then by all means stick with the Propeller and Picaxe until you get more experience. Both are very easy to work with (at least compared to XMOS, which can be a real bear for a beginner.)
Got a link to the video of the XMOS guy tripping on acid? That I've got to see!
Actually I think the Prop CAN wait for multiple asynchronus events to happen on input pins. This would let a spare cog emulate an interrupt handler. With a spare pin and a counter in NCO mode setup as a one shot, you could even add a timeout.
Should wait until any masked bit of INA changes. At that point code would be needed to figure out which bit changed and jump to the appropriate event handler. Should give less than a clock of timing jitter with 5-10 (or more) instructions of overhead before reaching event handler code. (assuming no events happen simultaneously...) It does require a pin for every software interrupt it needs to respond too. (or a soft interrupt pin, and an interrupt vector in hub.)
Lawson
P.S. XMOS vs Prop. biggest advantage I see for XMOS is the multiplier. Otherwise the XMOS seems more complex and harder to deal with. Vs the Prop 2 don't see any advantages for XMOS (other that xmos is avaliable now...)
No, you're not.
You have enough experience and the capacity to learn C or another language, as well as other micro-controller architectures. However, if you want to learn those subjects, you need to put aside any biases against them.
Do you mean the guy with the bald head who speaks very quitely? That sounds like David May. Which wikipedia introduces as "...Professor of Computer Science at the University of Bristol and founder and Chief Technology Officer of XMOS Semiconductor. May was lead architect for the transputer. As of 2007, he holds 34 patents, all in microprocessing and multi-processing."
David is one seriously cool dude and I'm pretty sure acid has got nothing to do with it. He even had time to chat with me on the forums about xcore determinism over the New Year break a couple of years back. He's also into motorcycles http://www.cs.bris.ac.uk/~dave/biking.html All of which which put's him in the list of heroes in my book.
OK now I am being a fan boy:)
Mays Law : "Software efficiency halves every 18 months, compensating Moore's Law."
@Heater... Like i said, it was kind of a joke:) But yes, i do think it was that man. I think in the video they went to go visit him somewhere and he was talking(Quietly) about the XMOS... It was a few years ago that i saw this video. I meant no disrespect for him, i just thought it was a little strange that's all:)