Hby Prof. Feature
3 8 C++ language support
5 10 C language support
10 7 Spin language support
3 3 PBASIC language support
10 10 PASM language support
1 3 C compiler generates PASM
10 10 C compiler generates LMM PASM
3 2 C compiler generates XMM PASM (executes from external memory)
1 1 C compiler generates spin bytecodes
4 3 Spin code can execute from external memory
1 1 Compiler and tools must be based on GCC
5 8 Simulator
5 10 Debugger
8 9 Graphical interface to all features
5 7 Command line interface to all features
10 10 Runs under Windows
5 3 Runs under Linux
1 1 Runs on a Mac
5 8 Text editor must have lots of features
1 2 Compiler tool-chain, and make process similar to GCC
Pursuant to the Mac part of the question, there's a rumor afoot that Apple is planning to phase out OS/X, in favor of iOS:
That's a pretty good example of a quote taken out of context. When Jobs said they're "demoting" the PC, he meant that it is no longer the center of the "digital hub", meaning that iDevices don't have to sync to the computer using iTunes. Now they sync to the (and I hate typing this word) "cloud". OS X will be gone someday, but not very soon. And someday all Mac applications may have to be purchased through the App Store, but that won't happen really soon either and if it does I don't see any reason why a Propeller dev tool would be rejected from the store.
I would be shocked to see Apple move off of OS X. iOS isn't ready yet for general computing.
IMHO, they will just transition to the use of the App Store for more and better integration among their various products, starting with "Lion" being App Store only distribution... That actually makes perfect sense on the computer platform. Everybody gets a account for updates, etc... and that's just a sales opportunity. Everybody also gets to do what computers do; namely, just write and or use software from any number of sources, not just the app store.
That's annoying as physical media would be better for longer term use of the computers. Already, their machines are shipping without physical media now, though media can still be purchased. I'm snagging a set of "snow leopard" for my Mac, just so I have physical media to install from going forward. Never did like not having a baseline distribution of a OS, though there always is disk cloning, which I do regularly, as my thinkpad didn't come with physical media EITHER. Apple is not alone in this.
Many applications, like CAD will be difficult to port over to iOS, for a lot of reasons, a primary one being the cost of the port probably doesn't equate to the new revenue said port would bring in, and the losses from customers not moving over, and or dropping the app to run on some other OS. The body of OSS available for the Mac isn't something to just throw away either.
Apple themselves uses some high end cad (the CAD I work with every day BTW) to do their product design on OS X, and that port was not cheap. Doing it again is highly likely off the table, all things given.
The computer operating system won't go anywhere. There will be integration, and probably some "iOS" mode people can launch into, if that makes sense, and some extension of use cases to include computer, pad, pod, etc...
That's a pretty good example of a quote taken out of context. When Jobs said they're "demoting" the PC, he meant that it is no longer the center of the "digital hub", meaning that iDevices don't have to sync to the computer using iTunes. Now they sync to the (and I hate typing this word) "cloud". OS X will be gone someday, but not very soon. And someday all Mac applications may have to be purchased through the App Store, but that won't happen really soon either and if it does I don't see any reason why a Propeller dev tool would be rejected from the store.
Wow, this kind of sounds like Apple is becoming the "Big Brother" they saved humanity from in their 1984 Superbowl ad. I hope most of us are too smart to fall for that.:)
Oops, I forgot to put a smiley on my previous post. I have added the smiley. I agree with you SSteve, Apple should not be considered in this thread. Oh wait, that's not what I meant. I mean, of course the tools will be supported on a Mac -- as long as they can be dual-booted in Windows or Linux. Oh noooo. That's not what I meant either. Uh, I'll just be quiet now.;)
FWIW: I only posted what I did, because I don't think the rumor is anything material, and the tools, such as they will be, should run on a Mac no problem. It's just a UNIX at the core, and that's going to be true for some time, that's all.
That, and I have one now, along with Win 7, and a Ubuntu machine. The trifecta Would love some excuse to hook a prop to those boxes.
Has there been any progress or decisions made by Parallax on this subject yet?
I'm sure there are a lot of people here interested in learning more about how Parallax intends to cater to professional users of the Propeller and Propeller 2 - even if they are not particularly interested in arguing about the minutiae of particular tools.
As you might be able to guess, the aspect that interests me most is neither the GCC nor Eclipse tools themselves - it is how Parallax currently thinks Spin will fit into this particular puzzle.
My interest is both from a purely technical perspective (one thing we all learned from the Prop 1 is that combining Spin with "traditional" languages like C in a meanginful manner is quite difficult, and I'd like to hear if Parallax has any new ideas about that) and also personal (the Catalina Hardware Abstraction Layer is currently implemented in Spin, and I will soon have to make a decision as to whether to persevere with this approach for the Prop 2 or not).
An update from Parallax would be much appreciated.
I know that Ken and all the Parallax staff are stretched to the max right now but that this topic is still of singular importance. We all need to hang tight for awhile longer. Parallax will return to this thread, I can assure you.
I hear NASA still uses Fortran. They beg for Community College's to teach it here. There's not enough interest.
This hearsay could be out of date of course.
I hear NASA still uses Fortran. They beg for Community College's to teach it here. There's not enough interest.
This hearsay could be out of date of course.
I have a friend who recently started work with a COBOL programming house. I couldn't believe that such things still existed, but apparently their business is expanding.
The funny thing is that he's not a trained programmer - but it seems with COBOL you can't tell the difference between a program written by someone with decades of training and experience, and one written by someone with none at all.
With COBOL the program is usually designed by someone else, and the programmers simply convert it into code. They used to be called coders rather than programmers. It's still the best language for business applications as there are no rounding errors and it has built-in database support. C would need special libraries and would be rather messy, although C++ could help.
I hear NASA still uses Fortran. They beg for Community College's to teach it here. There's not enough interest.
This hearsay could be out of date of course.
Fortran is still actively supported at places like
There is a very good FORTRAN-C translator utility. I used it once to convert a large program to C; the resultant code compiled and ran without any problems.
Fortran is still (unfortunately) very big with the scientific crowd... Fortran is better for matrix operations and such.
But, I think it's dying and I'm pretty sure C will take over...
But, I don't really see a need for Fortran on a microcontroller...
Fortran is still (unfortunately) very big with the scientific crowd... Fortran is better for matrix operations and such.
But, I think it's dying and I'm pretty sure C will take over...
But, I don't really see a need for Fortran on a microcontroller...
Have you looked at Fortran 95? It may be that the ancient versions of Fortran will eventually go away but it will take more than C to displace Fortran 95. I think some of the things it does would be difficult even in C++.
Whoa! Fortran 95 is definitely "not your father's Fortran!" I cut my teeth on Fortran -- at the time, a language formatted for punch cards -- but by the time I entered grad school, it was being panned as the "language of the streets." Structured, top-down programming was all the rage, and languages like Algol, Pacal, PL/I, and even PL360 had obtained the imprimatur of the intelligentsia. But it seems that the lessons of the past are causing a convergence in the computer language arena. Even Fortran is now looking modern!
I used a program that had a solid modeling kernel written in Fortran 95. SGI shipped run time libraries for that as late as 2005, on IRIX. I'm sure those got a Linux port, but I stepped away before trying their technical computing distribution of Linux. There are better kernels today; namely, Parasolid, but that one allowed for all the interesting geometry cases, where modern ones are somewhat trimmed down. (arcane things for the crowd here, I am sure)
If I could I’d like to bring you both back to the topic and up to date on our progress and plans relative to GCC. Most importantly, we thank you for your patience.
Since starting this thread we’ve been quiet, but using the time to talk with developers, to read this thread and to preliminarily identify the team and management framework. We will be approaching this project with a precise plan and predictable outcome. I’ve summarized how we see the effort shaping up – let me know where I’ve only added confusion and I’ll try to clarify (or ask jazzed for help).
Brief Overview
Our objective is to develop an open-source tool chain with a commercially-acceptable language using existing code bases. It is necessary for code to compile under Windows, Mac and Linux operating systems. Between the Propeller 2 design and tools, commercial product developers would have many reasons to use Propeller 2 in mass since it would have everything they want (more memory to support a LMM kernel for C/C++, I/O flexibility, more RAM, A/D, code protect, etc.).
To meet this goal we are furthering our plans to create a GCC tool-chain that will be generating LMM type executable instructions from C/C++ sources. An IDE such as NetBeans, Eclipse and/or Visual Studio would be used for command-line programming and debugging. We would evaluate and choose the tools for the front end but no decision has been made as of yet. Other tools could be added by the community, too.
The GCC compiler and IDE would be the official tool for C/C++ programming in Propeller 2. Spin/PASM (and other languages you like) could be used with the IDE through command-line interfaces.
The existing Parallax Propeller Tool created in Delphi will also be improved to support Spin/PASM in Propeller 2. The Propeller Tool may also be improved to support the GCC compiled code.
With these two approaches Parallax Semiconductor will continue to foster the Spin/PASM language environment concurrent with the C/C++ GCC effort. You read it right – we’ll have objects in both languages that meet the Gold Standard, relying in part on the community for C/C++ objects. This takes advantage of our current code base and provides an entry point for developers who rely on C/C++.
Spin/PASM Compiler port to C/C++, Parallax Micro C and BST
An open-source C/C++ based Spin/PASM compiler will be provided for both Propeller 1 and 2 chips.
Our Propeller 1 compiler is currently being ported by Roy Eltham to C/C++ so that enhancements could be made by the community who wish to compile on other operating systems or add other features to their code. This work is about 60% finished. Speaking with Chip and Jeff, after we successfully complete the Propeller 1 port we would do a side-by-side comparison with Chip’s Propeller 2 compiler written in ASM and then enhance it to support the Propeller 2 in similar code base. This will be released as a stand-alone command-line compiler and will be used by new releases of the Propeller Tool software.
Our internal software team lead by Jeff continues to develop Parallax Micro C, our translator for the Education program. This effort will be accomplished in parallel with the GCC project. Propeller 2 is not a replacement for Propeller 1 due to a higher cost, and Propeller 1 provides plenty of horsepower for the educational customer projects that will be showcased on the PropBOE. The Parallax Micro C effort will support a Prop Bot (using PropBOE with DC motors/encoders on an improved Boe-Bot chassis) as well as the PropBOE educational program.
In the near future (after the Propeller 1 C/C++ compiler is fully ported) we could ask Brad to incorporate it into BST. A side-by-side comparison of BST and the Propeller Tool from Parallax could be made, and we would discuss any feature additions with Brad. The objective would be to make BST take the place of the Propeller Tool, open-sourcing the code. Discussion still has to happen around this effort, and we owe a huge thanks to Brad for patience towards us.
Team Framework
We quickly recognized that we don’t have the staff resources or expertise to do this in-house. Parallax Semiconductor has formed an agreement with Steve Denson (jazzed) to be our Technical Liaison. His role consists of working on our behalf to assemble the team (both paid and community contributors), to review the scopes of work, to assemble the schedule and to interpret various technical issues to Parallax Semiconductor. Parallax will be the Project Manager (Jeff Martin and I).
The developer team would include an engineer who would design the LMM kernel, a GCC developer, Propeller coders for the libraries and bin utils, and a front-end developer for the IDE. The GCC and LMM kernel developers would both have backup people. I’ll defer to Steve to identify the team members once he has their approval.
Communication
The developers on this forum are critically important to the success of this project. Your projects including BST, PropBASIC, Catalina, Sphinx, and LMM are examples. If you feel that you aren’t being heard or that we haven’t provided the right kind of interface for this project please let me know.
A private forum will be opened for the GCC/IDE developers. Some community members are welcome here, too. Why private? If we make it public, we’ll never get through the minutiae posed by this project. Timelines will get extended because the developers will read and write forum posts instead of following through with our scope of work and schedule. The cost to Parallax Semiconductor would also increase as the details are debated instead of being coded. Further, some of the contract details are best kept between the developers and Parallax Semiconductor.
A public forum thread on Parallax Semiconductor will be managed by Steve Denson. Each week Steve will make an updated post on this thread, summarizing the activity going on around the project.
Steve will be the primary point of contact on behalf of Parallax Semiconductor.
Process
The basic process at this point is the following:
1. Parallax Semiconductor will provide an updated Propeller 2 Features and Specifications document to the developers and forum members. Our FAEs met with Chip last week for this purpose. An instruction set should follow soon and will be posted here http://www.parallaxsemiconductor.com/Products/propeller2specs. Provided the improved specifications are sufficient to give developers the background they need, we would move to the next step.
2. Technical Liaison Steve Denson will contact the developers and request that they develop a scope of work and schedule. Parallax Semiconductor will pay for their effort, providing us the ability to back out if we learn the costs and/or development timeline are not in our interests. This is an important point since we need to reconcile the whole investment with a timeline and likely return.
3. A schedule would be produced and team members commence work with a completion date timed to match Propeller 2. Parallax Semiconductor would provide working FPGA platforms to the key developers.
4. Project commences.
Please feel free to comment on what you’ve read. We hope to meet most everybody’s goals with these plans. And thank you to Chip for developing an interesting multi-core chip that enables these possibilities.
Comments
Totally over my head I'm afraid.
Cheers
If true, this would mean that any Propeller dev tools hosted by an Apple product would have to be purchased through the Apple App Store.
-Phil
That's a pretty good example of a quote taken out of context. When Jobs said they're "demoting" the PC, he meant that it is no longer the center of the "digital hub", meaning that iDevices don't have to sync to the computer using iTunes. Now they sync to the (and I hate typing this word) "cloud". OS X will be gone someday, but not very soon. And someday all Mac applications may have to be purchased through the App Store, but that won't happen really soon either and if it does I don't see any reason why a Propeller dev tool would be rejected from the store.
The Cloud
And why one will pay App Store for programs that are initially made for free use? - Type BradC BST for propeller?
Only for that that them are compiled to run on Apple iOS?
You don't need to pay to download free programs from either App Store.
IMHO, they will just transition to the use of the App Store for more and better integration among their various products, starting with "Lion" being App Store only distribution... That actually makes perfect sense on the computer platform. Everybody gets a account for updates, etc... and that's just a sales opportunity. Everybody also gets to do what computers do; namely, just write and or use software from any number of sources, not just the app store.
That's annoying as physical media would be better for longer term use of the computers. Already, their machines are shipping without physical media now, though media can still be purchased. I'm snagging a set of "snow leopard" for my Mac, just so I have physical media to install from going forward. Never did like not having a baseline distribution of a OS, though there always is disk cloning, which I do regularly, as my thinkpad didn't come with physical media EITHER. Apple is not alone in this.
Many applications, like CAD will be difficult to port over to iOS, for a lot of reasons, a primary one being the cost of the port probably doesn't equate to the new revenue said port would bring in, and the losses from customers not moving over, and or dropping the app to run on some other OS. The body of OSS available for the Mac isn't something to just throw away either.
Apple themselves uses some high end cad (the CAD I work with every day BTW) to do their product design on OS X, and that port was not cheap. Doing it again is highly likely off the table, all things given.
The computer operating system won't go anywhere. There will be integration, and probably some "iOS" mode people can launch into, if that makes sense, and some extension of use cases to include computer, pad, pod, etc...
That, and I have one now, along with Win 7, and a Ubuntu machine. The trifecta
Has there been any progress or decisions made by Parallax on this subject yet?
I'm sure there are a lot of people here interested in learning more about how Parallax intends to cater to professional users of the Propeller and Propeller 2 - even if they are not particularly interested in arguing about the minutiae of particular tools.
As you might be able to guess, the aspect that interests me most is neither the GCC nor Eclipse tools themselves - it is how Parallax currently thinks Spin will fit into this particular puzzle.
My interest is both from a purely technical perspective (one thing we all learned from the Prop 1 is that combining Spin with "traditional" languages like C in a meanginful manner is quite difficult, and I'd like to hear if Parallax has any new ideas about that) and also personal (the Catalina Hardware Abstraction Layer is currently implemented in Spin, and I will soon have to make a decision as to whether to persevere with this approach for the Prop 2 or not).
An update from Parallax would be much appreciated.
Ross.
I know that Ken and all the Parallax staff are stretched to the max right now but that this topic is still of singular importance. We all need to hang tight for awhile longer. Parallax will return to this thread, I can assure you.
-Phil
Understood - I just want to let them to know that some of us are still interested!
Ross.
Personally, I'm holding out for a Propeller Lisp compiler. :-)
Don't we have one already? Doesn't XLISP compile with Catalina?
This hearsay could be out of date of course.
I have a friend who recently started work with a COBOL programming house. I couldn't believe that such things still existed, but apparently their business is expanding.
The funny thing is that he's not a trained programmer - but it seems with COBOL you can't tell the difference between a program written by someone with decades of training and experience, and one written by someone with none at all.
Ross.
Fortran is still actively supported at places like
http://www.openwatcom.org/index.php/Main_Page
With the right backend, we could see Fortran on the Prop II !!
But, I think it's dying and I'm pretty sure C will take over...
But, I don't really see a need for Fortran on a microcontroller...
Have you looked at Fortran 95? It may be that the ancient versions of Fortran will eventually go away but it will take more than C to displace Fortran 95. I think some of the things it does would be difficult even in C++.
http://en.wikipedia.org/wiki/Fortran_95_language_features
-Phil
Since starting this thread we’ve been quiet, but using the time to talk with developers, to read this thread and to preliminarily identify the team and management framework. We will be approaching this project with a precise plan and predictable outcome. I’ve summarized how we see the effort shaping up – let me know where I’ve only added confusion and I’ll try to clarify (or ask jazzed for help).
Brief Overview
Our objective is to develop an open-source tool chain with a commercially-acceptable language using existing code bases. It is necessary for code to compile under Windows, Mac and Linux operating systems. Between the Propeller 2 design and tools, commercial product developers would have many reasons to use Propeller 2 in mass since it would have everything they want (more memory to support a LMM kernel for C/C++, I/O flexibility, more RAM, A/D, code protect, etc.).
To meet this goal we are furthering our plans to create a GCC tool-chain that will be generating LMM type executable instructions from C/C++ sources. An IDE such as NetBeans, Eclipse and/or Visual Studio would be used for command-line programming and debugging. We would evaluate and choose the tools for the front end but no decision has been made as of yet. Other tools could be added by the community, too.
The GCC compiler and IDE would be the official tool for C/C++ programming in Propeller 2. Spin/PASM (and other languages you like) could be used with the IDE through command-line interfaces.
The existing Parallax Propeller Tool created in Delphi will also be improved to support Spin/PASM in Propeller 2. The Propeller Tool may also be improved to support the GCC compiled code.
With these two approaches Parallax Semiconductor will continue to foster the Spin/PASM language environment concurrent with the C/C++ GCC effort. You read it right – we’ll have objects in both languages that meet the Gold Standard, relying in part on the community for C/C++ objects. This takes advantage of our current code base and provides an entry point for developers who rely on C/C++.
Spin/PASM Compiler port to C/C++, Parallax Micro C and BST
An open-source C/C++ based Spin/PASM compiler will be provided for both Propeller 1 and 2 chips.
Our Propeller 1 compiler is currently being ported by Roy Eltham to C/C++ so that enhancements could be made by the community who wish to compile on other operating systems or add other features to their code. This work is about 60% finished. Speaking with Chip and Jeff, after we successfully complete the Propeller 1 port we would do a side-by-side comparison with Chip’s Propeller 2 compiler written in ASM and then enhance it to support the Propeller 2 in similar code base. This will be released as a stand-alone command-line compiler and will be used by new releases of the Propeller Tool software.
Our internal software team lead by Jeff continues to develop Parallax Micro C, our translator for the Education program. This effort will be accomplished in parallel with the GCC project. Propeller 2 is not a replacement for Propeller 1 due to a higher cost, and Propeller 1 provides plenty of horsepower for the educational customer projects that will be showcased on the PropBOE. The Parallax Micro C effort will support a Prop Bot (using PropBOE with DC motors/encoders on an improved Boe-Bot chassis) as well as the PropBOE educational program.
In the near future (after the Propeller 1 C/C++ compiler is fully ported) we could ask Brad to incorporate it into BST. A side-by-side comparison of BST and the Propeller Tool from Parallax could be made, and we would discuss any feature additions with Brad. The objective would be to make BST take the place of the Propeller Tool, open-sourcing the code. Discussion still has to happen around this effort, and we owe a huge thanks to Brad for patience towards us.
Team Framework
We quickly recognized that we don’t have the staff resources or expertise to do this in-house. Parallax Semiconductor has formed an agreement with Steve Denson (jazzed) to be our Technical Liaison. His role consists of working on our behalf to assemble the team (both paid and community contributors), to review the scopes of work, to assemble the schedule and to interpret various technical issues to Parallax Semiconductor. Parallax will be the Project Manager (Jeff Martin and I).
The developer team would include an engineer who would design the LMM kernel, a GCC developer, Propeller coders for the libraries and bin utils, and a front-end developer for the IDE. The GCC and LMM kernel developers would both have backup people. I’ll defer to Steve to identify the team members once he has their approval.
Communication
The developers on this forum are critically important to the success of this project. Your projects including BST, PropBASIC, Catalina, Sphinx, and LMM are examples. If you feel that you aren’t being heard or that we haven’t provided the right kind of interface for this project please let me know.
A private forum will be opened for the GCC/IDE developers. Some community members are welcome here, too. Why private? If we make it public, we’ll never get through the minutiae posed by this project. Timelines will get extended because the developers will read and write forum posts instead of following through with our scope of work and schedule. The cost to Parallax Semiconductor would also increase as the details are debated instead of being coded. Further, some of the contract details are best kept between the developers and Parallax Semiconductor.
A public forum thread on Parallax Semiconductor will be managed by Steve Denson. Each week Steve will make an updated post on this thread, summarizing the activity going on around the project.
Steve will be the primary point of contact on behalf of Parallax Semiconductor.
Process
The basic process at this point is the following:
1. Parallax Semiconductor will provide an updated Propeller 2 Features and Specifications document to the developers and forum members. Our FAEs met with Chip last week for this purpose. An instruction set should follow soon and will be posted here http://www.parallaxsemiconductor.com/Products/propeller2specs. Provided the improved specifications are sufficient to give developers the background they need, we would move to the next step.
2. Technical Liaison Steve Denson will contact the developers and request that they develop a scope of work and schedule. Parallax Semiconductor will pay for their effort, providing us the ability to back out if we learn the costs and/or development timeline are not in our interests. This is an important point since we need to reconcile the whole investment with a timeline and likely return.
3. A schedule would be produced and team members commence work with a completion date timed to match Propeller 2. Parallax Semiconductor would provide working FPGA platforms to the key developers.
4. Project commences.
Please feel free to comment on what you’ve read. We hope to meet most everybody’s goals with these plans. And thank you to Chip for developing an interesting multi-core chip that enables these possibilities.
Ken Gracey