My favourite IDE is Rowley Associates CrossStudio, They wrote it themselves using QT and it runs on Windows, MAC OS and Linux. It's used with all their compilers.
As a fan of KDE (vs. Gnome) I've always -- by extension -- liked Qt. Unfortunately, there now seems to be concern, with Nokia's turn to Win7 for their cell platforms, that they will not continue to support it:
*Not professional, but I have been involved in professional development at a higher level than embedded, so those are my answers based on what I think I would need
4/7 - C++ language support (depends on project scale)
10/10 - C language support (baseline HLL requirement)
10/3 - Spin language support (project scale may warrant quick and dirty approach possible)
3/1 - PBASIC language support
10/10 - PASM language support
10/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
10/10 - C compiler generates XMM PASM (executes from external memory)
2/3 - C compiler generates spin bytecodes
3/1 - Spin code can execute from external memory
1/5 - Compiler and tools must be based on GCC
5/8 - Simulator
5/10 - Debugger
8/8 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/8 - Runs on a Mac (might as well)
5/5 - Text editor must have lots of features, such as auto-completion and syntax support (might use my own editor)
2/5 - Compiler tool-chain, and make process must be similar to GCC (understandable, not limiting)
If I understand correctly, you would assign a 10 for each of the items you listed. Does the following match what you said? What would you assign to the items with a question mark? Are your scores as a hobbyist or a professional developer, or both? Do the "LMM PASM" and "XMM PASM" items mean that there should be a separate assembler that understands LMM and XMM, or are you just saying that C should support those memory modes?
Dave
? - C++ language support
10 - C language support
10 - Spin language support
? - PBASIC language support
10 - PASM language support
10 - C compiler generates PASM
10 - C compiler generates LMM PASM
10 - C compiler generates XMM PASM (executes from external memory)
10 - C compiler generates spin bytecodes
? - Spin code can execute from external memory
? - Compiler and tools must be based on GCC
? - Simulator
? - Debugger
10 - Graphical interface to all features
10 - Command line interface to all features
10 - Runs under Windows
10 - Runs under Linux
10 - Runs on a Mac
10 - Text editor must have lots of features, such as auto-completion and syntax support
? - Compiler tool-chain, and make process must be similar to GCC
10 - LMM PASM language support
10 - XMM PASM language support
10 - Compilation to multiple targets from one opened IDE
If I understand correctly, you would assign a 10 for each of the items you listed. Does the following match what you said? What would you assign to the items with a question mark? Are your scores as a hobbyist or a professional developer, or both? Do the "LMM PASM" and "XMM PASM" items mean that there should be a separate assembler that understands LMM and XMM, or are you just saying that C should support those memory modes?
Dave
? - C++ language support
10 - C language support
10 - Spin language support
? - PBASIC language support
10 - PASM language support
10 - C compiler generates PASM
10 - C compiler generates LMM PASM
10 - C compiler generates XMM PASM (executes from external memory)
10 - C compiler generates spin bytecodes
? - Spin code can execute from external memory
? - Compiler and tools must be based on GCC
? - Simulator
? - Debugger
10 - Graphical interface to all features
10 - Command line interface to all features
10 - Runs under Windows
10 - Runs under Linux
10 - Runs on a Mac
10 - Text editor must have lots of features, such as auto-completion and syntax support
? - Compiler tool-chain, and make process must be similar to GCC
10 - LMM PASM language support
10 - XMM PASM language support
10 - Compilation to multiple targets from one opened IDE
Ps. NOT all that languages need be in same time as Propeller II arrive.
BUT --> PASM's need be done to time e have Propeller II.
1/1 - C++ language support
1/1 - C language support
10/10 - Spin language support Enhanced Spin -- not what we have now
1/1 - PBASIC language support
10/10 - PASM language support Enhanced w/ macros, etc.
1/1 - C compiler generates PASM
1/1 - C compiler generates LMM PASM
1/1 - C compiler generates XMM PASM (executes from external memory)
1/1 - C compiler generates spin bytecodes
5/5 - Spin code can execute from external memory Meh. More interested in uC than uP.
5/5 - Compiler and tools must be based on GCC Any FOSS tool chain is acceptable.
1/1 - Simulator
1/1 - Debugger
10/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor must have lots of features... Would be satisfied w/current IDE editing features, if they all worked
10/10 - C++ language support (Might as well it comes for free with GCC and Clang/LLVM
10/10 - C language support
1/1 - Spin language support (Not required now that I have C and the memory space to put it)
1/1 - PBASIC language support (No idea what that is, never use BASIC)
10/10 - PASM language support
1/1 - C compiler generates PASM (Makes no sense to me. Not enough room in GOG)
10/10 - C compiler generates LMM PASM (Yes for speed)
10/10 - C compiler generates XMM PASM (Yes now we have more pins for XMM solutions)
1/1 - C compiler generates spin bytecodes (Not required, I have Zog for bytecode solutions)
1/1 - Spin code can execute from external memory (See above)
1/1 - Compiler and tools must be based on GCC (GCC, Clang/LLVM, whatever works)
4/4 - Simulator (Nice to have)
4/4 - Debugger (Nice to have)
5/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows (No excuse not to)
10/10 - Runs under Linux (Essential)
10/10 - Runs on a Mac (No excuse not to)
1/1 - Text editor must have lots of features, such as auto-completion and syntax support
--------
1/1 - Compiler tool-chain, and make process must be similar to GCC (See below)
What does that mean? If I have a command line compiler I can always use make if I want to.
My hobby and work choices are the same. Generally I want what is easiest for me no matter where.
I put Spin out of this picture. I assume that a supper easy Prop Tool like tool will exist for those that want Spin. Must be so to support all the code we have in Spin, as an easy start for beginners
and so on.
I hope there is a PASM assembler to go with all this.
Here are the results of the survey with 6 people responding. I'll update it again after more surveys are posted.
Hobby Prof. Both Feature
5.2 7.2 6.2 C++ language support
8.5 8.5 8.5 C language support
8.5 4.3 6.4 Spin language support
3.5 2.5 3.0 PBASIC language support
10.0 10.0 10.0 PASM language support
5.8 7.0 6.4 C compiler generates PASM
8.5 8.5 8.5 C compiler generates LMM PASM
8.2 7.8 8.0 C compiler generates XMM PASM (executes from external memory)
4.5 3.5 4.0 C compiler generates spin bytecodes
5.5 3.2 4.3 Spin code can execute from external memory
5.0 6.5 5.8 Compiler and tools must be based on GCC
6.0 7.2 6.6 Simulator
5.2 7.5 6.3 Debugger
7.2 8.8 8.0 Graphical interface to all features
10.0 10.0 10.0 Command line interface to all features
10.0 10.0 10.0 Runs under Windows
10.0 10.0 10.0 Runs under Linux
7.0 7.0 7.0 Runs on a Mac
5.3 6.5 5.9 Text editor must have lots of features, such as auto-completion and syntax support
6.3 7.7 7.0 Compiler tool-chain, and make process must be similar to GCC
I'm not sure what those results mean. The respondents within this thread comprise a very biased sample that probably does not represent Parallax's broader customer base (many of whom would not even understand some of the questions). Moreover, averaging individual scores, as if they were linearly independent can be misleading. IOW, it's important to track how an answer to one question correlates with answers to others. For example, a strong preference for Spin may coincide with a strong preference for Mac-compatible tools and a disdain for a command-line interface. By doing the correlations, you may discover that respondents fall into two or more disjoint sets of preferences, which might suggest that more than one tool chain is appropriate.
But, still, it's a good start. Thanks for the effort.
Hobby Prof. Feature
5 10 C++ language support
10 10 C language support
1 1 Spin language support
1 1 PBASIC language support
10 10 PASM language support
10 10 C compiler generates PASM
10 10 C compiler generates LMM PASM
10 10 C compiler generates XMM PASM (executes from external memory)
1 1 C compiler generates spin bytecodes
1 1 Spin code can execute from external memory
1 1 Compiler and tools must be based on GCC
5 10 Simulator
5 10 Debugger
8 8 Graphical interface to all features
8 8 Command line interface to all features
10 10 Runs under Windows
8 8 Runs under Linux
5 5 Runs on a Mac
8 8 Text editor must have lots of features, such as auto-completion and syntax support
8 8 Compiler tool-chain, and make process must be similar to GCC
@Phil, I intend to show the raw data and do some analysis of the data after I receive a few more responses. At this point there are 7 respondents, and it seems that 5 of them are very similar. A few of them show stronger interest in C++. So far, your response is the only one that shows strong interest in Spin, and little interest in C, which is good input. I'm hoping to see a few more Spin-oriented responses, but the title of this thread may be keeping them out. I should probably move the survey to its own thread with a title like "Prop 2 IDE and Tools Survey".
@Sapieha, I decided not to change or add on to the survey questions until I receive a dozen or so responses. It is difficult to compare responses if the later group of people are voting on different questions then the initial group of people. I think you have a very good suggestion about supporting multiple targets in one session. I don't quite understand your other items about "LMM PASM language support" and "XMM PASM language support". Could you elaborate on those two items?
Hobby Prof. Feature
1 8 C++ language support
1 10 C language support
10 9 Spin language support
1 1 PBASIC language support
10 10 PASM language support
1 1 C compiler generates PASM
10 10 C compiler generates LMM PASM
5 1 C compiler generates XMM PASM (executes from external memory)
1 1 C compiler generates spin bytecodes
1 1 Spin code can execute from external memory
1 1 Compiler and tools must be based on GCC
1 2 Simulator
2 10 Debugger
6 8 Graphical interface to all features
8 8 Command line interface to all features
10 10 Runs under Windows
10 6 Runs under Linux
1 1 Runs on a Mac
4 7 Text editor must have lots of features
1 3 Compiler tool-chain, and make process similar to GCC
@Sapieha, I decided not to change or add on to the survey questions until I receive a dozen or so responses. It is difficult to compare responses if the later group of people are voting on different questions then the initial group of people. I think you have a very good suggestion about supporting multiple targets in one session. I don't quite understand your other items about "LMM PASM language support" and "XMM PASM language support". Could you elaborate on those two items?
That have little work with HOW Propeller will start.
If It start ALL as PASM - Then for ASSEMBLY type programing You need Any type of Assembler that can handle programs that will be bigger as only one COG length.
AND as it is announced that Propeller II will only have LOADER on ROM -- That is next sure that that is case!
I'm not sure that binutils exists because of ELF although I may be wrong. I'm pretty sure binutils pre-dates ELF and was also used to work with earlier COFF object files. Also, you keep saying that ELF is designed for Unix systems. Can you give me an example of some feature of ELF that only makes sense on Unix? It seems like a pretty generic format to me.
Hi David,
Yes, probably should have said ELF and COFF - and probably also several other binary formats. First line of the Wikipedia article on binutils:
The GNU Binary Utilities, or binutils, is a collection of programming tools for the manipulation of object code in various object file formats.
See what I mean? Catalina has no special object code or object file formats - and therefore no need for any binutils.
And I didn't mean ELF could only be used on Unix, I said it was not a native format on other platforms. Not that I'm advocating this, but if you are primarily a Windows house, wouldn't it make more sense to use an M$ compatible object format (which I believe these days is a proprietary version of COFF called "PE COFF")?.
What? Since 1998 I have used nothing but Linux to develop embedded code on. That's "a unix" system is it not?. Almost never see anything else around here.
It did happen, then! Was anything resolved, or is that confidential?
I guess it must be confidential, because I was at the webinar, and didn't hear any of this stuff being discussed at all. Maybe jazzed is referring to another meeting?
No. Why would you want your tools for embedded development be different and incompatible with all the other host platforms?
Heater, I know what you mean - but what's the difference between having to use use MinGW on Windows (to allow you to use ELF binaries) and having to use WINE on Linux (to allow you to use PE COFF binaries)!
Is it any other micro that use that BINARIES at all?.
How That BINARIES help Propeller II to be compatible with other Micros?.
In PC world Most BIN Linkers are to link diferent parts of binary files that are compiled --- NOT necessary at same time. Else use DLL's that are build to be possible to distribute separately without delivery of Source code. Mostly to have possibility to build LIBRARY'S that can be sold without need of distribute Source code.
Question:
Will we have that on Propeller II?.
I think Yours method of linking are correct for Propeller.
As that always need Source code to be compiled!.
Heater, I know what you mean - but what's the difference between having to use use MinGW on Windows (to allow you to use ELF binaries) and having to use WINE on Linux (to allow you to use PE COFF binaries)!
In my earlier post, I suggested that the survey should be filled out by the forum membership based on their personal preferences, and it should be filled out based on the practices of the company they work at.
Hi Dave,
I agree with Phil that any numbers we submit are only reflective of the forum members, not the eventual cusotmers of Parallax Semiconductor - but here are my numbers:
1/ 1 - C++ language support
10/10 - C language support
10/ 1 - Spin language support
3/ 1 - PBASIC language support
10/ 1 - PASM language support
1/ 1 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
10/ 1 - C compiler generates XMM PASM (executes from external memory)
1/ 1 - C compiler generates spin bytecodes
1/ 1 - Spin code can execute from external memory
1/ 1 - Compiler and tools must be based on GCC
3/ 3 - Simulator
10/10 - Debugger
5/ 8 - Graphical interface to all features
10/ 3 - Command line interface to all features
10/10 - Runs under Windows
10/ 3 - Runs under Linux
5/ 1 - Runs on a Mac
5/ 5 - Text editor must have lots of features, such as auto-completion and syntax support
--------
1/ 3 - Compiler tool-chain, and make process must be similar to GCC
Is it any other micro that use that BINARIES at all?.
How That BINARIES help Propeller II to be compatible with other Micros?.
Question:
Will we have that on Propeller II?.
Hi Sapieha,
I'm not sure I understand your questions exactly. There are two main purposes of a common object format such as ELF (which I think is what you mean by binaries) - one is as an intermediate library format, and the other is as an executable format (i.e. depending on whether it is used as either the input or the output of the linker).
ELF binaries for the Propeller would certainly not be compatible with any other microcontroller, and I don't think any embedded microcontroller would even use ELF as an executable format (I could be wrong here, but I did a quick google and nothing popped up). So I think we are talking mainly about the advanages of ELF as an intermediate library format.
Is it necessary to have such a format? No (as demonstrated by Catalina). It doesn't stop you having libraries, or distirbuting them in compiled form if you want to.
Is it desirable to have such a format? Maybe - it depends on the size of your projects. I remember the days when compiling a system took a whole day, and you did everything possible to not have to recompile code unless you absolutely had to. Are we likely to fact this prospect on a microcontroller with a few hundred kilobytes of RAM? I really doubt it. I routinely compile programs with Catalina that consist of tens of thousands of lines of code (generating binaries of a couple of megabytes) and the compilation process never takes more than a few seconds.
I'm not sure I understand your questions exactly. There are two main purposes of a common object format such as ELF (which I think is what you mean by binaries) - one is as an intermediate library format, and the other is as an executable format (i.e. depending on whether it is used as either the input or the output of the linker).
It is correct assumption from You side.
Sorry if I not use correct names -- BUT still as I said -- Compilers is not my primary knowledge.
Here are the latest numbers from the 9 people that have responded. I added a "Spin versus C score" which is the sum of the 3 Spin related features minus 3 of the C related features. This gives a measure of the Spin versus C preference. A value of zero would be neutral, a negative value shows a preference toward C, and a positive value shows a preference toward Spin. The attached spreadsheet shows the responses ordered by the Spin versus C scores for both the hobby category and the professional category.
Hobby Prof. Feature
4.2 6.9 C++ language support
8.0 9.0 C language support
8.0 4.1 Spin language support
2.9 2.0 PBASIC language support
10.0 9.0 PASM language support
5.2 6.0 C compiler generates PASM
9.0 9.0 C compiler generates LMM PASM
8.2 6.6 C compiler generates XMM PASM (executes from external memory)
3.3 2.7 C compiler generates spin bytecodes
4.0 2.4 Spin code can execute from external memory
3.7 4.7 Compiler and tools must be based on GCC
5.0 6.4 Simulator
5.3 8.3 Debugger
6.9 8.6 Graphical interface to all features
9.6 8.8 Command line interface to all features
10.0 10.0 Runs under Windows
9.8 8.6 Runs under Linux
5.9 5.4 Runs on a Mac
5.4 6.6 Text editor must have lots of features, such as auto-completion and syntax support
4.8 6.3 Compiler tool-chain, and make process must be similar to GCC
-9.9 -15.3 Spin versus C score
Note: The "Spin versus C score" is computed by adding the 3 items that reference
Spin and subtracting the "C language support", "C compiler generates LMM PASM" and
the "C compiler generates XMM PASM" items.
While I find it okay that C is negative and Spin is positive, the way you calculate the "Spin versus C score" is very odd.
With the 3 Spin related items you mean:
- Spin language support
- C compiler generates spin bytecodes ?
- Spin code can execute from external memory ?
is this correct?
I think only the first item has really to do with Spin.
The last item is just not necessary because Spin is so memory friendly.
(not trust any statistics you did not manipulate yourself)
Since I'm the Propeller programmer at my company, my personal ratings are the same as my employer's.
1/1 - C++ language support
1/1 - C language support
10/10 - Spin language support
1/1 - PBASIC language support
10/10 - PASM language support Enhanced w/ macros, etc.
1/1 - C compiler generates PASM
1/1 - C compiler generates LMM PASM
1/1 - C compiler generates XMM PASM (executes from external memory)
1/1 - C compiler generates spin bytecodes
3/3 - Spin code can execute from external memory
5/5 - Compiler and tools must be based on GCC any FOSS toolchain is fine
3/3 - Simulator
4/4 - Debugger
10/10 - Graphical interface to all features
10/10 - Command line interface to all features
3/3 - Runs under Windows
3/3 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor must have lots of features modern features like code completion
@Ariba, the Spin versus C score is arbitrary, but it does seem to correctly order the responses that prefer C versus the ones that prefer Spin. I tried using the difference between the "Spin language support" and the "C language support", but I just get values of -9, 0 and 9. The score computed from the 6 values provides more levels of discrimination. I am only using the Spin versus C score to group similar responses together, and it seems to do that fairly well.
@SSteve, thanks for your input. I've added it to the spreadsheet. It's good to have another response with a preference for Spin. I also see that you prefer the Mac. The tools should be supported on all three platforms.
If we draw some early conclusions from the data, it seems that there's not much interest in the C compiler generating Spin bytecodes or executing Spin code from external memory. There is also not much interest in supporting PBASIC. I actually meant PropBASIC in that item, so I hope everyone understood that.
The score for Spin language support is quite low in the professional column, but it is fairly high in the hobby column, which makes sense to me. Everything else in the professional column is above a 6 except for the GCC and Mac items. SSteve's input should push the Mac item close to 6.
Well, PropBASIC really isn't on the table for Parallax since it's not their product. I'm sure Bean has his own plans for it wrt future versions of the Propeller.
As for Spin, there will be a certain % of commercial developers that will use it, and there is no reason that GCC/etc. needs to try to compile it. Parallx already has a Spin compiler that may need to be ported out of Delphi to something more cross-platform, but as long as it can be integrated with Eclipse/etc., all should be well. I hope Parallax starts another 2 threads, one each for Spin & PASM.
I think you can take my poll responses an those of SSteve as good examples of the polarization between the, shall we say, "hobbyist" and "professional" camps.
My results put everything to do with C, command lines and cross platform support up to max. I even go so far as to deprecate Spin by putting it down to minimum.
SSteve on the other hand does almost the opposite, Spin and graphical tools is on the top, C is down at the bottom.
If there is a lot of such polarization in the user base and we then take a simple average of poll results to figure out what to prioritize in the tool chain we will end up with a ghastly mess of a tool that does nothing very well.
Hence my view is that there should be two tool chains here with barley any overlap. A new improved, ultra-simple, cross platform Propeller Tool for the "hobbyist" camp and the full up GCC (or Clang/LLVM) tool chain for the "professionals".
Here's the results from the 10 respondents. I computed an overall average for the whole group of 10, and also averages for the 7 that prefer C and the 2 respondents that prefer Spin. I sorted the rows from highest to lowest based on the "C" professional column. I believe that is the target audience for this effort. I list the Windows/Linux/Mac items as separate items.
I totally understand that this is a very unscientific survey, but I hope that it can provide some guidance in how we should prioritize things.
Average C Group Spin Group
Hobby Prof. Hobby1 Prof1 Hobby2 Prof2 Feature
------------- ------------- ------------- -------
7.3 8.2 8.7 10.0 1.0 1.0 C language support
8.2 8.2 10.0 10.0 1.0 1.0 C compiler generates LMM PASM
5.2 7.9 5.3 9.1 2.5 2.5 Debugger
10.0 9.1 10.0 8.7 10.0 10.0 PASM language support
9.6 8.9 9.4 8.4 10.0 10.0 Command line interface to all features
7.2 8.7 6.0 8.1 10.0 10.0 Graphical interface to all features
3.9 6.3 3.9 7.3 1.0 1.0 C++ language support
7.5 6.0 9.0 6.9 1.0 1.0 C compiler generates XMM PASM (executes from external memory)
4.8 6.1 4.9 6.7 2.0 2.0 Simulator
4.8 5.5 5.1 6.1 1.0 1.0 C compiler generates PASM
2.1 6.3 4.0 5.7 Compiler tool-chain, and make process must be similar to GCC
5.9 6.9 4.1 5.6 10.0 10.0 Text editor must have lots of features
3.8 4.7 2.6 3.9 5.0 5.0 Compiler and tools must be based on GCC
8.2 4.7 7.4 2.4 10.0 10.0 Spin language support
3.1 2.5 2.7 1.9 1.0 1.0 C compiler generates spin bytecodes
3.9 2.5 3.0 1.0 4.0 4.0 Spin code can execute from external memory
2.7 1.9 2.1 1.0 1.0 1.0 PBASIC language support
------------- ------------- ------------- -------
9.3 9.3 10.0 10.0 6.5 6.5 Runs under Windows
9.1 8.0 9.7 8.1 6.5 6.5 Runs under Linux
6.3 5.9 4.7 4.1 10.0 10.0 Runs on a Mac
Comments
-Phil
*Not professional, but I have been involved in professional development at a higher level than embedded, so those are my answers based on what I think I would need
4/7 - C++ language support (depends on project scale)
10/10 - C language support (baseline HLL requirement)
10/3 - Spin language support (project scale may warrant quick and dirty approach possible)
3/1 - PBASIC language support
10/10 - PASM language support
10/10 - C compiler generates PASM
10/10 - C compiler generates LMM PASM
10/10 - C compiler generates XMM PASM (executes from external memory)
2/3 - C compiler generates spin bytecodes
3/1 - Spin code can execute from external memory
1/5 - Compiler and tools must be based on GCC
5/8 - Simulator
5/10 - Debugger
8/8 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/8 - Runs on a Mac (might as well)
5/5 - Text editor must have lots of features, such as auto-completion and syntax support (might use my own editor)
2/5 - Compiler tool-chain, and make process must be similar to GCC (understandable, not limiting)
If I understand correctly, you would assign a 10 for each of the items you listed. Does the following match what you said? What would you assign to the items with a question mark? Are your scores as a hobbyist or a professional developer, or both? Do the "LMM PASM" and "XMM PASM" items mean that there should be a separate assembler that understands LMM and XMM, or are you just saying that C should support those memory modes?
Dave
? - C++ language support
10 - C language support
10 - Spin language support
? - PBASIC language support
10 - PASM language support
10 - C compiler generates PASM
10 - C compiler generates LMM PASM
10 - C compiler generates XMM PASM (executes from external memory)
10 - C compiler generates spin bytecodes
? - Spin code can execute from external memory
? - Compiler and tools must be based on GCC
? - Simulator
? - Debugger
10 - Graphical interface to all features
10 - Command line interface to all features
10 - Runs under Windows
10 - Runs under Linux
10 - Runs on a Mac
10 - Text editor must have lots of features, such as auto-completion and syntax support
? - Compiler tool-chain, and make process must be similar to GCC
10 - LMM PASM language support
10 - XMM PASM language support
10 - Compilation to multiple targets from one opened IDE
Yes if You have in place of ? 10 to.
It si only one that I have some directions to BUT still 10 to it.
"? - Compiler tool-chain, and make process must be similar to GCC" -- It NOT need TRACK correctly GCC -- BUT need be functional
Ps. NOT all that languages need be in same time as Propeller II arrive.
BUT --> PASM's need be done to time e have Propeller II.
1/1 - C language support
10/10 - Spin language support Enhanced Spin -- not what we have now
1/1 - PBASIC language support
10/10 - PASM language support Enhanced w/ macros, etc.
1/1 - C compiler generates PASM
1/1 - C compiler generates LMM PASM
1/1 - C compiler generates XMM PASM (executes from external memory)
1/1 - C compiler generates spin bytecodes
5/5 - Spin code can execute from external memory Meh. More interested in uC than uP.
5/5 - Compiler and tools must be based on GCC Any FOSS tool chain is acceptable.
1/1 - Simulator
1/1 - Debugger
10/10 - Graphical interface to all features
10/10 - Command line interface to all features
10/10 - Runs under Windows
10/10 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor must have lots of features... Would be satisfied w/current IDE editing features, if they all worked
What does that mean? If I have a command line compiler I can always use make if I want to.
My hobby and work choices are the same. Generally I want what is easiest for me no matter where.
I put Spin out of this picture. I assume that a supper easy Prop Tool like tool will exist for those that want Spin. Must be so to support all the code we have in Spin, as an easy start for beginners
and so on.
I hope there is a PASM assembler to go with all this.
I'm not sure what those results mean. The respondents within this thread comprise a very biased sample that probably does not represent Parallax's broader customer base (many of whom would not even understand some of the questions). Moreover, averaging individual scores, as if they were linearly independent can be misleading. IOW, it's important to track how an answer to one question correlates with answers to others. For example, a strong preference for Spin may coincide with a strong preference for Mac-compatible tools and a disdain for a command-line interface. By doing the correlations, you may discover that respondents fall into two or more disjoint sets of preferences, which might suggest that more than one tool chain is appropriate.
But, still, it's a good start. Thanks for the effort.
-Phil
C.W.
You only Show - Table You write at start of that questions.
In my opinion You need even Show addition's in end of it That many of us made.
@Sapieha, I decided not to change or add on to the survey questions until I receive a dozen or so responses. It is difficult to compare responses if the later group of people are voting on different questions then the initial group of people. I think you have a very good suggestion about supporting multiple targets in one session. I don't quite understand your other items about "LMM PASM language support" and "XMM PASM language support". Could you elaborate on those two items?
Andy
That have little work with HOW Propeller will start.
If It start ALL as PASM - Then for ASSEMBLY type programing You need Any type of Assembler that can handle programs that will be bigger as only one COG length.
AND as it is announced that Propeller II will only have LOADER on ROM -- That is next sure that that is case!
Hi David,
Yes, probably should have said ELF and COFF - and probably also several other binary formats. First line of the Wikipedia article on binutils:
And I didn't mean ELF could only be used on Unix, I said it was not a native format on other platforms. Not that I'm advocating this, but if you are primarily a Windows house, wouldn't it make more sense to use an M$ compatible object format (which I believe these days is a proprietary version of COFF called "PE COFF")?.
Ross.
Absolutely agree with both these statemements!
Ros.
Lucky you!
No. Why would you want your tools for embedded development be different and incompatible with all the other host platforms?
I guess it must be confidential, because I was at the webinar, and didn't hear any of this stuff being discussed at all. Maybe jazzed is referring to another meeting?
Ross.
Heater, I know what you mean - but what's the difference between having to use use MinGW on Windows (to allow you to use ELF binaries) and having to use WINE on Linux (to allow you to use PE COFF binaries)!
Ross.
My question?.
Is it any other micro that use that BINARIES at all?.
How That BINARIES help Propeller II to be compatible with other Micros?.
In PC world Most BIN Linkers are to link diferent parts of binary files that are compiled --- NOT necessary at same time. Else use DLL's that are build to be possible to distribute separately without delivery of Source code. Mostly to have possibility to build LIBRARY'S that can be sold without need of distribute Source code.
Question:
Will we have that on Propeller II?.
I think Yours method of linking are correct for Propeller.
As that always need Source code to be compiled!.
Hi Dave,
I agree with Phil that any numbers we submit are only reflective of the forum members, not the eventual cusotmers of Parallax Semiconductor - but here are my numbers:
Hi Sapieha,
I'm not sure I understand your questions exactly. There are two main purposes of a common object format such as ELF (which I think is what you mean by binaries) - one is as an intermediate library format, and the other is as an executable format (i.e. depending on whether it is used as either the input or the output of the linker).
ELF binaries for the Propeller would certainly not be compatible with any other microcontroller, and I don't think any embedded microcontroller would even use ELF as an executable format (I could be wrong here, but I did a quick google and nothing popped up). So I think we are talking mainly about the advanages of ELF as an intermediate library format.
Is it necessary to have such a format? No (as demonstrated by Catalina). It doesn't stop you having libraries, or distirbuting them in compiled form if you want to.
Is it desirable to have such a format? Maybe - it depends on the size of your projects. I remember the days when compiling a system took a whole day, and you did everything possible to not have to recompile code unless you absolutely had to. Are we likely to fact this prospect on a microcontroller with a few hundred kilobytes of RAM? I really doubt it. I routinely compile programs with Catalina that consist of tens of thousands of lines of code (generating binaries of a couple of megabytes) and the compilation process never takes more than a few seconds.
Ross.
It is correct assumption from You side.
Sorry if I not use correct names -- BUT still as I said -- Compilers is not my primary knowledge.
Hobby Prof. Feature 4.2 6.9 C++ language support 8.0 9.0 C language support 8.0 4.1 Spin language support 2.9 2.0 PBASIC language support 10.0 9.0 PASM language support 5.2 6.0 C compiler generates PASM 9.0 9.0 C compiler generates LMM PASM 8.2 6.6 C compiler generates XMM PASM (executes from external memory) 3.3 2.7 C compiler generates spin bytecodes 4.0 2.4 Spin code can execute from external memory 3.7 4.7 Compiler and tools must be based on GCC 5.0 6.4 Simulator 5.3 8.3 Debugger 6.9 8.6 Graphical interface to all features 9.6 8.8 Command line interface to all features 10.0 10.0 Runs under Windows 9.8 8.6 Runs under Linux 5.9 5.4 Runs on a Mac 5.4 6.6 Text editor must have lots of features, such as auto-completion and syntax support 4.8 6.3 Compiler tool-chain, and make process must be similar to GCC -9.9 -15.3 Spin versus C score Note: The "Spin versus C score" is computed by adding the 3 items that reference Spin and subtracting the "C language support", "C compiler generates LMM PASM" and the "C compiler generates XMM PASM" items.While I find it okay that C is negative and Spin is positive, the way you calculate the "Spin versus C score" is very odd.
With the 3 Spin related items you mean:
- Spin language support
- C compiler generates spin bytecodes ?
- Spin code can execute from external memory ?
is this correct?
I think only the first item has really to do with Spin.
The last item is just not necessary because Spin is so memory friendly.
(not trust any statistics you did not manipulate yourself)
Andy
1/1 - C++ language support
1/1 - C language support
10/10 - Spin language support
1/1 - PBASIC language support
10/10 - PASM language support Enhanced w/ macros, etc.
1/1 - C compiler generates PASM
1/1 - C compiler generates LMM PASM
1/1 - C compiler generates XMM PASM (executes from external memory)
1/1 - C compiler generates spin bytecodes
3/3 - Spin code can execute from external memory
5/5 - Compiler and tools must be based on GCC any FOSS toolchain is fine
3/3 - Simulator
4/4 - Debugger
10/10 - Graphical interface to all features
10/10 - Command line interface to all features
3/3 - Runs under Windows
3/3 - Runs under Linux
10/10 - Runs on a Mac
10/10 - Text editor must have lots of features modern features like code completion
@SSteve, thanks for your input. I've added it to the spreadsheet. It's good to have another response with a preference for Spin. I also see that you prefer the Mac. The tools should be supported on all three platforms.
If we draw some early conclusions from the data, it seems that there's not much interest in the C compiler generating Spin bytecodes or executing Spin code from external memory. There is also not much interest in supporting PBASIC. I actually meant PropBASIC in that item, so I hope everyone understood that.
The score for Spin language support is quite low in the professional column, but it is fairly high in the hobby column, which makes sense to me. Everything else in the professional column is above a 6 except for the GCC and Mac items. SSteve's input should push the Mac item close to 6.
As for Spin, there will be a certain % of commercial developers that will use it, and there is no reason that GCC/etc. needs to try to compile it. Parallx already has a Spin compiler that may need to be ported out of Delphi to something more cross-platform, but as long as it can be integrated with Eclipse/etc., all should be well. I hope Parallax starts another 2 threads, one each for Spin & PASM.
My results put everything to do with C, command lines and cross platform support up to max. I even go so far as to deprecate Spin by putting it down to minimum.
SSteve on the other hand does almost the opposite, Spin and graphical tools is on the top, C is down at the bottom.
If there is a lot of such polarization in the user base and we then take a simple average of poll results to figure out what to prioritize in the tool chain we will end up with a ghastly mess of a tool that does nothing very well.
Hence my view is that there should be two tool chains here with barley any overlap. A new improved, ultra-simple, cross platform Propeller Tool for the "hobbyist" camp and the full up GCC (or Clang/LLVM) tool chain for the "professionals".
I totally understand that this is a very unscientific survey, but I hope that it can provide some guidance in how we should prioritize things.