Just for the record, Brad wrote bst which was the first non-parallax compiler to run on multiple platforms. It contains a simple Terminal, an editor, and a project zipper too.
I used it very successfully with compiling various versions of heater's ZiCog.
While it's not open source, I don't know of any bugs.
These people (Brad, etc, etc) devoted heaps of time without reward. Sometimes criticism was poorly placed and resulted in offending some.
It pays to be careful in how you word requests when its being done for free!
For the record, nobody should take my enjoyment of Spin, and preference of Propeller Tool (for the moment, anyway) as an indictment of anything else.
That goes for me, too. It all depends upon what one can be most productive with. For me, it's Spin/PASM using the Prop Tool.
-Phil
It sounds like Propeller Tool + BST are all anyone really needs for Spin programming until the day that BST no longer works on modern Windows or Linux systems.
But I'm simply saying this to direct attention back to the compactness of Spin and how easy it is to use and also understand how it compiles and runs. I groked Spin in the first hour or two and then PASM took a bit longer as some might remember. It was always a shame though that you couldn't mix PASM inline with Spin which would have been possible with LMM I guess. It was always a nuisance to have to load up a whole cog just for some simple function that would then have to communicate with the PASM cog through global variables. Nonetheless, Spin+PASM is a great combination and a tribute to Chip's insightfulness and it is a shame that Spin has been essentially shelved to focus on attracting new C people (which it hasn't really has it?).
Now if OpenSpin had a proper absolute listing I would probably use it.
Nonetheless, Spin+PASM is a great combination and a tribute to Chip's insightfulness and it is a shame that Spin has been essentially shelved to focus on attracting new C people (which it hasn't really has it?).
Only Parallax could answer that question. It's my understanding that it was difficult to sell Spin into schools because they wanted a "standard language". C fills that role but I'm not sure if that has resulted in increased sales or not. Ideally, Parallax would have continued to support Spin even after also providing support for C but I think their resources may be too limited for that. I would actually like to see some evolution of the Spin language itself to fill some of that gaps that made me want to use C in the first place. When I first started programming in Spin I missed structures immediately as well as object references. I remember having a discussion at Parallax with Chip and some others about how those features could be added to Spin but I don't think we ever came to any conclusions. Certainly no one has attempted to implement any of the ideas. Eric Smith's FastSpin might be a good way to try some of these ideas. He uses YACC or Bison for parsing Spin syntax so I imagine that it would be pretty easy to extend the syntax to support some of these new features. The trick would be doing it in a way that doesn't overly complicate Spin to the point that you might as well just use C.
Only Parallax could answer that question. It's my understanding that it was difficult to sell Spin into schools because they wanted a "standard language". C fills that role but I'm not sure if that has resulted in increased sales or not. Ideally, Parallax would have continued to support Spin even after also providing support for C but I think their resources may be too limited for that. I would actually like to see some evolution of the Spin language itself to fill some of that gaps that made me want to use C in the first place. When I first started programming in Spin I missed structures immediately as well as object references. I remember having a discussion at Parallax with Chip and some others about how those features could be added to Spin but I don't think we ever came to any conclusions. Certainly no one has attempted to implement any of the ideas. Eric Smith's FastSpin might be a good way to try some of these ideas. He uses YACC or Bison for parsing Spin syntax so I imagine that it would be pretty easy to extend the syntax to support some of these new features. The trick would be doing it in a way that doesn't overly complicate Spin to the point that you might as well just use C.
C needs to be as easy and as quick to use as Spin, and as compact too. I would think that if C compiled to Spin bytecode which is essentially a VM just like Tachyon is, then it would be compact and perhaps more compatible with existing Spin objects etc. Logically we could enhance Spin of course but the trouble with that is that it is not a "standard" language like C. But as I often remark, neither is the Propeller a standard processor either. Maybe we should all just submit to assimilation, become part of the Borg collective, and accept Arduino/Arm, speak C, and not even bother with the Propeller....
Only Parallax could answer that question. It's my understanding that it was difficult to sell Spin into schools because they wanted a "standard language". C fills that role but I'm not sure if that has resulted in increased sales or not. Ideally, Parallax would have continued to support Spin even after also providing support for C but I think their resources may be too limited for that. I would actually like to see some evolution of the Spin language itself to fill some of that gaps that made me want to use C in the first place. When I first started programming in Spin I missed structures immediately as well as object references. I remember having a discussion at Parallax with Chip and some others about how those features could be added to Spin but I don't think we ever came to any conclusions. Certainly no one has attempted to implement any of the ideas. Eric Smith's FastSpin might be a good way to try some of these ideas. He uses YACC or Bison for parsing Spin syntax so I imagine that it would be pretty easy to extend the syntax to support some of these new features. The trick would be doing it in a way that doesn't overly complicate Spin to the point that you might as well just use C.
C needs to be as easy and as quick to use as Spin, and as compact too. I would think that if C compiled to Spin bytecode which is essentially a VM just like Tachyon is, then it would be compact and perhaps more compatible with existing Spin objects etc. Logically we could enhance Spin of course but the trouble with that is that it is not a "standard" language like C. But as I often remark, neither is the Propeller a standard processor either. Maybe we should all just submit to assimilation, become part of the Borg collective, and accept Arduino/Arm, speak C, and not even bother with the Propeller....
C could be compiled to Spin bytecodes but I doubt that would make it as compact as Spin. There are many Spin bytecodes that are specifically intended to implement specific Spin language features that don't apply to C. The PropGCC CMM memory model is close to Spin bytecodes in its compactness and matches the GCC code generator better.
Logically we could enhance Spin of course but the trouble with that is that it is not a "standard" language like C. But as I often remark, neither is the Propeller a standard processor either. Maybe we should all just submit to assimilation, become part of the Borg collective, and accept Arduino/Arm, speak C, and not even bother with the Propeller....
It would be very nice if companies and programmers were open to new ideas and new ways of doing things. Many are but most seem to want to be able to apply old skills to new problems and don't want to invest the time in a radical new approach. That's a shame but according the the research that Parallax did into their customer base it seems to be a reality. If it weren't for the unique features of the Propeller most of us would not be here. The trouble is it seems we aren't a big enough market to sustain even a company as small as Parallax. Just like the x86 dominance has stunted processor evolution, so has C dominance stunted language evolution. I guess we're lucky that it isn't universally true. We now have ARM competing with x86 and languages like Python and JavaScript competing with C.
The standard Spin implementation uses a stack based interpreter, so the resulting bytecodes do look a bit like Forth. It is possible to write C code that gets compiled into Spin bytecodes by using CSPIN. It's also possible to compile Spin code into assembly using registers instead of a stack by using one of Eric's utilities, such as spin2cpp. PropGCC support a compact memory model (CMM) that generates about same code size as Spin bytecodes, and it normally runs slightly faster.
The integrated feature of Spin and PASM is that they can be compiled together in one file. They can both use the same constants, and they can both access the same DAT variables. These features are lacking in the C and ASM implementation in PropGCC. Perhaps if these features were added to PropGCC it would make it easier for programmers to use. Also, the PropGCC version of assembly is a bit harder to use that PASM. I think if PASM code could be included in C programs just like it is in Spin it would make it much more convenient for programmers. Of course, this would make the C code non-standard, which is one drawback to the idea.
Spin also has a concept of objects. So to provide the same functionality in PropGCC the programmer would actually need to use C++. C++ opens up a whole world of stuff that is way too complicated and memory hungry for the Prop. So what is needed is just some of the basic object features of C++, but not all of the other complicated stuff. Also, much of the C/C++ libraries pull in way too much stuff and use up lots of memory. So the libraries would need to be simplified as well. Much of this library simplification has already been done, but maybe it needs to be organized a bit more.
So C/C++ could be just as easy to use as Spin if it only a subset of the language was used, and PASM could be included.
The standard Spin implementation uses a stack based interpreter, so the resulting bytecodes do look a bit like Forth. It is possible to write C code that gets compiled into Spin bytecodes by using CSPIN. It's also possible to compile Spin code into assembly using registers instead of a stack by using one of Eric's utilities, such as spin2cpp. PropGCC support a compact memory model (CMM) that generates about same code size as Spin bytecodes, and it normally runs slightly faster.
The integrated feature of Spin and PASM is that they can be compiled together in one file. They can both use the same constants, and they can both access the same DAT variables. These features are lacking in the C and ASM implementation in PropGCC. Perhaps if these features were added to PropGCC it would make it easier for programmers to use. Also, the PropGCC version of assembly is a bit harder to use that PASM. I think if PASM code could be included in C programs just like it is in Spin it would make it much more convenient for programmers. Of course, this would make the C code non-standard, which is one drawback to the idea.
I'm not sure it would matter if the code that contained embedded PASM was non-standard. That code would be very specific to the Propeller anyway.
Spin also has a concept of objects. So to provide the same functionality in PropGCC the programmer would actually need to use C++. C++ opens up a whole world of stuff that is way too complicated and memory hungry for the Prop.
It is, of course, possible to use C++ without the standard C++ library. This is what PropWare does and it works very well on the Propeller. So it is the standard C++ library that is the problem not the object-oriented features of C++.
So what is needed is just some of the basic object features of C++, but not all of the other complicated stuff. Also, much of the C/C++ libraries pull in way too much stuff and use up lots of memory. So the libraries would need to be simplified as well. Much of this library simplification has already been done, but maybe it needs to be organized a bit more.
Yes, it has been done in PropWare.
So C/C++ could be just as easy to use as Spin if it only a subset of the language was used, and PASM could be included.
It would certainly be possible to write a preprocessor for C that would do something similar to what is done in Spin to allow C/C++ and PASM to be mixed in the same file. You could also deal with some of the other things people don't like about C like forward function declarations and header files. This is what the Arduino does. However, it does result in non-standard C code but there might still be an advantage to this approach since most of the core language remains the same.
C++ opens up a whole world of stuff that is way too complicated and memory hungry for the Prop. So what is needed is just some of the basic object features of C++, but not all of the other complicated stuff.
C++ code can be as compact as C. Using objects does not cause any overhead. In fact if you write C code using structs and pointers to structs then C++ using classes will compile to exactly the same binary! Which I had kept my example C and C++ code that shows that.
So C/C++ could be just as easy to use as Spin if it only a subset of the language was used, and PASM could be included.
Yes. The fact that the Arduino is programmed in C++ demonstrates that. Well, I don't know what they do for assembler mind.
@David Betz
...C dominance stunted language evolution.
On the other hand, C spawned C++. Hundreds of other language compilers and run times are written in C/C++. Like Perl, Python, Java, Javascript etc. A whole array of language styles and capabilities.
I haven't used PropWare, but it sounds like I should look into if it provides a compact library for C. It might make sense to use a pre-processor to enforce a simple subset of C/C++ and to allow for embedded PASM. The pre-processor would generate standard C++ header and source files, and also generate PropGCC assembly from the PASM code. This could be used to provide similar features that are available in Spin/PASM.
Some of the enhancements that have been proposed for Spin could be included in the C++ subset, such as types, structs and embedded floating point. These are things that are already in C/C++. The simple C++ could be made to conform to standard C++ by putting the PASM within a comment block, or using an "#ifdef __SIMPLE_C__" to hide the PASM from a standard compiler.
EDIT: Sorry for straying from the subject of this thread, but the idea of creating a C environment that includes the best features of Spin intrigues me.
On the other hand, C spawned C++. Hundreds of other language compilers and run times are written in C/C++. Like Perl, Python, Java, Javascript etc. A whole array of language styles and capabilities.
Yes that's true although some probably regret that some of the C syntax has crept into these newer languages. I hear compaints like "too many braces" that remind me of complaints about LISP having "too many parens". :-)
C has exactly the right number of braces. Which ones would people want to remove?
Arguably I would have preferred if C did not allow single line blocks with "if", "while" etc. I would forbid this:
if (a == 2)
doSomething();
And require this:
if (a == 2)
{
doSomething();
}
Which is more consistent. Less bug prone. And makes it easier to add another statement after the "if" without dicking around with braces, perhaps forgetting them and introducing a bug. See recent ssh bug.
Also I think I'm right in saying that enforcing curly braces like that means the round braces could be removed from the syntax of "if", "while" etc without breaking anything.
Lisp certainly has too many braces. Worse they are all the same!
Python does not have enough.
At least we use braces which is a lot less annoying than "begin"/"end", "if"/"fi" or whatever other nonsense.
C has exactly the right number of braces. Which ones would people want to remove?
All of them!
Seriously, though, I've taught both C and Spin for the Prop in a robotics class. Half the time in teaching C was spent dealing with the kids' mismatched braces or missing semicolons. Never had that instructional overhead with Spin.
C has exactly the right number of braces. Which ones would people want to remove?
All of them!
Seriously, though, I've taught both C and Spin for the Prop in a robotics class. Half the time in teaching C was spent dealing with the kids' mismatched braces or missing semicolons. Never had that instructional overhead with Spin.
-Phil
How much of the Spin time was spent fixing wrong indentation?
How much of the Spin time was spent fixing wrong indentation?
Not much. The advantage of forced indentation is that it's easier to visualize a program's structure than with just braces and no forced indentation. But if you're going to mandate indentation in C, as I tried to with my students, the braces are reduced to syntactic gingerbread.
Maybe that's why Chip and Guido van Rossum went with indentation. There's nothing to encourage proper indentation better than programs that won't work correctly without it!
But, that "syntactic gingerbread" is very helpful when people are using almost any editor that highlights matched brackets. Your editor/IDE and compiler can help find mistakes in code. When reading code if it's looks a bit weird in you are having trouble working out what it does, those braces tell you the authors intentions, rather than letting you wonder if the formatting has been mangled somewhere along the line.
I hope I didn't offend anybody. I was just saying the thread was going off topic, and the discussion could be continued in another new thread. It was taking away from LocalRodger's OP.
Comments
I used it very successfully with compiling various versions of heater's ZiCog.
While it's not open source, I don't know of any bugs.
These people (Brad, etc, etc) devoted heaps of time without reward. Sometimes criticism was poorly placed and resulted in offending some.
It pays to be careful in how you word requests when its being done for free!
That goes for me, too. It all depends upon what one can be most productive with. For me, it's Spin/PASM using the Prop Tool.
-Phil
But I'm simply saying this to direct attention back to the compactness of Spin and how easy it is to use and also understand how it compiles and runs. I groked Spin in the first hour or two and then PASM took a bit longer as some might remember. It was always a shame though that you couldn't mix PASM inline with Spin which would have been possible with LMM I guess. It was always a nuisance to have to load up a whole cog just for some simple function that would then have to communicate with the PASM cog through global variables. Nonetheless, Spin+PASM is a great combination and a tribute to Chip's insightfulness and it is a shame that Spin has been essentially shelved to focus on attracting new C people (which it hasn't really has it?).
Now if OpenSpin had a proper absolute listing I would probably use it.
C needs to be as easy and as quick to use as Spin, and as compact too. I would think that if C compiled to Spin bytecode which is essentially a VM just like Tachyon is, then it would be compact and perhaps more compatible with existing Spin objects etc. Logically we could enhance Spin of course but the trouble with that is that it is not a "standard" language like C. But as I often remark, neither is the Propeller a standard processor either. Maybe we should all just submit to assimilation, become part of the Borg collective, and accept Arduino/Arm, speak C, and not even bother with the Propeller....
The integrated feature of Spin and PASM is that they can be compiled together in one file. They can both use the same constants, and they can both access the same DAT variables. These features are lacking in the C and ASM implementation in PropGCC. Perhaps if these features were added to PropGCC it would make it easier for programmers to use. Also, the PropGCC version of assembly is a bit harder to use that PASM. I think if PASM code could be included in C programs just like it is in Spin it would make it much more convenient for programmers. Of course, this would make the C code non-standard, which is one drawback to the idea.
Spin also has a concept of objects. So to provide the same functionality in PropGCC the programmer would actually need to use C++. C++ opens up a whole world of stuff that is way too complicated and memory hungry for the Prop. So what is needed is just some of the basic object features of C++, but not all of the other complicated stuff. Also, much of the C/C++ libraries pull in way too much stuff and use up lots of memory. So the libraries would need to be simplified as well. Much of this library simplification has already been done, but maybe it needs to be organized a bit more.
So C/C++ could be just as easy to use as Spin if it only a subset of the language was used, and PASM could be included.
@David Betz On the other hand, C spawned C++. Hundreds of other language compilers and run times are written in C/C++. Like Perl, Python, Java, Javascript etc. A whole array of language styles and capabilities.
Some of the enhancements that have been proposed for Spin could be included in the C++ subset, such as types, structs and embedded floating point. These are things that are already in C/C++. The simple C++ could be made to conform to standard C++ by putting the PASM within a comment block, or using an "#ifdef __SIMPLE_C__" to hide the PASM from a standard compiler.
EDIT: Sorry for straying from the subject of this thread, but the idea of creating a C environment that includes the best features of Spin intrigues me.
Arguably I would have preferred if C did not allow single line blocks with "if", "while" etc. I would forbid this: And require this:
if (a == 2) { doSomething(); }Which is more consistent. Less bug prone. And makes it easier to add another statement after the "if" without dicking around with braces, perhaps forgetting them and introducing a bug. See recent ssh bug.Also I think I'm right in saying that enforcing curly braces like that means the round braces could be removed from the syntax of "if", "while" etc without breaking anything.
Lisp certainly has too many braces. Worse they are all the same!
Python does not have enough.
At least we use braces which is a lot less annoying than "begin"/"end", "if"/"fi" or whatever other nonsense.
Also English does not use white space to confer meaning so much. Barring paragraph breaks and such. Unless one is into poetry I guess.
All of them!
Seriously, though, I've taught both C and Spin for the Prop in a robotics class. Half the time in teaching C was spent dealing with the kids' mismatched braces or missing semicolons. Never had that instructional overhead with Spin.
-Phil
Maybe that's why Chip and Guido van Rossum went with indentation. There's nothing to encourage proper indentation better than programs that won't work correctly without it!
-Phil
There was talk about branching this off ever since Duane brought it back up to the top.
It would please the forum Gods to start a new thread with this interesting conversation.
Who wants to start?
.
My code mostly reads like Vogon poetry.