I've just looked at the code map for a real-life customer project running on an 8-bit CPU. I see one block which is an interrupt service routine which deals with moving a stepper motor, based on a timer tick. It implements dynamic speed ramping so has quite a bit of 24-bit fixed point maths going on complete with a multiply. On an 8-bit CPU this consumes quite a few words of memory space; on a 32-bit CPU it should be a lot cleaner.
The whole thing is written in 'C' and it takes just 477 words of code space and a handful of words in data space.
I have no reason to doubt that on a P1+ it'll fit nicely within one core and the 496 words of register space available. That to me is exactly the sort of function that should live within a core. As long as the C compiler generates 'native' code I see no reason it shouldn't.
If the compiler can take normal everyday C code and compile inner loops to native PASM and load them to COG for execution then and get almost the same performance as hand written PASM. With no special effort on the part of the programmer...Then I would say it has great utility.
Compiling source code to native instruction is what C compilers are expected to do. If they can't do that then they are pretty pointless
Sorry - you're talking about caching PASM in a cog (which Catalina already does in the CMM kernel). That's not the same as "cog C". Or at least not what I thought you meant by "cog C", which is C code targeted to execute in a cog.
I've just looked at the code map for a real-life customer project running on an 8-bit CPU. I see one block which is an interrupt service routine which deals with moving a stepper motor, based on a timer tick. It implements dynamic speed ramping so has quite a bit of 24-bit fixed point maths going on complete with a multiply. On an 8-bit CPU this consumes quite a few words of memory space; on a 32-bit CPU it should be a lot cleaner.
The whole thing is written in 'C' and it takes just 477 words of code space and a handful of words in data space.
I have no reason to doubt that on a P1+ it'll fit nicely within one core and the 496 words of register space available. That to me is exactly the sort of function that should live within a core. As long as the C compiler generates 'native' code I see no reason it shouldn't.
From my experience, what takes 477 words on an ARM or AVR architecture (designed for efficient execution of compiled high-level languages) is likely to take much more space in PASM - around twice as much, in fact (I've measured it). So it is quite unlikely your example would fit in 496 instructions on the P1. The P16X32B may be better. I'll reserve judgment on that. But this is a very niche application, and as soon as you try and extend it and then run out of space, you're finished.
No, I mentioned two real world and working examples:
1) The heater_FFT which, optionally, caches code to COG automatically. And when using OpenMP pragma directives can do the same over multiple COGs for a performance boost.
2) The FullDuplexSerial in C. Written specifically as code to be run in COG.
I believe both techniques have great utility.
A C programmer who want's to bit-bang some pins to drive some external gadget at speeds that do not require PASM will find this very useful. Brian has an example above. Indeed with the increased speed of the PII the need to resort to PASM is reduced.
No, I mentioned two real world and working examples:
1) The heater_FFT which, optionally, caches code to COG automatically. And when using OpenMP pragma directives can do the same over multiple COGs for a performance boost.
2) The FullDuplexSerial in C. Written specifically as code to be run in COG.
I believe both techniques have great utility.
A C programmer who want's to bit-bang some pins to drive some external gadget at speeds that do not require PASM will find this very useful. Brian has an example above. Indeed with the increased speed of the PII the need to resort to PASM is reduced.
Sorry, I disagree.
The first is just FCACHE (or equivalent). A useful technique, certainly - but nothing special, and certainly not "cog C". It's more akin to just a simple instruction cache.
The second (fullduplex serial) is a fairly trivial driver on the Propeller. The PASM version of a serial driver requires only a few dozen instructions, so the fact that you can do this in C is not particularly impressive, even for a quite inefficient C compiler.
...what takes 477 words on an ARM or AVR architecture (designed for efficient execution of compiled high-level languages) is likely to take much more space in PASM - around twice as much, in fact (I've measured it).
Really?! I am genuinely surprised and curious as to what's going on to cause that.
I've been peeking under the hood of compilers for many years now and have only found one that was truly terrible (PL/M on an 8051) so I think I've got a pretty good handle on what goes on. What in the Propeller architecture holds things back?
Really?! I am genuinely surprised and curious as to what's going on to cause that.
I've been peeking under the hood of compilers for many years now and have only found one that was truly terrible (PL/M on an 8051) so I think I've got a pretty good handle on what goes on. What in the Propeller architecture holds things back?
On the P1, it's lack of any indexed addressing. This may be rectified on the P16X32B.
So, then what is the point of having C on Propeller?
You use C where it is appropriate (high level control flow, implementing complex or abstract algorithims) and assembler where is is appropriate (high-speed drivers, or wherever speed or determinism is important).
One of the problems with the Propeller is that people tend to forget it was supposed to be an embedded micro-controller, not a micro-processor, and not a "system on a chip". Assembler is the appropriate language for many things in this domain.
I think of C on the Propeller as replacing SPIN - not replacing PASM.
You use C where it is appropriate (high level control flow, implementing complex or abstract algorithims) and assembler where is is appropriate (high-speed drivers, or wherever speed or determinism is important).
One of the problems with the Propeller is that people tend to forget it was supposed to be an embedded micro-controller, not a micro-processor, and not a "system on a chip". Assembler is the appropriate language for many things in this domain.
I think of C on the Propeller as replacing SPIN - not replacing PASM.
Ross.
Good line of reasoning except for all the C haters around here and within Parallax ;-)
Having C is allowing Parallax to broaden it's educational market customers ... hated or not.
There is an opportunity for running the Parallax Propeller-C Simple Libraries on Catalina if you're interested in that. If not, someone will write yet another unwanted C compiler.
Good line of reasoning except for all the C haters around here and within Parallax ;-)
Having C is allowing Parallax to broaden it's educational market customers ... hated or not.
There is an opportunity for running the Parallax Propeller-C Simple Libraries on Catalina if you're interested in that. If not, someone will write yet another unwanted C compiler.
The abundance of C haters both in these forums and within Parallax doesn't bother me. It used to, but then I remembered after a while that I began writing Catalina so that I could do the projects I wanted to do, which were simply not possible without it (and still would not be - yet I have now finished all the projects I originally had planned when I bought my first Propeller). If others also find it useful well good for them.
I'll have a look at the Propeller C libraries. If you recall, I once proposed we all adopt a common "propeller.h" file, as I did with ImageCraft compiler, so that people could use whatever compiler they wanted. I also proposed a common object interface, so we could share PASM objects. I have no objection to doing a bit of extra work if it helps everyone benefit from the Propeller.
But I'm not sure why you think C compilers on the Propeller are "unwanted". Catalina certainly gets a lot of use, both within these forums and without. I honestly have no idea about GCC, but my impression was that it has a solid base in educational use. Not so?
I'd hazard a guess your project uses PASM objects. Most Propeller projects do - even GCC ones.
Ross.
No I'm using several COG C drivers to do the work I need done. I don't like to write ASM, PASM, or any other assembly. I prefer to code in C/C++. It works. It's fast enough. Irregardless of who thinks I ought to do things otherwise I, for one, found the ability to do that useful.
I'm not a compiler writer so I can't get into the guts of it or argue how wasteful it is is isn't. All I can say is that I appreciate the fact that I can produce a driver that executes at near PASM speed without the head-pounding frustration I generally experience trying to program in ASM.
But I'm not sure why you think C compilers on the Propeller are "unwanted". Catalina certainly gets a lot of use, both within these forums and without. I honestly have no idea about GCC, but my impression was that it has a solid base in educational use. Not so?
Propeller GCC is getting plenty of use. Don't assume too much Ross.
I'm just saying that there is an opportunity. If you want to cooperate great, if not you'll be left out again.
Personally, I think Ross is mostly right in that for complex drivers you probably want to do it in assembly.
But, for simple drivers or for fun, doing cog code in C is interesting and nice to have.
A few thoughts from someone who definitely prefers to code in C...
1) A common header file, dealing with the low-level stuff, would be great.
2) A common interface to Objects would be great++ and would be a huge benefit in getting the P1+ out there and being used.
3) C vs PASM Objects doesn't really matter. My approach when writing blocks of code that do 'something' (see my stepper driver example above) is to write it as I think it and then try it. I often use a scope to see how long it takes to run. If it works and is quick enough I leave alone. If I need to make it faster then I look at the generated code and see where it can be improved. Ditto if it needs to be smaller (but this is rarely a consideration). If I'm still struggling, which is very rarely, I'll drop into ASM.
I don't read many C haters. What I do see is push back on C being the best, when the truth is there are just options.
Today, C is a great option!
On the P1+ P2 whatever it ends up being called, C is going to sing! I will do more with it at that time. The small nature of the P1 makes using it a less than desirable option for me personally. But that's me. I also like how one can compartmentalize PASM into a COG, and work in C, SPIN, whatever, and that is my preference. Currently, giving a C compiler directives, using inline, etc... takes enough work, input, etc... that I find it preferable to just write some PASM.
And for me C is verbose. Often that is not needed, and I really don't prefer to do things that won't pay off well. Those same things for others have significant pay offs, and they do them.
Options.
Forth is an option too. Many of us don't see it as paying off, but for those that do, it rocks. Peter has done very well, and I'm sure he would have some reasons for that all coming together.
C for education is the right thing to do. No worries on that.
SPIN is also the right thing to do. It will be lean, mean and flexible on the next chip, just like it is on this one. "better" will be subjective, just as it is on this one.
This all is no different than the reuse discussion we had. Encouraging it is great. Mandating it, not so much.
Options.
Speaking about options, a nicely done PASM body of code to run in a COG is reusable anywhere. Notable.
Personally, I like seeing options and I like learning about them. All good.
Edit: I want to emphasize the C efforts are great today. So much work, but it's paying off. Great job all around. Better options means life in Propeller land is just better.
Edit: I want to emphasize the C efforts are great today. So much work, but it's paying off. Great job all around. Better options means life in Propeller land is just better.
Exactly. Those options make things possible for me that I would otherwise go elsewhere to do or sit and twiddle my thumbs waiting for someone else to do. *I* don't see that as just a gimmick.
I'm using cog c for several drivers in my code, and it's great! It's allowing me to use some of the same code on another processor, because I have abstracted pin setting and reading into a header.
I'm talking to multiple 165 and 595 shift registers, strings of WS2801 LED drivers, and an accelerometer chip. It's plenty fast enough.
I use PASM too when it's needed, just turns out to not be needed as much as before because of cog c!
It helps people to understand options. That is what we want in the end. Where there is that understanding, there will be use. More understanding = more use.
potatohead,
I plan to release all the code under MIT license when I have it all more done. It's all part of a larger unreleased project right now that is still in early development stage.
Some of it is a bit specialized. For example, the 165 & 595 code uses a shared latch and clock lines between the two chains of chips.
My main point was that cog c is very useful and has the added benefit of being cross platform when used appropriately. PASM is not cross platform at all. Cog C is far from pointless. In fact, I would go so far as to say it is a required feature.
My main point was that cog c is very useful and has the added benefit of being cross platform when used appropriately. PASM is not cross platform at all. Cog C is far from pointless. In fact, I would go so far as to say it is a required feature.
Agreed, and a very obvious and local Cross Platform use, will be P1 <-> P2
Cog C is far from pointless. In fact, I would go so far as to say it is a required feature.
Well, I suppose I could be convinced of its utility if there were enough real-world examples, and adding it is fairly easy, so I may do it. But I've looked through all the objects I routinely use, and I can find only two or three (out of dozens) that could possibly be re-coded in C, and even then the result would simply be larger executable sizes and slower objects.
Comments
I think you're doing down your own work.
I've just looked at the code map for a real-life customer project running on an 8-bit CPU. I see one block which is an interrupt service routine which deals with moving a stepper motor, based on a timer tick. It implements dynamic speed ramping so has quite a bit of 24-bit fixed point maths going on complete with a multiply. On an 8-bit CPU this consumes quite a few words of memory space; on a 32-bit CPU it should be a lot cleaner.
The whole thing is written in 'C' and it takes just 477 words of code space and a handful of words in data space.
I have no reason to doubt that on a P1+ it'll fit nicely within one core and the 496 words of register space available. That to me is exactly the sort of function that should live within a core. As long as the C compiler generates 'native' code I see no reason it shouldn't.
Sorry - you're talking about caching PASM in a cog (which Catalina already does in the CMM kernel). That's not the same as "cog C". Or at least not what I thought you meant by "cog C", which is C code targeted to execute in a cog.
From my experience, what takes 477 words on an ARM or AVR architecture (designed for efficient execution of compiled high-level languages) is likely to take much more space in PASM - around twice as much, in fact (I've measured it). So it is quite unlikely your example would fit in 496 instructions on the P1. The P16X32B may be better. I'll reserve judgment on that. But this is a very niche application, and as soon as you try and extend it and then run out of space, you're finished.
Ross.
1) The heater_FFT which, optionally, caches code to COG automatically. And when using OpenMP pragma directives can do the same over multiple COGs for a performance boost.
2) The FullDuplexSerial in C. Written specifically as code to be run in COG.
I believe both techniques have great utility.
A C programmer who want's to bit-bang some pins to drive some external gadget at speeds that do not require PASM will find this very useful. Brian has an example above. Indeed with the increased speed of the PII the need to resort to PASM is reduced.
Sorry, I disagree.
The first is just FCACHE (or equivalent). A useful technique, certainly - but nothing special, and certainly not "cog C". It's more akin to just a simple instruction cache.
The second (fullduplex serial) is a fairly trivial driver on the Propeller. The PASM version of a serial driver requires only a few dozen instructions, so the fact that you can do this in C is not particularly impressive, even for a quite inefficient C compiler.
Ross.
Really?! I am genuinely surprised and curious as to what's going on to cause that.
I've been peeking under the hood of compilers for many years now and have only found one that was truly terrible (PL/M on an 8051) so I think I've got a pretty good handle on what goes on. What in the Propeller architecture holds things back?
Me: "One can use FCACHE in C to make your code run a lot faster"
You: "That's silly, people should write such code in assembler."
Me: "One can write simple bit-banging drivers in C that run pretty quick in C without resorting to assembler"
You: "That's silly, people should write such code in assembler."
Me: " I guess those 'silly' C programmers who want to make their lives easier will be using GCC then"
You: "That's silly, people should write such code in assembler."
We will let the audience to this exchange decide how silly they want to be.:)
On the P1, it's lack of any indexed addressing. This may be rectified on the P16X32B.
Ross.
And good luck to them. They will start out writing in C, and end up back in assembler before their project is half finished.
Ross.
Ah yes, that'll do it.
The FDS in C uses two cyclic buffers quite successfully despite the alleged handicap.
It's not a showstopper, as we have all demonstrated. It just makes the code much larger than it would be on a chip that does have indexed addressing.
C in particular is a heavily stack-oriented language, and all local variables (those that are not in registers) are indexed off a frame pointer.
Not having this capability can double or even triple the number of instructions required.
Ross.
You use C where it is appropriate (high level control flow, implementing complex or abstract algorithims) and assembler where is is appropriate (high-speed drivers, or wherever speed or determinism is important).
One of the problems with the Propeller is that people tend to forget it was supposed to be an embedded micro-controller, not a micro-processor, and not a "system on a chip". Assembler is the appropriate language for many things in this domain.
I think of C on the Propeller as replacing SPIN - not replacing PASM.
Ross.
Dang... I should go rewrite my projects then. I didn't know.
I'd hazard a guess your project uses PASM objects. Most Propeller projects do - even GCC ones.
Ross.
Having C is allowing Parallax to broaden it's educational market customers ... hated or not.
There is an opportunity for running the Parallax Propeller-C Simple Libraries on Catalina if you're interested in that. If not, someone will write yet another unwanted C compiler.
The abundance of C haters both in these forums and within Parallax doesn't bother me. It used to, but then I remembered after a while that I began writing Catalina so that I could do the projects I wanted to do, which were simply not possible without it (and still would not be - yet I have now finished all the projects I originally had planned when I bought my first Propeller). If others also find it useful well good for them.
I'll have a look at the Propeller C libraries. If you recall, I once proposed we all adopt a common "propeller.h" file, as I did with ImageCraft compiler, so that people could use whatever compiler they wanted. I also proposed a common object interface, so we could share PASM objects. I have no objection to doing a bit of extra work if it helps everyone benefit from the Propeller.
But I'm not sure why you think C compilers on the Propeller are "unwanted". Catalina certainly gets a lot of use, both within these forums and without. I honestly have no idea about GCC, but my impression was that it has a solid base in educational use. Not so?
Ross.
No I'm using several COG C drivers to do the work I need done. I don't like to write ASM, PASM, or any other assembly. I prefer to code in C/C++. It works. It's fast enough. Irregardless of who thinks I ought to do things otherwise I, for one, found the ability to do that useful.
I'm not a compiler writer so I can't get into the guts of it or argue how wasteful it is is isn't. All I can say is that I appreciate the fact that I can produce a driver that executes at near PASM speed without the head-pounding frustration I generally experience trying to program in ASM.
I'm just saying that there is an opportunity. If you want to cooperate great, if not you'll be left out again.
Personally, I think Ross is mostly right in that for complex drivers you probably want to do it in assembly.
But, for simple drivers or for fun, doing cog code in C is interesting and nice to have.
1) A common header file, dealing with the low-level stuff, would be great.
2) A common interface to Objects would be great++ and would be a huge benefit in getting the P1+ out there and being used.
3) C vs PASM Objects doesn't really matter. My approach when writing blocks of code that do 'something' (see my stepper driver example above) is to write it as I think it and then try it. I often use a scope to see how long it takes to run. If it works and is quick enough I leave alone. If I need to make it faster then I look at the generated code and see where it can be improved. Ditto if it needs to be smaller (but this is rarely a consideration). If I'm still struggling, which is very rarely, I'll drop into ASM.
I don't read many C haters. What I do see is push back on C being the best, when the truth is there are just options.
Today, C is a great option!
On the P1+ P2 whatever it ends up being called, C is going to sing! I will do more with it at that time. The small nature of the P1 makes using it a less than desirable option for me personally. But that's me. I also like how one can compartmentalize PASM into a COG, and work in C, SPIN, whatever, and that is my preference. Currently, giving a C compiler directives, using inline, etc... takes enough work, input, etc... that I find it preferable to just write some PASM.
And for me C is verbose. Often that is not needed, and I really don't prefer to do things that won't pay off well. Those same things for others have significant pay offs, and they do them.
Options.
Forth is an option too. Many of us don't see it as paying off, but for those that do, it rocks. Peter has done very well, and I'm sure he would have some reasons for that all coming together.
C for education is the right thing to do. No worries on that.
SPIN is also the right thing to do. It will be lean, mean and flexible on the next chip, just like it is on this one. "better" will be subjective, just as it is on this one.
This all is no different than the reuse discussion we had. Encouraging it is great. Mandating it, not so much.
Options.
Speaking about options, a nicely done PASM body of code to run in a COG is reusable anywhere. Notable.
Personally, I like seeing options and I like learning about them. All good.
Edit: I want to emphasize the C efforts are great today. So much work, but it's paying off. Great job all around. Better options means life in Propeller land is just better.
Exactly. Those options make things possible for me that I would otherwise go elsewhere to do or sit and twiddle my thumbs waiting for someone else to do. *I* don't see that as just a gimmick.
I'm talking to multiple 165 and 595 shift registers, strings of WS2801 LED drivers, and an accelerometer chip. It's plenty fast enough.
I use PASM too when it's needed, just turns out to not be needed as much as before because of cog c!
I think we need to share more of this stuff.
It helps people to understand options. That is what we want in the end. Where there is that understanding, there will be use. More understanding = more use.
That is also what we want in the end.
I plan to release all the code under MIT license when I have it all more done. It's all part of a larger unreleased project right now that is still in early development stage.
Some of it is a bit specialized. For example, the 165 & 595 code uses a shared latch and clock lines between the two chains of chips.
My main point was that cog c is very useful and has the added benefit of being cross platform when used appropriately. PASM is not cross platform at all. Cog C is far from pointless. In fact, I would go so far as to say it is a required feature.
Seeing a cross platform use case will help the cause considerably.
Agreed, and a very obvious and local Cross Platform use, will be P1 <-> P2
Well, I suppose I could be convinced of its utility if there were enough real-world examples, and adding it is fairly easy, so I may do it. But I've looked through all the objects I routinely use, and I can find only two or three (out of dozens) that could possibly be re-coded in C, and even then the result would simply be larger executable sizes and slower objects.
I can't see any actual benefit.
Ross.