Phil,
I think you are correct. It's pretty obviously the case given the contents of this thread if you read it through.
Heater,
I think you are sort of right, but it's not going to happen. Partially because it's not a black and white thing. It's not a world filled with just pros and casuals. It's wide spectrum of folks up and down the scale. Also because, there are existing professional customers that use the Prop 1, and moving to a Prop 2 for them will likely entail using existing Spin/PASM code. I do think Spin will see some upgrades on the Prop 2, but it will probably be able to run exisiting Spin code with little effort involved (it will not be binary compatible, just source level).
Also, Spin can address many professional needs, you are crazy to think otherwise. Not everyone is insistent on using ancient languages and tools based on ancient editors (holy cake someone asked for it to be vi? seriously?). Yes there are some that demand C/C++ or other more standard languages, but why cater to only them?
Even jobs that use C might benefit from a simple glue language like Spin, in the same manner that Spin and PASM interact now. it would be silly to hide Spin away, as if embarrassed by it. The thing that makes Spin a great tool (or "toy" IYO) is that it encourages play. And by play, I mean that it makes experimenting and trying out different things quick and easy. That can lead to more rapid application development which, any company will tell you, has a positive effect on the bottom line. Even if Spin code never ends up in a production product, it could still be beneficial for quickly testing new ideas. It may well be true that most companies will shun Spin because it's "different", but it should still be available to those companies who come to understand its benefits.
I didn't really expect to convince you. But it's enough for me to hear the choir's "amens" while I preach. Choir? Are you there?
I'm, was a bit harsh there about "toys in the cupboard". I don't want Spin to go away. I look forward to using it on Prop II. And I'm sure there are open mind developers of commercial products that are quite happy to use it , indeed understand it's advantages when working on the Prop. I'm may be crazy but not that crazy yet:)
However this is a thread entitled "GCC/Eclipse and Propeller 2...". So again I say why all this talk of Spin here? I think creating a new Spin compiler front out of GCC would be a waste of time and resources. And a proper integration of Spin with Eclipse is also not required. And wanting C and Spin to interoperate in the same program is not required.
(holy cake someone asked for it to be vi? seriously?).
Don't panic, there is nothing you have to do to vi to make it work nicely with Spin. I uses vi to edit Spin code a lot. It has very nice Spin syntax highlighting. Is a lot faster than the Prop tool. In fact it is in every way superior to the Prop Tool starting from the point that the Prop Tool can't even run on my machine:)
Tools and languages may be ancient, but they work damn well. Once you have invented the wheel it's hard to find anything better to replace it:)
Surprising as it may seem, I agree with Phil. My reservations about Spin are primarily technical, not philosophical. If the proposed toolchain can't support Spin as well, then how is it an advance on what we have at present?
I'll throw in another one as well - If the toolchain doesn't suppport both the Prop I and the Prop II, then what's the point of it? Are we saying that professional users won't use the Prop I? That's rubbish! They'll use it if it suits their purpose - but they certainly won't use it if they have to change tools to do so!
If the toolchain doesn't suppport both the Prop I and the Prop II, then what's the point of it?
Good point.
In my mind there are two tool chains. One for that new target market of "professional" programmers and one continuing in the tradition of ultra simplicity for the rest of us. (Yes, I'm not a "professional" when it comes to my Prop hobby, I have tried to get it into some commercial product developments though.)
The "professional" tool is the all singing all dancing large scale IDE like Eclipse. Naturally it provides a C compiler for the Prop. Hopefully also C++ and perhaps some other languages. It's primary target is the Prop II simply because space limitations on the Prop I make C programming there less attractive. Mind you I have seen people coding in C for those tiny PICs and AVRs.
Meanwhile Spin gets it's own IDE. That ultra simple Prop Tool like tool for the rest of the world of "casual" programmers. Except that it is open sourced, it is cross platform. Perhaps take the Spin compiler that it looks like Roy is creating in C/C++ and use it with PZST from Andrey Demenyev.
If the Prop Tool cannot be open sourced or made cross platform because of licensing restrictions on some key component then it has no future. Just scrap it. There is already at least one replacement waiting in the wings.
Not everyone is insistent on using ancient languages and tools based on ancient editors (holy cake someone asked for it to be vi? seriously?). Yes there are some that demand C/C++ or other more standard languages, but why cater to only them?
You don't have to cater to them - they will work around you however hard you try to nobble them with fancy IDEs and graphical frippery. Many of these "ancient" tools are still under intense active development. The people who choose to use them generally designed the languages they're programming in, have memorized all the library calls they will ever need, can generally compile and run code in their head faster than using a computer, and often don't need to do any debugging at all.
All they want is a set of tools that maximizes the speed at which they can convert the code in their heads into executable form.
Linus Torvalds and Richard Stallman apparently both still use emacs - which explains why Windows is still more popular than Linux (if they had used vi instead it would probably be the other way around!).
By the way, Roy, what's this about "ancient languages". Spin, although it is new, is in many ways an ancient language. Lacking in the power and expressiveness of a lot of other languages that have evolved since FORTRAN and Algol.
It doesn't make sense to leave Propeller 1 out of the GCC tool chain back-end plan.
After all, we have to have hardware for development and they are in the same machine family.
Heater I understand your position, but you're probably just throwing GAS on the fire.
Spin's expressiveness and performance (via optimization) can easily be augmented without any changes to its basic flavor or to the VM. That's why it's so important to lift its compiler out of the dusty x86 assembly dungeon and ensconce it in a sparkly new HLL, so people can extend it. Heck, I might even have to learn C so I can implement my own ideas!
I do wonder where the BST code base might fit into this scheme, if at all. I'm surprised we haven't heard from Brad in this thread. (He hasn't posted anything in the forum since March.)
Just get rid of the $, @, regex, implicit variables, hash tables, and other junk in PERL and add typed variable declarations to you functions and function signatures. Nothing to it.
Heater I understand your position, but you're probably just throwing GAS on the fire.
Ha, as I spit morning coffee all over keyboard:)
You are right, I said "I rest my case" about a thousand post ago. I should stick to that.
Phil,
Spin's expressiveness and performance (via optimization) can easily be augmented without any changes to its basic flavor or to the VM. That's why it's so important to lift its compiler out of the dusty x86 assembly dungeon and ensconce it in a sparkly new HLL, so people can extend it. Heck, I might even have to learn C so I can implement my own ideas!
Why learn C to do that, why not do it in Spin? Could it be because of the lack of Spins power and expressiveness of which I speak:)
Seriously whilst there are probably some improvements to Spin that can be made, at some point we might ask "why are we creating yet another language" and reinventing the wheel?
C++ can be used in such a way as to provide all the features of Spin (objects and the like) on the Prop without any over head over C for example.
Just get rid of the $, @, regex, implicit variables, hash tables, and other junk in PERL ...
Geez, what's left?!! I'd feel naked without hashes and regexes. Maybe I should become just competent enough in C to read and rewrite the compiler in Perl. (Except that would probably slow it down ten-fold.)
Linus Torvalds and Richard Stallman apparently both still use emacs - which explains why Windows is still more popular than Linux (if they had used vi instead it would probably be the other way around!).
Boy I hope the emacs fans don't hear about that. We don't need an emacs-vi brawl here too.
Linus Torvalds and Richard Stallman apparently both still use emacs - which explains why Windows is still more popular than Linux (if they had used vi instead it would probably be the other way around!).
Ross.
Stallman developed emacs. I've always liked it, but I haven't used it for a long time.
Spin's expressiveness and performance (via optimization) can easily be augmented without any changes to its basic flavor or to the VM. That's why it's so important to lift its compiler out of the dusty x86 assembly dungeon and ensconce it in a sparkly new HLL, so people can extend it.
I'm not sure why we would want to write the compiler for our shiny new modern language Spin in an ancient language like C or C++. Let's write it in Spin itself. After all, C compilers are almost always written in C. If an ancient language like C can implement itself then surely a modern language like Spin can do the same even better.
I'm not sure why we would want to write the compiler for our shiny new modern language Spin in an ancient language like C or C++. Let's write it in Spin itself. After all, C compilers are almost always written in C. If an ancient language like C can implement itself then surely a modern language like Spin can do the same even better.
David,
I had to read this twice before I realized you were joking!
I think creating a new Spin compiler front out of GCC would be a waste of time and resources.
I'm afraid I was probably the one who mentioned this idea first but it was mostly to show that adopting the GCC toolchain doesn't necessarily rule out the use of Spin. However, while it would be perfectly possible to create a Spin frontend for GCC, I agree that it should not be very high priority and may not have much value at all if there is no interest in linking Spin code with C/C++ code. It should certainly not be a focus of the initial project.
I'm the one that suggested VI, but I was just kidding. I did put a smiley when I mentioned it. Several of us would be happy with VI, but I know that most people aren't comfortable with it. It may have something to do with whether a person can touch-type, or not. VI is efficient if you can touch-type, and it would be harder if you can't.
It's a bit puzzling that we can't agree on the approach, or even what will be implemented. Of course, Spin will be supported on the Prop 2. It would be foolish not to support it. Parallax has stated that they are redoing the Spin compiler in a high level language. It's not clear whether it makes sense to create a GCC variant that compiles Spin, but it's certainly worth investigating.
Chip stated at the beginning of the thread he wants to create a cross-compiler suite for the Prop 2 that supports Spin, C/C++ and possibly other languages. So clearly he wants to support Spin and C/C++ on the Prop 2.
The title of this thread mentions "GCC/Eclipse", so these are the implied tools for the compiler and the IDE's GUI, but this is open for debate. I don't understand why we aren't considering Ross' C compiler. It seems like a good basis to start with. Of course, GCC may be a better way to go, but we should be able to use a large amount of the work that Ross has done. And Parallax should pay Ross to use his code. Most companies contract out to some other company to develop their tools.
I don't have much of an opinion on the GUI. Simple and leaner is better for me.
I guess my comment wasn't entirely supposed to be a joke, merely a challenge that if Spin is such a modern and advanced language it should be possible and also desireable to write its compiler in Spin itself. I know you've written one that runs on the Propeller itself and that was/is a great achievement! In fact, given the existence of Sphinx I'm not sure why there is so much talk about needing a language to do on-chip development. We already have that in Sphinx!
The only real reason for the smiley is that there is no Spin compiler that I know of that runs on the PC and generates code for the PC so any effort to do this would have to include creating a Spin compiler that targets x86 code and runs on a PC under Windows/Mac OS X/Linux.
I have ported Sphinx to run under SpinSim on a PC and Linux. So technically, it can run on a PC and produce code that runs on a PC, but within the SpinSim VM. However, it is clearly better to write the compiler in a language that supports data structures, and runs on most developement platforms.
The title of this thread mentions "GCC/Eclipse", so these are the implied tools for the compiler and the IDE's GUI, but this is open for debate. I don't understand why we aren't considering Ross' C compiler. It seems like a good basis to start with. Of course, GCC may be a better way to go, but we should be able to use a large amount of the work that Ross has done. And Parallax should pay Ross to use his code. Most companies contract out to some other company to develop their tools.
As Francis Urquhart would say, "You might very well think so - but I couldn't possibly comment !"
But seriously, that's why (at least for me) it is all about what Parallax wants other than C that will make the difference. If they just want C, then we have that. If they want C++ (or Fortran or Ada) then GCC may be a better way to go. If they want Spin as well, then I really don't know what is the best course.
As to the IDE - I'm beginning to agree with whoever suggested this be made a separate discussion. There are many IDEs, and they can all be made to support any languages you want. IDE wars are nearly as futile as text editor wars
I'm not sure why we would want to write the compiler for our shiny new modern language Spin in an ancient language like C or C++. Let's write it in Spin itself. After all, C compilers are almost always written in C. If an ancient language like C can implement itself then surely a modern language like Spin can do the same even better.
... I just thought it was funny that anyone would regard Spin as a "modern" language. Fantastic as it is for its intended purpose, from a language purists perspective, Spin makes even C look "high level" - and Modula-2 look positively "futuristic"!.
I certainly didn't mean to belittle mparks Sphinx efforts, which are currently the best choice for self-hosted development we have!
A very interesting webinar - thanks to Parallax for hosting it. It demonstrated their commitment to developing a professional programming toolset for the Prop II. Special thanks to jazzed for his presentation on GCC/Eclipse.
We learned enough from Chip about the Prop II instruction set to begin preliminary work on various LMM-based language compilers for the new processor. It doesn't look like being too difficult - which is a credit to Chip's ingenuity!
The best news for me is that the performance of LMM-based languages on the Prop II should be much improved over their performance on the Prop I, with the ratio of performance between PASM executed from Hub RAM, and PASM executed from Cog RAM, being theoretically reduced to only 2:1 (although how close we get to that in practice depends on how good the various code generators are!).
Given that the native clock speed of the Prop II is expected to be twice that of the Prop I, it seems we may be able to execute PASM from Hub RAM on the Prop II as fast as we can currrently execute PASM from Cog RAM on the Prop I - and do it on all 8 cogs simultaneously.
Also, the new Prop II instructions will allow the code size to be reduced significantly for stack-oriented languages like C - possibly halved in many cases. So even though the Prop II only has 4 times as much Hub RAM as the Prop I, we may still effectively get 8 times as much codespace when using a high level language.
There is a minor downside in that the Prop II instruction set is significantly more complex than that of the Prop I, so it may be harder for users to use the new instructions effectively except from a compiled language - but if the performance of such languages is good enough there will be far less need to resort to hand-coded PASM except where absolute maximum performance is required - which in itself will go a long way to bringing the Prop II into line with the expectations of users who have experience with other processors.
Another minor downside is that LMM will work quite differently on the Prop II - so much so that there is unlikely to be much commonality between the LMM "primitives" supported by kernels on the Prop I and on the Prop II. This means there will probably need to be separate code generators for the Prop I and the Prop II (at least in Catalina - which already has two!).
While it is still early days yet in determining where Parallax wants to go with GCC/Eclipse, from my perspective I can already see most of the changes I will need to make to Catalina to support the Prop II - and (time permitting) I will probably do this whether or not there ends up being a GCC port. Of course, with GCC there is the advantage that the porting process necessarily generates a suitable assembler, whereas with Catalina (unless I want to write my own) I will have to wait until either Parallax, BradC, or MPark add the new Prop II instructions into their respective toolsets. But pretty much as soon as any one of these becomes available, I would expect to be able to release a version of Catalina for the Prop II.
If I had to predict the most likely outcome based on this webinar, I currently think we might end up with two C compilers for the Prop II - Catalina (which will support both the Prop I and Prop II) and GCC (which I'm guessing will probably only support the Prop II).
Now if only we had some actual silicon to work with ... !
"...the ratio of performance between PASM executed from Hub RAM, and PASM executed from Cog RAM, being theoretically reduced to only 2:1..."
Zog is going to be mightily miffed about that.:)
Edit: Some hours later: These revelations by RossH seem to be so astounding that the forum has been shocked into silence!
Another minor downside is that LMM will work quite differently on the Prop II
Presumably existing PASM code, and hence existing LMM kernels will run unchanged (or almost unchanged) on the Prop II without the benefits of the available speed ups. So we wont have to wait for new code generators in order to use Catalina on the Prop II.
heater: Unfortunately I don't look outside the Prop forum very often. I suspect this maybe the same as others, and hence the silence. Hey, this should make ZiCog fly
... the ratio of performance between PASM executed from Hub RAM, and PASM executed from Cog RAM, being theoretically reduced to only 2:1 (although how close we get to that in practice depends on how good the various code generators are!).
Given that the native clock speed of the Prop II is expected to be twice that of the Prop I, it seems we may be able to execute PASM from Hub RAM on the Prop II as fast as we can currrently execute PASM from Cog RAM on the Prop I...
I thought that Prop2 PASM is 8 times faster than on Prop1 (160 MHz with 1 cycle per instruction to 80 MHz and 4 cycle/instruction). So with a ratio of 2:1 the LMM speed of the Prop2 should be 4 times higher then the native PASM speed of Prop1.
That would be awsome!
I can imagine a 4 instruction LMM loop on Prop2 with RDQUAD and then execute the 4 loaded longs as instructions and then loop. If this fits in 8 cycles (= 1 hub cycle) then 2:1 is possible.
Are the details of LMM on Prop2 kept secret for now, or can one of the Webinar attendees explain a bit more?
I thought that Prop2 PASM is 8 times faster than on Prop1 (160 MHz with 1 cycle per instruction to 80 MHz and 4 cycle/instruction). So with a ratio of 2:1 the LMM speed of the Prop2 should be 4 times higher then the native PASM speed of Prop1.
I'd forgotten about the 1 cycle per instruction instead of 4, so you may be right!
That would be awsome!
I can imagine a 4 instruction LMM loop on Prop2 with RDQUAD and then execute the 4 loaded longs as instructions and then loop. If this fits in 8 cycles (= 1 hub cycle) then 2:1 is possible.
Are the details of LMM on Prop2 kept secret for now, or can one of the Webinar attendees explain a bit more?
Andy
Not secret (as far as I know) but also not well documented yet. I won't try to explain further because (as you can see) I'm a bit hazy about some of the hardware details myself.
Hopefully the more hardware-savvy attendees will jump in and explain. I'm mainly interested in the new instructions, which should significantly improve the speed (and also reduce the code size) of stack-oriented languages that use LMM.
Comments
I think you are correct. It's pretty obviously the case given the contents of this thread if you read it through.
Heater,
I think you are sort of right, but it's not going to happen. Partially because it's not a black and white thing. It's not a world filled with just pros and casuals. It's wide spectrum of folks up and down the scale. Also because, there are existing professional customers that use the Prop 1, and moving to a Prop 2 for them will likely entail using existing Spin/PASM code. I do think Spin will see some upgrades on the Prop 2, but it will probably be able to run exisiting Spin code with little effort involved (it will not be binary compatible, just source level).
Also, Spin can address many professional needs, you are crazy to think otherwise. Not everyone is insistent on using ancient languages and tools based on ancient editors (holy cake someone asked for it to be vi? seriously?). Yes there are some that demand C/C++ or other more standard languages, but why cater to only them?
Even jobs that use C might benefit from a simple glue language like Spin, in the same manner that Spin and PASM interact now. it would be silly to hide Spin away, as if embarrassed by it. The thing that makes Spin a great tool (or "toy" IYO) is that it encourages play. And by play, I mean that it makes experimenting and trying out different things quick and easy. That can lead to more rapid application development which, any company will tell you, has a positive effect on the bottom line. Even if Spin code never ends up in a production product, it could still be beneficial for quickly testing new ideas. It may well be true that most companies will shun Spin because it's "different", but it should still be available to those companies who come to understand its benefits.
I didn't really expect to convince you. But it's enough for me to hear the choir's "amens" while I preach.
-Phil
I'm, was a bit harsh there about "toys in the cupboard". I don't want Spin to go away. I look forward to using it on Prop II. And I'm sure there are open mind developers of commercial products that are quite happy to use it , indeed understand it's advantages when working on the Prop. I'm may be crazy but not that crazy yet:)
However this is a thread entitled "GCC/Eclipse and Propeller 2...". So again I say why all this talk of Spin here? I think creating a new Spin compiler front out of GCC would be a waste of time and resources. And a proper integration of Spin with Eclipse is also not required. And wanting C and Spin to interoperate in the same program is not required.
Don't panic, there is nothing you have to do to vi to make it work nicely with Spin. I uses vi to edit Spin code a lot. It has very nice Spin syntax highlighting. Is a lot faster than the Prop tool. In fact it is in every way superior to the Prop Tool starting from the point that the Prop Tool can't even run on my machine:)
Tools and languages may be ancient, but they work damn well. Once you have invented the wheel it's hard to find anything better to replace it:)
Surprising as it may seem, I agree with Phil. My reservations about Spin are primarily technical, not philosophical. If the proposed toolchain can't support Spin as well, then how is it an advance on what we have at present?
I'll throw in another one as well - If the toolchain doesn't suppport both the Prop I and the Prop II, then what's the point of it? Are we saying that professional users won't use the Prop I? That's rubbish! They'll use it if it suits their purpose - but they certainly won't use it if they have to change tools to do so!
Ross.
Good point.
In my mind there are two tool chains. One for that new target market of "professional" programmers and one continuing in the tradition of ultra simplicity for the rest of us. (Yes, I'm not a "professional" when it comes to my Prop hobby, I have tried to get it into some commercial product developments though.)
The "professional" tool is the all singing all dancing large scale IDE like Eclipse. Naturally it provides a C compiler for the Prop. Hopefully also C++ and perhaps some other languages. It's primary target is the Prop II simply because space limitations on the Prop I make C programming there less attractive. Mind you I have seen people coding in C for those tiny PICs and AVRs.
Meanwhile Spin gets it's own IDE. That ultra simple Prop Tool like tool for the rest of the world of "casual" programmers. Except that it is open sourced, it is cross platform. Perhaps take the Spin compiler that it looks like Roy is creating in C/C++ and use it with PZST from Andrey Demenyev.
If the Prop Tool cannot be open sourced or made cross platform because of licensing restrictions on some key component then it has no future. Just scrap it. There is already at least one replacement waiting in the wings.
You don't have to cater to them - they will work around you however hard you try to nobble them with fancy IDEs and graphical frippery. Many of these "ancient" tools are still under intense active development. The people who choose to use them generally designed the languages they're programming in, have memorized all the library calls they will ever need, can generally compile and run code in their head faster than using a computer, and often don't need to do any debugging at all.
All they want is a set of tools that maximizes the speed at which they can convert the code in their heads into executable form.
Linus Torvalds and Richard Stallman apparently both still use emacs - which explains why Windows is still more popular than Linux (if they had used vi instead it would probably be the other way around!).
Ross.
After all, we have to have hardware for development and they are in the same machine family.
Heater I understand your position, but you're probably just throwing GAS on the fire.
I do wonder where the BST code base might fit into this scheme, if at all. I'm surprised we haven't heard from Brad in this thread. (He hasn't posted anything in the forum since March.)
-Phil
Just get rid of the $, @, regex, implicit variables, hash tables, and other junk in PERL and add typed variable declarations to you functions and function signatures. Nothing to it.
Ha, as I spit morning coffee all over keyboard:)
You are right, I said "I rest my case" about a thousand post ago. I should stick to that.
Phil,
Why learn C to do that, why not do it in Spin? Could it be because of the lack of Spins power and expressiveness of which I speak:)
Seriously whilst there are probably some improvements to Spin that can be made, at some point we might ask "why are we creating yet another language" and reinventing the wheel?
C++ can be used in such a way as to provide all the features of Spin (objects and the like) on the Prop without any over head over C for example.
-Phil
Stallman developed emacs. I've always liked it, but I haven't used it for a long time.
I'm not sure why we would want to write the compiler for our shiny new modern language Spin in an ancient language like C or C++. Let's write it in Spin itself. After all, C compilers are almost always written in C. If an ancient language like C can implement itself then surely a modern language like Spin can do the same even better.
David,
I had to read this twice before I realized you were joking!
Ross.
Sorry. I forgot the smiley face!
I'm afraid I was probably the one who mentioned this idea first but it was mostly to show that adopting the GCC toolchain doesn't necessarily rule out the use of Spin. However, while it would be perfectly possible to create a Spin frontend for GCC, I agree that it should not be very high priority and may not have much value at all if there is no interest in linking Spin code with C/C++ code. It should certainly not be a focus of the initial project.
It's a bit puzzling that we can't agree on the approach, or even what will be implemented. Of course, Spin will be supported on the Prop 2. It would be foolish not to support it. Parallax has stated that they are redoing the Spin compiler in a high level language. It's not clear whether it makes sense to create a GCC variant that compiles Spin, but it's certainly worth investigating.
Chip stated at the beginning of the thread he wants to create a cross-compiler suite for the Prop 2 that supports Spin, C/C++ and possibly other languages. So clearly he wants to support Spin and C/C++ on the Prop 2.
The title of this thread mentions "GCC/Eclipse", so these are the implied tools for the compiler and the IDE's GUI, but this is open for debate. I don't understand why we aren't considering Ross' C compiler. It seems like a good basis to start with. Of course, GCC may be a better way to go, but we should be able to use a large amount of the work that Ross has done. And Parallax should pay Ross to use his code. Most companies contract out to some other company to develop their tools.
I don't have much of an opinion on the GUI. Simple and leaner is better for me.
I don't get it.
-Phil
I guess my comment wasn't entirely supposed to be a joke, merely a challenge that if Spin is such a modern and advanced language it should be possible and also desireable to write its compiler in Spin itself. I know you've written one that runs on the Propeller itself and that was/is a great achievement! In fact, given the existence of Sphinx I'm not sure why there is so much talk about needing a language to do on-chip development. We already have that in Sphinx!
The only real reason for the smiley is that there is no Spin compiler that I know of that runs on the PC and generates code for the PC so any effort to do this would have to include creating a Spin compiler that targets x86 code and runs on a PC under Windows/Mac OS X/Linux.
As Francis Urquhart would say, "You might very well think so - but I couldn't possibly comment !"
But seriously, that's why (at least for me) it is all about what Parallax wants other than C that will make the difference. If they just want C, then we have that. If they want C++ (or Fortran or Ada) then GCC may be a better way to go. If they want Spin as well, then I really don't know what is the best course.
As to the IDE - I'm beginning to agree with whoever suggested this be made a separate discussion. There are many IDEs, and they can all be made to support any languages you want. IDE wars are nearly as futile as text editor wars
As to David's comment ...
... I just thought it was funny that anyone would regard Spin as a "modern" language. Fantastic as it is for its intended purpose, from a language purists perspective, Spin makes even C look "high level" - and Modula-2 look positively "futuristic"!.
I certainly didn't mean to belittle mparks Sphinx efforts, which are currently the best choice for self-hosted development we have!
Ross.
A very interesting webinar - thanks to Parallax for hosting it. It demonstrated their commitment to developing a professional programming toolset for the Prop II. Special thanks to jazzed for his presentation on GCC/Eclipse.
We learned enough from Chip about the Prop II instruction set to begin preliminary work on various LMM-based language compilers for the new processor. It doesn't look like being too difficult - which is a credit to Chip's ingenuity!
The best news for me is that the performance of LMM-based languages on the Prop II should be much improved over their performance on the Prop I, with the ratio of performance between PASM executed from Hub RAM, and PASM executed from Cog RAM, being theoretically reduced to only 2:1 (although how close we get to that in practice depends on how good the various code generators are!).
Given that the native clock speed of the Prop II is expected to be twice that of the Prop I, it seems we may be able to execute PASM from Hub RAM on the Prop II as fast as we can currrently execute PASM from Cog RAM on the Prop I - and do it on all 8 cogs simultaneously.
Also, the new Prop II instructions will allow the code size to be reduced significantly for stack-oriented languages like C - possibly halved in many cases. So even though the Prop II only has 4 times as much Hub RAM as the Prop I, we may still effectively get 8 times as much code space when using a high level language.
There is a minor downside in that the Prop II instruction set is significantly more complex than that of the Prop I, so it may be harder for users to use the new instructions effectively except from a compiled language - but if the performance of such languages is good enough there will be far less need to resort to hand-coded PASM except where absolute maximum performance is required - which in itself will go a long way to bringing the Prop II into line with the expectations of users who have experience with other processors.
Another minor downside is that LMM will work quite differently on the Prop II - so much so that there is unlikely to be much commonality between the LMM "primitives" supported by kernels on the Prop I and on the Prop II. This means there will probably need to be separate code generators for the Prop I and the Prop II (at least in Catalina - which already has two!).
While it is still early days yet in determining where Parallax wants to go with GCC/Eclipse, from my perspective I can already see most of the changes I will need to make to Catalina to support the Prop II - and (time permitting) I will probably do this whether or not there ends up being a GCC port. Of course, with GCC there is the advantage that the porting process necessarily generates a suitable assembler, whereas with Catalina (unless I want to write my own) I will have to wait until either Parallax, BradC, or MPark add the new Prop II instructions into their respective toolsets. But pretty much as soon as any one of these becomes available, I would expect to be able to release a version of Catalina for the Prop II.
If I had to predict the most likely outcome based on this webinar, I currently think we might end up with two C compilers for the Prop II - Catalina (which will support both the Prop I and Prop II) and GCC (which I'm guessing will probably only support the Prop II).
Now if only we had some actual silicon to work with ... !
Ross.
That all sounds brilliant.
"...the ratio of performance between PASM executed from Hub RAM, and PASM executed from Cog RAM, being theoretically reduced to only 2:1..."
Zog is going to be mightily miffed about that.:)
Edit: Some hours later: These revelations by RossH seem to be so astounding that the forum has been shocked into silence!
Presumably existing PASM code, and hence existing LMM kernels will run unchanged (or almost unchanged) on the Prop II without the benefits of the available speed ups. So we wont have to wait for new code generators in order to use Catalina on the Prop II.
heater: Unfortunately I don't look outside the Prop forum very often. I suspect this maybe the same as others, and hence the silence. Hey, this should make ZiCog fly
I thought that Prop2 PASM is 8 times faster than on Prop1 (160 MHz with 1 cycle per instruction to 80 MHz and 4 cycle/instruction). So with a ratio of 2:1 the LMM speed of the Prop2 should be 4 times higher then the native PASM speed of Prop1.
That would be awsome!
I can imagine a 4 instruction LMM loop on Prop2 with RDQUAD and then execute the 4 loaded longs as instructions and then loop. If this fits in 8 cycles (= 1 hub cycle) then 2:1 is possible.
Are the details of LMM on Prop2 kept secret for now, or can one of the Webinar attendees explain a bit more?
Andy
Not secret (as far as I know) but also not well documented yet. I won't try to explain further because (as you can see) I'm a bit hazy about some of the hardware details myself.
Hopefully the more hardware-savvy attendees will jump in and explain. I'm mainly interested in the new instructions, which should significantly improve the speed (and also reduce the code size) of stack-oriented languages that use LMM.
Ross.