Heater with regard to your last line: the program FastTracker 2 (from the scene group Triton) had a very nice quote referring to windows95 "Windows, the power of yesterday in today's computers" ;-) I always loved it ;-)
Blimey, despite all the friction during most of this thread it has some how acquired a three star rating.
I believe we can thank Kuba for that. He has offered a lot of interesting and unbiased information to the debate.
One technical difference I can see is the way memory is accessed and shared. Correct me if I am wrong (I have never used one), but with the XS1, all 8 threads can see all of the memory so you don't have to copy stuff to and from cog memory, like with coginit. Also, because you can use exactly what you need, you leave the rest of the memory available for the other threads. With multiple instances of the same thread, could they share the same code section, thus saving memory? If so, this would save a lot of memory in some applications.
Speaking of memory, how does one strap on more memory to a XS1?
You are right about the XMOS on-chip memory, the 64k bytes of SRAM for each XCore is accessible to all threads:
Within a single core, tasks can use shared memory to exchange data with other tasks. Tasks can also use channels
to exchange data and synchronize across cores or within a core. Single cycle instructions can exchange a word of data, implicitly synchronizing the receiver with the sender. If shared memory is used, tasks can use single cycle lock-instructions to synchronize.
There is also 8k of OTP memory that can be used for small programs, boot code, and security keys.
External memory is interfaced the same way as on the Propeller, via I/O pins.
Hinv,
Yes you can start many threads all running the same code. They will all get their own data and stack areas.
You can share data areas between threads if you work in C or assembler but the XC language won't allow that.
For the multi core devices each core has 64k RAM, not shared with other cores. So if you want to run the same code in multiple threads on multiple cores that code has to be loaded into the cores where it will run. Still you only have to write it once and the tools will make sure the binary for the threads gets loaded into the right cores.
Hinv,
The X tools will also spread your code for threads around multiple connected chips. They all get loaded in one go by the tools. Upto 16 chips can be handled this way.
@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.
"The C Programming Language by Brian Kernighan and Dennis Ritchie" It is small and to the point, contains the important stuff and written by the creator of C. I wish I had had it as an undergrad.
Yep, but make sure you get the one with "ANSI" stamped on the cover.. otherwise you'll learn archaic C and your code will have things like 'pointer = (struct something *) malloc (size);' instead of the safer (in case you forget to include the header) and simpler 'pointer = malloc (size);'. And code without prototypes etc. This is the kind of bad code I see from a lot of people just out of university, so I'm wondering if they're really using that old, non-ANSI version of the K&R C book.
What competition problem? Have you forgotten the original subject of this thread? You are planning to start a competition between the XMOS and a chip that doesn't even exist yet? Ok - let me shortcut that process for you by emulating the P2 in my head ... There! P2 wins!
Ross.
LOL at Ross.. "emulating the P2 in my head.." I've been reading this thread this morning, and I had to laugh at that.
Is there a way to lock down the scheduler to only use 4 threads so that you can rely on having 100MHz(or 125MHz) threads?
Do these kind of questions get answered on the XMOS forums like all of the ninny questions that graciously get answered here?
I can't wait to get the TurboProp. Then we could do a fair comparison. I would really like to see what PhiPi can do with those intelligent pins. All of that processing power in each pin seems overkill, but not if it is put to good use.
No there is no way to "lock" the thing down to 4 threads, not in the chip or in the tools. However the tools include a timing analyser that can report execution time of functions, selected code blocks or loops. You can specify minimum time requrements for critical pieces of code and have it fail compilation if they are exceeded. All this can be done from the IDE so in the simplest case you just click the timing anslyser icon then select a function and you will imediatly see the time in ns of the function and each instruction within it. If those instructions are greater than 10ns you know you have two many threads in the code.
Yes, pretty much any level of question will get an answer on the forum. I've asked my fair share of newbie questions. Although as you may have seen the traffic there is a lot less. Not so many hobbists about.
I'm getting desperate for the Prop II as well. But there is still a lot to be doing with Prop I.
One thing to measure when comparing MCU's is the size of the code emitted by the compilers. This is somewhat down to the quality of the compiler optimizers and partly down to the nature of the instructions set and how instructions are coded. Smaller binaries means more functionality for your application program.
This is all to be taken with a bucket of salt but the result was that whilst XMOS C and Catalina generate about the same number of instructions the XMOS binary code is about 50% of the size. This is mostly due to X using compact 16 bit instructions rather than the 32 bit that the Propeller requires.
If you want compact code on the Prop you need to go to Spin and take the performance hit of an interpreter.
- clocked buffered I/O makes some things VERY easy
- more MIPS
- channels between cores/chips
- a G4 effectively has 16 x 100Mhz "threads" roughly equivalent to cogs, or 32 not quite as deterministic roughly 50Mhz threads
P2 advantages (based on available preliminary data)
- ADC & DAC on every pin
- "saner" I/O mapping
- >100Mhz I/O
- easy video generation
- CLUT
- 8x 160Mhz (estimated) hard deterministic cogs
Until I can try both side by side, that is the best I can do for a tech comparison
Both will be a pain to prototype with (unless using breakout boards)
Both will have a place in the market, and most people will choose the processor based on how well it fits their application/budget.
Yea and you can add me to that list now. Seriously that describes me almost exactly. I wasted a lot of time with XMOS, at first it appears great and it's built on C so it shouldn't take much to get good at it. I was WRONG uggg, I can't get over the way they implement there I/O structure, it's just awful and un-intuitive to me. Plus you should look at some of the other aspects of the XC language like "timers". I remember first reading their tutorials and of coarse eventually understanding what they were saying, but definitely I kept coming across basic stuff that I had already learned and having to stop and be like "wait, what the heck is going on here again". That is bad, cause once you pick it up you need to be able to move on quickly and not have to go over the same things again and again as complexity is introduced to the basics. Uggg, stay away from XMOS unless they are the only option. And don't expect to pick it up and get rollin like with an arduino. The people at Arduino did it right, let me tell you. Parallax isn't bad either but kinda slow and costs too much for the value you actually get from it.
I have had the XMOS IDE and XC on my own machine before. For really simple things, it is no more difficult to use than an ARM. But if you think you can easily exploit the features that make XMOS uniquely XMOS, you are sniffing glue. One can rattle off a whole list of features, but they are all meaningless if you can't make them work. I know specific cases where very intelligent and motivated individuals wasted months of their lives on XMOS and finally gave up in disgust.
Now, as this thread has been resting for almost a year we can start flogging again with renewed vigour...
Ah, well not really. In the XMOS vs P2 bout the XMOS still wins as it's opponent hasn't shown up yet.
@K2,
From a long time back:
Certainly the 1000MHz you quote can't be applied to a single thread. It is necessarily divvied up into many threads. Even some of its most ardent supporters were not initially aware of that fact. It does make for great headlines, though
I'm can't for the life of me see where anyone ever claimed or was duped into thinking this. XMOS has always been straight about clocks/threads/cores.
@AndreL
Perhaps what we'd all like to hear is more details of the [p2] 3D features you have mentioned.
@K2,
A fast ARM is worth much more than an Xthingy for most tasks simply because it doesn't box the developer into a stupid paradigm
Or perhaps:
"A fast ARM is worth much more than an Propeller thingy for most tasks simply because it doesn't box the developer into a stupid paradigm"
Meaningless in both cases, Chips like Prop and X are not really comparable to chips like ARM. And they are intended for very different application spaces.
Also I don't think the Xthingy boxes you into any paradigm, if you want to run regular C code you can. It provides for threads as do many micro-controllers but you don't need an OS or software scheduler to use threads on X. It provides multiple cores, as does a Prop. It provides an easy way to communicate between cores and/or chips. What's not to like about all of that?.
@kuba
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.
I could do with reading it all again but I did not skip so much. Yes of course an XMOS thread can start another thread at will from an existing patch of code in memory or something dynamically loaded as you have described.
BUT that is on one core. What I can't do on XMOS is:
1) Load a chunk of code from somewhere
2) Find another free core (not thread)
3) Start that core (or probably a thread on that core) running the code chunk.
That's what coginit does. As far as I know you cannot do it on XMOS unless there is already some code running on the other core(s) that receives your code chunk via a channel and starts it running for you.
The next issue is that if an XMOS device could do that, with or without software assist, it's quite likely that the newly running core does not have access to the I/O pins for some device it is driving because on X pins are not shared among cores as they are on Propellers.
Hence my statement about the "magic" of coginit.
Finally, again I see a lot of confusion around the use of the word determinism.
Prop users are into having their code execute exactly as they wrote it in the time they have calculated for it (cycle counting).
Kuba points out that actually it's not the code execution time that matters (as long as it's fast enough) but rather knowing the timing of your inputs and outputs which can be done with hardware assist on the I/O as XMOS does.
BUT I look at a slightly different form of "determinism" as I have stated elsewhere. That is to be able to determine that if I start up a COG running Spin/ PASM from some random object I have downloaded from some where it absolutely will not bugger up the timing of my carefully crafted application.
I cannot do this with XMOS threads for example, that one last new thread can rob by code of execution time.
Kuba points out that XMOS has timing analysis tools to spot this failure but it is still a failure.
Having said that, perhaps that is not such a big issue for most users/applications as I make it out to be.
I can't get over the way they implement there I/O structure, it's just awful and un-intuitive to me. Plus you should look at some of the other aspects of the XC language like "timers".
In the interests of a factual and infromative comparison between devices could you please give details of:
1) What is awful about the XMOS I/O structure?
2) What's the problem with XMOS timers?
Just saying things are bad does not really help unless it's pointed out why. From my, admittedly limited, playing with X devices I/O and timers worked as advertised. Which is not to say there are some features that can frustrate like:
1) Having pins grouped into ports, you have to set a whole port width of pins to input or output together. Which makes randomly tacking devices onto an XMOS trickier than the Prop where all pins are independent and equal.
2) Each XMOS core has it's own set of pins, cores cannot use pins on other cores. Again this can make allocating resources a bit more tricky and again it makes randomly tacking devices onto an XMOS harder.
All in all it makes life harder for the hobbyist tinkerer.
Uggg, stay away from XMOS unless they are the only option. And don't expect to pick it up and get rollin like with an arduino.
That's odd. I found one could get a "hello world" program up on X as easily as you can on Arduino or the Prop, or flash LEDS and such. Yes of course getting the most out of an XMOS, or a Prop requires a lot of study but then that's true of most devices.
Comments
I believe we can thank Kuba for that. He has offered a lot of interesting and unbiased information to the debate.
Cool. I didn't know that. That brings him up a notch in my book too (Ducati 1098 here...)
http://grieg.gotdns.com/blog/?p=207
Speaking of memory, how does one strap on more memory to a XS1?
There is also 8k of OTP memory that can be used for small programs, boot code, and security keys.
External memory is interfaced the same way as on the Propeller, via I/O pins.
Yes you can start many threads all running the same code. They will all get their own data and stack areas.
You can share data areas between threads if you work in C or assembler but the XC language won't allow that.
For the multi core devices each core has 64k RAM, not shared with other cores. So if you want to run the same code in multiple threads on multiple cores that code has to be loaded into the cores where it will run. Still you only have to write it once and the tools will make sure the binary for the threads gets loaded into the right cores.
The X tools will also spread your code for threads around multiple connected chips. They all get loaded in one go by the tools. Upto 16 chips can be handled this way.
"The C Programming Language by Brian Kernighan and Dennis Ritchie" It is small and to the point, contains the important stuff and written by the creator of C. I wish I had had it as an undergrad.
-Tor
LOL at Ross.. "emulating the P2 in my head.." I've been reading this thread this morning, and I had to laugh at that.
Do these kind of questions get answered on the XMOS forums like all of the ninny questions that graciously get answered here?
I can't wait to get the TurboProp. Then we could do a fair comparison. I would really like to see what PhiPi can do with those intelligent pins. All of that processing power in each pin seems overkill, but not if it is put to good use.
Doug
Yes, pretty much any level of question will get an answer on the forum. I've asked my fair share of newbie questions. Although as you may have seen the traffic there is a lot less. Not so many hobbists about.
I'm getting desperate for the Prop II as well. But there is still a lot to be doing with Prop I.
We have C compilers for both X and P (Catalina) and a little benchmarking was going on in this thread http://forums.parallax.com/showthread.php?133848-C-Expressive-Enough-for-Idiomatic-PASM where Catalina, Intel GCC, XMOS C and ZPU-GCC are compared compiling the same code snippet.
This is all to be taken with a bucket of salt but the result was that whilst XMOS C and Catalina generate about the same number of instructions the XMOS binary code is about 50% of the size. This is mostly due to X using compact 16 bit instructions rather than the 32 bit that the Propeller requires.
If you want compact code on the Prop you need to go to Spin and take the performance hit of an interpreter.
Man, he took it all the way back to 1885!? Those people will think it is Greek, or something similar.
Excellent:)
Now, as this thread has been resting for almost a year we can start flogging again with renewed vigour...
Ah, well not really. In the XMOS vs P2 bout the XMOS still wins as it's opponent hasn't shown up yet.
@K2,
From a long time back:
I'm can't for the life of me see where anyone ever claimed or was duped into thinking this. XMOS has always been straight about clocks/threads/cores.
@AndreL
Perhaps what we'd all like to hear is more details of the [p2] 3D features you have mentioned.
@K2,
Or perhaps:
"A fast ARM is worth much more than an Propeller thingy for most tasks simply because it doesn't box the developer into a stupid paradigm"
Meaningless in both cases, Chips like Prop and X are not really comparable to chips like ARM. And they are intended for very different application spaces.
Also I don't think the Xthingy boxes you into any paradigm, if you want to run regular C code you can. It provides for threads as do many micro-controllers but you don't need an OS or software scheduler to use threads on X. It provides multiple cores, as does a Prop. It provides an easy way to communicate between cores and/or chips. What's not to like about all of that?.
@kuba
I could do with reading it all again but I did not skip so much. Yes of course an XMOS thread can start another thread at will from an existing patch of code in memory or something dynamically loaded as you have described.
BUT that is on one core. What I can't do on XMOS is:
1) Load a chunk of code from somewhere
2) Find another free core (not thread)
3) Start that core (or probably a thread on that core) running the code chunk.
That's what coginit does. As far as I know you cannot do it on XMOS unless there is already some code running on the other core(s) that receives your code chunk via a channel and starts it running for you.
The next issue is that if an XMOS device could do that, with or without software assist, it's quite likely that the newly running core does not have access to the I/O pins for some device it is driving because on X pins are not shared among cores as they are on Propellers.
Hence my statement about the "magic" of coginit.
Finally, again I see a lot of confusion around the use of the word determinism.
Prop users are into having their code execute exactly as they wrote it in the time they have calculated for it (cycle counting).
Kuba points out that actually it's not the code execution time that matters (as long as it's fast enough) but rather knowing the timing of your inputs and outputs which can be done with hardware assist on the I/O as XMOS does.
BUT I look at a slightly different form of "determinism" as I have stated elsewhere. That is to be able to determine that if I start up a COG running Spin/ PASM from some random object I have downloaded from some where it absolutely will not bugger up the timing of my carefully crafted application.
I cannot do this with XMOS threads for example, that one last new thread can rob by code of execution time.
Kuba points out that XMOS has timing analysis tools to spot this failure but it is still a failure.
Having said that, perhaps that is not such a big issue for most users/applications as I make it out to be.
In the interests of a factual and infromative comparison between devices could you please give details of:
1) What is awful about the XMOS I/O structure?
2) What's the problem with XMOS timers?
Just saying things are bad does not really help unless it's pointed out why. From my, admittedly limited, playing with X devices I/O and timers worked as advertised. Which is not to say there are some features that can frustrate like:
1) Having pins grouped into ports, you have to set a whole port width of pins to input or output together. Which makes randomly tacking devices onto an XMOS trickier than the Prop where all pins are independent and equal.
2) Each XMOS core has it's own set of pins, cores cannot use pins on other cores. Again this can make allocating resources a bit more tricky and again it makes randomly tacking devices onto an XMOS harder.
All in all it makes life harder for the hobbyist tinkerer.
That's odd. I found one could get a "hello world" program up on X as easily as you can on Arduino or the Prop, or flash LEDS and such. Yes of course getting the most out of an XMOS, or a Prop requires a lot of study but then that's true of most devices.