As much as I'd be perfectly happy with Spin being extended <grin> I do understand Jessica's need.
In the past, I've worked for both BCIT and SFU (British Columbia Institute of Technology and Simon Fraser University), and instructors have to justify their choices for training materials to administrators who often don't have a clue, and rely on "checkboxes" - ie - all microcontrollers must have C available, and all courses for them must be taught in C.
I know, its dumb, but that is often how it is.
I actually think a translator is a reasonable choice, as long as Spin is extended to the point that translated code meets the minimum requirements I posted - and as a side effect, we all will benefit from a MUCH better Spin development environment - just image:
' get pin definitions
#include "hardware.i"
typedef point
word x, y
byte color
#ifdef MORPHEUS
' code
#endif
#ifdef TRIBLADE
' code
#endif
StefanL38 said...
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 came up with LMM, which ImageCraft and Ross are using, heater is writing ZOG which has GCC and is going to use my VMCOG, I have not written a C compiler [noparse]:)[/noparse]
structs and unions absolutely need to be as declared, without padding - as often they are used to access data structures retrieved from disk (read SD cards on prop); and once you have struct's and unions, typedef's are just a few keystrokes away - and make declarations much nicer.
As I said, I'd love to see the translator too - as long as the basics were added to Spin so that the translator would be efficient, and so that I (and everyone else) benefits from the new Spin features.
Dave Hein said...
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.
Wow, I have to say I was pretty excited when I saw this post that Parallax was thinking of providing C for the prop not because I use it but because I Want to and have been seriously thinking of learning how to use this language but after reading through these posts
you guys have raised issues I would have (being a complete novice) never even thought to consider! RossH and others have made very important points. I would have been very disappointed to invest time and money into learning C for the prop only to relaize that my efforts to learn C would only really be applicable to a propriety version just for the prop. My desire to learn C was do to the fact that I thought the language was forgive me Universal and I could easily port code between MCU's .. After seriously reading through everyone's comments
I would have to agree with the Nay Sayers I being a hobbyist and looking for an educational source to learn C would pass on a prop propriety version. And of course this is just my 02 cents but I would have to question why educators would be willing to make what seems like such a drastic compromise with the proposed prop C.
From my perspective as a university student, I don't think C would really help the market. At my school (UC Riverside) we learn C++ for a year before we do any other sort of programming, except for some people like MEs who do MATLAB. We then do a course with FPGAs, then we get to the microcontroller scene. In any case, the professors have control over what sort of materials they use to teach their class. For the most part momentum means that things don't change much, but once technologies become outdated it doesn't really matter whether there is a C compiler for the propeller. The professors are much more interested in what sort of concepts the chip can teach, rather than the specifics.
What is really needed for the educational market are a couple of translation guides: C/C++ -> Spin and Java -> Spin. These guides should be concise (~25 pages) and have example programs in both languages showing basic conversions, and how to do things in Spin that aren't possible in the previous language.
As far as the adoption of the Propeller in the educational market, most people that I talk to automatically assume that since the propeller is a 32 bit multi core processor it's much too powerful for what they want to do, and some sort of machismo prevents them from using it. Overcoming this stereotype is, IMHO, one of the greatest challenges facing the widespread adoption of the Propeller in Education. You have to convince educators that the Propeller isn't hopelessly complicated, and adding another language layer with hidden traps won't help.
I have to agree with the sentiment here on finishing the current prop tool.
Some of the issues have needed to be addressed for waaaay too long.
Every time I use the provided tools, I hunt for the non-existent ifdefs, includes and macros....
wishing I could simplify my target goals through proper selection and not fragmentation of my project data.
....Let alone an editor that folds up code properly and serious in depth bookmark functionality.....
.... and understands // and {....} and (*....*) <for you Delphi folks> multiple line comment lockouts.
.... oh, and PC bitmap font issues... that could be selectable, not every file needs/wants drawings.
.... where is the new forum trial with the enhanced (working) search ?
(that's probably the biggest student need as of current )
yeah, I know how to site search with Google. ( that ought to be a sticky now )
I hope that Parallax can find the time necessary to address both issues, that of
pandering to the LCD so that their products might find an expanded home in school
and therefore widen the client base.
This can only help to get the company additional capital that it could use wisely
in our advanced areas.
I think that the authors of the current C implementations deserve first consideration
for their paid/unpaid hard efforts, and Parallax should find the best way to achieve
their educational goals through these authors until the authors feel 'tapped out' in ability
(I can't imagine that happening)
as well as a Generously Paid Workload from Parallax.
These innovators are who make you shine, and are directly mirroring your primary
philosophies with their own contributions.
Don't get me wrong, no crybaby here.
I'm used to slogging it out with rope start editors, 8" floppys
and 15 second working intervals / reboots to get things past hanging IRQ's etc;
I really appreciate how much has gone into making the CURRENT product release
as smooth as it is, and wish you the best in widening your client base.
But please, not at the expense of alienating the loyal developers you have already cultivated.
jack
(perhaps we will get to my <Real> Propeller Issues Someday)
Your points about the educational market are perfectly valid. What school would get funding for their courses if they proposed to teach students a 40 year old computer language? Why, even in my university days - when C was shiny and new - it was not considered suitable as a teaching language. And, as Jessica has clarified, addressing this market was crucial to the development of the specification for PMC.
Unfortunately, the professional embedded and industrial market is a somewhat different beast. Most embedded software is still written in C, and programmers who want to work in this market are simply expected to know it. These days (since it does not get taught much) they either have to learn it for themselves, or (like me) be such an old fart that they grew up with it.
This will remain true until there is a serious competitor language to C - but C fills the role so well that there are none even on the horizon. The trend for most new languages (like Ada, C++ and Java) is to make them bigger, bigger and BIGGER. The commercial imperatives behind this are obvious - it is not in a hardware manufacturers interest to develop (or promote) a small, fast language that might mean their customers could actually get away with using smaller and cheaper hardware to do the job. Neither is it in software companies interests - they generally prefer locking their customers into such a maze of incomprehensible and non-portable gibberish languages that their customers cannot even contemplate moving away from their perfidious products. Some software companies now make more money teaching people how to use their ridiculous products (and then certifying them!) than they do from selling you the products in the first place.
All this conspires to make most new languages impractical for use on small microcontrollers. This is why C persists. The upshot is that if the Propeller does not have a true ANSI compliant C compiler it will simply not be considered for a lot of high-volume embedded applications. And Parallex will sell less Propellers. And we may never see the Prop III - perhaps not even the Prop II. And that would be very sad.
To also respond to something mikeiv posted just a few minutes ago - this thread is not about "naysaying" PMC (at least I'm not). It is about pointing out that PMC is not yet adequately addressing its stated goals. Possibly this is because its main two goals - i.e. to address educational needs as well as the needs of professional users - may in fact be irreconcilable.
But the one thing they do have in common is the need for the real C language - not a C-like substitute.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
With all that's been said in this thread, I think it's important to identify the premises at work here:
1. The Propeller needs better penetration in the ____________ market (fill in the blank).
Name any market sector. Every business wants more product penetration in that market.
2. To penetrate that market, we need a Propeller C tool (PMC), ugly as that prospect may be.
Sure, some market sector can be chosen for #1 that makes this premise inarguably true.
3. To penetrate that market, Parallax needs to divert scarce resources from finishing the current Prop Tool to develop PMC.
This one's a show-stopper, and I'm glad to see I'm not alone in recognizing that fact. First things first. I hope Parallax comes to the same conclusion.
4. To penetrate that market, PMC needs to have the following features: ____________ (fill in the blank).
There's so much discussion of this one here, but it's pure fantasy until #3 can be addressed adequately.
RossH probably a poor choice of words I simply meant that I was in agreement with others who that in its present proposed configuration felt the prop C was probably not a good idea at this time .. I have not taken anything anyone has said here in a negative manner quite the contrary I am very impressed with the points that some people have made. As I stated I am such a novice that I would have blindly jumped on the prop C bandwagon never considering the Pro's or Con's , Having read through all the comments I was quite enlightened and impressed with the knowledgeable about C everyone seems to have. I have also on several occasions pointed out how awesome is it of Parallax to actually ask its customers there opinion That is what keeps me coming back and ordering products time and time again.
Catalina is a C compiler and supports external memory on some platforms. Output is compiled PASM. ImageC also outputs compiled PASM (but IIRC·is currently limited to 32KB hub memory).
bst and homespun Spin/Pasm compilers both support #ifdef, etc now. ZiCog is full of them for various platforms.
Now to the real issues...
I have read all the comments and many have made very valid points. In particular, RossH in his post immediately above this makes extremely valid points.
I want to change my opinion based on the discussion so far...
PropTool needs work. Everyone agrees. So make an offer to BradC he cannot refuse. Why? because it does multi-platform. We get the #ifdef extensions already done.
Catalina and ImageC both compile to PASM and use LMM. These are full-blown C and I think that is what is required. Make them an offer.
PMC version - see below
Standard C to Spin Bytecode - see below
C (of any kind) to Spin sourcecode - forget it!
PMC version
I suggest just make a version of Spin using C like syntax which compiles to spin bytecode. Make it a switch in the compiler or even a compiler directive. What I am saying here is a fairly simple exercise to change the Spin syntax to a C style syntax. So, make the case statements switch statements, use braces, don't force indentation, etc. Just plain spin using a C syntax.
This would give everyone all the benefits of·a C like syntax, but gain all of the spin benefits. Yes spin is slower, but remember the PropII is coming and it should not matter then. It may solve some of the school's problem.
Standard C to Spin Bytecode
It must be a Standard C even if some features are not implemented. That is clear from many here.
The spin bytecode is compact. As I said previously, the Spin Interpreter can be extended.
It should not be a preprocessor, but indeed a part of PropTool (whatever that will become) and live with spin/PMC and Pasm
I think this would be a great addition for when speed is not the main objective.
You would get a great deal of help from the forum members here to code this.
Sphinx
Don't forget, we have a spin/pasm compiler which now runs on the prop. It has #ifdef, etc too. This needs some consideration with any PMC implementation.
Final comment
Please do not forget the great work done by some. I am sure rather than doing this in-house, a joint community effort would give you quicker and likely better results. And use this fact to generate publicity for the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99, just to clarify, when I say preprocessor, I don't mean something outside of the PropTool. I mean what 99% of other compiled languages have which is a preprocess pass built into the tool/compiler that does all of the expansion, substitution, and inclusion stuff defined by all the #include/#define/#if/etc. commands before it·does the actual compile pass(es).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I've just noticed Dave Hein's thread that has popped up again; a C to Spin converter.
It seems to me that all the pieces are already done.
1) C to Spin with Dave's program.
2) C to PASM directly with Catalina.
3) An IDE that can run on multiple platforms with BST.
So rather than reinvent the wheel, I wonder if the next step might be to integrate existing applications?
I'm thinking of an enhanced version of BST. Write some C code. Then two compilation options - compile to Spin then download and run that, or compile using Catalina.
Why would you use one or the other? Well, if you know C but do not understand spin yet, seeing C converted to spin will be very useful. Plus, that converted spin can go into the Obex to be shared with everyone.
On the other hand, if you want speed and the ability to access large external memory (512k or more), then compile the C with catalina.
It would just be a matter of which 'compile' button you press.
Roy, what I mean is that it should not emit spin, even if it is hidden. This would mean that the language would not be as efficient as it would be if it targetted the spinbytecode directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99, ok, I understand and agree. I'm not sure why they wouldn't make it target bytecode. To me it seems kinda weird and harder to target Spin source from C. I would expect that you'd have a better mapping of C to bytecode.
I think the best approach they could take is to work out a licencing deal with RossH for Catalina to incorperate into the Proptool.
In any case, I think I'll be sticking with coding my Props mostly in PASM with small amounts of Spin glue. Of course, I code for a living and use mutliple languages, so I'm not really the target audience for this project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Nice idea - but not really practical I'm afraid. Beyond quite small programs, it is unlikely that code could be successfully transferred back and forth between a PASM compiler environment (Catalina or otherwise) and the SPIN translator environment (PMC or CSPIN). And to do so, you'd probably need yet another set of tools. For instance, something to convert a CON block into a set of #defines (or vice-versa) - who would want to do this boring and error-prone work by hand every time you moved environments?
It would certainly not be practical the way PMC is defined at present - too many C language features missing, or which would work differently. And even if a program compiled successfully in both environments, there is a fair chance it would not execute in precisely the same way - and it would be beyond the capabilities of many programmers to understand why this should be the case, or what to do to fix it.
The only way this might be made to work is to stick to some kind of 'pidgin' dialect that was a strict common (or easily and automatically translatable) subset of all of three languages - i.e. SPIN, C and PMC. No libraries. No structures. No unions. No unsigned variables. No #includes. No pointers to functions. No pointer arithmetic. No variadic functions. Various operators diallowed. Ugh!
The longer this thread goes on, the more I agree with those who maintain that trying to converge C and SPIN may simply be a waste of time (and more importantly, a waste of the precious Parallax resources which would be far better dedicated to developing the Prop II!).
What's wrong with just having SPIN for education and hobbyist use, and C for those who prefer it, or need to use it, or want to learn it?
PMC may end up taking on a life of it's own if Parallax believes there is sufficient educational value in it. More likely (I think) is that SPIN may end up evolving into something a little more "PMC-like" over time - PMC actually embodies some very clever ideas, and would have some serious advantages over the current incarnation of SPIN. However, I doubt either of these approaches is going to end up attracting a significant number of new users to the Propeller.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
PMC does not solve any problems Propeller have. I can bet that not a single meaningful educational institution will buy into Propeller because of the availability of the PMC.
The age of non-standard C is over.
***
If you want to do it right, spec a new spin'ish byte code and compile Standard C into that.
I find PMC a good approach to fulfill the need of a C like syntax for educational purposes.
It seems I am in minority with this opinion, but I really don't undestand the argument, that it has
to be full compatible to standard C.
If you need this, you can use Catalina or ImageCraft-C. Why are they not in use more than Spin then?
Because the Propeller is not made for C and it makes no sense when Parallax also makes another try to come
to the same result. So Parallax goes another way, which tries to combine C and Spin.
Reusing existing C code with Microcontrollers is just a wish, but not reality this days. I programmed many
different Microcontrollers like PICs, AVRs, and Motorola in C, and all have a standardized C compiler.
But it's impossible to take the code of one controller and run it on another. Right now I make a PIC code,
and if I look at the code, there is not one standard library included, but many PIC specific definition libraries.
The code begins with 20 "pragma" lines, and every other line in the code accesses a special hardware register
of the PIC, which is not available on a PC or another controller.
The same happens with the Propeller. Standard libraries don't fit well to the specific hardware features of
the Propeller.
So it makes much more sense if we can use existing Spin objects in PMC than useless existing C code.
The Arduino shows that there is a demand for a simplified, non standard C, that's one of the reasons for it's
success.
I agree that the PropTool needs conditional compiling for PMC _and_ Spin. I think there are also possibilities
for #include, but this is more complicated if it should fit to Spin's object concept.
Hi Jessica,
in my opinion (I had been working at an university, I am working at a large firm, I am a hobby programmer.):
University: The goal is to teach typical things. The Propeller chip is a rather untypical microprocessor. To move from a very untypical language partly in the direction of a typical one, will help just a little bit. The language should at least support the full K&C standard, so that it can be called C. A standard Hello.C must run without any changement.
Professional development: Standard C is required. And debugging features.
Hobbyist: I was never convinced of the bytecode approach. It needs, that you can and want to do assembler as well, only the combination of both makes sense. You have to learn both at the same time. Something like PropBasic is better in my opinion. You can do almost anything without assembler. If there would be need for more speed, you can start coding from the assembler output of the compiler. So here a C to PASM compiler with optional LMM (just like PropBasic) is ideal. It should have an interface to existing spin objects. For hobbyist using you can start with a subset of C.
The best thing, I found in the Spec, is that float will be fully integrated. #include is necessary of course.
I wonder, if your IDE could be more open to allow plugins. So a preprocessor could be integrated later. And the PropBasic Compiler immediately. You have very gifted people here in this forum.....
I think we need two types of include, one that physically includes the code from the specified file, and
another which just includes an object.
Libraries should be included as objects, so that they occupy the memory only 1 time, also if included in
the top object and sub-objects.
The PMC to Spin translator should administrate a list of all the library methodes, and include the right
object name as prefix if a methode is called. So the library methodes can be used like in normal C.
Perhaps the #include syntax can also be used to include user objects, instead of the "class" keyword.
The fllowing code fragment shows what I mean:
#include "myfunctions.spin" '-> really included at end of this object
#include "tv_text.spin" as tv '-> object
#include "keyboard.pmc" as kb '-> object
#include <stdio> '-> object
void main()
{
tv.out( getc() );
putc( kb.getkey() );
myfunction1();
}
---translates to Spin code:---
OBJ
tv : "tv_text"
kb : "keyboard.pmc"
stdio : "stdio.pmc" '-> library objects get filename as name
PUB main
tv.out( stdio.getc ) '-> getc gets stdio. prefix from translator
stdio.putc( kb.getkey )
myfunction1
pub myfunction1 '-> included from myfunctions.spin
...
pub myfunction2
...
Such a concept would allow to run a "Hello World" and other C examples without changes.
If you want the output on VGA then just change the #include <stdio> to something like
#include <vga_io> as stdio
The Translator or better the Spin compiler should eliminate not needed methodes from the binary output,
otherwise the libraries would blow up the code to much.
Currently there are two existing C compilers, ICC and Catalina. As far as I can see there are two advantages that PMC has over ICC and Catalina, 1-it is free and 2-it can use standard spin objects. And 1 isn't even an advantage over Catalina. If you compared it to ICC then ICC would probably come out ahead in every other area.
As everyone else has mentioned there are also several things missing from Spin such as a preprocessor. Some of these things have already been implemented in bst, which imo could be adopted as the 'official' propeller tool. However, some of the things that people have mentioned can make a lot of the code more complex and harder to understand. For example, conditional compilation sounds good in theory and even works well sometimes but it can also easily make code a mess and hard to understand. For example
Here there is really only three lines of code but it gets really hard to read. I think conditional compilation is needed but it needs some fancy work in the ide to keep the code easy too read. For example, at the top of the window all the defines are listed as check boxes where they can be turned on and off and the code within those sections is hidden.
Other perceived problems with spin are the lack of structures and typedefs. Structures are not really supposed to be necessary in an OO language which is probably one reason they are not included in spin. Instead of structures an "object.variable" syntax could be added to spin and that would do away with the need for structures. This would be possible with the existing byte code but the bytecode would be a little messy and slow. Typedefs are probably not much really important if we don't have structures so then there is probably no need to add them.
There are also some problems with translating c to spin like the limits on the number of methods and constants in an object. This shouldn't be a problem for files that are written for the propeller but it could be a problem when trying to use existing code. Things like structures (proposed solution could cause naming conflicts and will require changes to spin compiler to not sort variables. Also, proposed array solution is not good because then the variables aren't going to be arranged in memory as expected), function pointers (not supported in spin), variables with preassigned values (not supported in spin unless in a dat section), and case sensitivity are also likely to cause problems.
What I suggest is that a couple of features be added to standard spin, Parallax reaches some kind of agreement with ImageCraft about ICC use in schools and uni, and bst be adopted as the 'official' prop tool (need mac support).
The features that should be added to spin are conditional compilation, object.variable syntax, a BAS block for for basic-assembly blocks to ease asm intro for beginners, multi-dimension arrays and probably a couple of things that I'm missing.
Things like structures (proposed solution could cause naming conflicts and will require changes to spin compiler to not sort variables. Also, proposed array solution is not good because then the variables aren't going to be arranged in memory as expected), function pointers (not supported in spin), variables with preassigned values (not supported in spin unless in a dat section), and case sensitivity are also likely to cause problems.
...
Steven,
I use the array solution for structs in cspin, and it works fine.· Look at the sample C and Spin code below.· Spin does have a problem with duplicate names because of the global nature of variable names and the case insensitivity.· I resolved this in cspin by adding a _0, _1, etc. to duplicate names.· Notice how the generated spin code uses Test_0 because of a conflict with the reserved word "test".
cspin also handles pre-assigned values without any problems.· cspin doesn't support function pointers, but they can be implemented by modifying entries in the method table.
From an educational / non-C programmer POV, I can see some benefit from C>Spin - but only if you already know Spin (in which case, why would you want to learn C for the Propeller?!).
From a professional perspective, I can see why Parallax would like C on the Propeller, but I can't see that any professional would be interested in a) Spin as output, nor b) an implementation that doesn't support ANSI C.
I believe that supporting standards is the box that Parallax need to tick to gain acceptance in education and industry.
On face value, it appears obvious that Parallax should make offers to RossH (Catalina) and BradC (BST) - making Catalina and BST the official C and IDE - but we're assuming that Ross & Brad would be comfortable with this (which I really hope they would be).
C'mon Parallax - don't go it alone; you'll be quicker to market by adopting what's already there
Dave Hein said...
I use the array solution for structs in cspin, and it works fine.
It will most of the time but what about if I write the structure to a binary file or send it byte by byte over a serial link and than try to read it on a pc? Because the pc won't add the extra bytes needed for alignment on the propeller you will need two different versions of the code instead of just one.
Dave Hein said...
cspin also handles pre-assigned values without any problems.
I presume that this is by using the dat section or by having an init method that sets all the values?
Dave Hein said...
cspin doesn't support function pointers, but they can be implemented by modifying entries in the method table.
You could do this but then it isn't safe to use in more than one core unless locks or something are used.
I haven't looked at cspin so you may have these covered.
Steven,
Most compilers have an option to create packed or unpacked structs.· I use the Watcom compiler, which generates unpacked structs by default.· When structs are used in binary files I think the safest thing is to design structs so that there are no holes even if the compiler is set for the unpacked mode.· This way theres no ambiguity with other applications/platforms.· Of course, there's always the little endian versus big endian issue.· I'll add packed structs to my TODO list for cspin.
Pre-assigned values are put in the DAT section if they are defined outside of a function.· Pre-assigned values defined within a function are assigned at the beginning of a function.· cspin currently does not support static variables defined within a function.
Function pointers could be made cog-safe by reserving an array of 8 dummy methods in the method table.· Each cog would use its own dedicated dummy method.
Dave
stevenmess2004 said...
Things like structures (proposed solution could cause naming conflicts and will require changes to spin compiler to not sort variables.
Whatever the latest pre-release version of bst is (can't remember) has the ability to do this by declaring a block VARX rather than VAR. It has the potential to cause you headaches with alignment, but it won't sort the variables for you. You either need VAR or VARX for the entire object, you can't pick and choose though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
I am a professional c-programmer.
I tried it with spin, but my spin-lines very often ends with a ';' --> error. My comments starts with // --> also wrong. "Greater than or equal" is >= --> another error...........
Maybe I am simply too stupid, but if you code all the time in C then many things come automatically (without thinking).
These problems PMC would solve and porting c-code would be much easier.
necessary preprocesser-features (in c and in assembler):
#define (also macrodefinition especially for assembler)
#undef
#ifdef and/or #if defined()
#ifndef and/or #if !defined()
#if
#elif
#else
#endif
#error
additional necessary language features:
something like this:
Sapieha said...
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,
language features that would be nice:
struct
union
not necessary language features:
typedef
goto
continue
variable argument lists
?:
double
Standard library (putc, getc, puts, gets, sscanf, sprintf, printf, atoi, itoa, strlen, strcpy, strcmp, strncmp, malloc, free....)
in my opinion errors:
- extern means, that something is defined/initialized in another file. --> keyword extern is not necessary (without static it is "public")
- int temp[noparse][[/noparse]25], *p; p = &temp; (should be: p = &temp[noparse][[/noparse]0]; or p = temp; because temp in c is a pointer)
- unsigned, signed (datatypes should all be signed as standard, but prefix signed should be allowed)
Best thing of course would be a standard C-Compiler which compiles to pasm (not LMM) and spin-bytecode and a debugger integrated in one IDE.
This is in my opinion the only solution who could push the propeller in the professional market.
I have decided that PMC (by some other name) is a workable idea with caveats assuming you have resources to do it.
You must:
Use one or more real ANSI C (89/99) compilers to build the Propeller executable binary (pre ANSI C89 does not qualify).
Officially qualify and recommend one or more real ANSI C compilers which emits LMM, Spin bytecode, or other VM code.
Use an official product name other than PMC to avoid getting sued.
Further:
Contributors and decision makers should have more familiarity with C language (Ken and others should take a class).
You should constrain yourself on polluting the product with all those weird Spin-like operators. Allowing the "?" conditional operator would be appreciated by many.
Library paths must be supported. The #include should be allowed for global scope items ... "class" does not provide global scope.
The #ifdef is expected by C programmers, but the alternative #if defined(...) you suggest is workable.
Using a real C compiler in the product adds flexibility that allows for real C programming when "students" graduate.
Finally, If you want people to more adopt Spin as a programming language, illustrating a killer application and providing a runtime environment for it on the PC would be more effective than providing a C to Spin translator (better use of scare resources, leverage current resources, easier for users to learn).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
jazzed said...
Allowing the "?" conditional operator would be appreciated by many.
That would also be greatly appreciated in Spin. I can't count the number of times I've wished it were available. Plus, it can be implemented using the current set of byte codes, with only a change to the compiler.
Very interesting comments, so far. But stepping back just a little (to give us a breather), I'm guessing Parallax is interested in approaching high schools or even middle schools, not just colleges and universities. Also, although they are a company and need to make a profit, I think it's partly about how to best make available the opportunities that the Propeller provides to a greater audience such that it can be applied to do useful things in the world and to give folks joy in programming and perhaps to teach them to think outside the box (though there's nothing wrong with thinking inside an established box when it's a good box). I'd guess that one of the things that the Parallax staff enjoys the most is working with the younger educational audiences out there, and it's no doubt a shame (not just for Parallax but for the denied potential users) if it's only the language that stands in the way of them being able to do that in some instances.
Having said that, I think the upcoming Prop II has some serious commercial applications, above-and-beyond the Prop I. And so the C language could be important for that in extending its reach in that realm. And the Prop II will have enhanced educational uses as well (with even an on-board development system being considered (at least at one time), which probably lends itself more to the educational community). As such, I'm kind of curious to know how much of this C languange consideration on Parallax's part is motivated by the forthcoming chip.
Of course, it's been said many times that the Prop I will be around for a long time concurrent with the Prop II, particularly due to its low-power performance and available DIP package, not to mention Parallax's committment to long-term sourcing for its customers. But I think that the move to facilitating (not switching to) C has to be done with the Prop II in mind, because, if one is not dealing with an existing design that's fashioned around the Prop I, why would one choose the Prop I over the Prop II? Well, the aforesaid low power capability and the DIP package, as well as easier interfacing (fewer pins) and lower cost (assuming the Prop I comes in a few dollars cheaper). Sure, there's those things. But the additional memory, speed and enhanced simplicity of A/D & D/A (and even interfacing with built-in pull-up/pull-down resistors) are going to be mighty appealing to many if not most folks (dataloggers and what-not requiring low-power aside), particularly considering that solutions will be developed to provide ease-of-use for the more complex packaging (for the educational/hobbiest markets).
So, in summary, in terms of strategy, perhaps this C discussion has to be done with the slow-but-sure "transition" to the Prop II in mind. Yes, Parallax has its hands full with its current activities, true, and even with the current chip. But its likely that the development software for the Prop I will never be perfectly finished (not that this warrants not trying or abandonment), but long-range plans should include the Prop II. Also, most, if not all, of the work that would be done to implement C for use with the current chip would likely be applicable to the new chip (where embedding a new version of SPIN is a given). So, a Prop II with C (SPIN and PASM (and others)) seems quite appealing. I'm very surprised that Parallax is considering C given how tightly stretched their resources seem to be (or maybe that's just Chip's, ha-ha). As such, it makes sense that they must have the Prop II in mind. Anyway, just an attempt at a "step back" perspective. BTW, the Prop I is now nearly 4 years old from release; that's about 40 in chip years. On the other hand, "You're not getting older, Prop I, you're getting better!"
I think making a c like language is a disadvantage to all. You say you want it so schools are more likely to teach using your products. This is great for your bottom line but terrible for the students who think they are learning C but realize once they leave school that they do not actually know how to program in C.
If all you want is to make more money go ahead with your plans. If you want to support and encorage the programmers of the future and not hinder them by confusing them then make a true c compiler or purchase the rights to one that already exists.
Comments
In the past, I've worked for both BCIT and SFU (British Columbia Institute of Technology and Simon Fraser University), and instructors have to justify their choices for training materials to administrators who often don't have a clue, and rely on "checkboxes" - ie - all microcontrollers must have C available, and all courses for them must be taught in C.
I know, its dumb, but that is often how it is.
I actually think a translator is a reasonable choice, as long as Spin is extended to the point that translated code meets the minimum requirements I posted - and as a side effect, we all will benefit from a MUCH better Spin development environment - just image:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
structs and unions absolutely need to be as declared, without padding - as often they are used to access data structures retrieved from disk (read SD cards on prop); and once you have struct's and unions, typedef's are just a few keystrokes away - and make declarations much nicer.
As I said, I'd love to see the translator too - as long as the basics were added to Spin so that the translator would be efficient, and so that I (and everyone else) benefits from the new Spin features.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
you guys have raised issues I would have (being a complete novice) never even thought to consider! RossH and others have made very important points. I would have been very disappointed to invest time and money into learning C for the prop only to relaize that my efforts to learn C would only really be applicable to a propriety version just for the prop. My desire to learn C was do to the fact that I thought the language was forgive me Universal and I could easily port code between MCU's .. After seriously reading through everyone's comments
I would have to agree with the Nay Sayers I being a hobbyist and looking for an educational source to learn C would pass on a prop propriety version. And of course this is just my 02 cents but I would have to question why educators would be willing to make what seems like such a drastic compromise with the proposed prop C.
What is really needed for the educational market are a couple of translation guides: C/C++ -> Spin and Java -> Spin. These guides should be concise (~25 pages) and have example programs in both languages showing basic conversions, and how to do things in Spin that aren't possible in the previous language.
As far as the adoption of the Propeller in the educational market, most people that I talk to automatically assume that since the propeller is a 32 bit multi core processor it's much too powerful for what they want to do, and some sort of machismo prevents them from using it. Overcoming this stereotype is, IMHO, one of the greatest challenges facing the widespread adoption of the Propeller in Education. You have to convince educators that the Propeller isn't hopelessly complicated, and adding another language layer with hidden traps won't help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
Some of the issues have needed to be addressed for waaaay too long.
Every time I use the provided tools, I hunt for the non-existent ifdefs, includes and macros....
wishing I could simplify my target goals through proper selection and not fragmentation of my project data.
....Let alone an editor that folds up code properly and serious in depth bookmark functionality.....
.... and understands // and {....} and (*....*) <for you Delphi folks> multiple line comment lockouts.
.... oh, and PC bitmap font issues... that could be selectable, not every file needs/wants drawings.
.... where is the new forum trial with the enhanced (working) search ?
(that's probably the biggest student need as of current )
yeah, I know how to site search with Google. ( that ought to be a sticky now )
I hope that Parallax can find the time necessary to address both issues, that of
pandering to the LCD so that their products might find an expanded home in school
and therefore widen the client base.
This can only help to get the company additional capital that it could use wisely
in our advanced areas.
I think that the authors of the current C implementations deserve first consideration
for their paid/unpaid hard efforts, and Parallax should find the best way to achieve
their educational goals through these authors until the authors feel 'tapped out' in ability
(I can't imagine that happening)
as well as a Generously Paid Workload from Parallax.
These innovators are who make you shine, and are directly mirroring your primary
philosophies with their own contributions.
Don't get me wrong, no crybaby here.
I'm used to slogging it out with rope start editors, 8" floppys
and 15 second working intervals / reboots to get things past hanging IRQ's etc;
I really appreciate how much has gone into making the CURRENT product release
as smooth as it is, and wish you the best in widening your client base.
But please, not at the expense of alienating the loyal developers you have already cultivated.
jack
(perhaps we will get to my <Real> Propeller Issues Someday)
Your points about the educational market are perfectly valid. What school would get funding for their courses if they proposed to teach students a 40 year old computer language? Why, even in my university days - when C was shiny and new - it was not considered suitable as a teaching language. And, as Jessica has clarified, addressing this market was crucial to the development of the specification for PMC.
Unfortunately, the professional embedded and industrial market is a somewhat different beast. Most embedded software is still written in C, and programmers who want to work in this market are simply expected to know it. These days (since it does not get taught much) they either have to learn it for themselves, or (like me) be such an old fart that they grew up with it.
This will remain true until there is a serious competitor language to C - but C fills the role so well that there are none even on the horizon. The trend for most new languages (like Ada, C++ and Java) is to make them bigger, bigger and BIGGER. The commercial imperatives behind this are obvious - it is not in a hardware manufacturers interest to develop (or promote) a small, fast language that might mean their customers could actually get away with using smaller and cheaper hardware to do the job. Neither is it in software companies interests - they generally prefer locking their customers into such a maze of incomprehensible and non-portable gibberish languages that their customers cannot even contemplate moving away from their perfidious products. Some software companies now make more money teaching people how to use their ridiculous products (and then certifying them!) than they do from selling you the products in the first place.
All this conspires to make most new languages impractical for use on small microcontrollers. This is why C persists. The upshot is that if the Propeller does not have a true ANSI compliant C compiler it will simply not be considered for a lot of high-volume embedded applications. And Parallex will sell less Propellers. And we may never see the Prop III - perhaps not even the Prop II. And that would be very sad.
To also respond to something mikeiv posted just a few minutes ago - this thread is not about "naysaying" PMC (at least I'm not). It is about pointing out that PMC is not yet adequately addressing its stated goals. Possibly this is because its main two goals - i.e. to address educational needs as well as the needs of professional users - may in fact be irreconcilable.
But the one thing they do have in common is the need for the real C language - not a C-like substitute.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1. The Propeller needs better penetration in the ____________ market (fill in the blank).
Name any market sector. Every business wants more product penetration in that market.
2. To penetrate that market, we need a Propeller C tool (PMC), ugly as that prospect may be.
Sure, some market sector can be chosen for #1 that makes this premise inarguably true.
3. To penetrate that market, Parallax needs to divert scarce resources from finishing the current Prop Tool to develop PMC.
This one's a show-stopper, and I'm glad to see I'm not alone in recognizing that fact. First things first. I hope Parallax comes to the same conclusion.
4. To penetrate that market, PMC needs to have the following features: ____________ (fill in the blank).
There's so much discussion of this one here, but it's pure fantasy until #3 can be addressed adequately.
-Phil
Catalina is a C compiler and supports external memory on some platforms. Output is compiled PASM. ImageC also outputs compiled PASM (but IIRC·is currently limited to 32KB hub memory).
bst and homespun Spin/Pasm compilers both support #ifdef, etc now. ZiCog is full of them for various platforms.
Now to the real issues...
I have read all the comments and many have made very valid points. In particular, RossH in his post immediately above this makes extremely valid points.
I want to change my opinion based on the discussion so far...
PMC version
I suggest just make a version of Spin using C like syntax which compiles to spin bytecode. Make it a switch in the compiler or even a compiler directive. What I am saying here is a fairly simple exercise to change the Spin syntax to a C style syntax. So, make the case statements switch statements, use braces, don't force indentation, etc. Just plain spin using a C syntax.
This would give everyone all the benefits of·a C like syntax, but gain all of the spin benefits. Yes spin is slower, but remember the PropII is coming and it should not matter then. It may solve some of the school's problem.
Standard C to Spin Bytecode
You would get a great deal of help from the forum members here to code this.
Sphinx
Don't forget, we have a spin/pasm compiler which now runs on the prop. It has #ifdef, etc too. This needs some consideration with any PMC implementation.
Final comment
Please do not forget the great work done by some. I am sure rather than doing this in-house, a joint community effort would give you quicker and likely better results. And use this fact to generate publicity for the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
It seems to me that all the pieces are already done.
1) C to Spin with Dave's program.
2) C to PASM directly with Catalina.
3) An IDE that can run on multiple platforms with BST.
So rather than reinvent the wheel, I wonder if the next step might be to integrate existing applications?
I'm thinking of an enhanced version of BST. Write some C code. Then two compilation options - compile to Spin then download and run that, or compile using Catalina.
Why would you use one or the other? Well, if you know C but do not understand spin yet, seeing C converted to spin will be very useful. Plus, that converted spin can go into the Obex to be shared with everyone.
On the other hand, if you want speed and the ability to access large external memory (512k or more), then compile the C with catalina.
It would just be a matter of which 'compile' button you press.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I think the best approach they could take is to work out a licencing deal with RossH for Catalina to incorperate into the Proptool.
In any case, I think I'll be sticking with coding my Props mostly in PASM with small amounts of Spin glue. Of course, I code for a living and use mutliple languages, so I'm not really the target audience for this project.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Nice idea - but not really practical I'm afraid. Beyond quite small programs, it is unlikely that code could be successfully transferred back and forth between a PASM compiler environment (Catalina or otherwise) and the SPIN translator environment (PMC or CSPIN). And to do so, you'd probably need yet another set of tools. For instance, something to convert a CON block into a set of #defines (or vice-versa) - who would want to do this boring and error-prone work by hand every time you moved environments?
It would certainly not be practical the way PMC is defined at present - too many C language features missing, or which would work differently. And even if a program compiled successfully in both environments, there is a fair chance it would not execute in precisely the same way - and it would be beyond the capabilities of many programmers to understand why this should be the case, or what to do to fix it.
The only way this might be made to work is to stick to some kind of 'pidgin' dialect that was a strict common (or easily and automatically translatable) subset of all of three languages - i.e. SPIN, C and PMC. No libraries. No structures. No unions. No unsigned variables. No #includes. No pointers to functions. No pointer arithmetic. No variadic functions. Various operators diallowed. Ugh!
The longer this thread goes on, the more I agree with those who maintain that trying to converge C and SPIN may simply be a waste of time (and more importantly, a waste of the precious Parallax resources which would be far better dedicated to developing the Prop II!).
What's wrong with just having SPIN for education and hobbyist use, and C for those who prefer it, or need to use it, or want to learn it?
PMC may end up taking on a life of it's own if Parallax believes there is sufficient educational value in it. More likely (I think) is that SPIN may end up evolving into something a little more "PMC-like" over time - PMC actually embodies some very clever ideas, and would have some serious advantages over the current incarnation of SPIN. However, I doubt either of these approaches is going to end up attracting a significant number of new users to the Propeller.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The age of non-standard C is over.
***
If you want to do it right, spec a new spin'ish byte code and compile Standard C into that.
Otherwise, you are wasting your time.
It seems I am in minority with this opinion, but I really don't undestand the argument, that it has
to be full compatible to standard C.
If you need this, you can use Catalina or ImageCraft-C. Why are they not in use more than Spin then?
Because the Propeller is not made for C and it makes no sense when Parallax also makes another try to come
to the same result. So Parallax goes another way, which tries to combine C and Spin.
Reusing existing C code with Microcontrollers is just a wish, but not reality this days. I programmed many
different Microcontrollers like PICs, AVRs, and Motorola in C, and all have a standardized C compiler.
But it's impossible to take the code of one controller and run it on another. Right now I make a PIC code,
and if I look at the code, there is not one standard library included, but many PIC specific definition libraries.
The code begins with 20 "pragma" lines, and every other line in the code accesses a special hardware register
of the PIC, which is not available on a PC or another controller.
The same happens with the Propeller. Standard libraries don't fit well to the specific hardware features of
the Propeller.
So it makes much more sense if we can use existing Spin objects in PMC than useless existing C code.
The Arduino shows that there is a demand for a simplified, non standard C, that's one of the reasons for it's
success.
I agree that the PropTool needs conditional compiling for PMC _and_ Spin. I think there are also possibilities
for #include, but this is more complicated if it should fit to Spin's object concept.
Andy
in my opinion (I had been working at an university, I am working at a large firm, I am a hobby programmer.):
University: The goal is to teach typical things. The Propeller chip is a rather untypical microprocessor. To move from a very untypical language partly in the direction of a typical one, will help just a little bit. The language should at least support the full K&C standard, so that it can be called C. A standard Hello.C must run without any changement.
Professional development: Standard C is required. And debugging features.
Hobbyist: I was never convinced of the bytecode approach. It needs, that you can and want to do assembler as well, only the combination of both makes sense. You have to learn both at the same time. Something like PropBasic is better in my opinion. You can do almost anything without assembler. If there would be need for more speed, you can start coding from the assembler output of the compiler. So here a C to PASM compiler with optional LMM (just like PropBasic) is ideal. It should have an interface to existing spin objects. For hobbyist using you can start with a subset of C.
The best thing, I found in the Spec, is that float will be fully integrated. #include is necessary of course.
I wonder, if your IDE could be more open to allow plugins. So a preprocessor could be integrated later. And the PropBasic Compiler immediately. You have very gifted people here in this forum.....
Good luck with the decisions!
Christof
I think we need two types of include, one that physically includes the code from the specified file, and
another which just includes an object.
Libraries should be included as objects, so that they occupy the memory only 1 time, also if included in
the top object and sub-objects.
The PMC to Spin translator should administrate a list of all the library methodes, and include the right
object name as prefix if a methode is called. So the library methodes can be used like in normal C.
Perhaps the #include syntax can also be used to include user objects, instead of the "class" keyword.
The fllowing code fragment shows what I mean:
#include "myfunctions.spin" '-> really included at end of this object #include "tv_text.spin" as tv '-> object #include "keyboard.pmc" as kb '-> object #include <stdio> '-> object void main() { tv.out( getc() ); putc( kb.getkey() ); myfunction1(); } ---translates to Spin code:--- OBJ tv : "tv_text" kb : "keyboard.pmc" stdio : "stdio.pmc" '-> library objects get filename as name PUB main tv.out( stdio.getc ) '-> getc gets stdio. prefix from translator stdio.putc( kb.getkey ) myfunction1 pub myfunction1 '-> included from myfunctions.spin ... pub myfunction2 ...Such a concept would allow to run a "Hello World" and other C examples without changes.
If you want the output on VGA then just change the #include <stdio> to something like
#include <vga_io> as stdio
The Translator or better the Spin compiler should eliminate not needed methodes from the binary output,
otherwise the libraries would blow up the code to much.
Andy
Currently there are two existing C compilers, ICC and Catalina. As far as I can see there are two advantages that PMC has over ICC and Catalina, 1-it is free and 2-it can use standard spin objects. And 1 isn't even an advantage over Catalina. If you compared it to ICC then ICC would probably come out ahead in every other area.
As everyone else has mentioned there are also several things missing from Spin such as a preprocessor. Some of these things have already been implemented in bst, which imo could be adopted as the 'official' propeller tool. However, some of the things that people have mentioned can make a lot of the code more complex and harder to understand. For example, conditional compilation sounds good in theory and even works well sometimes but it can also easily make code a mess and hard to understand. For example
Here there is really only three lines of code but it gets really hard to read. I think conditional compilation is needed but it needs some fancy work in the ide to keep the code easy too read. For example, at the top of the window all the defines are listed as check boxes where they can be turned on and off and the code within those sections is hidden.
Other perceived problems with spin are the lack of structures and typedefs. Structures are not really supposed to be necessary in an OO language which is probably one reason they are not included in spin. Instead of structures an "object.variable" syntax could be added to spin and that would do away with the need for structures. This would be possible with the existing byte code but the bytecode would be a little messy and slow. Typedefs are probably not much really important if we don't have structures so then there is probably no need to add them.
There are also some problems with translating c to spin like the limits on the number of methods and constants in an object. This shouldn't be a problem for files that are written for the propeller but it could be a problem when trying to use existing code. Things like structures (proposed solution could cause naming conflicts and will require changes to spin compiler to not sort variables. Also, proposed array solution is not good because then the variables aren't going to be arranged in memory as expected), function pointers (not supported in spin), variables with preassigned values (not supported in spin unless in a dat section), and case sensitivity are also likely to cause problems.
What I suggest is that a couple of features be added to standard spin, Parallax reaches some kind of agreement with ImageCraft about ICC use in schools and uni, and bst be adopted as the 'official' prop tool (need mac support).
The features that should be added to spin are conditional compilation, object.variable syntax, a BAS block for for basic-assembly blocks to ease asm intro for beginners, multi-dimension arrays and probably a couple of things that I'm missing.
And so ends another essay on pmc...
I use the array solution for structs in cspin, and it works fine.· Look at the sample C and Spin code below.· Spin does have a problem with duplicate names because of the global nature of variable names and the case insensitivity.· I resolved this in cspin by adding a _0, _1, etc. to duplicate names.· Notice how the generated spin code uses Test_0 because of a conflict with the reserved word "test".
cspin also handles pre-assigned values without any problems.· cspin doesn't support function pointers, but they can be implemented by modifying entries in the method table.
Dave
typedef struct TestS { char x; short y; int z; } TestT; TestT struct1; void Test(void) { TestT struct2; CopyTest(&struct2); } void CopyTest(TestT *ptr) { ptr->x = struct1.x; ptr->y = struct1.y; ptr->z = struct1.z; }I'm a hobbyist and not a C programmer.
From an educational / non-C programmer POV, I can see some benefit from C>Spin - but only if you already know Spin (in which case, why would you want to learn C for the Propeller?!).
From a professional perspective, I can see why Parallax would like C on the Propeller, but I can't see that any professional would be interested in a) Spin as output, nor b) an implementation that doesn't support ANSI C.
I believe that supporting standards is the box that Parallax need to tick to gain acceptance in education and industry.
On face value, it appears obvious that Parallax should make offers to RossH (Catalina) and BradC (BST) - making Catalina and BST the official C and IDE - but we're assuming that Ross & Brad would be comfortable with this (which I really hope they would be).
C'mon Parallax - don't go it alone; you'll be quicker to market by adopting what's already there
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
I presume that this is by using the dat section or by having an init method that sets all the values?
You could do this but then it isn't safe to use in more than one core unless locks or something are used.
I haven't looked at cspin so you may have these covered.
We are developing open hardware platforms apace, which will greatly ease the task of
designing embedded kit around it.
And the software effort to give us 'console' control via CP/M is proceeding well.
For the beginner, PropBASIC is an attractive option. If only the Spin experts would
transcode more of the Obex to give it a flying start!
But there is so much to do to integrate all of the above: PMC as proposed looks like a
diversion - more fragmentation than benefit.
Regards,
T o n y
Most compilers have an option to create packed or unpacked structs.· I use the Watcom compiler, which generates unpacked structs by default.· When structs are used in binary files I think the safest thing is to design structs so that there are no holes even if the compiler is set for the unpacked mode.· This way theres no ambiguity with other applications/platforms.· Of course, there's always the little endian versus big endian issue.· I'll add packed structs to my TODO list for cspin.
Pre-assigned values are put in the DAT section if they are defined outside of a function.· Pre-assigned values defined within a function are assigned at the beginning of a function.· cspin currently does not support static variables defined within a function.
Function pointers could be made cog-safe by reserving an array of 8 dummy methods in the method table.· Each cog would use its own dedicated dummy method.
Dave
Whatever the latest pre-release version of bst is (can't remember) has the ability to do this by declaring a block VARX rather than VAR. It has the potential to cause you headaches with alignment, but it won't sort the variables for you. You either need VAR or VARX for the entire object, you can't pick and choose though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
I tried it with spin, but my spin-lines very often ends with a ';' --> error. My comments starts with // --> also wrong. "Greater than or equal" is >= --> another error...........
Maybe I am simply too stupid, but if you code all the time in C then many things come automatically (without thinking).
These problems PMC would solve and porting c-code would be much easier.
necessary preprocesser-features (in c and in assembler):
#define (also macrodefinition especially for assembler)
#undef
#ifdef and/or #if defined()
#ifndef and/or #if !defined()
#if
#elif
#else
#endif
#error
additional necessary language features:
something like this:
language features that would be nice:
struct
union
not necessary language features:
typedef
goto
continue
variable argument lists
?:
double
Standard library (putc, getc, puts, gets, sscanf, sprintf, printf, atoi, itoa, strlen, strcpy, strcmp, strncmp, malloc, free....)
in my opinion errors:
- extern means, that something is defined/initialized in another file. --> keyword extern is not necessary (without static it is "public")
- int temp[noparse][[/noparse]25], *p; p = &temp; (should be: p = &temp[noparse][[/noparse]0]; or p = temp; because temp in c is a pointer)
- unsigned, signed (datatypes should all be signed as standard, but prefix signed should be allowed)
Best thing of course would be a standard C-Compiler which compiles to pasm (not LMM) and spin-bytecode and a debugger integrated in one IDE.
This is in my opinion the only solution who could push the propeller in the professional market.
You must:
- Use one or more real ANSI C (89/99) compilers to build the Propeller executable binary (pre ANSI C89 does not qualify).
- Officially qualify and recommend one or more real ANSI C compilers which emits LMM, Spin bytecode, or other VM code.
- Use an official product name other than PMC to avoid getting sued.
Further:- Contributors and decision makers should have more familiarity with C language (Ken and others should take a class).
- You should constrain yourself on polluting the product with all those weird Spin-like operators. Allowing the "?" conditional operator would be appreciated by many.
- Library paths must be supported. The #include should be allowed for global scope items ... "class" does not provide global scope.
- The #ifdef is expected by C programmers, but the alternative #if defined(...) you suggest is workable.
- Using a real C compiler in the product adds flexibility that allows for real C programming when "students" graduate.
Finally, If you want people to more adopt Spin as a programming language, illustrating a killer application and providing a runtime environment for it on the PC would be more effective than providing a C to Spin translator (better use of scare resources, leverage current resources, easier for users to learn).▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
-Phil
Having said that, I think the upcoming Prop II has some serious commercial applications, above-and-beyond the Prop I. And so the C language could be important for that in extending its reach in that realm. And the Prop II will have enhanced educational uses as well (with even an on-board development system being considered (at least at one time), which probably lends itself more to the educational community). As such, I'm kind of curious to know how much of this C languange consideration on Parallax's part is motivated by the forthcoming chip.
Of course, it's been said many times that the Prop I will be around for a long time concurrent with the Prop II, particularly due to its low-power performance and available DIP package, not to mention Parallax's committment to long-term sourcing for its customers. But I think that the move to facilitating (not switching to) C has to be done with the Prop II in mind, because, if one is not dealing with an existing design that's fashioned around the Prop I, why would one choose the Prop I over the Prop II? Well, the aforesaid low power capability and the DIP package, as well as easier interfacing (fewer pins) and lower cost (assuming the Prop I comes in a few dollars cheaper). Sure, there's those things. But the additional memory, speed and enhanced simplicity of A/D & D/A (and even interfacing with built-in pull-up/pull-down resistors) are going to be mighty appealing to many if not most folks (dataloggers and what-not requiring low-power aside), particularly considering that solutions will be developed to provide ease-of-use for the more complex packaging (for the educational/hobbiest markets).
So, in summary, in terms of strategy, perhaps this C discussion has to be done with the slow-but-sure "transition" to the Prop II in mind. Yes, Parallax has its hands full with its current activities, true, and even with the current chip. But its likely that the development software for the Prop I will never be perfectly finished (not that this warrants not trying or abandonment), but long-range plans should include the Prop II. Also, most, if not all, of the work that would be done to implement C for use with the current chip would likely be applicable to the new chip (where embedding a new version of SPIN is a given). So, a Prop II with C (SPIN and PASM (and others)) seems quite appealing. I'm very surprised that Parallax is considering C given how tightly stretched their resources seem to be (or maybe that's just Chip's, ha-ha). As such, it makes sense that they must have the Prop II in mind. Anyway, just an attempt at a "step back" perspective. BTW, the Prop I is now nearly 4 years old from release; that's about 40 in chip years. On the other hand, "You're not getting older, Prop I, you're getting better!"
If all you want is to make more money go ahead with your plans. If you want to support and encorage the programmers of the future and not hinder them by confusing them then make a true c compiler or purchase the rights to one that already exists.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.