So we hear you were interested in C for the Propeller
Jessica Uelmen
Posts: 490
As many of you know (and have discussed) one of the main hurdles the Propeller faces from being widely accepted is its lack of free C language support. It’s been a long-standing discussion here at Parallax on whether developing C for the Propeller would even be practical or efficient, given that the Propeller chip’s architecture does not naturally align itself with the C language.
Nonetheless, the need is there, and Parallax is striving to fill that void by developing a C-based source translator that will be built into the Propeller Tool. This will enable programming the Propeller in C (based upon many ANSI C89 & C99 standards) while still staying true to the Propeller chip’s architecture & design principles. This integrated system will work similar to how the Propeller Tool compiles Spin objects currently, providing a simple, easy-to-use programming interface. Propeller MicroC (or PMC as we are currently calling it – name subject to change) will allow the user to program in both PMC and Propeller Assembly like we currently program in both Spin and Propeller Assembly. Also, PMC delivers full access to all existing Spin objects– opening the door to incorporate functionality that has already developed.
So why are we telling you this? Well, we’ve worked very hard over the last couple of weeks to put together specifications for the PMC language, and would love your input. I’ve attached said spec to this post for your review. Our current target audience is college & high school students, college & high school teachers, professional engineers and hobbyists. Since we’ve probably got representatives from each of these groups here in the forums, we want to know if this will meet your needs, or if you see any blatant problems with our approach.
One important thing to note that this spec was written for a reader familiar with both C and Spin/Propeller. It’s meant to detail the structure and functionality of the language but not to teach the language or the Propeller… that will be the job of another document and on-line help system once the source translator is complete.
Good or bad, we’d love to hear from you (and yes, we realize how much we’re opening ourselves up for attack here). Keep in mind that we won’t be able to incorporate all suggestions, or support all possibilities, but we DO want to hear all we can. No point in developing a C-based language for the Propeller if no one can use it!
So…bring it on!
-- Jessica
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jessica Uelmen
Education Department
Parallax Inc.
Nonetheless, the need is there, and Parallax is striving to fill that void by developing a C-based source translator that will be built into the Propeller Tool. This will enable programming the Propeller in C (based upon many ANSI C89 & C99 standards) while still staying true to the Propeller chip’s architecture & design principles. This integrated system will work similar to how the Propeller Tool compiles Spin objects currently, providing a simple, easy-to-use programming interface. Propeller MicroC (or PMC as we are currently calling it – name subject to change) will allow the user to program in both PMC and Propeller Assembly like we currently program in both Spin and Propeller Assembly. Also, PMC delivers full access to all existing Spin objects– opening the door to incorporate functionality that has already developed.
So why are we telling you this? Well, we’ve worked very hard over the last couple of weeks to put together specifications for the PMC language, and would love your input. I’ve attached said spec to this post for your review. Our current target audience is college & high school students, college & high school teachers, professional engineers and hobbyists. Since we’ve probably got representatives from each of these groups here in the forums, we want to know if this will meet your needs, or if you see any blatant problems with our approach.
One important thing to note that this spec was written for a reader familiar with both C and Spin/Propeller. It’s meant to detail the structure and functionality of the language but not to teach the language or the Propeller… that will be the job of another document and on-line help system once the source translator is complete.
Good or bad, we’d love to hear from you (and yes, we realize how much we’re opening ourselves up for attack here). Keep in mind that we won’t be able to incorporate all suggestions, or support all possibilities, but we DO want to hear all we can. No point in developing a C-based language for the Propeller if no one can use it!
So…bring it on!
-- Jessica
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jessica Uelmen
Education Department
Parallax Inc.
Comments
First, a general comment.
Source translation will be very inefficient for constructs not natively supported by Spin, so I strongly recommend taking this opportunity to add some extensions to Spin, which will make the C translator much more efficient, and easier to implement.
I am currently reading your v0.54 specs... and here are my comments:
Page 6:
struct/typedef/union
Currently marked "maybe" - I *STRONGLY* suggest addint support for struct/typedef/union to both Spin and Micro C, as it is currently one of the biggest limitations of Spin, and their lack would needlessly limit Micro C
#include
This is NECESSARY, both for Spin, and Micro C. Consider how much easier a "pins.i" would make compiling objects with different TV, VGA, keyboard etc pins!
#ifdef/#ifndef
This is also needed, it would allow writing programs that will self-adapt to different Propeller boards at compile time - this also needs #include to work.
Page 7:
?: is a very useful shorthand construct that leads to efficient code, I suggest adding it to Spin as well
Page 8 & 9:
If struct/typedef/union are supported, the {symbol} data_type data,data,...,data can be coded in C as a pre-initialized array
message byte "Hello World!",13,0
can be written in C as
char message[noparse]/noparse="Hello World\13\0";
Page 12:
I think the following syntax would be more readable:
class pst = "FullDuplexSerial";
it could even be
obj pst = "FullDuplexSerial"
Page 22:
PLEASE add multi-dimensional array support to Spin!
Page 23:
PLEASE add struct/typedef/union! With #include,#ifdef etc it would make Spin far more powerful and useful if it was added to the Spin language - and it would make MUCH easier, more efficient translation possible.
All in all, a great idea - however it would be much better with the above suggestions, improving Spin and making translation much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I am a hobbyis and I mostly working with the Basic Stamp, but as soon as I had find out about the Propeller and the Basic compiler, I very much like to work with Propeller as well, so I hope in the event of developing the new C compilers, the Propeller Basic compiler not falling in the shadow of the new C language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
At the end, everything will became Electrons...!
Most forumistas know that I'm not a big fan of C and that I believe Spin to be the better choice for the Propeller, since it was designed for the Prop. At least you're not trying to compile to assembly or LMM with PMC, and that's a good thing. What concerns me (nay, even galls me a bit) is the diversion of resources, which really need to be brought to bear on the Propeller Tool itself (which, IMO, was never really finished), to the splintering of dev tools that PMC represents. What's even more galling is that I see features in the PMC spec (namely preprocessing features) that I've been lobbying for for years for the Prop Tool, only to be met with stony silence or vague, as-yet unfulfilled promises.
What I fear most from this development is that it represents a thrust towards professional-level dev tools for the C community, while relegating Spin to the hobbyist market. That would be a grave mistake. Please, please, PLEASE, keep your eye on the ball, and finish the Propeller Tool first, before embarking on another dev tool adventure. We need conditional compilation, INCLUDEs, macros, and a way to organize our Spin objects in subdirectories. Give us that first, and I'll be quiet about C.
Thank you,
-Phil
SPIN with those tools will pack a serious punch, IMHO, largely mitigating the advantages C would bring for having them!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I think Bean has the basic compiler well in hand.
http://forums.parallax.com/showthread.php?p=867134
Now back to C.
Jim
the best language to use on the prop was pasm. Spin is nice
when you don't really need maximum speed...you can whip
up something that works quickly with spin.
What I would really like is a super dooper maxed out pro
quality macro assembler for pasm with all the bells and whistles
It would be nice if it had automatic code generation for common
tasks....this would be a boon to beginners especially. A really good
FAST emulator would be nice to go along with it. I use the one called gear
but it's a bit slow.
There needs to be a comprehensive beginners tutorial for pasm. All I
found when learning were two tiny pdf files. They were useful but
very brief. Several hundred pages are needed...a really thorough
treatise for the complete idiot.
The ability to reference the Propeller Object Exchange from C code is terrific ... that represents a whole lot of wheels that won't have to be reinvented, and doing it with "class" means that "#include" can still be used in its original C way. It also sets PMC apart from other C implementations for the Propeller.
I'm currently working on a project that would benefit mightily from either multi-dimensional arrays, or struct/union/typedef (or both).
I'm not entirely sure I understand the "extern" business -- at least in my mind that means "defined in another source file" and you say it's the same as "PUB".
The specification for ASM functions should probably allow an (optional) FIT specification:
asm toggle [noparse][[/noparse]fit [noparse][[/noparse]address]] { declarations instructions }Of course, adding these "extensions" to Spin would just increase its value more.
Tom.
Post Edited (tmaynard) : 4/15/2010 9:44:27 PM GMT
All you need to add macro capabilities to PASM is a macro-processor like m4.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
In fact there are already 3 or 4 or more ways to get C code running on the Prop: Catalina, ICC, Zog, BDS C ....
PMC is not C. I don't quite see the point of it yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
is probably a great idea. Free C built into the tools..even if it
is a slightly odd flavor of C could make many consider the prop
where they might not otherwise. Every shop has people that
are good at C.
The free C for AVR is very good...Winavr (gcc) and a lot of AVRs
get sold because of it I'm certain. But the prop is just so wonderfully
different than a harvard architecture like AVR... I'm left wondering
how C can be made to fit well with 8 processors, no interrupts..etc.
LMM will be a must of course but the ram in the cogs has to be well used
also...the indeterminate speed of access to the hub ram will need to
be automatically handled somehow. It's just so different than having
32, 64, 128 kb or more of flash all in one contiguous space on an AVR or
ARM.
There are just things you can do with a 6.00 prop that you could never
do with a similar priced AVR or PIC, and if you can do it in C without
having to re-train everybody then it can only be a good thing.
I don't follow, C cares not about how many cores you have or interrupts.
Holly "LMM will be a must of course"
It seems not. What Parallax is proposing is a translator from "not quite C" to Spin and hence to Spin byte codes. No LMM.
Sounds awful.
You are right, I would never have touched an AVR were it not for GCC and WinAvr.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You are currently proposing a C-like language that easily translates into C.· The problem with this is that existing C programs would have to be heavily modified to run as a PMC program.· All the small differences between real C and PMC will drive a programmer crazy.· I would suggest implementing a full-featured standard C compiler that generates Spin byte codes.
If you do implement the first option, please include the #include directive.· This would be extremely useful, even with the class instruction.· It would also be good to allow functions with a variable number of arguments.· The printf function is as much a part of C as any of the standard syntactical elements.· And please make sure that quoted strings are automatically terminated with a NULL.
The byre[noparse]/noparse, word[noparse]/noparse and long[noparse]/noparse features should not be included in PMC, and are not needed as long as pointers can be defined as unsigned char *, unsigned short * and long *.· I would not include the Spn-specific operators either.
You may want to take a look at the cspin pre-processor I did that converts C to spin.· The thread is located at http://forums.parallax.com/showthread.php?p=874747·.· Carefully, read the end of the readme file that describes the limitations and features that haven't been implemented yet.· You may also want to look at CLIB in the OBEX.· As I mentioned before, the standard C library functions are a big part of developing in C, even though they are formally defined in the language.
Dave
·
There are some things, like typedef and arrays of types and multidimensional arrays and #include that really should be in Spin, and probably were omitted because the proptool was never finished to keep things simple. If you want the C people, those things need to be provided. But if you want to keep the Spin people, some of those things need to be in Spin too. Okay, maybe not GOTO. But definitely the other stuff.
For example:
GOTO could then be implemented with spin JMP bytecodes.
SWITCH could then work properly without alot of extra·code generation.
You guys also need to support short circuit && and || operations. This will be a huge problem in porting code to the propeller as it is EXPECTED!!!_!!!_!!!. I've seen many C programs that use short circuit operation to test error cases. It will not be good if it is not included.
...
The PMC module will be very limited if it cannot fully support excepted C9- and C99 standards that are available on other micro controllers.
People will want to be able to port their code easily. Make it so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 4/15/2010 11:50:59 PM GMT
LoL, don't hold back...tell us how you really feel about C
I will admit that C certainly gives you plenty of rope to hang yourself with.
(just look at the obfuscated C code contest)
Whenever I have to look at another coders C code I run it through
a program that formats and cleans it up the way I like it.
Maybe you could work to perfect Catalina and have that as the free C
Or buy the rights to ICC and offer that for free.
ImageCraft is probably not smiling about the idea of a free Parallax C for
the prop. I have used their C for ARM and AVR...they are very good.
Holly, I will admit that C is not inherently bad tool; it's just that it's a product of its time, and its time was 1974. Spin has many of the same "features" I hate C for such as not managing memory or enforcing array boundaries; on a limited CPU such omissions make sense. But they don't make sense when writing business logic code on a PC, or when writing anything that involves security, or really when writing anything where you are not depending on the coder's genius to keep you out of serious hard to diagnose trouble. (On the other hand C also has the curly braces thing and ignoring whitespace, which are symptoms of total brain-death as well as lack of memory in the PDP-11).
The main problem with most of the existing prop C implementations is that they are either seriously more limited than Spin, or require special hardware. LMM is great but not for business logic that doesn't need to be fast, because it's less memory efficient than Spin and therefore reduces the total lines of code you can fit in Hub RAM. Most of the other strategies involve at least some external RAM. Compiling to Spin bytecode is the only way to create a C that can be competitive with Spin itself. But if PMC comes out supporting features that Spin never has despite years of desperate begging on the part of propheads, I suspect some people are going to become peeved.
Your desire to officially support C language is commendable. Unfortunately, it must also allow leveraging the investments that potential customers have already made. Having looked at your document, the proposal falls short.
If you must follow this path, I·recommend you support at least ANSI C89 features including the C pre-processor (and·several expected·extentions introduced by Cygnus in GNU C99). Without this "minimum" feature set, it will be difficult for most of your target audience (customers not already loyal) to embrace your C product.
Once you support the "minimum" feature set, then you can add extentions if you like. Most experienced C programmers for example know how to write C programs that can call "object functions" via data structs. You do not have to reinvent the wheel to do this since "object->function(...)" can do this already ... all you have to do is conveniently package it.
LMM C is fast and furious, but it is also large and luxurious. So for memory usage on your current platform, that's a non-starter. If all anyone ever needs to do is toggle LEDs, then size don't matter ... but most C customers won't stop there. An LMM C will of course shine on your future product, so that should be a consideration.
While I'm not crazy about the Z80, I do feel that something like heater's approach with ZOG is probably the best you can do for a byte wide instruction set similar to Spin bytecodes. It also allows you to offer the LMM C follow on for your next product since adding the instruction set to GNU will allow the same product for both Propellers. Of course, natively compiled LMM PASM·with GNU can be difficult, but probably not in right consultant's hands.
A C to Spin translator is fine if all you care about is converting customers or providing a "loose solution" for your current loyal customers. This is after all your business niche to treat as you like. If you want to "compete" for more serious market share though, you will have to do better. All of the existing micros that support ANSI C89 or GNU C99 are light years ahead of you. Good luck with whatever you do.
Sincerely and kindly as possible,
--Steve
PS: PMC is a trademark of PMC-Sierra, Inc. [noparse][[/noparse]url]http://www.pmc-sierra.com/legal/#trademarks[noparse][[/noparse]/url]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I do agree with Phil - there are more important and useful things to do
Wow! I'm pleased that Parallax now recognizes the importance of C to the wider acceptance of the Propeller. I have read your document once, and will read it again in the greater detail it deserves. However, I already have some initial comments, and I hope you will accept them in the constructive spirit in which they are intended:
- The fact that you need to call your language "PMC" (because it isn't actually "C") will be a significant turn off to most professional C programmers. The days of custom implementations of "yet another C-like" language are long gone - C has been standardized for (literally) decades now.
- The subset of C you have chosen to support has some very strange omissions. No #include? No unsigned types? No "goto"? Only maybe support for the standard ternary operator? There doesn't seem to be any rational reason for any of these particular exclusions (just saying things like "Propeller doesn't support" goto is a bit misleading - what you mean is that SPIN does not have a "goto" statement)
- C does not require new keywords to do what you propose to do in table 7 (and section 3.12 and 3.13). A simple library and some macros would be a better approach. For example, what would happen if I want to port existing C code that happens to use "lookup" as the name of a function? Or "cnt" as the name of a variable? A good optimizing C compiler can make any necessary library calls as efficient as inline code.
- The additional operators you propose in table 9 will only serve to obscure C programs - which are often already difficult to read because of the terseness of some of the existing operators - even further. Just one example: C has operators = and == which already serve to confuse new C users. You propose adding a third operator === which will make the potential for confusion substantially worse.
- I don't really understand what section 2.3 is saying. Will the standard C library be provided or not? I hope so, because it is as much a part of C as "#include" - and also because it is not possible to provide exact equivalents to many of the standard C functions using Propeller objects. For example, no equivalent of "printf" is possible because Propeller objects do not support variadic functions. Functions like "setjmp" and "longjmp" cannot be implemented at all.
- Adopting the keyword "class" perpetuates the confusion that Propeller objects are in fact objects in the normal sense (i.e. the sense that would be understood by most object-oriented programmers). Terms such as "class" have well defined meanings in computer science - e.g. see here. Continuing to misuse industry-standard terms like this will only lead to further confusion in the minds of Propeller users.
- Translating C code to SPIN is a is an approach that has been discussed many times in these forums - and even tried - but it is an approach which has been largely dismissed. There are two main reasons for this:
- SPIN is too slow. Even unoptimized, the existing C compilers (which compile straight to PASM) can already generate code that is many times faster than the best hand-optimized SPIN code. PMC programs will be 4 to 8 times slower than their C equivalents - they are quite likely to be even slower than the equivalent SPIN programs. Of course this gap may narrow on the Prop II - but if PMC isn't substantially faster than SPIN, why would anyone use it?
- Many C features are difficult to implement in SPIN. The most obvious examples are structures, unions and pointer arithmetic. The proposed PMC implementation of structures is bizarre - it will lead to insidious and difficult to eradicate bugs in PMC programs - including perfectly legal C programs that work on any C compiler.
To reiterate - I welcome Parallax's recognition of C as a prerequisite for mainstream acceptance of the Propeller, and hope that this document generates a large amount of constructive discussion about the subject. However, while PMC may well find a place in the Parallax toolkit, it does not really address the need for an actual C compiler. PMC is a non-standard language which looks like C but will generate substantially slower programs.Of course, I recognize that PMC has at least one significant advantage over the current C compilers available on the Propeller - it is integrated with the existing tools, and provides users with a solution that can integrate both SPIN and PMC. However, overall, my reaction is that PMC does not yet achieve its own stated goals. It seems to me that in its current form it will not serve any part of the Propeller community particularly well. New propeller users will find it inexplicably bizarre, and existing C programmers will dismiss it once they realize how much of their existing C code base they will have to re-write to use it. In fact, it may even turn professional users against the Propeller because it might take them some time to realize how little of their existing C code can be used with PMC.
For me, C has two key features, neither of which PMC achieves in its current form:
1. C is ubiquitous and standard. It is well understood in its current form by most professional programmers who work in the embedded domain. 2. C is simple and fast. The main problem with existing C solutions on the Propeller (and I include Catalina here) is that the need to implement them using LMM makes the whole thing unacceptably slow for many applications. Fortunately, this problem is likely to be significantly improved (if not completely resolved) on the Prop II.
If Parallax has some moral or commercial objection to offering a free "GPL-ed" C compler like Catalina to its users, I'd be happy to discuss with you how we could allow Parallax to offer it as a free (but fully supported and non-GPL-ed) alternative to their customers.Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/16/2010 2:14:06 AM GMT
- The spin compiler is really should be fixed to allow organizing spin objects into subdirectories.
- Inventing yet another language is a waste of time- considering there are already 2 c compilers which support standard c.
- Compiling to spin code doesn't make sense.
See attached pdf on how easy it is to program the Propeller in C using Catalina, ViewPort and BlackCat:
- manage debug/release configuration of multi-file project with project editor that reads/writes standard "code::blocks" project files.
- create new source/project files from templates
- edit source code with professional level code editor (similar features as visual studio: bookmarks, code folding, regex search/replace)
- compile as Ansi standard C (with targets that support anything from clock to video) and load to Propeller with one click (multiple memory architectures supported)
- graphically debug code with breakpoints, stepping, watched variables and more
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Others have also made these comments but here is my take...
Now, I hate C, always have, always will. However, the professional community demands C, even if they end up using C & Pasm. The hobbyist would like C at least to start with until they see the ease of Spin. So here is my take....
The above are some questions I have. I don't have the answers since I am not a C programmer, just a little C.
How about a contest (or some reward to the big providers) to create an open source PMC to Spin Bytecode (or just convert to Spin initially)? I am sure there are a number who would revell in this opportunity and Parallax could take the code to do what it wants and maintain if it likes.
Dave's cspin preprocessor could be a good place to start.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
C can also be wrtten and compiled on the propeller. I just wrote this on a propeller and also compiled it on the propeller
/* Hello world example in BDS C */ #include <stdio.h> main() { printf("Hello World\n"); }But it isn't very practical as it took over half a minute to compile.
What would be great is integration of C and PASM in the way spin and pasm are integrated, eg you define a variable in Spin and pasm can now access it, and you can mix and match assembly and a higher level language. The convolutions I have gone through in the past in Basic poking assembly code one byte at a time into what I thought was free memory only to find out it wasn't...
Looking at Spin, I suspect many lines can be translated 1:1 into C. This sounds a very interesting project.
addit: to follow on with Cluso's comment re BST, I have not used the PropTool software for many months now. It doesn't have the features necessary to write code where many authors are contributing at the same time (mainly #ifdef to quickly comment in and out large sections of code).
I wonder if parallax would consider making both the author of Catalina and the author of BST offers they can't refuse?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/16/2010 1:34:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
No, PMC will be slower than SPIN - perhaps substantially slower.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
That seems like very sound advice -- and it worked with SX/B vis-a-vis the SX-Key IDE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
This is the crux of the whole deal. It's not C. The main reason people want to use C is code portability and cross-architecture re-use. The tool you are describing won't facilitate that and will just serve to further fragment the Propeller code base.
There are already 2 good C compilers for the Propeller, why not support them instead?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Much like the existing balance between Spin and Assembler, I think it makes sense to have a C compiler for the Spin interpreter that can include native assembly code.
Just like on the forums, there's often agreement and differing opinions even within the company, but we're charting our course on these issues right now. I recognize that we try to do it all internally far too often, especially when our customers are already making similar efforts that we could integrate to our tools. It may be the case that the PMC concept defined in the spec grew significantly considering it was initially discussed to be a very light-duty C2Spin translator to ease the entry for education (similar to the Lego NQC). This is not an attempt to create a compiler that would be compatible with other C code written for other processors. Just not practical. The target audience is primarily education, though we mentioned hobby as well. But the creation of a spec actually forces us to face the many questions in detail, hence the well-done document from Jeff and Jessica.
Please carry on. . .
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken Gracey
Parallax Inc.
Follow me at http://twitter.com/ParallaxKen for some insider news.