A Parallax-C Proposal
jazzed
Posts: 11,803
RossH, Ken Gracey, Chip Gracey, and other interested parties to whom it may concern:
Since this is not going at all well for various reasons (not any fault of the current propgcc contributors except me and possibly some responsibility of Parallax), I believe the best possible compromise for many things right now is this Parallax-C solution:
Let me explain my thinking on each of the points listed above. Most things which I know will cause innumerable repetition of previous caustic arguments will be omitted such as GCC/LCC fitness to the task or why Parallax thinks they need one thing or another.
This is an opportunity to find reasonable common ground for the benefit of Parallax and it's target markets. Do not let the opportunity to do the right thing whatever that may be escape you.
1. Parallax creates a GCC port that can run in a modified Catalina infrastructure.
This means that advantages of GCC and Catalina can be brought to bear for Parallax' benefit. A modified infrastructure is one that meets various Parallax customer needs including: using an industry standard tool chain for large customers who expect it and/or an optional Catalina LCC tool chain for smaller professional and hobby users. How this is done exactly is TBD. The current propgcc tool-chain effort will not change, but will be molded at the right point for interaction with the Catalina infrastructure.
2. Catalina is renamed to Parallax-C or some other "marketing" name.
Parallax-C would be different enough from the current Catalina definition to warrant a new moniker. Some of the differences (improvements for some, funny business for others) are listed below.
3. Parallax-C allows more flexible choice of device drivers for SD Card, etc....
Any updates from existing device drivers for "key" infrastructure devices like SD Card or serial devices should be flexible and not "tied at the hip" to certain aspects of Catalina/Catalyst. A configuration file should be used to specify components for the user that can be modified by a GUI (allows helping the user avoid mistakes). Catalina HMI components can be included, but are not the only way to specify device drivers.
4. Parallax-C allows more flexible device drivers for external memory.
External memory schemes will be defined in a ways that only requires additions of files and changes to a configuration file to allow including new hardware.
5. Parallax-C allows a flexible solution for specifying the LMM VM kernel.
The LMM VM kernel will be selected based on the tool-chain in use with a configuration file.
6. Parallax-C allows a better solution for specifying the target hardware.
The user's target hardware selection will be managed with a configuration file. There are many attributes that need to be "encapsulated" for a target platform. These include but are not limited to: 1) clock mode/frequency, 2) secondary serial-ports for multiple Propeller configurations, 3) SD Card pins and device driver file name, 4) TV/VGA pins and device driver file-name, 5) external memory type and device driver file name (or specialized external LMM VM kernel), 6) optional device pin and device drivers for chips such as ADC, Accelerometer, Keyboard/Mouse, etc....
7. Parallax-C provides easier ways to specify memory models.
Memory models can include HUB only, External RAM (optional HUB stack), External Flash and HUB data/stack, specialized EEPROM models, or memory code, data, bss, stack of the user's choice.
8. Parallax-C uses a different loader than Catalina currently employs.
Performance of the Catalina loader is horrible. It has to be fixed.
9. Parallax-C eventually uses an open source SPIN/PASM compiler.
Currently Catalina uses Homespun which is not open source. If mpark chooses to open-source the compiler, we can use it long term. Parallax-C is required to be open source, and we will use the tools that fit that requirement.
10. The "public" should contribute only in areas where they are proficient.
This means if you don't know anything about the GCC back-end, you can ask questions to learn about it if you like (and some expert may exercise their right to answer), but until you have demonstrated an expertise in that area, any criticisms you have should be kept to yourself. This goes for any area where you do not have demonstrated ability.
11. Everything goes public except for the supervision and rights of contractors.
Everything including P2 details that have not been shared with the public at large will be open. The rights of contractors will not be violated in any way, and especially with regard to private matters including compensation. Contractors rights to have one single point of contact (Parallax or the designated liason) for decisions that need to made will not be violated. Anyone's insistence that a contractor must do something that is not aligned with the rights policy will be ignored unless the contractor voluntarily gives up that right. By no means will a contractors agreement be broken.
12. Everything is developed in a public way except when it may violate a contractors rights.
GCC contractors have been assured that they will have a forum for team questions and answers that will be conducted without unnecessary interference; this policy will continue - no ifs, ands, or buts. The propgcc project code repository is publicly available right now. Only certain people will have the right to commit to the repository. People are welcome to ask questions on things that may not be clear in the repository. Everyone will be able to clone a copy of the repository and do experimental work. Some material will be publicly posted to allow people to work with propgcc. Additional repositories will be created so that contributors who are "qualified" in their areas will be allowed to contribute - qualification will be decided by Parallax and the "owner" of the repository regardless of breadth of experience or education. That is, all you have to do is demonstrate competency.
--
Any comments for additions, deletions, amplifications, modifications are acceptable and will be treated respectfully. However, please understand I reserve the right to respond (or not) to any posts whether I agree (or not) with the post content. I will not respond to posts that I think are out of line.
Cheers.
--Steve
Since this is not going at all well for various reasons (not any fault of the current propgcc contributors except me and possibly some responsibility of Parallax), I believe the best possible compromise for many things right now is this Parallax-C solution:
- Parallax creates a GCC port that can run in a modified Catalina infrastructure.
- Catalina is renamed to Parallax-C or some other "marketing" name.
- Parallax-C allows more flexible choice of device drivers for SD Card, etc....
- Parallax-C allows more flexible device drivers for external memory.
- Parallax-C allows a better solution for specifying the LMM VM kernel.
- Parallax-C allows a better solution for specifying the target hardware.
- Parallax-C provides easier ways to specify memory models.
- Parallax-C uses a loader that has a better scheme than Catalina currently employs.
- Parallax-C eventually uses an open source SPIN/PASM compiler.
- The "public" should contribute only in areas where they are proficient.
- Everything goes public except for the supervision of contractors.
- Everything is developed in a public way except when it may violate a contractors rights.
Let me explain my thinking on each of the points listed above. Most things which I know will cause innumerable repetition of previous caustic arguments will be omitted such as GCC/LCC fitness to the task or why Parallax thinks they need one thing or another.
This is an opportunity to find reasonable common ground for the benefit of Parallax and it's target markets. Do not let the opportunity to do the right thing whatever that may be escape you.
1. Parallax creates a GCC port that can run in a modified Catalina infrastructure.
This means that advantages of GCC and Catalina can be brought to bear for Parallax' benefit. A modified infrastructure is one that meets various Parallax customer needs including: using an industry standard tool chain for large customers who expect it and/or an optional Catalina LCC tool chain for smaller professional and hobby users. How this is done exactly is TBD. The current propgcc tool-chain effort will not change, but will be molded at the right point for interaction with the Catalina infrastructure.
2. Catalina is renamed to Parallax-C or some other "marketing" name.
Parallax-C would be different enough from the current Catalina definition to warrant a new moniker. Some of the differences (improvements for some, funny business for others) are listed below.
3. Parallax-C allows more flexible choice of device drivers for SD Card, etc....
Any updates from existing device drivers for "key" infrastructure devices like SD Card or serial devices should be flexible and not "tied at the hip" to certain aspects of Catalina/Catalyst. A configuration file should be used to specify components for the user that can be modified by a GUI (allows helping the user avoid mistakes). Catalina HMI components can be included, but are not the only way to specify device drivers.
4. Parallax-C allows more flexible device drivers for external memory.
External memory schemes will be defined in a ways that only requires additions of files and changes to a configuration file to allow including new hardware.
5. Parallax-C allows a flexible solution for specifying the LMM VM kernel.
The LMM VM kernel will be selected based on the tool-chain in use with a configuration file.
6. Parallax-C allows a better solution for specifying the target hardware.
The user's target hardware selection will be managed with a configuration file. There are many attributes that need to be "encapsulated" for a target platform. These include but are not limited to: 1) clock mode/frequency, 2) secondary serial-ports for multiple Propeller configurations, 3) SD Card pins and device driver file name, 4) TV/VGA pins and device driver file-name, 5) external memory type and device driver file name (or specialized external LMM VM kernel), 6) optional device pin and device drivers for chips such as ADC, Accelerometer, Keyboard/Mouse, etc....
7. Parallax-C provides easier ways to specify memory models.
Memory models can include HUB only, External RAM (optional HUB stack), External Flash and HUB data/stack, specialized EEPROM models, or memory code, data, bss, stack of the user's choice.
8. Parallax-C uses a different loader than Catalina currently employs.
Performance of the Catalina loader is horrible. It has to be fixed.
9. Parallax-C eventually uses an open source SPIN/PASM compiler.
Currently Catalina uses Homespun which is not open source. If mpark chooses to open-source the compiler, we can use it long term. Parallax-C is required to be open source, and we will use the tools that fit that requirement.
10. The "public" should contribute only in areas where they are proficient.
This means if you don't know anything about the GCC back-end, you can ask questions to learn about it if you like (and some expert may exercise their right to answer), but until you have demonstrated an expertise in that area, any criticisms you have should be kept to yourself. This goes for any area where you do not have demonstrated ability.
11. Everything goes public except for the supervision and rights of contractors.
Everything including P2 details that have not been shared with the public at large will be open. The rights of contractors will not be violated in any way, and especially with regard to private matters including compensation. Contractors rights to have one single point of contact (Parallax or the designated liason) for decisions that need to made will not be violated. Anyone's insistence that a contractor must do something that is not aligned with the rights policy will be ignored unless the contractor voluntarily gives up that right. By no means will a contractors agreement be broken.
12. Everything is developed in a public way except when it may violate a contractors rights.
GCC contractors have been assured that they will have a forum for team questions and answers that will be conducted without unnecessary interference; this policy will continue - no ifs, ands, or buts. The propgcc project code repository is publicly available right now. Only certain people will have the right to commit to the repository. People are welcome to ask questions on things that may not be clear in the repository. Everyone will be able to clone a copy of the repository and do experimental work. Some material will be publicly posted to allow people to work with propgcc. Additional repositories will be created so that contributors who are "qualified" in their areas will be allowed to contribute - qualification will be decided by Parallax and the "owner" of the repository regardless of breadth of experience or education. That is, all you have to do is demonstrate competency.
--
Any comments for additions, deletions, amplifications, modifications are acceptable and will be treated respectfully. However, please understand I reserve the right to respond (or not) to any posts whether I agree (or not) with the post content. I will not respond to posts that I think are out of line.
Cheers.
--Steve
This discussion has been closed.
Comments
'Some really good points and interesting ideas!
I might ease up a bit on #10, even though I completely understand where you're coming from. Someone could legitimately question the "why" of something, even if they don't understand the "how." For example, one could ask, "Why do we need a dev system that requires hundreds of megabytes of disk space?" Despite the underlying critical tone, it's a reasonable thing for a non-GCC-literate person to bring up. It works the same in any democratic process. I can legitimately criticize my elected representatives if their economic decisions affect me negatively, even though I'm clueless about Keynesian Economics. Like it or not, the GCC committee may be called to task by the uninformed, and it would help their public perception if they deign to respond generously.
-Phil
For first time I need say to You.
My hands up to that.
And the hobbyist side is not forced to use GCC/Eclipse as Parallax has repeatedly stated they'll have their own lightweight IDE system for them. And no doubt there will be P2 versions of CodeBlocks and other programs.
@rod1963, Thank you. I understand your point, and I would be happy with that too. I'm trying to build some consensus, and if that position is the most popular, then that's the consensus.
People can ask why or exercise critical thinking if they like.... A forum allows freedom of speech to a point, but persuasion comes in all forms, informed or not, and is often successful many ways right or wrong. I'll avoid discussing religion, politics, and how to keep people from losing their shirts in the financial markets
What I suggest instead is that the repos are made publicly available, with instructions on how to clone, get set up for development, etc. Nothing fancy, 1 page or so. Everybody is free to do their own thing on a local copy, and if they desire, they submit their changes to the project for review. The project team can accept or reject the changes as appropriate. If something is rejected, the submitting developer always has the option to fork the project if so desired, so no effort is wasted.
There can also be a process in place to accept commit-level developers to the project, ie, if they submit accepted patches, modules, etc. But mostly, I'm saying to avoid the perception that people aren't welcome to be a part of the development effort.
I'm suggesting that anybody should be allowed to submit a patch or code to the project for review, whether or not they've been deemed "qualified". Then let the project committee decide whether the submission should be included or not.
And by submit, I mean "Hey guys, look at this...", not automatically have commit access to a repo.
I just thought I'd drop in a quick response so you knew I had seen your post. Thanks for the frank assesment of the current state, and also for your willingness to consider alternatives.
There's a lot to digest here, but I'm basically amenable to whatever is in the best interests of Parallax.
I need to read your post a couple more times to get my head around your suggestions before responding to the detail. Also, I guess I would be interested in hearing Parallax's reaction before we spend too much time identifying any specific courses of action.
Ross.
Ok. I see, you mean peer review. Yes, that's a bit different.
If the stake-holders in a given repository decides that a change is necessary and sufficient, there would be nothing wrong with giving access to the area for a time for the commit. Eventually however the only "commiters" will be Parallax staff or their selected contributor in maintenance mode.
Yes, the idea is to benefit Parallax and their customers old and new.
Parallax is and will be the owner. They will need to maintain the end product.
It would be valuable if you could spend some time reviewing the ideas. If you can,
please respond before Monday morning US time so that we can review your feedback.
Thanks for your consideration,
--Steve
I don't like anything less than a proper GCC targeting Propeller solution. Sorry. Especially for the Prop 2. I don't think Parallax should settle for anything less.
1. Parallax creates a GCC port that can run in a modified Catalina infrastructure.
We finish a proper GCC tool-chain as planned, but the end result will be packaged so that either Catalina's LCC or the GCC compiler can be used in the official end product.
Some preliminary thoughts (the numbers below refer to the numbers in Jazzed's original post) ...
1. Yes. The kernel architecture is one obvious point of potentially shared infrastructure - I always wondered why the GCC effort did not simply start with a working LMM kernel (Catalina's would have been an easy choice, but there are others). Developing a GCC code generator for the Catalina LMM kernel could be done very quickly (it only took two weeks to develop the first LCC one, although to be fair LCC is a lot simpler than GCC). Beyond the kernel itself, the other shared infrastructure/points of interaction could include XMM APIs, Plugins (drivers), the Registry, the final loadable binary formats, the loaders themselves, possibly even the debuggers.
2. Yes. I'm quite fond of the name Catalina, but I'm happy to keep it for the "bleeding edge" compiler and for Parallax to use another name. But surely they could come up with something a bit more evocative than Parallax C ? For those with an astronomical bent, how about Parallax ParseC ?
3. Yes, it would be nice to provide an easier way for people to include new and improved drivers on their own (I agree it is still a little clunky), but maintenance-wise I think the reality is that the key supported drivers should be released only by the ParseC team - however, users are free to use their own "non-certified" drivers if they realize they will only get ad-hoc support (i.e. not "official" support) from the ParseC team.
4. Catalina was originally going to support more memory schemes - after all, there is only a limited way of arranging the four standard segment types supported by nearly all compilers. But it turns out that only a few of the possible arrangements make any practical sense. I guess this one is likely to remain controversial, but (in my view) supporting some of the complex memory arrangements that might make sense in a virtual or managed memory environment are just unnecessary complications on a teeny-weeny embedded microcontroller that has neither an operating system nor a memory management unit. However, if the ParseC team determine additional memory modes are required, they can be added in ParseC quite independenly of Catalina.
5. Yes. Although Catalina already supports multiple LMM kernels. Each one is in a separate file included during the compilation, so I'm not sure what else would be needed. Happy to discuss further - but remember that the code generator, selected memory layout, loader and kernel pretty much always have to align - you can't really configure them independently.
6. Yes. The most recent changes incorporated in Catalina 3.1 would appear to achieve most of this. Some more minor tweaks could achieve the rest.
7. In my view, some of these options don't make sense, and would probably never get used. So why knock yourself out supporting them? There's a huge amount of additional work involved in each additional memory model. However, basically this is the same as point 4 - i.e. if the ParseC team wants them, they can be added quite independently of Catalina.
8. If you say so, then Yes. I think I probably load more programs onto more propellers (I have over a dozen sitting on the desk in front of me) more often than perhaps anyone outside Parallax, and I don't find it "horrible". However, I accept it could be improved. Since this is a completely independent piece of work that could be done by anyone (it is primarily about the serial port handling on various Linux and Windows platforms, and not about the propeller at all) I'd be happy for the ParseC team to take it on entirely.
9. Yes. But which one? The Parallax one is (unfortunately) the least suitable candidate. Both Homespun and BST surpassed it in capability years ago. My own preference is for Catalina to continue to use Homespun, but if Parallax can't get the thumscrews tight enough on Michael Park for him to release the source, then ParseC is free to use another Spin/PASM compiler altogether if it wants. The requirements that any such compiler has to meet to support either Catalina or ParseC are fairly simple (I think both BST and Homespun qualify - I just got tired of maintaining support for both of them).
10, 11, 12. Not sure exactly how to respond to these points - but while reading them I began to get some inkling of the problems with the propgcc project. The vibe in these paragraphs is all wrong for a cooperative development (and I'm kind of surprised that Parallax has got itself tied up in such a gordian knot - it doesn't sound like the Parallax I thought I knew): "public" (in quotes!), "expert", "exercise their right", "demonstrated an expertise", "criticisms ... kept to yourself", "rights of contractors", "ownership", "violate a contractors rights", "qualifications", "private matters", "compensation", "allowed to contribute" etc etc. If this is the way the ParseC project is likely to end up, then Parallax is welcome to take the Catalina source and run with it (it is open source after all!) - but I'd rather just keep pottering about with Catalina on my own.
Ross.
One of the most active development projects I know of, with a huge number of contributors, is the Git project itself. And there is only one person who actually commits to the repository which the rest of us are cloning. Works fabulously.
-Tor
I am confused about your proposal. As the coordinator of the the GCC effort, you probably should have discussed this with the group first before posting something like this. Or at the very least, do this as a PM amoung you, Ken, Chip and Ross. I realize you posted this as an individual, and not as the GCC coordinator, but it may appear to others that the GCC group agrees wtih your proposal.
Personally, I disagree with most of your proposal. I think it would be much better to just open up the GCC effort so that everyone can contribute. Someone would have to control checkins into the respository to maintain the integritry of the codebase. Everything that you're suggesting can be done with the GCC tools over time. Perhaps you are seeking a quick solution? Can you describe in a few words why you made this proposal?
Dave
To heal wounds.
There are no problems with the propgcc project. We cooperate fine as a group. Perceptions of problems exist only because it has to be a side-show. I am required to update status. Starting this week, status will be provided in a forum blog.
I don't see that. Nearly all CPUs have multiple C compilers available. First there are usually one or more "professional" compilers, intended for professional users - these tend to cost substantial amounts of money, and are almost always tightly closed source. Then GCC is usually available as a "free" open source option (sometimes with the option of paid support, sometimes not). Finally there are often one or more additional options (either "free" or very inexpensive) generated by various others (LCC, Clang, PCC etc) - these may be either open or closed source, and some may even have "semi official" status (in that the CPU vendor may direct customers to them if they seem to suit the customer's particular needs).
However, the Propeller is a bit unique - the architecture does not easily lend itself to high-level languages, so I doubt that we are going to see any more "professional" or "other" options arising. This means that from Parallax's perspective it is either the GCC "one size fits all" option, or else they consider supporting multiple different offerings, perhaps to suit different markets.
Personally (and naturally!) I favor the latter - after all, GCC/Eclipse (especially Eclipse) is not really a suitable option for hobbyists, enthusiasts or novices. Catalina is a better fit for such users. At the moment, Catalina exists because I am content to persevere in spite of a lot of negativity (not directing this comment at anyone specifically, it is just a general observation - a lot of it comes from those who won't even admit that C is even a desirable option on the Propeller!).
So I think Jazzed's idea of identifying potential points of interaction and/or shared infrastructure is worth at least considering. However, before we go any further it would be good to hear any comments from Parallax themselves, since (being at least slightly removed from both GCC and Catalina) they can offer a disinterested perspective.
Ken? Chip? Anyone?
Ross.
That point of view have already stopped only ONE Propeller Tool we had that can be RUN on multiple platforms.
So guys START thinking NOT hacking --- We need all type of tools and as many variations as possible.
And as I saw already ---- If Parallax not officially say them SPONSOR any of them --- It will be always someone that hack on it in same way them HACKED ---- BradC to stop working on BST !
I think enough time has passed on this thread to demonstrate that there is zero interest in Jazzed's proposal from Parallax ... in which case I'd like to reclaim the name ParseC - I kind of like it, and it would suit one of my planned future Catalina "add-on" components.
Ross.
Being some distance from this, I can say 'the bigger the beast, the harder it is to control'.
It may be smarter to divide and conquer, as there are many productive things that can be done with much lower cross-dependencies, so it woudl be better to separate them out, into clearly different forks.
The Props very small COG memory means Assembler will always be important, and so work on a 'better assembler' can be done, without worrying about whose back-end is doing what... (if you get my drift.. ?)
There is a lot of room to take an assembler and move it towards a C-- level of operation.
This should cover both P1 and P2, with P2 in skeleton mode.
Then, there is a Simulator, and again this is agnostic of 'whose back-end is doing what'., and can focus on P1, and have P2 in skeleton mode.
I am locking and moving this thread. This particular thread does not belong in the Parallax Semiconductor forum which is primarily meant for customer <-> FAE interactions. There are also undertones of negativity here. Parallax would like these forums to remain professional and positive for everybody.
Thank you,
Daniel
I appreciate all your efforts with Catalina!
I think it's just great.
C is an absolute must if the Prop2 is to be a serious commercial uC.
The more flavors of C available the better IMO.
GCC for the Prop2 and a few really good books showing beginners how to
set up and use Eclipse and program the Prop2 in C will be desperately needed.
If it takes as long to have these books as it is taking to have really good PASM
books then it will be a crying shame.
Catalina and GCC and a commercial C compiler for the Prop2 will be pretty sweet.