Having both chips use the same toolchain means that I can choose the right hardware for a specific design without having to worry about using different languages or toolchains.
I may be late to the game here, but if you need another GCC tester (particularly one who has been using GCC for cross compiling as well as building the cross compiler for well over a decade) then I might be able to help.
Also, I'm an avid Darwin user, so I can pitch in to make sure this mess builds under "that other" environment.
I may be late to the game here, but if you need another GCC tester (particularly one who has been using GCC for cross compiling as well as building the cross compiler for well over a decade) then I might be able to help.
Also, I'm an avid Darwin user, so I can pitch in to make sure this mess builds under "that other" environment.
Either way, "go team go"!
-joe
Welcome! Yes, we need many testers and demo coders. Thanks for your interest.
--Steve
This first one is Prop 1 PASM in a COG with stack in HUB. It's like a little SPIN on steroids.
Congratulations on reaching your first milestone. Are you planning on posting a binary?
I'm intrigued by your selected memory model - it is far more ambitious than I had expected. It would appear that GCC will soon be able to achieve all of the code size of PASM with all of the speed of Spin!
I look forward to the inevitable benchmark shootout
Congratulations on reaching your first milestone. Are you planning on posting a binary?
I'm intrigued by your selected memory model - it is far more ambitious than I had expected. It would appear that GCC will soon be able to achieve all of the code size of PASM with all of the speed of Spin!
I look forward to the inevitable benchmark shootout
Ross.
Brilliant! Let me know when you have a method for coding a COG driver in C for said shootout.
What has been accomplished is not a milestone as defined in the project. Nothing is ready for distribution.
It was just a small measure of progress which I am required to report regardless of anyone's opinion.
I don't get the seemingly hostile back and forth? Am I missing something?
The gcc stuff is being done at Parallax's request. There are a lot of very compelling reasons to go with gcc, not the least of which is Parallax business customers wanting it.
Also, I'm sure before they are done it will be able to use OBEX Spin and PASM objects too. However, one of the goals is the ability to write the equivalent of a Spin or PASM driver object using C/C++ and have it run in a cog without an LMM (in other words compile to native PASM). It'll be even more interesting when the P2 comes around.
I don't sense any hostility at all -- a good-natured competition maybe -- but nothing untoward. Any jousting that might exist in this arena can only be healthy for all parties concerned.
Whetstone, no it requires floating point and is too big.
Dhrystone, no it is all string oriented and is too big.
Star Trek, is right out.
I was thinking more in terms of our infamous recursive fibo() benchmark.
Or the C version of the heater_fft which is integer only and should fit in cog. Also does not need so many stack ops and would be a nice comparison to the PASM version.
I would much rather work with you than some others I've met. I think you should get over whatever is bugging you.
I'm not sure if that is a compliment or a criticism. Perhaps it was intended to be both?
Actually, nothing was bugging me particularly - possibly excepting the degree to which this effort is consuming Parallax's obviously scarce resources - resources which (I believe) would have been much better spent documenting the instruction set of the Prop 2, and/or generating a working Spin/PASM compiler for it, so that the talented resource base that Parallax has garnered in these forums does not continue to go to waste (I mean where the Prop 2 is concerned, obviously). This issue just continues to floor me - how long do Parallax think the market is going to wait before they go off and adopt some of the other more powerful multi-core offerings that are appearing all the time (Gosh - soon I may even begin to agree with Leon!). Is the promise of eventual GCC support going to stem that tide? No, of course not!
However, now what is bugging me is that anyone should be surprised that I should be intensely interested in the progress of this work, in seeing how GCC compares to Catalina technically, and in commenting accordingly.
For instance, I find the choice of memory model (which is really the only technical detail as yet released) quite surprising. This is not a model I would ever adopt for Catalina, but naturally I am interested in understanding if there are applications for which it might prove to be a better choice than LMM. Yes, I accept it could be used to write a driver in C that can run entirely within a cog (something that you quite rightly point out that Catalina can't do) - but then I'm not at all convinced that this is a particularly useful thing to be able to do. However, I will try to keep an open mind.
I am no compiler writer and have no idea if that PASM plus hub stack model will ever prove to be useful.
But I imagine it's a good place to start for an anyone who has a experience retargeting GCC but has only just been introduced to the Prop. Isn't targeting raw machine code a natural instinct for a C compiler writer?
I am no compiler writer and have no idea if that PASM plus hub stack model will ever prove to be useful.
Well, apparently it can be used to create a driver in C that can run entirely within a cog.
IMO, the fact that they got GCC to compile anything that can run on the Propeller is an accomplishment.
I'm not so convinced that Parallax is wasting their resources. After all, their priorities and decisions are theirs, even when we don't agree with them. Sometime I feel like starting a thread titled "If I ran Parallax for a day..." to complain about all of the stuff that they did that I wouldn't have done. I'm sure Ken would be thrilled to have all of his mistakes pointed out, so you know, he could "improve".
I am no compiler writer and have no idea if that PASM plus hub stack model will ever prove to be useful.
But I imagine it's a good place to start for an anyone who has a experience retargetting GCC but has only just been introduced to the Prop. Isn't targetting raw machine code a natural instinct for a C compiler writer?
Well, not unless you only ever expect to write programs less than 500 instructions long. Otherwise, it would appear to be a bit of a dead end. I presume the GCC team also have a novel way round that particular constraint, but since they haven't told anyone what it is yet, it's a bit early to speculate how useful it might be.
But when they do release the information, I will feel quite entitled to either criticize or marvel (as appropriate!).
A simulator running on a PC shouldn't be too difficult, it's been done for the P1. For compiler development a single cog and hub memory should be all that is needed.
Comments
Amen!
Project resources are %90 confirmed. Ken Gracey has one more person to contact.
Official GCC requirements are scheduled to be finalized this Thursday.
Code for the GCC port is being committed into the repository.
Thanks,
--Steve
I agree with Jon that picking the right chip for the right job is a chip for me.
I for one am happy to hear that things are moving along.
Everything's good here, so we say nothing..
-Tor
I may be late to the game here, but if you need another GCC tester (particularly one who has been using GCC for cross compiling as well as building the cross compiler for well over a decade) then I might be able to help.
Also, I'm an avid Darwin user, so I can pitch in to make sure this mess builds under "that other" environment.
Either way, "go team go"!
-joe
Welcome! Yes, we need many testers and demo coders. Thanks for your interest.
--Steve
This week we are seeing code generator progress.
Code is being committed into the repository.
It is encouraging that we continue to see people volunteering for Propeller GCC testing.
Thanks blittled and base2design.
--Steve
Is it Prop 1 PASM within a cog or is there an LMM kernel defined already?
This first one is Prop 1 PASM in a COG with stack in HUB. It's like a little SPIN on steroids.
It's all very early, but one of our star contributors put together a serial TX program yesterday with this model.
You'll never guess what the program printed to my serial terminal
Brilliant, sounds like we nearly have something to be playing with, err I mean testing.
Congratulations on reaching your first milestone. Are you planning on posting a binary?
I'm intrigued by your selected memory model - it is far more ambitious than I had expected. It would appear that GCC will soon be able to achieve all of the code size of PASM with all of the speed of Spin!
I look forward to the inevitable benchmark shootout
Ross.
What has been accomplished is not a milestone as defined in the project. Nothing is ready for distribution.
It was just a small measure of progress which I am required to report regardless of anyone's opinion.
Catalina 3.1 now uses any existing OBEX Spin or PASM drivers - no C coding required. Why reinvent the wheel?
So - Whetstone? Dhrystone? FFT?
How about Super Star Trek at 10 paces? (phasers set to "stun", of course)
Ross.
-Phil
The gcc stuff is being done at Parallax's request. There are a lot of very compelling reasons to go with gcc, not the least of which is Parallax business customers wanting it.
Also, I'm sure before they are done it will be able to use OBEX Spin and PASM objects too. However, one of the goals is the ability to write the equivalent of a Spin or PASM driver object using C/C++ and have it run in a cog without an LMM (in other words compile to native PASM). It'll be even more interesting when the P2 comes around.
Roy
I don't sense any hostility at all -- a good-natured competition maybe -- but nothing untoward. Any jousting that might exist in this arena can only be healthy for all parties concerned.
-Phil
I'd classify it as "rivalry" rather than "hostility". What else would you expect?
Ross.
Dhrystone, no it is all string oriented and is too big.
Star Trek, is right out.
I was thinking more in terms of our infamous recursive fibo() benchmark.
Or the C version of the heater_fft which is integer only and should fit in cog. Also does not need so many stack ops and would be a nice comparison to the PASM version.
You can see, I want to play with this already:)
I'm not sure if that is a compliment or a criticism. Perhaps it was intended to be both?
Actually, nothing was bugging me particularly - possibly excepting the degree to which this effort is consuming Parallax's obviously scarce resources - resources which (I believe) would have been much better spent documenting the instruction set of the Prop 2, and/or generating a working Spin/PASM compiler for it, so that the talented resource base that Parallax has garnered in these forums does not continue to go to waste (I mean where the Prop 2 is concerned, obviously). This issue just continues to floor me - how long do Parallax think the market is going to wait before they go off and adopt some of the other more powerful multi-core offerings that are appearing all the time (Gosh - soon I may even begin to agree with Leon!). Is the promise of eventual GCC support going to stem that tide? No, of course not!
However, now what is bugging me is that anyone should be surprised that I should be intensely interested in the progress of this work, in seeing how GCC compares to Catalina technically, and in commenting accordingly.
For instance, I find the choice of memory model (which is really the only technical detail as yet released) quite surprising. This is not a model I would ever adopt for Catalina, but naturally I am interested in understanding if there are applications for which it might prove to be a better choice than LMM. Yes, I accept it could be used to write a driver in C that can run entirely within a cog (something that you quite rightly point out that Catalina can't do) - but then I'm not at all convinced that this is a particularly useful thing to be able to do. However, I will try to keep an open mind.
Ross.
But I imagine it's a good place to start for an anyone who has a experience retargeting GCC but has only just been introduced to the Prop. Isn't targeting raw machine code a natural instinct for a C compiler writer?
Well, apparently it can be used to create a driver in C that can run entirely within a cog.
IMO, the fact that they got GCC to compile anything that can run on the Propeller is an accomplishment.
I'm not so convinced that Parallax is wasting their resources. After all, their priorities and decisions are theirs, even when we don't agree with them. Sometime I feel like starting a thread titled "If I ran Parallax for a day..." to complain about all of the stuff that they did that I wouldn't have done. I'm sure Ken would be thrilled to have all of his mistakes pointed out, so you know, he could "improve".
Well, not unless you only ever expect to write programs less than 500 instructions long. Otherwise, it would appear to be a bit of a dead end. I presume the GCC team also have a novel way round that particular constraint, but since they haven't told anyone what it is yet, it's a bit early to speculate how useful it might be.
But when they do release the information, I will feel quite entitled to either criticize or marvel (as appropriate!).
Ross.
Oh no! What have I done???