I prefer the term lean. Right now, SPIN is really lean, but it needs a coupla basic things. I second Heater, BTW. Get those done with the fewest changes to the language itself, keeping it lean.
There are no C programmers interested in dumbing down SPIN. They are interested in making C do what it can do well! That needs to continue, and the product of it will be a great C environment on the Propeller, and a great SPIN environment on the Propeller. That should be the goal.
I prefer the term lean. Right now, SPIN is really lean, but it needs a coupla basic things. I second Heater, BTW. Get those done with the fewest changes to the language itself, keeping it lean.
There are no C programmers interested in dumbing down SPIN. They are interested in making C do what it can do well! That needs to continue, and the product of it will be a great C environment on the Propeller, and a great SPIN environment on the Propeller. That should be the goal.
I need to tread lightly here because I feel like I'm walking into a minefield with competing factions. I have to admit that I've spent a lot of years using C for embedded control programming and not only do I think it's well suited for it but I also like it. That said other than a couple of programs for blinking LEDs I haven't used it to do any programming for the propeller! For the propeller I've stuck with spin and have gotten fond of it. I hope no one reads this as a slight on spin since it's not intended as such.
I have a number of friends that currently do embedded machine control programming of various micro-controllers and when I've mentioned the propeller to them they've all responded along the lines of "it's a nice processor but........". They then go on about it's lack of support for C/C++ and the one or two that I've looking into propgcc and it's use with the prop and they're not impressed either. The fact is that whether it's fair or not until a way to efficiently and practically write high performance C code for the prop I don't see it being used by companies for high volume products. I don't see C or perl being suitable replacements for C/C++.
I guess it all depends upon where Parallax's emphasis lies. As was apparent initially, it seemed that C was being provided as an accommodation to those who already know C, to help shepherd them into the Propeller fold. Once corralled, they could then be anointed with the blessings of Spin, and life would be good. But C has lately taken on a much larger role than mere bait for the unwashed masses. To me, that's worrisome if it indicates a change of direction for Parallax.
Spin, combined with the Propeller Tool, is rather unique in its ability to promote a very short route from concept to working app. That's one of the things that makes programming the Propeller so much fun: instant gratification. After all, gratification delayed is gratification denied. I don't see C ever providing the same fun factor as Spin. Without that, it seems to me, the Propeller will be less appealing as a hardware platform, since new users will not only have to come up to speed with unique hardware but do so with tools that aren't designed hand-in-glove to fit that hardware. And if Spin remains just an entry-level language for the Propeller, there won't be a viable alternative for those C programmers daring to step outside the C box.
I do not think that adding professional features to Spin makes it less approachable to novices. The types of changes being contemplated, after all, do not make Spin programming more complicated if the new features don't get used. But they do help to keep Spin interesting and productive as users become more comfortable with the language. In my own early experience with Spin, I thought, "Hey, this is great! Spin can do anything!" Typical novice euphoria. But once the euphoria wears off, you begin to realize that things could be better still. And that's shy Spin has to grow. It's either grow or die. I prefer the former.
The number one thing about SPIN that helps everybody is the low number of things one has to know at any one time and track at any one time to author a program.
Now, that is a good and a bad.
The good? It's possible to just get in there and write code, and understand code already written. And let's just set all the line noise operators aside, and look at SPIN that way. It's very readable, and it's clean, and it can be one file, etc...
The bad? It's not possible for people who have experience to employ that experience.
My number one fear in this is we lose the good to get rid of the bad, leaving us with some messy thing that reminds us just how cool SPIN used to be.
Building in a pre-processor?? Scary stuff, because a program could then look entirely different! And it's going to, because people do that stuff with pre-processors, and that's not bad, but I don't think that's SPIN personally. That's something else entirely.
--->and no sleight to Phil either. I'm just articulating my position on this, nothing more, and I think I'm just as bad, because I want in-line PASM put in there, LOL!! It all is very tempting, but we must temper ourselves to really constrain these things to minimum change states, so that we don't make a mess out of things, losing that nice, lean, friendly, easy, fast environment we all know is worth a lot.
Doing it outside the language means output is SPIN, and though it may be somewhat difficult to read, we end up reading SPIN in the end, which is why I seconded Heater in not altering the language any more than strictly necessary to bring some of the more advanced forms within reach, and to make it work on P2 with the potency it has on P1.
If we do anymore than that, we've got C for those purposes and the goal of making C work well needs to cover that ground for a whole lot of reasons, so let it do that.
Phil says "grow or die" Yeah, I don't disagree, but I don't think it needs to grow much at the core so much as it needs better tools surrounding it, and we are getting those tools. Some real pros jumped on the P1, pros who know C so cold it's not even funny. Know what they told me? SPIN rules. It rules, because it's fast, clean, mean.
(I know fast is a relative term, but I mean fast in that it's possible to author stuff quickly and easily, without having to know a ton of things at any one time. Simple.)
Man, if we had the memory address space worked out, common sense common library structure, pointers to objects, etc... and SPIN will have grown a ton! So let's do that, but no more than we need and see where it really gets to.
This time, SPIN isn't set in stone. There is absolutely no need to toss it all in there, because there will be time. There will be enough time. If SPIN can exploit the P2 the way it can the P1, great!! Start there. Then when we've pounded out a lot of code and something really needs to happen, we can make that thing happen and do so in the leanest way, path of least core change way possible.
....or maybe C or something else makes more sense then. Seriously.
I guess it all depends upon where Parallax's emphasis lies. As was apparent initially, it seemed that C was being provided as an accommodation to those who already know C, to help shepherd them into the Propeller fold. Once corralled, they could then be anointed with the blessings of Spin, and life would be good.
Ummmm... Was this really the goal? I've been working on PropGCC from the beginning and I don't remember that ever being mentioned.
And that's shy Spin has to grow. It's either grow or die. I prefer the former.
-Phil
That is interesting, as a Noobe, I have not been around the Prop long enough to know the history. So; When was the last time Spin grew? And what was added?
The Propeller Tool has seen some incremental improvement since its introduction more than six years ago. Spin/PASM itself has seen no change in that time that I recall. (Oh, wait, I forgot: $ was added as a DAT symbol.)
SRLM, ... The #ifdef and other preprocessing things we might consider as part of the language but the build system, Make/Ant whatever, is surely not. On the other hand Spin with it's lack of header files and OBJ sections basically does not need a Make utility...Also not part of the language ... Historically many languages have not had the things you mention. Currently many of them still don't.
It doesn't matter whether it's part of the language proper, or part of the effective scope of the language. We need those tools to make professional programs. That's the distinction that I want to make.
And in any case, the OBJ section is nowhere near a substitute for a make script. For example, what if I have a program that can be run on hardware A or hardware B, and in either case include debug or no debug? That's four distinct possibilities there, and can't be done in OBJ sections (although simulated with #IFDEF).
"Many" languages not having these features is a bit misleading. The most popular languages do, and those are definitely professional. Why shouldn't Spin have the tools too?
...C was being provided as an accommodation to those who already know C, to help shepherd them into the Propeller fold. Once corralled, they could then be anointed with the blessings of Spin, and life would be good.
I don't recall that ever being the aim of the propgcc project. It would be a lost cause anyway as there is no way you are going to entice the majority of serious C users into using another language without a very good reason. Not because Spin is not worthy and not because C is the be all and end all of languages. Portability, and familiarity are big things to give up even if the language in question, C in this case is, is not you favorite thing. The mere fact that functions can be written tested and debugged on a PC under any operating system, easily, prior to getting anywhere near the target system is of huge utility. The fact that one can take those perfected functions and use them on a variety of different computers and MCU's is a killer feature which Spin does not provide.
Please do not think that C users are totally wedded to C and will reject Spin "just because it's not C". Pretty much everyone I have ever met who develops in C or C++ is multilingual. They will use any number of other languages to get the job done effectively. In my current small project team we have C, C++, Pascal, Perl, Python, PHP, JavaScript. Many embedded designers will have used ADA or PL/M or lots of assembler, all kind of things. For thse guys Spin has no benifit to attract them.
The question of intended audience for Spin has been metioned. I think that is something to reconsider in the light of the changes in the world since the Prop and Spin was introduced.
Since that time the Arduino phenomena has spread around the world. Those hundreds of thousands of AVR users are potential Prop users. However they are also not raw begineers anymore that need enticing with an ultra simple language like Spin. They are in fact C++ users.
Then we have the recent Raspberry Pi phenomena. Those hundreds of thousands of users are also potential Prop users. However they are being introduced to programming via a plethora of languages. I know the Raspi guys are always talk of starting of novices with Python but I can see there is already a lot more going on. Young kids are learning all kind of things on the Pi. When they feel the need for more direct embedded control and a Propeller they will not need Spin.
Then we have things like the mbed where unsophisticated users can easily use C#.
Parallax has already noted that it is also educators that are clamouring for C on the Propeller, and that kind of makes sense given all of the above. Never mind the idea of wanting their students to be familiar with mainstream tools in case they end up as professional engineers.
And in any case, the OBJ section is nowhere near a substitute for a make script.
The OBJ section tells the compiler what else it has to build in order to satisfy the dependencies of the current module. In that way Spin is ahead of many other languages.
C for example does not have that. Including header files does not do that. The user has to tell the compiler what else to compile or what libraries to include. That is why we have make or other build scripts. If I remember correctly there was no Make when C was introduced, it came later to solve that and other issues.
On the other hand languages like Pascal, Ada, Python have their dependencies written into the source rather like Spin OBJ section. That means you only have to point the compiler at the main module and it will pull in the rest automatically with no help from make files or build scripts. The requirements for building are in the source itself.
Now, all of this is orthogonal to the issue of arranging to build different versions of code for different hardware platforms or other feature selection. For that We often see a preprocessor and some "idef" mechanism in one form or another. That can be a preprocessor or it can be a feature of the compiler itself. either way I think you are right and Spin should have it. After all I need it to get most of my Spin code built and that's wahy I use BST.
What new world? The Arduino and Raspberry Pi are mere reiterations of the old world, rendered cheaply, and C is not a modern language by any stretch. With the Propeller and Spin, Parallax boldly staked out new territory in the world of microcontrollers and parallel processing. But they've had to do some backfilling to attract customers from the old world, and PropGCC is the result. But, IMO, C for the Prop is just a sideshow to get people into the big top. The Main Event is still Spin and PASM -- at least it is for me and, I'm betting, the majority of Parallax's current customers. So my hope is that Parallax will not divert any more resources to C than they absolutely have to to serve its purpose as an entry ramp for current C programmers.
What new world? The Arduino and Raspberry Pi are mere reiterations of the old world, rendered cheaply, and C is not a modern language by any stretch.
I agree, can't argue with that, old tried and tested CPU architectures, old tried and test languages. However that is not what I meant by new world, see below.
With the Propeller and Spin, Parallax boldly staked out new territory in the world of microcontrollers and parallel processing.
Quite so, and we love them for it. A seriously out of the box design that the mainstream manufactures would perhaps have been too timorous to pursue at the time. Even XMOS and it's multi-core MCUs came along later.
The Main Event is still Spin and PASM -- at least it is for me and, I'm betting, the majority of Parallax's current customers. So my hope is that Parallax will not divert any more resources to C than they absolutely have to to serve its purpose as an entry ramp for current C programmers.
For me the main event is the 8 COGs providing simple parallel execution of completely indepenent threads without any inter-thread timing depenencies or messy interrupts. It's the tight connection from CPU to I/O pins and the fact that any core can use any pin. (Contrast XMOS where that is not true). It's the counters and video generation. Its the simple serial programming. It's the DIP package and simple hardware requirements. It's the regular and dead easy to use instruction set and PASM. Spin is not actually an attraction in itself, but due to the small size of the bytcode binaries and easy integration of PASM is still about the best way to program in a HLL for the Prop.
Now, about this "new world" I mentioned. No, it's not about the languages and architectres exactly. I was thinking of the new world of potential users and customers.
Back in the day if you wanted to start out in embedded systems as a young student, hobbyist or casual user one good option wwas the BASIC Stamp. Anything else would get you into the "professional" world of expensive and complex MCU's along with expensive and complex dev tools.
There was not much to choose from. For the uninitialted at the time BASIC and Parallax support were a god send. There was nothing else.
Since then, as I said, the world has become flooded with inexpensive easy to use embedded systems, the Arduino, the Raspberry Pi, the mbed and so on. There is a whole "new world" of users growing up around these things (Or grown up in the case of the Arduino). That new world of users does not need the hand holding of Spin anymore.
So I should rephrase my question "So where does that leave Spin in this new world?" to something like "So where does that leave Spin in this new market landscape?"
I can't disagree that the market landscape has become more challenging to own than when the BASIC Stamp ruled the terrain. But I'm not convinced, either, that any company can lead -- or even survive -- by following. It's fine that Parallax is embracing C to attract otherwise-entrenched Arduino fans and those newly enamored of the Raspberry Pi. But I would be gravely disappointed if that embrace came at the expense of innovation in Spin development and enhancement. To me, that represents surrender and ultimate defeat, and that's not the Parallax I've come to know -- and depend upon for my livelihood.
I think my biggest disappointment with the Propeller -- if disappointment is even the proper term -- is that virtually nothing has been done in six years to advance the capabilities of Spin and the Propeller Tool. My steadfast hope is that Roy's work, in cooperation with Chip and Jeff, will re-energize the development of Spin into a first-class language for the Propeller and that somehow, somewhere, an open-sourced IDE will materialize to match.
Secondly, what's wrong with global search-and-replace? It's drop-dead simple to change symbol names that way. I do it all the time.
Apologies in advance if I have misunderstood the scenario here, so let me first explain how I've understood it: As using existing code for some purpose, by incorporating it in one's own and, if necessary, making adjustments.
In such a scenario, doing a global search-and-replace is disastrous. Why? Because it kills any possibility to easily incorporate a newer or different version of the original, and still keep one's (other, not search-and-replace) changes. The way I do such things is to import the original into my version control system, then, if necessary, add any modifications I need. Then if some updated variant of the original code appears I can simply use 'patch' (or the version control system's equivalent directly) to apply the diff between the previous version and the later version to my copy.
But if I have done a global search-and-replace all over the original code then that diff won't apply. I will basically have to do everything all over again. Much more work. I've seen exactly this scenario countless times over the years and these days I point out to co-workers that "you will not change a single whitespace unless it's part of a real modification".
No but it has stood the test of time, is well documented and support is just a Google search away.
But, IMO, C for the Prop is just a sideshow to get people into the big top. The Main Event is still Spin and PASM -- at least it is for me and,
It would seem the main customer base for the propeller is hobbyist and educational. With that said I would assume educators would rather pursue C/C++ for real world considerations. Likewise playing with a microprocessor at the hobby level can result in a career so again a knowledge of C/C++ has real world ramifications.
I would not hire anyone whose only programming experience was with spin, like it or not C/C++ is currently the paradigm for most embedded development.
I can see a generation of Arduino/Mbed hobby programmers easily making a transition to full time employment.
So my hope is that Parallax will not divert any more resources to C
IMHO Parallax would be bat siht crazy if they follow this suggestion.
With the Propeller and Spin, Parallax boldly staked out new territory in the world of microcontrollers and parallel processing.
While I agree that the Propeller was something new in the world of microcontrollers, Spin does not really break any new ground. As Heater said, it does have one feature that makes it easier to use than C which is the OBJ section of the program that combines object instantiation with dependency information. That is a very nice feature and is a step above what C or even C++ have. However, Spin has also left out important features that have been in languages for dozens of years and without replacing them with more modern ways of doing the same thing. I'm talking about type checking, structures, passing objects by reference in particular. It isn't completely a step forward.
For me the main event is the 8 COGs providing simple parallel execution of completely indepenent threads without any inter-thread timing depenencies or messy interrupts. It's the tight connection from CPU to I/O pins and the fact that any core can use any pin. (Contrast XMOS where that is not true). It's the counters and video generation. Its the simple serial programming. It's the DIP package and simple hardware requirements. It's the regular and dead easy to use instruction set and PASM. Spin is not actually an attraction in itself, but due to the small size of the bytcode binaries and easy integration of PASM is still about the best way to program in a HLL for the Prop.
One of the problems with Spin is that the programmer has very little control over the VAR space that is used. Every reference to an object in the OBJ section produces a unique VAR space for that object. If you call an object from different objects they use different VAR spaces. For example, you can't use the standard FullDuplexSerial from different objects for console I/O because the state variables and buffers are in the VAR space. The current solution is to create a modified version of FDS that puts the variables in a DAT section instead of VAR.
One way to improve this is to add a modifier to an entry in the OBJ section so that only one instance of the VAR section is created -- possibly under the top object. Or another modifier could use a pointer passed as an argument instead of automatically allocating VAR space for the object. Maybe the syntax could look something like this.
OBJ
ser1 : "FullDuplexSerial" top
ser2 : "FullDuplexSerial" @
PUB test1(ptr)
ser1.str(string("This print uses the VAR space defined in the top object", 13))
ser2.str(ptr, string("This print uses the VAR space defined by a pointer", 13))
The "ptr" parameter would be used by the compiler to override the VBASE that is in the call frame, and would not actually be passed to the "str" method.
EDIT: There could also be SIZEOF keyword that returns the size of the VAR space for an object. This would allow you to do something like:
OBJ
ser : "FullDuplexSerial" @
obj2 : "AnotherObject"
VAR
byte fds[SIZEOF(ser)]
PUB test1
ser.start(@fds, 31, 30, 0, 115200)
ser.str(@fds, string("This is a print from test1", 13))
test2(@fds)
obj2.test1(@fds) ' Print something in another object using this instance of FullDuplexSerial
PUB test2(ptr)
ser.str(ptr, string("This is a print from test2", 13))
I guess this discussion has gotten way off track. Maybe we should all agree to disagree about the relative importance of Spin and C and just concentrate on what the thread originally set out to discuss, how Spin can be improved. All of us recognize that Spin has some features that make it useful for programming the Propeller and also that there are a few features that, if added, would make it a better language. Let's just discuss those and leave behind our arguments about which language is best. Spin is here to stay so let's try to talk about how it can be made even better than it is now.
The best way to improve Spin is to make it cross-platform. Bear with me a while.
I should be able to take a Spin program and compile and run it on my four core Intel PC. Or what about take a Spin program, compile it for and run it on my XMOS multicore MCU? Or any number of other machines. Yes we have a Prop simulator to do that but that's not the same.
"That's crazy" you say, "Your Intel box does not have the I/O pins or the timers or the video hardware, your XMOS chip is not much better off, there is no point in doing that"
I say, so what?. Spin is a language. The language as such is independent of hardware. A language cannot live on a small island, if it cannot spread it is dead.
This of course is never going to happen. There is nothing that Spin offers that is not already available on my four core Intel box or XMOS chip or whatever. To make it happen would require an enormous effort by people who have a compelling reason to undertake the task. There is no such reason.
The conclusion I draw from this is that Spin is actually at the end of the road, it has reached a dead end. It served it's purpose in making the Prop I actually usefull given the memory constraints but is a lot less of a requirement for the Prop II. Spin should be around to enable legacy Prop I code to migrate to the Prop II but that is it.
I will now go and hide in my secret concrete bunker until the storm dies down.
The best way to improve Spin is to make it cross-platform. Bear with me a while.
I should be able to take a Spin program and compile and run it on my four core Intel PC. Or what about take a Spin program, compile it for and run it on my XMOS multicore MCU? Or any number of other machines. Yes we have a Prop simulator to do that but that's not the same.
"That's crazy" you say, "Your Intel box does not have the I/O pins or the timers or the video hardware, your XMOS chip is not much better off, there is no point in doing that"
I say, so what?. Spin is a language. The language as such is independent of hardware. A language cannot live on a small island, if it cannot spread it is dead.
This of course is never going to happen. There is nothing that Spin offers that is not already available on my four core Intel box or XMOS chip or whatever. To make it happen would require an enormous effort by people who have a compelling reason to undertake the task. There is no such reason.
The conclusion I draw from this is that Spin is actually at the end of the road, it has reached a dead end. It served it's purpose in making the Prop I actually usefull given the memory constraints but is a lot less of a requirement for the Prop II. Spin should be around to enable legacy Prop I code to migrate to the Prop II but that is it.
I will now go and hide in my secret concrete bunker until the storm dies down.
Well, there is Eric's spin2cpp which I suppose would allow Spin code to run on any platform that supports C++. I'm not sure if anyone has tried running Spin on a PC or any other microcontroller though.
Here's another example of how object VAR pointers could be used. In this example I open two files in the top object using FSRW. I then call a method in another object that copies the contents of the first file to the second file. This currently cannot be done in Spin because the second object would have a different VAR space for FSRW than the top object. However, object VAR pointers would allow pointers to be passed to any other object. Note, I changed the syntax a bit so that the VAR pointer is passed between parenthesis in the same way that an object index could be specified between square brackets. I think this makes it more consistent with the current syntax. I also change the "sizeof" function to "varsize".
Here is an idea I had about how object references could be handled in Spin. Spin already supports references to primitive types like long, word, and byte. Maybe we could extend this to objects as well. For instance, if I have a variable foo that contains the address of a long, I can access that long using the syntax long[foo]. What if I could do the following:
OBJ
myfile : "fsrw"
PUB main
do_stuff_with_a_file(@myfile)
PRI do_stuff_with_a_file(file_ptr)
fsrw[file_ptr].popen ...
In other words, the object type becomes a keywoard that can be used by the <type>[<ptr>] syntax that already exists for long, word, and byte.
So my hope is that Parallax will not divert any more resources to C
IMHO Parallax would be bat siht crazy if they follow this suggestion.
It must be the political season, when pants-on-fire lying prevails by ignoring context.
This is the entire quote, "So my hope is that Parallax will not divert any more resources to C than they absolutely have to to serve its purpose as an entry ramp for current C programmers," which I stand by.
Batang, the very least you could have done was add an ellipsis at the end of your truncated quotation, but even that would have been misleading.
Really, Spin needs to be great on P2, and C needs to be great on P2. That's it.
Heater, fine observation. That also suggests that Spin really should grow in it's own way, particularly well adapted to a Propeller. This is why I want the inline PASM. Spin should be about getting stuff done in lean ways. Rapid prototype style. That might be a little under the potential of P2, but that is OK because C will exceed that scale easily, IMHO.
I agree the thread has gotten off-track. But it was necessary to have the discussion about whether Spin should be improved at all, given the parallel PropGCC development. And that, of course, naturally seques to a discussion of the relative importance of the two. Both are good and necessary topics to get into the open, IMO, and not out of place here. But back to the topic at hand.
The biggest, absolutely most important change required by Spin is a way to organize libraries into sub-categories. My preference, as I've stated before, is something like:
OBJ
sio : "IO::Serial::FullDuplexSerial"
u : "Math::umath"
Keep the subdirectory stuff relative -- not absolute -- and the notation OS-agnostic. Absolute base references are the domain of a PATH environment variable, which lists source directories in the order in which they should be searched.
I do not believe that the assignment of subdirectory names should be a free-for-all, either, except in one's personal libraries. Whoever is in charge of the OBEX should also be in charge of maintaining order in the creation of sub-library names and categories.
I agree the thread has gotten off-track. But it was necessary to have the discussion about whether Spin should be improved at all, given the parallel PropGCC development. And that, of course, naturally seques to a discussion of the relative importance of the two. Both are good and necessary topics to get into the open, IMO, and not out of place here. But back to the topic at hand.
The biggest, absolutely most important change required by Spin is a way to organize libraries into sub-categories. My preference, as I've stated before, is something like:
OBJ
sio : "IO::Serial::FullDuplexSerial"
u : "Math::umath"
Keep the subdirectory stuff relative -- not absolute -- and the notation OS-agnostic. Absolute base references are the domain of a PATH environment variable, which lists source directories in the order in which they should be searched.
I do not believe that the assignment of subdirectory names should be a free-for-all, either, except in one's personal libraries. Whoever is in charge of the OBEX should also be in charge of maintaining order in the creation of sub-library names and categories.
-Phil
This sounds like an excellent idea. Would you also have a way to provide alternate base directories for searching for objects? What I'm trying to get at is that I may use the same object in several projects but I want to have only a single copy to avoid duplication of code and things getting out of sync if I update one copy but forget to update the others. Could I have some way of saying "look in /foo/bar/gag" for any libraries you can't find in the current directory? Also, having a directory of Parallax-supplied objects that would automatically be searched would be helpful as well.
Comments
I prefer the term lean. Right now, SPIN is really lean, but it needs a coupla basic things. I second Heater, BTW. Get those done with the fewest changes to the language itself, keeping it lean.
There are no C programmers interested in dumbing down SPIN. They are interested in making C do what it can do well! That needs to continue, and the product of it will be a great C environment on the Propeller, and a great SPIN environment on the Propeller. That should be the goal.
I need to tread lightly here because I feel like I'm walking into a minefield with competing factions. I have to admit that I've spent a lot of years using C for embedded control programming and not only do I think it's well suited for it but I also like it. That said other than a couple of programs for blinking LEDs I haven't used it to do any programming for the propeller! For the propeller I've stuck with spin and have gotten fond of it. I hope no one reads this as a slight on spin since it's not intended as such.
I have a number of friends that currently do embedded machine control programming of various micro-controllers and when I've mentioned the propeller to them they've all responded along the lines of "it's a nice processor but........". They then go on about it's lack of support for C/C++ and the one or two that I've looking into propgcc and it's use with the prop and they're not impressed either. The fact is that whether it's fair or not until a way to efficiently and practically write high performance C code for the prop I don't see it being used by companies for high volume products. I don't see C or perl being suitable replacements for C/C++.
Spin, combined with the Propeller Tool, is rather unique in its ability to promote a very short route from concept to working app. That's one of the things that makes programming the Propeller so much fun: instant gratification. After all, gratification delayed is gratification denied. I don't see C ever providing the same fun factor as Spin. Without that, it seems to me, the Propeller will be less appealing as a hardware platform, since new users will not only have to come up to speed with unique hardware but do so with tools that aren't designed hand-in-glove to fit that hardware. And if Spin remains just an entry-level language for the Propeller, there won't be a viable alternative for those C programmers daring to step outside the C box.
I do not think that adding professional features to Spin makes it less approachable to novices. The types of changes being contemplated, after all, do not make Spin programming more complicated if the new features don't get used. But they do help to keep Spin interesting and productive as users become more comfortable with the language. In my own early experience with Spin, I thought, "Hey, this is great! Spin can do anything!" Typical novice euphoria. But once the euphoria wears off, you begin to realize that things could be better still. And that's shy Spin has to grow. It's either grow or die. I prefer the former.
-Phil
Now, that is a good and a bad.
The good? It's possible to just get in there and write code, and understand code already written. And let's just set all the line noise operators aside, and look at SPIN that way. It's very readable, and it's clean, and it can be one file, etc...
The bad? It's not possible for people who have experience to employ that experience.
My number one fear in this is we lose the good to get rid of the bad, leaving us with some messy thing that reminds us just how cool SPIN used to be.
Building in a pre-processor?? Scary stuff, because a program could then look entirely different! And it's going to, because people do that stuff with pre-processors, and that's not bad, but I don't think that's SPIN personally. That's something else entirely.
--->and no sleight to Phil either. I'm just articulating my position on this, nothing more, and I think I'm just as bad, because I want in-line PASM put in there, LOL!! It all is very tempting, but we must temper ourselves to really constrain these things to minimum change states, so that we don't make a mess out of things, losing that nice, lean, friendly, easy, fast environment we all know is worth a lot.
Doing it outside the language means output is SPIN, and though it may be somewhat difficult to read, we end up reading SPIN in the end, which is why I seconded Heater in not altering the language any more than strictly necessary to bring some of the more advanced forms within reach, and to make it work on P2 with the potency it has on P1.
If we do anymore than that, we've got C for those purposes and the goal of making C work well needs to cover that ground for a whole lot of reasons, so let it do that.
Phil says "grow or die" Yeah, I don't disagree, but I don't think it needs to grow much at the core so much as it needs better tools surrounding it, and we are getting those tools. Some real pros jumped on the P1, pros who know C so cold it's not even funny. Know what they told me? SPIN rules. It rules, because it's fast, clean, mean.
(I know fast is a relative term, but I mean fast in that it's possible to author stuff quickly and easily, without having to know a ton of things at any one time. Simple.)
Man, if we had the memory address space worked out, common sense common library structure, pointers to objects, etc... and SPIN will have grown a ton! So let's do that, but no more than we need and see where it really gets to.
This time, SPIN isn't set in stone. There is absolutely no need to toss it all in there, because there will be time. There will be enough time. If SPIN can exploit the P2 the way it can the P1, great!! Start there. Then when we've pounded out a lot of code and something really needs to happen, we can make that thing happen and do so in the leanest way, path of least core change way possible.
....or maybe C or something else makes more sense then. Seriously.
That is interesting, as a Noobe, I have not been around the Prop long enough to know the history. So; When was the last time Spin grew? And what was added?
Eldon
-Phil
It doesn't matter whether it's part of the language proper, or part of the effective scope of the language. We need those tools to make professional programs. That's the distinction that I want to make.
And in any case, the OBJ section is nowhere near a substitute for a make script. For example, what if I have a program that can be run on hardware A or hardware B, and in either case include debug or no debug? That's four distinct possibilities there, and can't be done in OBJ sections (although simulated with #IFDEF).
"Many" languages not having these features is a bit misleading. The most popular languages do, and those are definitely professional. Why shouldn't Spin have the tools too?
I don't recall that ever being the aim of the propgcc project. It would be a lost cause anyway as there is no way you are going to entice the majority of serious C users into using another language without a very good reason. Not because Spin is not worthy and not because C is the be all and end all of languages. Portability, and familiarity are big things to give up even if the language in question, C in this case is, is not you favorite thing. The mere fact that functions can be written tested and debugged on a PC under any operating system, easily, prior to getting anywhere near the target system is of huge utility. The fact that one can take those perfected functions and use them on a variety of different computers and MCU's is a killer feature which Spin does not provide.
Please do not think that C users are totally wedded to C and will reject Spin "just because it's not C". Pretty much everyone I have ever met who develops in C or C++ is multilingual. They will use any number of other languages to get the job done effectively. In my current small project team we have C, C++, Pascal, Perl, Python, PHP, JavaScript. Many embedded designers will have used ADA or PL/M or lots of assembler, all kind of things. For thse guys Spin has no benifit to attract them.
The question of intended audience for Spin has been metioned. I think that is something to reconsider in the light of the changes in the world since the Prop and Spin was introduced.
Since that time the Arduino phenomena has spread around the world. Those hundreds of thousands of AVR users are potential Prop users. However they are also not raw begineers anymore that need enticing with an ultra simple language like Spin. They are in fact C++ users.
Then we have the recent Raspberry Pi phenomena. Those hundreds of thousands of users are also potential Prop users. However they are being introduced to programming via a plethora of languages. I know the Raspi guys are always talk of starting of novices with Python but I can see there is already a lot more going on. Young kids are learning all kind of things on the Pi. When they feel the need for more direct embedded control and a Propeller they will not need Spin.
Then we have things like the mbed where unsophisticated users can easily use C#.
Parallax has already noted that it is also educators that are clamouring for C on the Propeller, and that kind of makes sense given all of the above. Never mind the idea of wanting their students to be familiar with mainstream tools in case they end up as professional engineers.
So where does that leave Spin in this new world?
The OBJ section tells the compiler what else it has to build in order to satisfy the dependencies of the current module. In that way Spin is ahead of many other languages.
C for example does not have that. Including header files does not do that. The user has to tell the compiler what else to compile or what libraries to include. That is why we have make or other build scripts. If I remember correctly there was no Make when C was introduced, it came later to solve that and other issues.
On the other hand languages like Pascal, Ada, Python have their dependencies written into the source rather like Spin OBJ section. That means you only have to point the compiler at the main module and it will pull in the rest automatically with no help from make files or build scripts. The requirements for building are in the source itself.
Now, all of this is orthogonal to the issue of arranging to build different versions of code for different hardware platforms or other feature selection. For that We often see a preprocessor and some "idef" mechanism in one form or another. That can be a preprocessor or it can be a feature of the compiler itself. either way I think you are right and Spin should have it. After all I need it to get most of my Spin code built and that's wahy I use BST.
-Phil
Now, about this "new world" I mentioned. No, it's not about the languages and architectres exactly. I was thinking of the new world of potential users and customers.
Back in the day if you wanted to start out in embedded systems as a young student, hobbyist or casual user one good option wwas the BASIC Stamp. Anything else would get you into the "professional" world of expensive and complex MCU's along with expensive and complex dev tools.
There was not much to choose from. For the uninitialted at the time BASIC and Parallax support were a god send. There was nothing else.
Since then, as I said, the world has become flooded with inexpensive easy to use embedded systems, the Arduino, the Raspberry Pi, the mbed and so on. There is a whole "new world" of users growing up around these things (Or grown up in the case of the Arduino). That new world of users does not need the hand holding of Spin anymore.
So I should rephrase my question "So where does that leave Spin in this new world?" to something like "So where does that leave Spin in this new market landscape?"
I can't disagree that the market landscape has become more challenging to own than when the BASIC Stamp ruled the terrain. But I'm not convinced, either, that any company can lead -- or even survive -- by following. It's fine that Parallax is embracing C to attract otherwise-entrenched Arduino fans and those newly enamored of the Raspberry Pi. But I would be gravely disappointed if that embrace came at the expense of innovation in Spin development and enhancement. To me, that represents surrender and ultimate defeat, and that's not the Parallax I've come to know -- and depend upon for my livelihood.
I think my biggest disappointment with the Propeller -- if disappointment is even the proper term -- is that virtually nothing has been done in six years to advance the capabilities of Spin and the Propeller Tool. My steadfast hope is that Roy's work, in cooperation with Chip and Jeff, will re-energize the development of Spin into a first-class language for the Propeller and that somehow, somewhere, an open-sourced IDE will materialize to match.
-Phil
In such a scenario, doing a global search-and-replace is disastrous. Why? Because it kills any possibility to easily incorporate a newer or different version of the original, and still keep one's (other, not search-and-replace) changes. The way I do such things is to import the original into my version control system, then, if necessary, add any modifications I need. Then if some updated variant of the original code appears I can simply use 'patch' (or the version control system's equivalent directly) to apply the diff between the previous version and the later version to my copy.
But if I have done a global search-and-replace all over the original code then that diff won't apply. I will basically have to do everything all over again. Much more work. I've seen exactly this scenario countless times over the years and these days I point out to co-workers that "you will not change a single whitespace unless it's part of a real modification".
-Tor
No but it has stood the test of time, is well documented and support is just a Google search away.
It would seem the main customer base for the propeller is hobbyist and educational. With that said I would assume educators would rather pursue C/C++ for real world considerations. Likewise playing with a microprocessor at the hobby level can result in a career so again a knowledge of C/C++ has real world ramifications.
I would not hire anyone whose only programming experience was with spin, like it or not C/C++ is currently the paradigm for most embedded development.
I can see a generation of Arduino/Mbed hobby programmers easily making a transition to full time employment.
IMHO Parallax would be bat siht crazy if they follow this suggestion.
Cheers
One way to improve this is to add a modifier to an entry in the OBJ section so that only one instance of the VAR section is created -- possibly under the top object. Or another modifier could use a pointer passed as an argument instead of automatically allocating VAR space for the object. Maybe the syntax could look something like this.
OBJ ser1 : "FullDuplexSerial" top ser2 : "FullDuplexSerial" @ PUB test1(ptr) ser1.str(string("This print uses the VAR space defined in the top object", 13)) ser2.str(ptr, string("This print uses the VAR space defined by a pointer", 13))The "ptr" parameter would be used by the compiler to override the VBASE that is in the call frame, and would not actually be passed to the "str" method.EDIT: There could also be SIZEOF keyword that returns the size of the VAR space for an object. This would allow you to do something like:
OBJ ser : "FullDuplexSerial" @ obj2 : "AnotherObject" VAR byte fds[SIZEOF(ser)] PUB test1 ser.start(@fds, 31, 30, 0, 115200) ser.str(@fds, string("This is a print from test1", 13)) test2(@fds) obj2.test1(@fds) ' Print something in another object using this instance of FullDuplexSerial PUB test2(ptr) ser.str(ptr, string("This is a print from test2", 13))Edit: I have no specific improvements myself - I will let you guys figure that out.
I should be able to take a Spin program and compile and run it on my four core Intel PC. Or what about take a Spin program, compile it for and run it on my XMOS multicore MCU? Or any number of other machines. Yes we have a Prop simulator to do that but that's not the same.
"That's crazy" you say, "Your Intel box does not have the I/O pins or the timers or the video hardware, your XMOS chip is not much better off, there is no point in doing that"
I say, so what?. Spin is a language. The language as such is independent of hardware. A language cannot live on a small island, if it cannot spread it is dead.
This of course is never going to happen. There is nothing that Spin offers that is not already available on my four core Intel box or XMOS chip or whatever. To make it happen would require an enormous effort by people who have a compelling reason to undertake the task. There is no such reason.
The conclusion I draw from this is that Spin is actually at the end of the road, it has reached a dead end. It served it's purpose in making the Prop I actually usefull given the memory constraints but is a lot less of a requirement for the Prop II. Spin should be around to enable legacy Prop I code to migrate to the Prop II but that is it.
I will now go and hide in my secret concrete bunker until the storm dies down.
It makes religious and political discussion look tame!!
Well, there is Eric's spin2cpp which I suppose would allow Spin code to run on any platform that supports C++. I'm not sure if anyone has tried running Spin on a PC or any other microcontroller though.
obj fsrw : "fsrw" @ obj2 : "AnotherObject" dat file1 byte varsize(fsrw) file2 byte varsize(fsrw) pub main fsrw.mount(1) fsrw(@file1).popen(string("temp1.txt"), "r") fsrw(@file2).popen(string("temp2.txt"), "w") obj2.CopyFile(@file1, @file2)In other words, the object type becomes a keywoard that can be used by the <type>[<ptr>] syntax that already exists for long, word, and byte.
This is the entire quote, "So my hope is that Parallax will not divert any more resources to C than they absolutely have to to serve its purpose as an entry ramp for current C programmers," which I stand by.
Batang, the very least you could have done was add an ellipsis at the end of your truncated quotation, but even that would have been misleading.
-Phil
Really, Spin needs to be great on P2, and C needs to be great on P2. That's it.
Heater, fine observation. That also suggests that Spin really should grow in it's own way, particularly well adapted to a Propeller. This is why I want the inline PASM. Spin should be about getting stuff done in lean ways. Rapid prototype style. That might be a little under the potential of P2, but that is OK because C will exceed that scale easily, IMHO.
The biggest, absolutely most important change required by Spin is a way to organize libraries into sub-categories. My preference, as I've stated before, is something like:
Keep the subdirectory stuff relative -- not absolute -- and the notation OS-agnostic. Absolute base references are the domain of a PATH environment variable, which lists source directories in the order in which they should be searched.
I do not believe that the assignment of subdirectory names should be a free-for-all, either, except in one's personal libraries. Whoever is in charge of the OBEX should also be in charge of maintaining order in the creation of sub-library names and categories.
-Phil
This sounds like an excellent idea. Would you also have a way to provide alternate base directories for searching for objects? What I'm trying to get at is that I may use the same object in several projects but I want to have only a single copy to avoid duplication of code and things getting out of sync if I update one copy but forget to update the others. Could I have some way of saying "look in /foo/bar/gag" for any libraries you can't find in the current directory? Also, having a directory of Parallax-supplied objects that would automatically be searched would be helpful as well.