Still bugged that Parallax never called you back about 5 years ago? I had nothing to do with it.
No, I never thought you did - from memory, you weren't even working with Parallax at that time. I do know a bit about what happened, and I think it was mainly just an unfortunate turn of events.
It was your behavior after that which made me decide to have nothing to do with the PropGCC team while ever you were associated with it.
No, I never thought you did - from memory, you weren't even working with Parallax at that time. I do know a bit about what happened, and I think it was mainly just an unfortunate turn of events.
It was your behavior after that which made me decide to have nothing to do with the PropGCC team while ever you were associated with it.
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.
Ok. I've just written a code generator for Catalina that generates COG mode C - i.e. C code compiled to execute stand-alone within a single cog, including the stack and all variables. Seems to work for simple C code, but obviously it will need more testing.
This first cut supports only 32 bit integer types. I could add 8 bit types if anyone thought they would be useful, but I doubt I would bother with 16 bit types. Also, there is currently no library or plugin support, so COG mode will really only be useful for writing low-level stand-alone cog objects (such as a driver). Of course, those cog objects can be used by Catalina, but they will not themselves be able to make use of any other Catalina facilities.
I may add this to the next release of Catalina if I get time. Since COG code requires no support from any other part of Catalina, if I do add it I'll arrange to make it possible to spit out the output as a simple binary "blob", much the same way the spinc utility currenty does - these "blobs" can then be used from any language.
Not sure exactly when the next release of Catalina will be - I'm currently in the middle of re-plumbing Catalina's internals to make it possible to support the P16X32B, and I'm also testing a version of the graphics library that works in ALL memory modes (currently it works only in COMPACT, TINY and SMALL modes - LARGE mode was broken).
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.
Perhaps, but "and even then the result would simply be larger executable sizes and slower objects. " is pretty much true of almost any HLL vs ASM, but I can still see many advantages.
* It is inherently portable between P1 and P2 (and more loosely to/from other applicaitons)
* Properly done, with Source-commented PASM generated, it can be a great way to learn PASM
* If the Code is still too slow, in GOG mode, users can fine-tune the Assembly and use that.
Ideally the code-generators improve over time, so the final step is needed less and less.
Faster & Smarter Silicon also helps do more, without needing to step into PASM.
...I could be convinced of its utility if there were enough real-world examples...
That's a bit of a chickens and eggs problem isn't it? Especially in the case of Catalina which so far does not generate native code, so of course your users have not come up with any examples.
But which ever compiler I get the feeling it's still early days for C on the Propeller. So I would not expect to see many examples. I'm sure that will change with the PII.
Aside: I do love these compiler wars. It's great for the Prop user community to have choice and it seems to spur innovation in both.
Just wait till the Clang guys turn up and create a Propeller back end for LLVM
The merging of propgcc code back to the main line GCC project is not really of any concern or benefit to us the propgcc users at this point. We can just use the propgcc releases or build it ourselves from the source repository.
It becomes a concern in the long term when we would like to see GCC support the Propeller well into the future, perhaps after all the current propgcc team has moved on to other more interesting things.
I imagine this all depends on the GCC maintainers accepting propgcc changes back into their code base. They may not want even want to unless the Propeller becomes a lot more widely adopted.
I can't imagine the GCC team has any interest in adopting support for a chip that does not exist yet.
I'm confident that a propgcc supporting the P2 will emerge well before the actual P2 goes into production. Especially if Chip can promise to stop messing with the instruction set soon.
But some of those are in there for historical reasons rather than pragmatic reasons.
That is precisely my point: "pragmatic reasons". I think that support of the current P1 and future Propeller into the official gcc has a lot of benefits for both users and parallax itself.
Am I the only one here that sees benefits in having the propeller architecture into the GCC mainline?
You are wrong. The GCC compiler already supports architectures that doesn't exist as
Very true. I have no idea how many such "virtual" architectures are supported. However MIX is a very special case I believe. Devised decades ago by the famous Donald Knuth for pedagogical purposes in his famous books.
As a counter example there is GCC for things like the 6809 microprocessor that are not in the GCC mainline and I imagine never will be. And that is a real chip that has sold millions more than the Propeller. It would be asking a bt much for the GCC project to support everything.
I think that support of the current P1 and future Propeller into the official gcc has a lot of benefits for both users and parallax itself.
Am I the only one here that sees benefits in having the propeller architecture into the GCC mainline?
No. We don't disagree with you.
However having the propgcc folded into the mainline is not up to the propgcc team or Parallax. It's up to the GCC project. It's their project right?
The best we can hope is that propgcc is done very well and the Propellers sell well and become well known and then the GCC project sees it as a valuable addition.
Meanwhile, we can happily continue with what we have with no practical downside.
Amazing! Most people who turn to C point the finger at ADA, Pascal, Cobol, Java etc etc as being "too verbose". This must be the first time I have heard C being accused of verbosity.
Now, I do see where you are coming from given that Spin does away with the curly brackets and some parenthesis.
However I see that as an illusion. That dependency on white space for block delimiting is "verbosity", only it's hard to see. Besides Spin is a lot less expressive language.
I'm not saying one is better than the other. I am sharing what impacts me and how I see things. Sometimes why.
SPIN does not require a person to know or track as many things to author programs. Additionally, it's one with PASM. Finally, it's simple nature, lack of type checks, and many nice ways to express data make building projects simple, productive. Yes, one can get into trouble with those things, but hey. One can just get into trouble no matter what. Non issue for me.
I particularly like all of the options SPIN has in the DAT section for how data is represented. It's easy to read, very expressive in that way, and I never did like the whole 0x thing.
In SPIN we get all kinds of stuff! Just type it in, label it, specify an alignment if desired and go! I really like that. Probably my favorite feature, mostly because I can input data, literals, whatever in basically the form I'm thinking about it in, conversions optional nearly all the time. Second favorite feature is all the nice operators, shifts, assignments, booleans, and so on, making for concise expressions that do a lot, and that do them in mostly the same way one would do them in PASM, though that's not required at all. Can improve speed when well understood and applied.
I have to do extra stuff in C in these areas that I don't have to do in SPIN. And then again, with higher level constructs, there are things one has to do, or just can't do or must hack in SPIN, one can do easily in C. I don't care about these differences. What I do care is that we have the options so that when tasks come up or make sense, people can get tools that they find optimal without having to worry about the politics of it all.
And of course SPIN is missing a ton of stuff! Maybe we can add some of those things and improve it for larger projects. Of course, we may also get simple inline PASM too, which will be awesome!
IMHO, it's much better to understand why we are doing what we are doing, and have options for those things. The way I see it, we should maximize SPIN+PASM for the things it does well. And we should maximize C for the things it does well.
From there, people do what they do, no worries, until there are. And at that point, people seek better options. There isn't one unified "best" and there never will be. so why worry about it at all? Maximize stuff, do things, worry less.
It's like "dark matter", in that if we look at the guts of things, like physics people do about the nature of the world, that matters and the illusion is broken.
From a real basic, what do I have to know, what do I have to type, what do I have to read, SPIN is considerably leaner and easier to operate with than C and a lot of other stuff is. Illusion or not, that just is, whatever we call it.
Chip hit a home run with PBasic because it was very simple and timely in a world without easy MCU solutions. With Spin he got a base-hit ... or whatever depending on who you ask ... in a world of great competition.
A goal of business is to have as many customers as possible. That is achieved many ways of course. Some languages like C exclude many customers. The great irony of course is that not having C also excludes many customers. One quote I remember is (paraphrased and uncited so I don't get splattered with yellow juice) "well, maybe those aren't the customers you want."
Spin and PASM were designed for Propeller according to Chip's minimalist philosophy which is attractive. Unfortunately that's not what everyone needs especially with so many other simple and well paved options.
Good news is C is there and improving. In the end it's about users. (customers, but I think of them as users for a lot of subtle reasons)
Maybe we will maximize users going forward.
Another goal of business is to maximize revenue per user. This sometimes runs in conflict with having the most possible. Depends on what is worth what and who spends and why.
Having a robust, simple environment is a good thing. As for novice, maybe. I know some people with considerable skill, who enjoy SPIN for it's basic nature.
Whether or not it's novice really depend on context. And whether it's a good start for a novice also depends. No one size fits all here, just people and options.
One thing I am sure of is less ugly surrounding these things = more, better and happy users.
I think we will see this continue to improve as the tools do. And I say improve because the C tools are good now. I'm happy with the state of things now and will be contributing IN C, SPIN and PASM on the new chip. Looking forward to it.
For me currently, I have some mentoring in progress that I don't share here, and some projects that do not contain generally sharable things.
Others have their reasons too.
Look at what Roy might bring to the table, and Ross just added COG code. Not that those two are special, just came to mind on this discussion. SRLM has made some good ones, and you have your own too.
When we get to building a PropGCC on the new chip, I'll have some things to do there as well. (thank you for tagging me for contributor access)
This time around on our language wheel of pain and punishment, I thought just framing it as options makes more sense. There is some history and it's gonna be there, but we can always add options. Maybe just doing that for a while will improve things over all.
I particularly like all of the options SPIN has in the DAT section for how data is represented. It's easy to read, very expressive in that way, and I never did like the whole 0x thing.
In SPIN we get all kinds of stuff! Just type it in, label it, specify an alignment if desired and go! I really like that. Probably my favorite feature, mostly because I can input data, literals, whatever in basically the form I'm thinking about it in, conversions optional nearly all the time.
Can you give some examples of this? Certainly the difference between 0x1234 and $1234 is not great. You may prefer one over the other but I doubt it's a show stopper.
We really live in a world where standards quickly get abused, more so than every before.
So supporting the phyical plug-in of Arduino shields seems like a good thing, maybe even a no-brainer.
But I just don't feel that Parallax should be too vested in porting all and everything from the Arduino to the Propeller. It becomes a complex, high-overhead task to do so, and time might be better spent demonstrating better ways to run the device on the Propeller.
But I do suspect there are going to be boxes and boxes of Arduino shields sitting around in closets for years to come. And whenever someone clears their closet and passes on a box of Arduino shields, there is an opportunity to have the new user explore Propellers as a valid alternative to Arduino.
So... the PropellerASC+ is a an important first step. But the Propeller1+ might need to have 16 ADC and more i/o involved. Please see the attached interface diagram.
IMNSHO (in theory) the new Propeller chip will provide an economical, easy, and open alternative to Arduino users who need more bandwidth, memory and determinism. In reality, since the corporate bias is heavily tilted toward Broadcom, fairly competing in that market is an uphill battle, certainly not one that Parallax should directly attempt. If there is an opportunity, then Parallax should support a third party effort. Even a fraction of that market is worth something.
I like the idea of the new Propeller being placed on a very tiny module(with SDRAM:) and micro SD card slot. (with a cheap connector for the I/O.)
Comments
Still bugged that I refused to join your PropGCC team then?
Ross.
Still bugged that Parallax never called you back about 5 years ago? I had nothing to do with it.
No, I never thought you did - from memory, you weren't even working with Parallax at that time. I do know a bit about what happened, and I think it was mainly just an unfortunate turn of events.
It was your behavior after that which made me decide to have nothing to do with the PropGCC team while ever you were associated with it.
Ross.
Anyway our choices were made long ago right or wrong. I have no problem living with the way things turned out.
I made this question before (the big thread, post #6644):
Is there any plan to include Propeller into the official gcc repository?
We've been waiting to finish support for the new chip before trying to merge with the GCC mainline.
Sorry, but it is impossible for me to keep up with "the big thread".
Ok. I've just written a code generator for Catalina that generates COG mode C - i.e. C code compiled to execute stand-alone within a single cog, including the stack and all variables. Seems to work for simple C code, but obviously it will need more testing.
This first cut supports only 32 bit integer types. I could add 8 bit types if anyone thought they would be useful, but I doubt I would bother with 16 bit types. Also, there is currently no library or plugin support, so COG mode will really only be useful for writing low-level stand-alone cog objects (such as a driver). Of course, those cog objects can be used by Catalina, but they will not themselves be able to make use of any other Catalina facilities.
I may add this to the next release of Catalina if I get time. Since COG code requires no support from any other part of Catalina, if I do add it I'll arrange to make it possible to spit out the output as a simple binary "blob", much the same way the spinc utility currenty does - these "blobs" can then be used from any language.
Not sure exactly when the next release of Catalina will be - I'm currently in the middle of re-plumbing Catalina's internals to make it possible to support the P16X32B, and I'm also testing a version of the graphics library that works in ALL memory modes (currently it works only in COMPACT, TINY and SMALL modes - LARGE mode was broken).
Ross.
Perhaps, but "and even then the result would simply be larger executable sizes and slower objects. " is pretty much true of almost any HLL vs ASM, but I can still see many advantages.
* It is inherently portable between P1 and P2 (and more loosely to/from other applicaitons)
* Properly done, with Source-commented PASM generated, it can be a great way to learn PASM
* If the Code is still too slow, in GOG mode, users can fine-tune the Assembly and use that.
Ideally the code-generators improve over time, so the final step is needed less and less.
Faster & Smarter Silicon also helps do more, without needing to step into PASM.
But which ever compiler I get the feeling it's still early days for C on the Propeller. So I would not expect to see many examples. I'm sure that will change with the PII.
Aside: I do love these compiler wars. It's great for the Prop user community to have choice and it seems to spur innovation in both.
Just wait till the Clang guys turn up and create a Propeller back end for LLVM
Good news ! The merge will be started only after real ICs are shipped? Or can a beta version be released after Chip announces the new FPGA image?
The merging of propgcc code back to the main line GCC project is not really of any concern or benefit to us the propgcc users at this point. We can just use the propgcc releases or build it ourselves from the source repository.
It becomes a concern in the long term when we would like to see GCC support the Propeller well into the future, perhaps after all the current propgcc team has moved on to other more interesting things.
I imagine this all depends on the GCC maintainers accepting propgcc changes back into their code base. They may not want even want to unless the Propeller becomes a lot more widely adopted.
I can't imagine the GCC team has any interest in adopting support for a chip that does not exist yet.
I'm confident that a propgcc supporting the P2 will emerge well before the actual P2 goes into production. Especially if Chip can promise to stop messing with the instruction set soon.
The inclusion of the propeller architecture into the official version has benefits to both users and Parallax itself.
But some of those are in there for historical reasons rather than pragmatic reasons.
That is precisely my point: "pragmatic reasons". I think that support of the current P1 and future Propeller into the official gcc has a lot of benefits for both users and parallax itself.
Am I the only one here that sees benefits in having the propeller architecture into the GCC mainline?
As a counter example there is GCC for things like the 6809 microprocessor that are not in the GCC mainline and I imagine never will be. And that is a real chip that has sold millions more than the Propeller. It would be asking a bt much for the GCC project to support everything.
However having the propgcc folded into the mainline is not up to the propgcc team or Parallax. It's up to the GCC project. It's their project right?
The best we can hope is that propgcc is done very well and the Propellers sell well and become well known and then the GCC project sees it as a valuable addition.
Meanwhile, we can happily continue with what we have with no practical downside.
Now, I do see where you are coming from given that Spin does away with the curly brackets and some parenthesis.
However I see that as an illusion. That dependency on white space for block delimiting is "verbosity", only it's hard to see. Besides Spin is a lot less expressive language.
I'm not saying one is better than the other. I am sharing what impacts me and how I see things. Sometimes why.
SPIN does not require a person to know or track as many things to author programs. Additionally, it's one with PASM. Finally, it's simple nature, lack of type checks, and many nice ways to express data make building projects simple, productive. Yes, one can get into trouble with those things, but hey. One can just get into trouble no matter what. Non issue for me.
I particularly like all of the options SPIN has in the DAT section for how data is represented. It's easy to read, very expressive in that way, and I never did like the whole 0x thing.
In SPIN we get all kinds of stuff! Just type it in, label it, specify an alignment if desired and go! I really like that. Probably my favorite feature, mostly because I can input data, literals, whatever in basically the form I'm thinking about it in, conversions optional nearly all the time. Second favorite feature is all the nice operators, shifts, assignments, booleans, and so on, making for concise expressions that do a lot, and that do them in mostly the same way one would do them in PASM, though that's not required at all. Can improve speed when well understood and applied.
I have to do extra stuff in C in these areas that I don't have to do in SPIN. And then again, with higher level constructs, there are things one has to do, or just can't do or must hack in SPIN, one can do easily in C. I don't care about these differences. What I do care is that we have the options so that when tasks come up or make sense, people can get tools that they find optimal without having to worry about the politics of it all.
And of course SPIN is missing a ton of stuff! Maybe we can add some of those things and improve it for larger projects. Of course, we may also get simple inline PASM too, which will be awesome!
IMHO, it's much better to understand why we are doing what we are doing, and have options for those things. The way I see it, we should maximize SPIN+PASM for the things it does well. And we should maximize C for the things it does well.
From there, people do what they do, no worries, until there are. And at that point, people seek better options. There isn't one unified "best" and there never will be. so why worry about it at all? Maximize stuff, do things, worry less.
It's like "dark matter", in that if we look at the guts of things, like physics people do about the nature of the world, that matters and the illusion is broken.
From a real basic, what do I have to know, what do I have to type, what do I have to read, SPIN is considerably leaner and easier to operate with than C and a lot of other stuff is. Illusion or not, that just is, whatever we call it.
Chip hit a home run with PBasic because it was very simple and timely in a world without easy MCU solutions. With Spin he got a base-hit ... or whatever depending on who you ask ... in a world of great competition.
A goal of business is to have as many customers as possible. That is achieved many ways of course. Some languages like C exclude many customers. The great irony of course is that not having C also excludes many customers. One quote I remember is (paraphrased and uncited so I don't get splattered with yellow juice) "well, maybe those aren't the customers you want."
Spin and PASM were designed for Propeller according to Chip's minimalist philosophy which is attractive. Unfortunately that's not what everyone needs especially with so many other simple and well paved options.
Good news is C is there and improving. In the end it's about users. (customers, but I think of them as users for a lot of subtle reasons)
Maybe we will maximize users going forward.
Another goal of business is to maximize revenue per user. This sometimes runs in conflict with having the most possible. Depends on what is worth what and who spends and why.
Having a robust, simple environment is a good thing. As for novice, maybe. I know some people with considerable skill, who enjoy SPIN for it's basic nature.
Whether or not it's novice really depend on context. And whether it's a good start for a novice also depends. No one size fits all here, just people and options.
One thing I am sure of is less ugly surrounding these things = more, better and happy users.
+1
Less ugly would be more positive contributions.
I think we will see this continue to improve as the tools do. And I say improve because the C tools are good now. I'm happy with the state of things now and will be contributing IN C, SPIN and PASM on the new chip. Looking forward to it.
For me currently, I have some mentoring in progress that I don't share here, and some projects that do not contain generally sharable things.
Others have their reasons too.
Look at what Roy might bring to the table, and Ross just added COG code.
When we get to building a PropGCC on the new chip, I'll have some things to do there as well. (thank you for tagging me for contributor access)
This time around on our language wheel of pain and punishment, I thought just framing it as options makes more sense. There is some history and it's gonna be there, but we can always add options. Maybe just doing that for a while will improve things over all.
So supporting the phyical plug-in of Arduino shields seems like a good thing, maybe even a no-brainer.
But I just don't feel that Parallax should be too vested in porting all and everything from the Arduino to the Propeller. It becomes a complex, high-overhead task to do so, and time might be better spent demonstrating better ways to run the device on the Propeller.
But I do suspect there are going to be boxes and boxes of Arduino shields sitting around in closets for years to come. And whenever someone clears their closet and passes on a box of Arduino shields, there is an opportunity to have the new user explore Propellers as a valid alternative to Arduino.
So... the PropellerASC+ is a an important first step. But the Propeller1+ might need to have 16 ADC and more i/o involved. Please see the attached interface diagram.
I like the idea of the new Propeller being placed on a very tiny module(with SDRAM:) and micro SD card slot. (with a cheap connector for the I/O.)
Rich
There is a good example of a compact module, with cheap IO expansion here, which would be a good 'standard' to follow.
http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/