I appreciate (and understood from the document) that PMC is intended at least partly for educational purposes. However, the question remains as to why Parallax would want to educate potential new Propeller users in a language that looks very much like C, but in fact differs from that language in subtle ways that would be extremely difficult for a newcomer to appreciate, understand or correct. Much of the C code that newcomers might expect to extract directly from standard C text books would not work correctly under PCM.
The only other company I know who does this kind of thing is Micro$oft. I think we all know why they do it, and I would hate to see Parallax adopt this type of marketing strategy.
Ross.
P.S. For C code, there are various indentation styles (see here). Unfortunately, the one adopted by PCM (known as "Whitesmiths style") is probably the least common. The reason it is not popular is that this particular style adds very little to a newcomer's ability to understand C code. I strongly recommend that you adopt either K&R C style, or 1TBS style (my own preference - it stands for the "One True Brace Style". No kidding!).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm glad you are amenable to working with parallax to integrate Catalina
into the propeller tools. I did not know it was gpl... I suppose that means Parallax
is free to use it so long as source code is available? I think your work on Catalina
and also Bean's work on propbasic are brilliant! I know they are a labor
of love by 2 great guys that just love the propeller...but someone should be
paying at least a little for all the fine work.
The more I think about it the more I lean towards a true compiler that creates
pasm code...it just feels like "The right thing" anything else seems kludgey. (is that a word)
A compiler is better even if the object repository cannot be used easily. The best
objects just need to be rewritten for the C compiler.
It looks like the propeller tools were compiled with Delphi and compressed with an exe
compressor. (from what I can glean using a hex editor) I have used delphi a little
and it actually seems a good choice..it is very powerful and people seem to create
complex programs in record time. It would probably not be too difficult to slipstream
Catalina into things
So I recommend going with Catalina, improving the propeller tools (a lot)
adding a decent simulator to the tools, and patching Catalina right in there.
And please make a good guidebook for the C implementation.
And could someone crank out something for people trying to learn pasm!?!?
The lack of pasm info is disgraceful! There needs to be a pasm bible in
print and free .pdf form. The description of the pasm language in the big
propeller book is nice but is only useful to beginners as a reference text..
not at all as a guide for the beginner.
Well, it's early morning here and these are my final thoughts on C.... I hope my
rant is of some value to Parallax...I just love the strange and beautiful propeller
and I really want it to succeed. Every time I reflect that it is mainly the creation
of a lone individual I am amazed.
Thanks for the kind words. Yes, Catalina (or at least the major part of it) is GPL. Some is LGPL, and most of the rest is MIT. This means that anyone (Parallax included) is entitled to adopt it, tweak it (hopefully to improve it!) and redistribute it - provided they issue their modified verison under the GPL, and supply the source code.
From previous forum discussions, it seems that some people still regard the GPL with suspicion. To address this, Catalina adopts the GPL only on the non-redistributable components such as the binder and the various utility programs, and adopts the "Lesser GPL" (LGPL) on any runtime components included in the final compiled program - this means that a program does not become GPL just because it is compiled with Catalina.
Even so, there may be some reluctance on the part of Parallax to use any software which could mean they may be required to issue the source code to their own toolset. This is why I am happy to discuss with Parallax the possibility of issuing them a special version of Catalina that is not subject to the GPL. This is my right as the license holder, and would not necessarily restrict my right to also issue Catalina under the GPL - it just means Parallax wouldn't be required to issue source to any part of Catalina they chose to include in their own toolset.
Ross.
P.S. I agree with you about PASM. I have many years assembly language programming experience, and PASM is one of the easiest assembly languages I have ever used - but I still need to consult the PASM manual nearly every time I program in it. A good PASM tutorial (which also teaches the basics of assembly language programming) would be a great addition to the Parallax arsenal.
I also agree with you about how extraordinary the Propeller (and the SPIN langauge) really are - this is why we are all prepared to spend so much of our spare time working with it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I can't see any reason why Parallax should object to publishing source for
any changes they made to Catalina.
Atmel added support for WinAVR (AVR version of gcc) to their toolset and
would have to publish source of any changes they made....far as I know
they never made any changes to that compiler though. It is supported
by a group of very fine C coders that keep it up to date for new AVR chips
as they are developed. WinAVR does not make compiled code that is quite as small
as the ImageCraft compiler...but it is very good for a free compiler.
It would be awesome if the prop tools had support for both your Catalina as well
as Bean's fine Propbasic!
Post Edited (HollyMinkowski) : 4/16/2010 5:29:20 AM GMT
I would much rather see improvements done to the Proptool that many have outlined above, than have a weird C-like language translation into spin.
I program in C/C++ for a living, and having something be "C-Like" instead of being actual C is simple right out! I think most C programmers would be far more annoyed and frustrated with a non-compliant C-like language·than just learning Spin/Pasm.
All this talk of indent/brace style shouldn't matter, anything attempting to be C like·should not enforce any formatting rules at all.
Seriously the single most important thing (in my opinion) to do is add a full preprocessor to Proptool (especially #include). It should literally be as simple as picking one of the available preprocessor libraries and passing the source through it first, the end result is something the existing compiler would compile for both Spin & PASM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Post Edited (Roy Eltham) : 4/16/2010 6:12:38 AM GMT
Personally, I like the C to Spin translator idea... Spin is actually close enough to C that it could be done easily. I always wanted to do it myself, but I noticed that somebody already did it... I think they called it CSpin or something like that.
The reason I like the idea is that I also write some C++ code and sometimes make mistakes when going from one to the other...
I don't really care if it's not 100% ANSI compliant. Portability is not really a big issue when you only have 32kB of RAM...
But, whatever it is you come up with, it had better be at least as fast and compact as SPIN, or I just won't use it...
From the standpoint of someone who has learned spin (mostly) and knows enough C to be dangerous....
Wiser minds than mine have stated that it needs to be "all" compatible...
For me, the appeal would be to have access to the large existing C codebase.
If it is not compatible on the whole, I would honestly stay in Spin where I'm more comfortable.
Rayman: "Portability is not really a big issue when you only have 32kB of RAM"
This is not true.
I have worked on numerous embedded projects were code is developed in C under Linux or Windows or whatever. That code is compiled with the normal GCC on the host. It can then be tested on the host. Of course the host platform does not have the hardware of the target but often a test harness simulating much of that can be wrapped around the code under development.
At the end of the day the code is cross compiled for the target where it generally works fairly soon. Most of the debugging ahving already been done.
This is especially important when targeting platforms that don't even exist yet. The hardware guys are developing that in parallel.
Looking at it that way portability is crucial. A mangled version of C on the target is totally pointless.
I'd rather see a bog standard C implementation that is compiled to Spin byte codes. Any interfacing with the unique Propeller features like pins, timers, starting up other COGs with PASM or Spin would be wrapped up in some Propeller library.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There have been some great comments in this thread, and everybody has their own perspective.· Many people love the Spin language, and they like things just the way they are.· I've grown used to the Spin language, and I would like to seem improvements added, such as the C pre-processor with #include, #define, #if and macros.
I think it's great that Parallax is considering a C compiler.· As I mentioned before, it should be a standards-compliant compiler and not a hybrid C/Spin language.· In my view, there is little value in providing a hybrid C/Spin language.· It would be a disservice to young programmers thinking they are learning C, but they are actually learning a hybrid language that nobody else supports.· It would also make it a nightmare to port large C programs.
So, in my opinion, if Parallax is going to support C they must make it standards-compliant.· However, I think it would be acceptable to allow some limitations, as long as the supported features are standards-compliant.· I also like the idea that the C-compiler would be compatible with existing Spin objects.· This means that the C compiler needs to generate Spin codebytes.
I don't think the compiler should generate Spin source code as an intermediate step.· Even though C and Spin are similar, there are enough subtle differences that will caues the intermediated Spin code to look very odd, and it will ultimately generate inefficient Spin codebytes.· It is better to generate Spin codebytes directly from the C compiler.
So the decision comes down to which features are supported and which features aren't.· The list of supported features should include
- C pre-processor
- structs
- unions
- typedefs
- pointers
- arrays up to 3 dimensions
- goto
- signed char, short, int and long
- unsigned char, short, int and long
- float
- goto
- ?:
- variable argument lists
The features that could be unsupported are
- arrays greater than 3 dimensions
- double
- function pointers
- long long
Function pointers would be nice, but they are difficult to implement in Spin bytecodes.· Some people have looked into function pointers, and there may be a creative way of doing this that allows for multiple cog operation.
So, I think what I am saying is that the C compiler should be implemented something like Catalina, where you start with a public domain compiler.· However, instead of generating PASM it will generate Spin codebytes.· Maybe Ross could help in developing a compiler that generates Spin codebytes.
Dave
Post Edited (Dave Hein) : 4/16/2010 2:26:43 PM GMT
As limited as Spin is and as much as people beg for new features and improvements I'm not convinced that that is the way to go either. You see despite it's short comings I love the simplicity of Spin, I'm sure for a new comer to micro-controllers and programming in general that simplicity is a god send.
If we start cluttering up Spin with our favorite features from C or whatever other language it is going to loose that simplicity and befuddle newcomers.
I hate to mention a certain other provider of multi-core embedded processors save to say that they also needed a C like language with built in facilities that match their unique CPU/IO hardware. The developers there learned twenty years ago that having a non-standard language in which to program your CPU was doomed to failure no matter how much more elegant and powerful it was.
Their solution now is to provide an enhanced C with all the parallelism, coms channels, array bounds checking etc etc built into it's syntax/sematics. BUT at the same time they provide a bog standard C that can be linked in that handles all the non hardware specific "business logic".
This is how I see Spin and C working together, but the C has to be standard and probably generating Spin byte codes.
Failing that I'm going to be using GCC and Spin/PASM by means of Zog[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The nice thing about a full-featured language is that novices can use the subset of the language they are comfortable with.· A novice can write simple programs just knowing the commands "int", "if", "for", "while", "printf" and "scanf".· He doesn't need to know how to use pointers, structs, unions, etc.· He may be a little confused why he has to put an "&" in front of parameters for scanf, but as long as he does it it works OK.
BTW, I changed my opinion about not supporting function pointers, long long, etc.· If the public domain compiler supports it then it can be made to work with Spin bytecodes.· Cog-safe function pointers could be implemented by reserving 8 entries in the method/object table·in each object.· Each entry is dedicated to a Cog.· The function pointer would just consist of a word containing an absolute object number and a method number within that object.· The function call would be implemented by manipulating the object offset and var offset in the Cog's dummy entry for that object, and then calling the dummy method.
I hate to mention a certain other provider of multi-core embedded processors save to say that they also needed a C like language with built in facilities that match their unique CPU/IO hardware. The developers there learned twenty years ago that having a non-standard language in which to program your CPU was doomed to failure no matter how much more elegant and powerful it was.
Their solution now is to provide an enhanced C with all the parallelism, coms channels, array bounds checking etc etc built into it's syntax/sematics. BUT at the same time they provide a bog standard C that can be linked in that handles all the non hardware specific "business logic".
The Inmos transputer didn't fail because of occam (it also had parallel C and Fortran compilers). ST decided not to fund any further development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
And could someone crank out something for people trying to learn pasm!?!?
The lack of pasm info is disgraceful! There needs to be a pasm bible in
print and free .pdf form. The description of the pasm language in the big
propeller book is nice but is only useful to beginners as a reference text..
not at all as a guide for the beginner.
Agree, agree, agree! Maybe a new thread needs to be started to campaign for this?
I don't see any advantage in having a C-to-spin source translator. It might be a small convenience to those who know C, but not spin. However, spin is a very easy language to learn. The only counter-intuitive part of the language is >= operator. I've been a C programmer for 15-20 years and even if the translator existed, I'd continue to write prop code in spin at this point.
Now, what would be advantageous would be a C compiler that compiled to native propeller assembly. Ideally it would support some form of large memory model. That would be an alternative that really offered something different to us -- an intermediate step in performance between spin and assembly. (haven't people already written 3rd-party compilers that do this? just buy out one of them!)
Oh, and whomever mentioned including support for #ifdef / #define.... I think that's a great idea. That could be treated as a preprocessor item that could be made generic to both C and spin. I'd love to have conditional defines in my spin code as it would allow me to easily have a single code module that could function on multiple hardware types. Currently when I make a hardware revision that alters the design, I have to fork off and maintain a slightly-different version of the modules that dealt with that hardware.
The point of Propeller C is not for experianced Propeller users, but to get people to use the Propeller. Then once they are hooked, they could learn spin to increase their knowledge. Just my 2 bytes.
I would very much prefer to see a C to assembly compiler that makes it fast and easy to write code that runs quickly than to see a C to spin compiler that is fast and easy but makes code that runs slowly. What's the point of that? C is supposed to be fast.
I don't necessarily like writing in assembly but I do because it runs quickly. I haven't completely researched the C options out there but if I could write C code that ran directly within a cog then I would stop writing assembly code except where speed is of utmost importance.
For a while I had been searching for a processor that ran a a faster speed that I normally use that had an inexpensive and easy to use development environment. I found that with the propeller if I run in assembly. Spin code makes it easy for someone to get started on the propeller but takes a big hit in performance so that it is more equivalent to a slower processor if extra cogs are used as peripherals. The Propeller II will be great but I'll still have to write in assembly and that is a real pain if you want to do a bunch of math.
I agree with most of the comments here that Parallax wouldn't be well served to spend a lot of time and money on a compiler that will make things run slowly even if it does mostly add compatibility with other existing code out there. It WOULD be well served to include a C compiler that compiled directly to assembly. Give it an option to run directly from a cog instead of using the LMM. With the exception of your main program, everything else can probably fit inside of a single COG. Like one of the other posts here said, it very well could be worth Parallax's time to talk with the people who made the C compilers for the propeller about integrating it into the propeller tool rather than reinventing the wheel.
I haven't read the spec, but based on what I've seen in comments, there seems to be a serious disconnect.
If I understand the premise of this project, it is that in order to go “main stream” you need to have a C complier.
If that is indeed the case, then you really can’t have “PMC”, you need to have plain old “C”. You need to support standard features and libraries, and that’s that, nothing more to discuss (other than possibly additional "prop specific libraries).
If you come out with PMC that isn’t C, you have not addressed the real problem you seem to be after. Manelyu, the ability for a “C Programmer” to plop down and start coding. If every time said programmer writes a piece of code, and it fails to compile, or worse, compiles, but does not work as expected, you’ll do more harm than good.
As one example, how many C programs have you seen without at least one #include directive? Listing that feature as “not certain” seems like certain death for the product.
As alluded to, if it’s not C, you’re not helping anyone. If it’s a “noob”, don’t fool them, or worse confuse them, with an “almost” C. Leave them in Spin. If you’re after the Pro, if it’s not “real” C, they’ll quickly move on.
I'd be happy with just something that made Spin more C like.
I'm very happy using Javascript, for example, which is very close to C++, but not exactly the same.
It would still be much better porting C to PMC that from C to Spin, right?
Yes, Micro, you're right. The original thought behind PMC was to answer requests from educational institutions that really want to use the Propeller but can't use Spin due to state or district standards that require them to teach some form of C. Many schools already use platforms that are programmed in non-ANSI compliant C variants as an introduction to embedded programming. We are hoping that even though it isn't exactly ANSI C, teachers would be more receptive to it than Spin, and enjoy the added benefit of working closely with a multi-processor architecture that isn't obscured by the language. Then, in a perfect world, by seeing how similar the two languages are, hopefully they will feel more comfortable making the change, if the additional benefits of Spin are needed for their objectives.
And if this solution is also satisfactory for some hobbyists or professionals and helps them make the transition from C to Spin, then that's just icing on the cake.
If you're a current Spin programmer, then yes, it would be in your best interest to stick with Spin. PMC is not meant for you. I don't think the spec made this clear enough, and that's our mistake...
Please keep your feedback coming, we really do appreciate it all. We need to know what's a show-stopper and what's not. I'm currently compiling a list to bring to our PMC development meetings of all of your points and suggestions. Hopefully, thanks to your feedback we can come up with a solution that is amenable to those new to the Propeller, and yet doesn't make our current Propeller-faithful cringe.
-- Jessica
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jessica Uelmen
Education Department
Parallax Inc.
So many great responses! I was particularly impressed with Andrey's "ad hoc polymorphism" reference. I'm nowhere near the C programmer most of you are. Even though I've written perhaps 20,000 lines of C code, I'm not very productive or sophisticated (heater: Damn! Golly! [noparse]:)[/noparse] Indeed the whole reason a confirmed ASM programmer like myself ever touches C is to get near-ASM speed without the tedium of endlessly creating control and data structures from scratch. So, for me, there is no great attraction of PMC vs. SPIN. Both are too slow for quadrature detectors and FIR filters.
I suggest using FullDuplexSerial to provide stdin, stdout and stderr (you can alias it to stdout) - frankly I'd include everything referenced in the K&R blue book.
If you don't provide the above, you are (sorry to be so blunt) wasting your time, and doing a disservice to the students.
If you don't want to compile to Spin byte codes, I cannot recommend strongly enough that you add the preprocessor features and the language features to Spin itself - which will also immensely enhance Spin's usability for programming.
Frankly, Catalina, ImageCraft C, and ZOG C all provide decent C compilers, so if you don't want to embed one of those in the IDE, then at least make a decent translator.
Regardless, you really should add these features to Spin...
I'm are not "C" lover - BUT if that "PMC" can give us New "Propeller Tools" That can compile both SPIN and Semi "C"-PMC that are very appreciated.
BUT
1. That New "Propeller Tools" need have possibility to Compile DAT-PASM snippets as separate xxx.bin files without HEADER/FOOTER only RAW COG-PASM Program DAT file's.
... To be possible to call from both "C" and "SPIN" as In-line ASSEMBLY to be executed from any COG and only communicate with them by Given HUB-Memory BOX's.
2. To that "Propeller Tools" need have some new directive's In DAT section -COGDATStart, HUBBOXADD=XXXXX, (This area need have possibility to be visible to compiler that it can use that addresses in "C" and "SPIN" but add Code to compiled Program at END of code REUSED after start of program) COGDATEND,
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I can't agree more with Bill Henning's last post.
C needs to have #include and #define as an absolute minimum, conditional compilation is incredibly useful when debugging code (We currently have to manually comment out debug lines in spin if we don't want them in the final product), and structs, unions, and typedefs make a programmers life much easier when data won't fit into 32 bits or has some sort of symbolic order. I could live without Standard library functions in the initial release as they will probably be added in short order by one of you loyal customers.
I also have to agree with Bill Henning's comments/minimum required features.
K&R C was used as the C textbook at the university I attended. Of course, that was years ago [noparse];)[/noparse]
I would imagine for PMC to be viable for the university market it would need to be a compliant C language.
I just don't see the need for C on the Prop. If you need performance, you write assembly language. After that, Spin works just fine. Spend the time on updating and extending the current Propeller Tool.
I never saw Spin as a barrier to using the Prop in embedded systems. I suspect most experienced developers didn't, either. Parallax needs to spread the word to these folks. Do a design contest with Circuit Cellar magazine and increase awareness.
The Prop is and always will be just a bit too esoteric for the beginner. That's why we have Arduino, Stamp and the rest.
How about an educational course that shows the differences and equalties between SPIN and C to get a understanding of programming languages on a higher level?
To invite these teachers that are forced to use C: what's more complicated to learn special purpose-registers on an ARM-processor witha 300 pages big but still poor and hard to understand documentation or SPIN?
I would love to see a fully compliant C compiler from Parallax.· However, there are existing solutions from RossH and Bill Henning for excellent C compilers for the Prop.· After re-reading the PMC document again, and seeing some of the comments from others I can see where a limited C solution could be useful.· As Rayman said, "It would still be much better porting C to PMC than from C to Spin, right?"
I can see where PMC might be a good start for Parallax.· It would allow them to quickly provide a C solution for a particular market segment.· I would hope that this would open the door for more C tools coming from Parallax in the future.· The Prop II will have the potential of competing in the DSP market.· By the time the Prop II comes out a fully compliant C compiler would make it a good candidate for many DSP applications.
I have one suggestion for PMC that I think is a necessity.· structs should be implemented as a memory block, and not as individual variables as proposed in the PMC document.· A struct is essentially an array of variable-sized elements.· I implemented structs in cspin by defining byte offset for each element in a CON section, and accessing a struct element using either byte[noparse]/noparse, word[noparse]/noparse or long[noparse]/noparse depending on the size of the element.· This allows struct pointers to be used in function calls, which is a common practice in C.· This will greatly improve the·ease of porting code to PMC.
Comments
I appreciate (and understood from the document) that PMC is intended at least partly for educational purposes. However, the question remains as to why Parallax would want to educate potential new Propeller users in a language that looks very much like C, but in fact differs from that language in subtle ways that would be extremely difficult for a newcomer to appreciate, understand or correct. Much of the C code that newcomers might expect to extract directly from standard C text books would not work correctly under PCM.
The only other company I know who does this kind of thing is Micro$oft. I think we all know why they do it, and I would hate to see Parallax adopt this type of marketing strategy.
Ross.
P.S. For C code, there are various indentation styles (see here). Unfortunately, the one adopted by PCM (known as "Whitesmiths style") is probably the least common. The reason it is not popular is that this particular style adds very little to a newcomer's ability to understand C code. I strongly recommend that you adopt either K&R C style, or 1TBS style (my own preference - it stands for the "One True Brace Style". No kidding!).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/16/2010 6:10:24 AM GMT
I'm glad you are amenable to working with parallax to integrate Catalina
into the propeller tools. I did not know it was gpl... I suppose that means Parallax
is free to use it so long as source code is available? I think your work on Catalina
and also Bean's work on propbasic are brilliant! I know they are a labor
of love by 2 great guys that just love the propeller...but someone should be
paying at least a little for all the fine work.
The more I think about it the more I lean towards a true compiler that creates
pasm code...it just feels like "The right thing" anything else seems kludgey. (is that a word)
A compiler is better even if the object repository cannot be used easily. The best
objects just need to be rewritten for the C compiler.
It looks like the propeller tools were compiled with Delphi and compressed with an exe
compressor. (from what I can glean using a hex editor) I have used delphi a little
and it actually seems a good choice..it is very powerful and people seem to create
complex programs in record time. It would probably not be too difficult to slipstream
Catalina into things
So I recommend going with Catalina, improving the propeller tools (a lot)
adding a decent simulator to the tools, and patching Catalina right in there.
And please make a good guidebook for the C implementation.
And could someone crank out something for people trying to learn pasm!?!?
The lack of pasm info is disgraceful! There needs to be a pasm bible in
print and free .pdf form. The description of the pasm language in the big
propeller book is nice but is only useful to beginners as a reference text..
not at all as a guide for the beginner.
Well, it's early morning here and these are my final thoughts on C.... I hope my
rant is of some value to Parallax...I just love the strange and beautiful propeller
and I really want it to succeed. Every time I reflect that it is mainly the creation
of a lone individual I am amazed.
while (x == y) { something(); somethingelse(); } finalthing();It's always seemed to be the easiest to read, for me at any rate, and helps to avoid problems with missing braces.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 4/16/2010 4:58:15 AM GMT
Thanks for the kind words. Yes, Catalina (or at least the major part of it) is GPL. Some is LGPL, and most of the rest is MIT. This means that anyone (Parallax included) is entitled to adopt it, tweak it (hopefully to improve it!) and redistribute it - provided they issue their modified verison under the GPL, and supply the source code.
From previous forum discussions, it seems that some people still regard the GPL with suspicion. To address this, Catalina adopts the GPL only on the non-redistributable components such as the binder and the various utility programs, and adopts the "Lesser GPL" (LGPL) on any runtime components included in the final compiled program - this means that a program does not become GPL just because it is compiled with Catalina.
Even so, there may be some reluctance on the part of Parallax to use any software which could mean they may be required to issue the source code to their own toolset. This is why I am happy to discuss with Parallax the possibility of issuing them a special version of Catalina that is not subject to the GPL. This is my right as the license holder, and would not necessarily restrict my right to also issue Catalina under the GPL - it just means Parallax wouldn't be required to issue source to any part of Catalina they chose to include in their own toolset.
Ross.
P.S. I agree with you about PASM. I have many years assembly language programming experience, and PASM is one of the easiest assembly languages I have ever used - but I still need to consult the PASM manual nearly every time I program in it. A good PASM tutorial (which also teaches the basics of assembly language programming) would be a great addition to the Parallax arsenal.
I also agree with you about how extraordinary the Propeller (and the SPIN langauge) really are - this is why we are all prepared to spend so much of our spare time working with it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Oh no - what have I done!
Now this thread is bound to degenerate into a "my style is better than your style" flame war!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I can't see any reason why Parallax should object to publishing source for
any changes they made to Catalina.
Atmel added support for WinAVR (AVR version of gcc) to their toolset and
would have to publish source of any changes they made....far as I know
they never made any changes to that compiler though. It is supported
by a group of very fine C coders that keep it up to date for new AVR chips
as they are developed. WinAVR does not make compiled code that is quite as small
as the ImageCraft compiler...but it is very good for a free compiler.
It would be awesome if the prop tools had support for both your Catalina as well
as Bean's fine Propbasic!
Post Edited (HollyMinkowski) : 4/16/2010 5:29:20 AM GMT
I program in C/C++ for a living, and having something be "C-Like" instead of being actual C is simple right out! I think most C programmers would be far more annoyed and frustrated with a non-compliant C-like language·than just learning Spin/Pasm.
All this talk of indent/brace style shouldn't matter, anything attempting to be C like·should not enforce any formatting rules at all.
Seriously the single most important thing (in my opinion) to do is add a full preprocessor to Proptool (especially #include). It should literally be as simple as picking one of the available preprocessor libraries and passing the source through it first, the end result is something the existing compiler would compile for both Spin & PASM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Post Edited (Roy Eltham) : 4/16/2010 6:12:38 AM GMT
The reason I like the idea is that I also write some C++ code and sometimes make mistakes when going from one to the other...
I don't really care if it's not 100% ANSI compliant. Portability is not really a big issue when you only have 32kB of RAM...
But, whatever it is you come up with, it had better be at least as fast and compact as SPIN, or I just won't use it...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
Wiser minds than mine have stated that it needs to be "all" compatible...
For me, the appeal would be to have access to the large existing C codebase.
If it is not compatible on the whole, I would honestly stay in Spin where I'm more comfortable.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
This is not true.
I have worked on numerous embedded projects were code is developed in C under Linux or Windows or whatever. That code is compiled with the normal GCC on the host. It can then be tested on the host. Of course the host platform does not have the hardware of the target but often a test harness simulating much of that can be wrapped around the code under development.
At the end of the day the code is cross compiled for the target where it generally works fairly soon. Most of the debugging ahving already been done.
This is especially important when targeting platforms that don't even exist yet. The hardware guys are developing that in parallel.
Looking at it that way portability is crucial. A mangled version of C on the target is totally pointless.
I'd rather see a bog standard C implementation that is compiled to Spin byte codes. Any interfacing with the unique Propeller features like pins, timers, starting up other COGs with PASM or Spin would be wrapped up in some Propeller library.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
I think it's great that Parallax is considering a C compiler.· As I mentioned before, it should be a standards-compliant compiler and not a hybrid C/Spin language.· In my view, there is little value in providing a hybrid C/Spin language.· It would be a disservice to young programmers thinking they are learning C, but they are actually learning a hybrid language that nobody else supports.· It would also make it a nightmare to port large C programs.
So, in my opinion, if Parallax is going to support C they must make it standards-compliant.· However, I think it would be acceptable to allow some limitations, as long as the supported features are standards-compliant.· I also like the idea that the C-compiler would be compatible with existing Spin objects.· This means that the C compiler needs to generate Spin codebytes.
I don't think the compiler should generate Spin source code as an intermediate step.· Even though C and Spin are similar, there are enough subtle differences that will caues the intermediated Spin code to look very odd, and it will ultimately generate inefficient Spin codebytes.· It is better to generate Spin codebytes directly from the C compiler.
So the decision comes down to which features are supported and which features aren't.· The list of supported features should include
- C pre-processor
- structs
- unions
- typedefs
- pointers
- arrays up to 3 dimensions
- goto
- signed char, short, int and long
- unsigned char, short, int and long
- float
- goto
- ?:
- variable argument lists
The features that could be unsupported are
- arrays greater than 3 dimensions
- double
- function pointers
- long long
Function pointers would be nice, but they are difficult to implement in Spin bytecodes.· Some people have looked into function pointers, and there may be a creative way of doing this that allows for multiple cog operation.
So, I think what I am saying is that the C compiler should be implemented something like Catalina, where you start with a public domain compiler.· However, instead of generating PASM it will generate Spin codebytes.· Maybe Ross could help in developing a compiler that generates Spin codebytes.
Dave
Post Edited (Dave Hein) : 4/16/2010 2:26:43 PM GMT
If we start cluttering up Spin with our favorite features from C or whatever other language it is going to loose that simplicity and befuddle newcomers.
I hate to mention a certain other provider of multi-core embedded processors save to say that they also needed a C like language with built in facilities that match their unique CPU/IO hardware. The developers there learned twenty years ago that having a non-standard language in which to program your CPU was doomed to failure no matter how much more elegant and powerful it was.
Their solution now is to provide an enhanced C with all the parallelism, coms channels, array bounds checking etc etc built into it's syntax/sematics. BUT at the same time they provide a bog standard C that can be linked in that handles all the non hardware specific "business logic".
This is how I see Spin and C working together, but the C has to be standard and probably generating Spin byte codes.
Failing that I'm going to be using GCC and Spin/PASM by means of Zog[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW, I changed my opinion about not supporting function pointers, long long, etc.· If the public domain compiler supports it then it can be made to work with Spin bytecodes.· Cog-safe function pointers could be implemented by reserving 8 entries in the method/object table·in each object.· Each entry is dedicated to a Cog.· The function pointer would just consist of a word containing an absolute object number and a method number within that object.· The function call would be implemented by manipulating the object offset and var offset in the Cog's dummy entry for that object, and then calling the dummy method.
Dave
The Inmos transputer didn't fail because of occam (it also had parallel C and Fortran compilers). ST decided not to fund any further development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 4/16/2010 4:13:28 PM GMT
Agree, agree, agree! Maybe a new thread needs to be started to campaign for this?
Now, what would be advantageous would be a C compiler that compiled to native propeller assembly. Ideally it would support some form of large memory model. That would be an alternative that really offered something different to us -- an intermediate step in performance between spin and assembly. (haven't people already written 3rd-party compilers that do this? just buy out one of them!)
Oh, and whomever mentioned including support for #ifdef / #define.... I think that's a great idea. That could be treated as a preprocessor item that could be made generic to both C and spin. I'd love to have conditional defines in my spin code as it would allow me to easily have a single code module that could function on multiple hardware types. Currently when I make a hardware revision that alters the design, I have to fork off and maintain a slightly-different version of the modules that dealt with that hardware.
Micro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
I don't necessarily like writing in assembly but I do because it runs quickly. I haven't completely researched the C options out there but if I could write C code that ran directly within a cog then I would stop writing assembly code except where speed is of utmost importance.
For a while I had been searching for a processor that ran a a faster speed that I normally use that had an inexpensive and easy to use development environment. I found that with the propeller if I run in assembly. Spin code makes it easy for someone to get started on the propeller but takes a big hit in performance so that it is more equivalent to a slower processor if extra cogs are used as peripherals. The Propeller II will be great but I'll still have to write in assembly and that is a real pain if you want to do a bunch of math.
I agree with most of the comments here that Parallax wouldn't be well served to spend a lot of time and money on a compiler that will make things run slowly even if it does mostly add compatibility with other existing code out there. It WOULD be well served to include a C compiler that compiled directly to assembly. Give it an option to run directly from a cog instead of using the LMM. With the exception of your main program, everything else can probably fit inside of a single COG. Like one of the other posts here said, it very well could be worth Parallax's time to talk with the people who made the C compilers for the propeller about integrating it into the propeller tool rather than reinventing the wheel.
-Jack
If I understand the premise of this project, it is that in order to go “main stream” you need to have a C complier.
If that is indeed the case, then you really can’t have “PMC”, you need to have plain old “C”. You need to support standard features and libraries, and that’s that, nothing more to discuss (other than possibly additional "prop specific libraries).
If you come out with PMC that isn’t C, you have not addressed the real problem you seem to be after. Manelyu, the ability for a “C Programmer” to plop down and start coding. If every time said programmer writes a piece of code, and it fails to compile, or worse, compiles, but does not work as expected, you’ll do more harm than good.
As one example, how many C programs have you seen without at least one #include directive? Listing that feature as “not certain” seems like certain death for the product.
As alluded to, if it’s not C, you’re not helping anyone. If it’s a “noob”, don’t fool them, or worse confuse them, with an “almost” C. Leave them in Spin. If you’re after the Pro, if it’s not “real” C, they’ll quickly move on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log
I'd be happy with just something that made Spin more C like.
I'm very happy using Javascript, for example, which is very close to C++, but not exactly the same.
It would still be much better porting C to PMC that from C to Spin, right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
And if this solution is also satisfactory for some hobbyists or professionals and helps them make the transition from C to Spin, then that's just icing on the cake.
If you're a current Spin programmer, then yes, it would be in your best interest to stick with Spin. PMC is not meant for you. I don't think the spec made this clear enough, and that's our mistake...
Please keep your feedback coming, we really do appreciate it all. We need to know what's a show-stopper and what's not. I'm currently compiling a list to bring to our PMC development meetings of all of your points and suggestions. Hopefully, thanks to your feedback we can come up with a solution that is amenable to those new to the Propeller, and yet doesn't make our current Propeller-faithful cringe.
-- Jessica
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jessica Uelmen
Education Department
Parallax Inc.
Post Edited (K2) : 4/16/2010 8:37:44 PM GMT
The lack of the following would be show stoppers:
Pre-Processing:
#define
#include
#ifdef
#ifndef
#if
#else
#endif
Language features:
struct
union
typedef
?:
multi-dimensional arrays of basic types, struct's etc
Standard library calls: (absolute minimum)
putc, getc, puts, gets, sscanf, sprintf, printf, atoi, itoa, strlen, strcpy, strcmp, strncmp, memcpy, memcmp, memset, malloc, free
I suggest using FullDuplexSerial to provide stdin, stdout and stderr (you can alias it to stdout) - frankly I'd include everything referenced in the K&R blue book.
If you don't provide the above, you are (sorry to be so blunt) wasting your time, and doing a disservice to the students.
If you don't want to compile to Spin byte codes, I cannot recommend strongly enough that you add the preprocessor features and the language features to Spin itself - which will also immensely enhance Spin's usability for programming.
Frankly, Catalina, ImageCraft C, and ZOG C all provide decent C compilers, so if you don't want to embed one of those in the IDE, then at least make a decent translator.
Regardless, you really should add these features to Spin...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 4/16/2010 8:35:07 PM GMT
I'm are not "C" lover - BUT if that "PMC" can give us New "Propeller Tools" That can compile both SPIN and Semi "C"-PMC that are very appreciated.
BUT
1. That New "Propeller Tools" need have possibility to Compile DAT-PASM snippets as separate xxx.bin files without HEADER/FOOTER only RAW COG-PASM Program DAT file's.
... To be possible to call from both "C" and "SPIN" as In-line ASSEMBLY to be executed from any COG and only communicate with them by Given HUB-Memory BOX's.
2. To that "Propeller Tools" need have some new directive's In DAT section -COGDATStart, HUBBOXADD=XXXXX, (This area need have possibility to be visible to compiler that it can use that addresses in "C" and "SPIN" but add Code to compiled Program at END of code REUSED after start of program) COGDATEND,
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
C needs to have #include and #define as an absolute minimum, conditional compilation is incredibly useful when debugging code (We currently have to manually comment out debug lines in spin if we don't want them in the final product), and structs, unions, and typedefs make a programmers life much easier when data won't fit into 32 bits or has some sort of symbolic order. I could live without Standard library functions in the initial release as they will probably be added in short order by one of you loyal customers.
David
K&R C was used as the C textbook at the university I attended. Of course, that was years ago [noparse];)[/noparse]
I would imagine for PMC to be viable for the university market it would need to be a compliant C language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
I never saw Spin as a barrier to using the Prop in embedded systems. I suspect most experienced developers didn't, either. Parallax needs to spread the word to these folks. Do a design contest with Circuit Cellar magazine and increase awareness.
The Prop is and always will be just a bit too esoteric for the beginner. That's why we have Arduino, Stamp and the rest.
To invite these teachers that are forced to use C: what's more complicated to learn special purpose-registers on an ARM-processor witha 300 pages big but still poor and hard to understand documentation or SPIN?
best regards
Stefan
I can see where PMC might be a good start for Parallax.· It would allow them to quickly provide a C solution for a particular market segment.· I would hope that this would open the door for more C tools coming from Parallax in the future.· The Prop II will have the potential of competing in the DSP market.· By the time the Prop II comes out a fully compliant C compiler would make it a good candidate for many DSP applications.
I have one suggestion for PMC that I think is a necessity.· structs should be implemented as a memory block, and not as individual variables as proposed in the PMC document.· A struct is essentially an array of variable-sized elements.· I implemented structs in cspin by defining byte offset for each element in a CON section, and accessing a struct element using either byte[noparse]/noparse, word[noparse]/noparse or long[noparse]/noparse depending on the size of the element.· This allows struct pointers to be used in function calls, which is a common practice in C.· This will greatly improve the·ease of porting code to PMC.
Dave