I hope that Spin (perhaps with a few tweaks and extensions) persists with the Prop II. Despite being difficult to categorize, it's the right tool for the Propeller.
I'll go along with that. I actually really like the language. My "main" language has always been Pascal, although I've used Python a bit and I know enough C & C++ to contribute the odd bug fix to open source software. I don't have a huge list of languages under my belt. I don't need to, but I'm not adverse to learning another language if it required. I felt immediately comfortable with Spin.
If you look at the only current alternative language (and the other alternatives being developed) they all share one thing in common. They are *significantly* larger. Nobody has been able to fit another language into a single cog with the efficiency that the Spin interpreter has. Why is that do you think? Could it be because Spin was designed from the ground up to expose all the features of the chip and therefore is not restricted by some of the limitations?
If you were to take one of the other languages.. let's pick.. oh, C for example. You would have to cripple the language to make it fit into an environment where it could use a small, simple bytecode and a single cog interpreter. Can you imagine the outcry?
Spin is incredibly elegant, compact and quite efficient. It's a very easy environment to be productive with, and it's little quirks are very easily learned.
As my Grandfather is always fond of emphasizing : "A poor workman always blames his tools."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
[color=black][b][u]Heater[/u]
[/b]As for Spin adoption vs age/experience. What's the problem? I've programmed in a lot of languages over the years, all the way back to Algol. Spin is just another one, with it's own quirks. [b]Seems to fit the task at hand very well[/b].[/color]
[color=black][b][u]Brad C[/u]
Spin is incredibly elegant, compact and quite efficient. It's a very easy environment to be productive with[/b], and it's little quirks are very easily learned.[/color]
[b][color=black]As my Grandfather is always fond of emphasizing : "A poor workman always blames his tools."[/color][/b]
[color=black][b][u]Phil[/u]
[/b]I hope that Spin (perhaps with a few tweaks and extensions) persists with the Prop II. Despite being difficult to categorize, [b]it's the right tool for the Propeller[/b].[/color]
[color=black][b][u]Potatohead[/u][/b]
[/color]
[color=black]I would describe SPIN as lean, useful, easy to learn, and well matched to the processor hardware attributes. [b]There is nothing else like SPIN + PASM[/b].[/color]
[color=black][b][u]Stefan[/u][/b]
[b]In my eyes Chip did a really great job. The architecture, SPIN-syntax, the propeller-IDE everything well developed to work effectivly[/b][/color]
[color=black][b] [/b]
[b][u]Localroger[/u][/b][/color]
[color=black][b]An original language[/b], designed to teach concepts and to be learned easily no matter what previous languages you know.[noparse][[/noparse]..]. [b]It truly is a synthesis of the strengths[/b] (in a very particular manner of evaluation) of many different approaches.[/color]
> Obviously the major problem of Spin is its very limited speed ...
That's not the problem. The design-goal was to get compact code (HUB-RAM limitation) and that was perfectly achieved. You can't have something fast and compact. Overall SPIN and PASM is a nice fit. I'm only complaining about the syntax.
In fact, most of the issues could be fixed with a pre-processor.
And re the byte, word, long:
Languages that didn't care about the processor behind it don't have a rich enough set of sizes that works good with µC. C made it wrong quite from the start and only fixed it with C99. For a language that is µC-centric, types like int8, int16, int32 and uint8 (+ char as a synonym), uint16, uint32 would be the most clear and obvious naming.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Well Jazzed I'll take Oberon(Wirth's successor to Pascal) or even TP7 as a intro to learning computer programming any day over Spin. Spin just doesn't have the HLL features to be useful and because its typeless which allows newbie coders to produce head scratching unreadable code.
I'm sure though some of the resident compiler writer gurus here could rewrite Spin and turn it into a language that generates machine code and also be useful for CompSci by including some features of C and Pascal, like type checking, bytes, 16 bit and 32 bit integers, chars etc.
As for Spin teaching about micro's, C or the micro's own assembly language would be a better fit.
Obivously I'm a proponent of Spin - wouldn't like it any other way! I think this is a result of my limited programming background. The only devices I've ever programmed are Apple II computers in BASIC, BASIC Stamps, SX chips (in SX/B) and the Propeller. No C or C++ experience and only enough Java with the Javelin Stamp to know I didn't want much to do with that particular language. Perhaps my limited experience is best in this case - I can do everything I've wanted to do with the Propeller and I don't know what friendly aspects are missing from Spin that are present in other languages.
The learning curve isn't steep for me, but a steady climb. The biggest challenge has been rethinking how to make use of multiple processors and tie them together in a useful fashion.
Going back to PBASIC, when we first started Stamps in Class we heard much criticism about BASIC not being appropriate in education. Around this time there was even a push (in California) to use Java for embedded programming (because it was being accepted for PC/web programming). PBASIC certainly made its way into schools and industry even though it is quite limited. Therefore I'm not surprised to read this kind of thread - it's a common consideration of Parallax customers going way back when. We won't tell you what to think about our languages, ever, but there's a strong belief in our office that these languages fit our processors quite nicely.
We're sticking with Imagecraft to see that we've got the C support so many people from industry seem to want.
Having a strong background in various dialects of BASIC from the last twenty years, and just enough C, and various
scripting languages to be really dangerous, Spin has been a wonderful transition into object oriented programming.
That being said, I also find myself slamming my head into the desk with the WORDS, and LONGS.
Spin is perfectly suited to the Propeller and a pleasure to write code in...
I'm not sure this is a good or bad thing: I find it flexible enough to write really awful code in, but the
Propeller is generally fast enough to cleanly execute my sloppy .spin code consistently without issue.
I've carried a lot of spaghetti code habits from my years of BASIC, and am slowly learning better methods. [noparse]:)[/noparse]
(Thank goodness Chip and company were wise enough not to include GOTO/GOSUB or I'd be really screwed!)
Ken, I've been programming since 1977 -- my first big project as a teenager was my own BASIC interpreter, written in 8080A assembly language with·only an assembling debugger (no compiler).· I've written several similar languages for embedded controllers for my own use in the years since.
I found out that the Propeller existed when Hackaday featured the Ybox2.· Within about half an hour of diving into the online docs I felt I had found home.· Spin is a perfect language for the level of development it's aimed at; probably the only thing I'd have done differently if I wrote it myself is using indentation for block framing, but I have an idea why Spin does it that way.· And I'd have put in GOTO because I'm lazy.
Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula.· How many people really know the limitations of floating point math?· Just recently Slashdot linked an article about a bug in the Patriot missile system caused by the fact that 0.1 cannot be represented exactly in binary, and they were adding 0.1 second clock ticks together until the errors amounted to more than a third of a second.· Now·I knew better than to do that when I was 16 years old, how the hell did a mistake like that end up in a production defense system that ended up costing over a dozen people their lives when it failed?
Learning to use things like polymorphism and multiple inheritance can make you a very productive coder, but before you even learn such things exist I believe you should know things like how to do binary math.· If you believe one should never optimize code, I don't want you working on my project and I want the person who taught you that fired.· If you think anyone at all should ever program a computer without knowing how the high level commands they write are converted into action by a CPU, I encourage you to find a rewarding career in car sales.
And this doesn't mean there isn't a need for more powerful languages with more advanced features.· It just means that (1) those languages aren't appropriate for a platform with 32K or even just 256K of core, and (2) you should never go near those languages until you have a firm grasp of the concepts that are necessary to write working code in simpler ones.
waltc said...
Well Jazzed I'll take Oberon(Wirth's successor to Pascal) or even TP7 as a intro to learning computer programming any day over Spin. Spin just doesn't have the HLL features to be useful and because its typeless which allows newbie coders to produce head scratching unreadable code.
I'm sure though some of the resident compiler writer gurus here could rewrite Spin and turn it into a language that generates machine code and also be useful for CompSci by including some features of C and Pascal, like type checking, bytes, 16 bit and 32 bit integers, chars etc.
Officer: "Sir, do you realize you have been driving at 100 MPH in a 35 MPH zone?"
Driver : "Yes officer....it is not my fault though...my·Ferrari does not have built into it any speed ··········· checking or limiting devices and it is just...."
Officer:"But sir what is that dial called speedometer in the middle of your dashboard for? Also ·········· I am sure your car does not have infinite speed does it?"
Driver :"Yes I could see the dial showing I·was at 100 but shouldn't a good car·limit my speed by itself? ··········· It should know when I am being a fool and stop me from doing it...no? It should also stop me from ··········· having accidents and not·go off the road when I sleep on the wheel and......·"
Officer:"Sir...perhaps you should not be driving a Ferrari...perhaps you should be driving a horse and buggy... ··········· then perhaps you would have·developed some horse sense.....here is your ticket!!!"
Post Edited (SamMishal) : 11/1/2009 7:13:01 PM GMT
@Nick:· That's exactly the point I meant with patchwork!· I'm not complaining of the ritch set of operators, but the fact that they are taken from languages that are quite orthogonal. A much clearer solution to add those extra ops would have been:· Take a route that is known (like Pascal, or C) for the common operators and add the extra ones by function-lookalikes.
There is a word for this practice of taking new and different paths that promise to let you do more with less, in this case less typing.· I think it's called "innovation."· You are saying this is a bad thing...?
> On embedded platforms in particular a word is 16 bits just as a byte is 8. On 16 bit processors? So, I'm right.
You're just arguing to hear your own voice here; you know exactly what I meant and why I made the prior comment about bytes vs. subdivisions of a word.· Today a word generically means 16 bits, and it means that on processors of any bit width.· Most platforms use "doubleword" and "quadword" for 32 and 64 bits respectively, but I happen to think "Long" is clearer.· It does take a little getting used to, and even I still sometimes type "word" when I mean "long," but the end result is much more readable particularly considering how we often mix types to save RAM.
"Object" has a quite well defined meaning in any programming-language taht is OO. And Parallax's use is an abuse of it.
Spin objects have public and private methods, the public of which are accessed by the industry sentence object.dosomething() syntax,·they hide their data, and they can have multiple instances.· These characterstics alone separate Spin from all non-OO languages (particularly as the first two·are features that limit the programmer and force him to think in a more modular way).· The fact that Spin objects don't also have classes and inheritance does not mean they're not objects, and I think Spin is a good foundation for moving to a language with a more powerful OO model.· I think starting with Spin is much better than what is commonly done nowadays, which is to teach the OO model as if it's a foundation supported by magical elves so that we have no effing idea what went wrong when it doesn't do what we expect.
So there is no need at all for a high(er) level language. Bite the PASM thing or die!
No, it's not to say more powerful tools aren't useful.· It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when they break.·
Look Nick, this isn't theoretical.· I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's.· Now this box does amazing things; the codebase is still in use on its successor instrument and it revolutionized my industry.· But until a couple of years ago it was miserably dog slow executing end-user code -- so slow I ended up hacking it and writing my own language for it, which ran 50 times faster than the one implemented by the factory.· (Originally after hacking it I wrote some apps in ASM, but that does get tired quick.· Fortunately, knowing the ASM made it possible to write my own higher level tools.)· Eventually I showed the factory what I did and they sheepishly went back and did some of that optimization you should never do.· Turns out the original author took a course in compiler design, so he wrote a parser into the interpreter that worked like a compiler parser.· Nobody had ever told him that byecode might be useful or that even interpreting plain text there are much better approaches.· For want of his school ever showing this guy a copy of the Tiny BASIC source code, we end users had to put up with this sluggish performance·for over a decade.
Another fun fact is that, when we got the beta instrument for evaluation in 1995, one of the first things we did was to hook it up to a small scale and program it to count by 0.2 lb, a common application.· Imagine our surprise to see it occasionally toss out an odd digit in the least significant place.· Turns out the brilliant guy who wrote an industry changing user interface had decided to get plenty of precision for any purpose by throwing double precision math at everything (and on a 20 MHz 16-bit box with no coprocessor this didn't help the speed any, but they thought it was a good compromise).· Too bad nobody ever got around to telling him that the double precision routines don't do their own rounding -- CPU cycles having been somewhat expensive when those libraries were written, the authors figured you'd want to wait and round at appropriate times during complex operations.· They finally got all the FP rounding issues resolved but it took almost a year.
Oh, and the firmware for this·box was·written in C++ with OO methods all the way -- I've seen the source.· You'd have loved it, except for the times it didn't work.
Javelin is substandard Java. PBASIC is better than the Smile I had to learn as a teenager on the C64.
Spin/PASM on Propeller is mostly a very nice achievement.
It took a while, but I finally concluded C is not practical on the current Propeller because of code size and performance in any form (ImageCraft, Catalina, or otherwise). Even with a byte-code like emitter/interpreter which would allow bigger programs, performance would suffer and space would still be tight. It seems promoting C more than a check-off item (or possibly at all) is a mistake except maybe to die-hard fanatics. In retrospect, I'm honestly sorry to have ever been a fan of the combination. There are many other more satisfying platforms for C in the micro-controller class. Maybe Propeller II will be a better fit, but that is just an attention keeping fantasy until it goes on sale.
Spin/PASM is your niche' ... enjoy that for what it is and promote widely it for what you think it should be.
@Waltc, I agree some HLL stuff is missing, but I'm spoiled by abundant memory and advances in the art provided by machines well beyond the micro-controller class. I would also appreciate some method signature type-checking (and other errors/warnings) for the times when I forget. When it comes down to it though, it is the student's responsibility to seek knowledge and ability beyond that afforded by "academic leveling."
I have been programming professionally since 1983, having been an EE and professional sound engineer 7 years before that.
All I have to say is: relax and enjoy whichever tools make you happy. There is plenty of room for everyone.
There are going to be many new concepts in the future of programming techniques.
Just beware of paradigm shifts without a clutch!. Stay open to new concepts, but don't hesitate to take out the garbage.
> There is a word for this practice of taking new and different paths that promise to let you do more with less, in this case less
> typing. I think it's called "innovation." You are saying this is a bad thing...?
Oh, you call that innovation!? Think about whom these weird operators that are flipped compared to other languages help:
A newbie to programming? No, because there is no background
A experienced programmer? No, because there is some background.
Look at how Obj-C made things. It requires more typing, but keeps the syntax simple an readable. Admittedly, things looks quite strange at the beginning.
> and even I still sometimes type "word" when I mean "long,"
How can this happen. When a word is always 16 bits? The problem here is, that two worlds are mixed. Byte is hardware-related, word is hardware-related, long is abstract. Stay within one context and things are clear. For µC-centric programming, types that show clearly what size they have is the way to go.
> Spin objects have public and private methods, ...
It doesn't support data-hiding. Private/public.
Also the lack of "header-files" doesn't make clear the encapsulation-principle. You have to wade through the complete source to find out what might be public or might be private.
That's an important element of objects. You *can* do OOP in any language.
What SPIN does are just codeblock, or reusable code. But then, it still lacks the headeer-thing.
> It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when
> they break.
An educational language should be very strict in all aspects. Admittedly, that's an impossible goal for µC. I do not think that C is good for teaching programming concepts. I still think, that Pascal (or Modula) is one of the best languages for starters. But again, not very well suited for µCs. So µCs arent the thing to start programming.
> I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Again, what can be done in SPIN on the Prop fits the platform quite well regarding size and speed.
> Oh, and the firmware for this box was written in C++ with OO methods all the way -- I've seen the source.
> You'd have loved it, except for the times it didn't work.
I'm not an OOP-advocate! I even think that real OOP is the wrong tool for µCs. C++ for the Prop would be completely useless (maybe the Prop II changes things). He's to small for that. But how about Occam?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Bah, header files, I hate header files. That's exactly the kind of cruft that a newbie programmer should not have to be confronted with. They just want to be able write some simple lines of code that tackle the task at hand without being distracted by that unnecessary baggage.
Unnecessary? Yes. Why should I have to always write my function signatures out twice just so that I can use a function in a different module? Was bad enough in C, where at least the header file documented what was available in whatever other module. Goes completely crazy in C++ where half the implementation ends up in the header file and the private methods/properties have to be specified there as well. One of the most regular complaints I've heard about ADA is the verbose repetition required in ADA specs and bodies.
Guess many programmers share my loathing of header files hence the popularity of auto documenting tools like DoxyGen and IDE's that spoon feed function signatures as you type. Trouble is you still have to write them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oh, you call that innovation!? Think about whom these weird operators that are flipped compared to other languages help: Actually, the process by which Spin gets its operators is pretty straightforward:
The ones that exist in BASIC are adopted straight, except for >= and <=.· The BASIC logical operators are the ones that coerce to -1, since it makes more sense to use the spelled out words like AND and NOT in IF statements.
The separate bitwise logical operators, are taken from C-like languages, since SOMETHING has to be used and this is a place they are consistently found.· This set also includes equality and inequality.
Operators not normally found in HLL's but available to the CPU are represented with various shorthand often used in CPU documentation, like >>, or those modified to provide an alternate version such as -> when necessary.
The assignment form, which does not exist in any BASIC I've ever used, is created by appending = to the operator, which creates the problem with => and =<.· I suppose he could have done that the other way e.g. =+ instead lf +=, but if it was me I would have probably put the equal after too, since I read that as "plus (with assignment)" instead of "assignment (with plus)."
The assignment character is made := to make it consistent with other assignment operators, boolean equality, and constant assignment.
If you keep this in mind, then moving to one of the languages that support a subset of Spin is pretty straightforward; I'm much more likely to trip up by leaving THEN or END IF out of a VB program after working in Spin than I am to try using +=.·
> and even I still sometimes type "word" when I mean "long,"
How can this happen.
It happens because I've gone from the "default data size" being 16 bits in most of my work to 32 bits in Spin.· I have also typed "word" instead of "dword" for FASM.· Outside the specific context of a 32-bit processor where "word" is being used in its obsolete sense as "processor fetch size" I have never seen plain "word" used to denote 32 bits.· That's "dword" or "word32."· Put your x86 assembler in 386 mode -- which is a 32 bit processor by any meaningful definition -- and try assuming 4 bytes is a word and see how well it works.
An educational language should be very strict in all aspects
NO!· NO, NO, NO, NO, NO!· 232 times I say it, THIS IS COMPLETELY WRONG.· Strictness is a crutch.· If you learn to walk on crutches you will never be able to walk without them.· This is exactly why I think Spin is a GOOD language to learn with.· It is much easier than .asm but forces you to learn many of the same concepts in order to succeed.··It does this while exposing you to concepts which will be useful in more powerful HLL's such as·those parts of object orientation that·encourage code modularity and reuse.· It is a quicker path to being ready for the higher levels, where you can let the machine take care of things without becoming helpless when the machine surprises you.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Please re-read what I wrote, because I did not say it was a bad design.· A brilliant programmer made some mistakes which he would not have made if his programming environment and his education had not abstracted away some relatively simple things he could have easily learned and should have known.· He was brilliant and remade an industry but he embarrassed his company because the people who taught him showed him classes and polymorphism when they should have been teaching him how floating point math works.
You are trying to make more people who will screw up in the same ways.· Please stop.
I'm not an OOP-advocate!
So, you're just a contrarian?· You're certainly passionate in your insistence that Spin is a piece of Smile.
heater said...
Unnecessary? Yes. Why should I have to always write my function signatures out twice just so that I can use a function in a different module? Was bad enough in C, where at least the header file documented what was available in whatever other module. Goes completely crazy in C++ where half the implementation ends up in the header file and the private methods/properties have to be specified there as well.
That's one reason I like Java/C# so much. C++ should just have all class code in the headers (AND allow simple initialized object instance data ... C++ is just weird to me). I don't mind headers in C though when we try to prevent API bugs with calls to binary libraries ... more or less required by the compiler/linker. Of course no one has tried using Spin stubs like headers yet in public code .... I've been considering that tough for allowing Spin programs bigger than 32KB.
said...
That's one reason I like Java/C# so much. C++ should just have all class code in the headers (AND allow simple initialized object instance data ... C++ is just weird to me). I don't mind headers in C though when we try to prevent API bugs with calls to binary libraries ... more or less required by the compiler/linker. Of course no one has tried using Spin stubs like headers yet in public code .... I've been considering that tough for allowing Spin programs bigger than 32KB.
Please clarify about using Spin stubs and 32kb limit.
I am pleased these things are not on Propeller. Others here have noted the low overhead nature of SPIN, but I thought I would comment a bit further on it.
It seems to me SPIN contains just enough for people to build complex things --if they are careful. The balance of necessary overhead and practical code elements that do things is well realized in that a few lines of spin is productive to a degree not found often. As somewhat of a newbie, in that I've done programming on and off my whole life. Nick highlights something I think cannot be stated often enough about Propeller in general:
"Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula. How many people really know the limitations of floating point math? "
I'm regularly experiencing stuff like this, and it only happens in those kind of raw environments where a programmer is free enough to do stuff --and free enough to really $%*&#(*$W^ it up! This is a good thing. The lack of hardware FP and even multiply puts the focus back on computing math. This also is a really good thing. (and challenging for me personally, in that way I remember as a kid figuring out the implications of binary, with friends on a chalk board because we had no-one to guide us otherwise --each thing realized was like gold, and doors opened wide each time)
On this note, before I make my last point, there are builders and selectors. The selectors are not always happy with a Propeller + SPIN + PASM. The usual checklist of goodies is not well fleshed out, meaning some creative work is required, or glue chips are required to realize a solution. On the other hand, I've noted the builder types love the thing, and how it's designed is part of why. The silicon isn't all that rigid, and it's well engineered, meaning the more grey matter applied over time, the smaller, cheaper, and more robust the solution is. I see this as the very best of properties, and it's why I'm here enjoying with the rest of you. Our skill does not matter, but the journey does. It's is both practical and possible to just take an hour and try something on a Propeller, then walk away, with little other investment required. SPIN is a big part of that.
Has anyone noted the ease with which code can be combined into a greater whole on SPIN? If it had more overhead, this task would be onerous, like it is on just about every other "re-use oriented" environment I've experienced. What I find most intriguing here is that I might not like how some other code is built, but I find I can deal with it more rapidly in SPIN, and part of dealing is understanding mind you, than I've experienced before. So, there is your balanced point regarding structure -vs- free form / language best practice, etc...
On speed:
Unlike most, I see spin as quick! Hell, it runs like assembly language on my old computers! Where I come from, that's fast. Damn fast for such a simple, readable language. When used on multiple COGs, or coupled with PASM, it's then really fast. I guess these things are relative.
Perhaps many of the speed expectations are a function of not building out PASM where it would be most useful. On that note, has anyone noted the near 1:1 relationships between SPIN and PASM? This is so sweet, in that it's possible to use SPIN to proto something up, applying techniques to be used in PASM on a second pass. Again, the overhead would spoil this, if it were more inclusive.
So there's my contribution. Maybe I'll add this:
I was away from this hobby for a long time. I left right at the dawn of the PC, moving to higher level software and networked systems, up to and including big NUMA boxes with 30GB RAM, 16CPUs, multi this disk, network and one OS image (if it was an SGI that is), etc.... Over the years, I watched micros grow, saw cool projects, and thought about returning more than once. One of the things that stopped me was libraries, header files, and other cruft that took away from just doing stuff.
One look at the Prop, SPIN, PASM, and I was back in the game, able to do things and enjoy the medium with very little overall investment up front. On Propeller, that investment can occur on the back end, if somebody wants to, and that plus the very friendly design where a few parts on a bread board does interesting things with few hassles, means the barrier to entry is the lowest I've ever seen. I am here because of that, and actually thinking of branching out someday to a few other chips to build things. Having to go the other way may well result in just not doing it, because of that barrier to entry.
So I lied! One final point:
There is nothing on Propeller, and in SPIN in particular, that prevents one from writing advanced code. The overhead elements must be built by the author of course, but they can be built, and once they are, what is the difference then? The only thing I see is a bit of management required, but there is management at that level anyway, so why not then just manage and use the thing as it is meant to be used?
(I never really grokked language battles because of this)
So then, rather than shoe-horn propeller users in to some paradigm (hate that word, but it's appropriate here), the core elements exposed to us are about as complete as they can be in SPIN, without having to go down that road. Having met Chip and having discussed this "go your own way" approach to computing, does anyone really expect anything less? Here's the noodler: Would the mind that doesn't grok this be capable of the Propeller in the first place? I personally don't think so, and that's part of the attraction, IMHO. (and a nice compliment to Chip, who is probably grinning at this thread)
Edit: To sum up, from a step back, I see the Propeller as kind of an older school, hard core statement to the effect, "See guys? It just does not have to be ugly to kick some ***!". I've laughed more than once seeing somebody declare the thing a toy, then seeing their jaw drop at that "toy" doing some of the things we do here for entertainment.
Why are you guys spitting hairs over whether SPIN is somehow elegant or clunky? What feeds into any kind of computer code is, first and foremost, our own mental processes. Are we to presume that our own human mental processes are somehow so elegant that a computer language could, at least in theory, result in program elegance of any kind??? Take a look at human language. It's full of idioms , artifacts, ambiguities galore, and it's been in development for hundreds of thousands of years. Nevermind all the unconscious neural processing that's been in the works for 3 or 4 billion years - and look how messy that can be. Alas, no computer language will ever be able to overcome our own internal disconnects. I don't have much experience with various computer languages but it seems to me that computer languages are somewhat like bureaucracies: they're full of jarring inadequacies and jolting contradictions but if you want to get something done, you've got to swallow your common sense and bite the bullet.
My turn LOL.· Peter, wow, you opened a big hornets nest here.
I have been programming since 1970 for fun - I had access to a Univac 1004 at work and used to use a small program to print out punched cards for our club sailing results. I went commercial hardware in 1974 and added programming in 1975. I have·professionally taught many·engineers·hardware maintenance and programmers programming courses on the Singer System Ten minicomputer. I have designed hardware and programmed using many micros since 1976.
As many of you will know, I studied Chip's Spin Interpreter and I had·a working version running about 20% faster before I optimised a little more and introduced a bug and got sidetracked. Chip's Interpreter is simply brilliant, although, like a lot of micros, squeezes a lot of code into the 496 cog longs and therefore makes some of it a little hard to read. I didn't have the same requirements as chip, so I was able to simplify and speedup·the code by placing the decode table in hub ram.
As for the comments about byte/word/long... A byte is 8 bits, word 16 bits, long 32 bits. Period - So get over it !· The jury is still out for 64 bits and this is not an issue here.
Now to SPIN as a language...
ADVANTAGES
Forces indentation - forces readability of code
Good set of instructions (if, repeat, etc)
Works great with PASM
Works great with multiple cogs
Largish programs
DISADVANTAGES
I don't like the operator shortcuts like ~ ~~ >| etc as they make the code less readable
Sometimes I think endif, etc would have been nice - but more typing. I still want enforced indentation.
Slow - use PASM if you require more speed
The disadvantages of 1 & 2 can be sorted with a compiler change. I can get 20% speed improvement from my version of the interpreter but I don't think this is as much an issue as it is made out to be. If you require real speed, then PASM is required.
Some of us are trying to make the prop do things it was not ever meant to do. This is natural. And it is doing this extremely well
The prop is after all, a microcontroller. It has a lot more ram than most microcontrollers. And 8 processors if fantastic.
In summary, SPIN & PASM make a great mix for the prop.
It is easy to get running, even for the novice. No complex things to understand.
Great intro for beginners - both hardware & programming
Able to use existing Objects with ease
A version of Basic to bring over the Stamp guys and gals is close
Hanno's 12-Blocks can even teach 5 year olds.
We have some great objects (FDX, keyboard, TV, VGA, SD, etc) which make using spin/prop simple.
Chip has done some amazing things here. If you don't like SPIN or PASM, use C (2 versions) or PBASIC when it's done. FemtoBasic is here, as are other languages. If you don't like any of them, go find another micro·· We can better spend our time developing, than arguing.
BTW - it was mentioned trolling through an object looking for PUBS. In the PropTool Editor, select the summary? option at the top (learn your tools)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I would describe it as a language that I really don't like, and wish I wasn't forced to learn and had been written differently, mainly with closing statements instead of indentation, and a little more intuitiveness
I have to agree that headers == bad; no headers == high productivity and rapid prototyping. If File->New included user-defined options for inserting the clock constants, I'd be happier still. (Jeff, are you reading this? )
Just to throw my 0000_0010 cents worth in - a byte was not always 8 bits. IIRC the original definition of a byte was the smallest addressible unit of storage - now almost universally 8 bits, but this standard only really developed since the advent of microprocessors. In the days of mainframes there were 6,7,8,9 and 10 & 12 bit bytes on various machines - for example, I worked on a CDC machine with 60 bit words, which consisted of 10 x 6 bit bytes. 8 bits is more correctly known as an "octet", but this term doesn't get used much outside the world of comms protocols these days.
As for SPIN as a language - like any language it does some things very well and other things badly. My biggest gripe at the moment is not with the language per se - it is that it has very few facilities to help you once your program gets beyond a couple of pages. That's the whole point about header files (in C) or package definitions vs package bodies (in Ada), or function prototypes (in various other languages). These are all mechanisms to help you cope once your code is not only too complex to fit on a screen, but perhaps also too complex to fit in any one person's head.
As for the "=>" vs ">=" debate, I always say "greater than or equal to" so that's how I expect to see it. The "=>" is standard mathematical notation for implication (a boolean operation).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
At one time or another I've used most of the programming languages around from Fortran, Cobol, Algol, APL, and Pascal to C, C++, Python, Smalltalk, and lots of others. Spin is just another one with some things borrowed from other languages and some things unique to it. It matches the hardware well and, as RossH said, it does some things very well and other things badly. On balance, it's effective and easy to use. I would not want to use it for an example of object oriented languages. Smalltalk would be much better for that, but Spin makes mostly effective use of encapsulation which is one major feature of OOPL.
RossH said...
My biggest gripe at the moment is not with the language per se - it is that it has very few facilities to help you once your program gets beyond a couple of pages. That's the whole point about header files (in C) or package definitions vs package bodies (in Ada), or function prototypes (in various other languages). These are all mechanisms to help you cope once your code is not only too complex to fit on a screen, but perhaps also too complex to fit in any one person's head.
Yes, this is useful - but it a function of one particular IDE, not a function of the SPIN language. Also, it only works for the current file, and it doesn't know about PASM functions at all. How many programmers write their entire Propeller application in SPIN (no PASM) and also have the whole program in a single file?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
header files have very limited utility. It's a neat idea, to have a place where you specify all your publicly available functions, objects, methods, constants etc. It probably worked quite well in an era when programs were smaller/simpler.
It always seemed to me to be a quick hack onto a language (C for example) to enable compiling of user apps against available binary modules/libraries without a) having to rescan the module/library so the compiler can link things properly b) having to give the user the module/library source code.
I see no reason why this doesn't go the other way around, that is I write my module then the compiler generates the header file exposing all the things I specify as public for the user.
I defy anyone to use a complicated library nowadays with only the header files as a guide. For example the Qt tool kit. You would be wading though a ton of files to find out what is available and it would take forever to figure out how to use it. Hence, as I said before, the common use nowadays of auto documenting tools and spoon feeding IDEs.
Now how come things like the DoxyGen syntax for documenting code are not properly defined as part of the language already so that the compiler can generate nice header files and documentation?
Further to criticisms of Spin. Anyone dreaming or complaining about features lacking from Spin should have a good long hard look at the Spin byte codes and the Spin interpreter.
If the feature they require ends up needing extensions to the byte codes capability then they should think how they are going to add that to the interpreter in it's 496 longs.
If the feature simply just requires more code, say for example range checking all array accesses they should ponder if it is worth the trade off in available HUB space.
If it turns out to be feature than can be implemented within those constraints by a syntax/compiler change then we have something to consider.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ross: True, a byte was not always 8 bits, but it has been accepted to be 8 bits for many years now, and ASCII has been the accepted character representation of it. Remember EBCDIC??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
I'll go along with that. I actually really like the language. My "main" language has always been Pascal, although I've used Python a bit and I know enough C & C++ to contribute the odd bug fix to open source software. I don't have a huge list of languages under my belt. I don't need to, but I'm not adverse to learning another language if it required. I felt immediately comfortable with Spin.
If you look at the only current alternative language (and the other alternatives being developed) they all share one thing in common. They are *significantly* larger. Nobody has been able to fit another language into a single cog with the efficiency that the Spin interpreter has. Why is that do you think? Could it be because Spin was designed from the ground up to expose all the features of the chip and therefore is not restricted by some of the limitations?
If you were to take one of the other languages.. let's pick.. oh, C for example. You would have to cripple the language to make it fit into an environment where it could use a small, simple bytecode and a single cog interpreter. Can you imagine the outcry?
Spin is incredibly elegant, compact and quite efficient. It's a very easy environment to be productive with, and it's little quirks are very easily learned.
As my Grandfather is always fond of emphasizing : "A poor workman always blames his tools."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
WELL SAID...............
[code]
Jo
That's not the problem. The design-goal was to get compact code (HUB-RAM limitation) and that was perfectly achieved. You can't have something fast and compact. Overall SPIN and PASM is a nice fit. I'm only complaining about the syntax.
In fact, most of the issues could be fixed with a pre-processor.
And re the byte, word, long:
Languages that didn't care about the processor behind it don't have a rich enough set of sizes that works good with µC. C made it wrong quite from the start and only fixed it with C99. For a language that is µC-centric, types like int8, int16, int32 and uint8 (+ char as a synonym), uint16, uint32 would be the most clear and obvious naming.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I'm sure though some of the resident compiler writer gurus here could rewrite Spin and turn it into a language that generates machine code and also be useful for CompSci by including some features of C and Pascal, like type checking, bytes, 16 bit and 32 bit integers, chars etc.
As for Spin teaching about micro's, C or the micro's own assembly language would be a better fit.
The learning curve isn't steep for me, but a steady climb. The biggest challenge has been rethinking how to make use of multiple processors and tie them together in a useful fashion.
Going back to PBASIC, when we first started Stamps in Class we heard much criticism about BASIC not being appropriate in education. Around this time there was even a push (in California) to use Java for embedded programming (because it was being accepted for PC/web programming). PBASIC certainly made its way into schools and industry even though it is quite limited. Therefore I'm not surprised to read this kind of thread - it's a common consideration of Parallax customers going way back when. We won't tell you what to think about our languages, ever, but there's a strong belief in our office that these languages fit our processors quite nicely.
We're sticking with Imagecraft to see that we've got the C support so many people from industry seem to want.
For me, Spin simply works!
Ken Gracey
Parallax Inc.
scripting languages to be really dangerous, Spin has been a wonderful transition into object oriented programming.
That being said, I also find myself slamming my head into the desk with the WORDS, and LONGS.
Spin is perfectly suited to the Propeller and a pleasure to write code in...
I'm not sure this is a good or bad thing: I find it flexible enough to write really awful code in, but the
Propeller is generally fast enough to cleanly execute my sloppy .spin code consistently without issue.
I've carried a lot of spaghetti code habits from my years of BASIC, and am slowly learning better methods. [noparse]:)[/noparse]
(Thank goodness Chip and company were wise enough not to include GOTO/GOSUB or I'd be really screwed!)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I found out that the Propeller existed when Hackaday featured the Ybox2.· Within about half an hour of diving into the online docs I felt I had found home.· Spin is a perfect language for the level of development it's aimed at; probably the only thing I'd have done differently if I wrote it myself is using indentation for block framing, but I have an idea why Spin does it that way.· And I'd have put in GOTO because I'm lazy.
Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula.· How many people really know the limitations of floating point math?· Just recently Slashdot linked an article about a bug in the Patriot missile system caused by the fact that 0.1 cannot be represented exactly in binary, and they were adding 0.1 second clock ticks together until the errors amounted to more than a third of a second.· Now·I knew better than to do that when I was 16 years old, how the hell did a mistake like that end up in a production defense system that ended up costing over a dozen people their lives when it failed?
Learning to use things like polymorphism and multiple inheritance can make you a very productive coder, but before you even learn such things exist I believe you should know things like how to do binary math.· If you believe one should never optimize code, I don't want you working on my project and I want the person who taught you that fired.· If you think anyone at all should ever program a computer without knowing how the high level commands they write are converted into action by a CPU, I encourage you to find a rewarding career in car sales.
And this doesn't mean there isn't a need for more powerful languages with more advanced features.· It just means that (1) those languages aren't appropriate for a platform with 32K or even just 256K of core, and (2) you should never go near those languages until you have a firm grasp of the concepts that are necessary to write working code in simpler ones.
Driver : "Yes officer....it is not my fault though...my·Ferrari does not have built into it any speed
··········· checking or limiting devices and it is just...."
Officer:"But sir what is that dial called speedometer in the middle of your dashboard for? Also
·········· I am sure your car does not have infinite speed does it?"
Driver :"Yes I could see the dial showing I·was at 100 but shouldn't a good car·limit my speed by itself?
··········· It should know when I am being a fool and stop me from doing it...no? It should also stop me from
··········· having accidents and not·go off the road when I sleep on the wheel and......·"
Officer:"Sir...perhaps you should not be driving a Ferrari...perhaps you should be driving a horse and buggy...
··········· then perhaps you would have·developed some horse sense.....here is your ticket!!!"
Post Edited (SamMishal) : 11/1/2009 7:13:01 PM GMT
There is a word for this practice of taking new and different paths that promise to let you do more with less, in this case less typing.· I think it's called "innovation."· You are saying this is a bad thing...?
> On embedded platforms in particular a word is 16 bits just as a byte is 8.
On 16 bit processors? So, I'm right.
You're just arguing to hear your own voice here; you know exactly what I meant and why I made the prior comment about bytes vs. subdivisions of a word.· Today a word generically means 16 bits, and it means that on processors of any bit width.· Most platforms use "doubleword" and "quadword" for 32 and 64 bits respectively, but I happen to think "Long" is clearer.· It does take a little getting used to, and even I still sometimes type "word" when I mean "long," but the end result is much more readable particularly considering how we often mix types to save RAM.
"Object" has a quite well defined meaning in any programming-language taht is OO. And Parallax's use is an abuse of it.
Spin objects have public and private methods, the public of which are accessed by the industry sentence object.dosomething() syntax,·they hide their data, and they can have multiple instances.· These characterstics alone separate Spin from all non-OO languages (particularly as the first two·are features that limit the programmer and force him to think in a more modular way).· The fact that Spin objects don't also have classes and inheritance does not mean they're not objects, and I think Spin is a good foundation for moving to a language with a more powerful OO model.· I think starting with Spin is much better than what is commonly done nowadays, which is to teach the OO model as if it's a foundation supported by magical elves so that we have no effing idea what went wrong when it doesn't do what we expect.
So there is no need at all for a high(er) level language. Bite the PASM thing or die!
No, it's not to say more powerful tools aren't useful.· It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when they break.·
Look Nick, this isn't theoretical.· I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's.· Now this box does amazing things; the codebase is still in use on its successor instrument and it revolutionized my industry.· But until a couple of years ago it was miserably dog slow executing end-user code -- so slow I ended up hacking it and writing my own language for it, which ran 50 times faster than the one implemented by the factory.· (Originally after hacking it I wrote some apps in ASM, but that does get tired quick.· Fortunately, knowing the ASM made it possible to write my own higher level tools.)· Eventually I showed the factory what I did and they sheepishly went back and did some of that optimization you should never do.· Turns out the original author took a course in compiler design, so he wrote a parser into the interpreter that worked like a compiler parser.· Nobody had ever told him that byecode might be useful or that even interpreting plain text there are much better approaches.· For want of his school ever showing this guy a copy of the Tiny BASIC source code, we end users had to put up with this sluggish performance·for over a decade.
Another fun fact is that, when we got the beta instrument for evaluation in 1995, one of the first things we did was to hook it up to a small scale and program it to count by 0.2 lb, a common application.· Imagine our surprise to see it occasionally toss out an odd digit in the least significant place.· Turns out the brilliant guy who wrote an industry changing user interface had decided to get plenty of precision for any purpose by throwing double precision math at everything (and on a 20 MHz 16-bit box with no coprocessor this didn't help the speed any, but they thought it was a good compromise).· Too bad nobody ever got around to telling him that the double precision routines don't do their own rounding -- CPU cycles having been somewhat expensive when those libraries were written, the authors figured you'd want to wait and round at appropriate times during complex operations.· They finally got all the FP rounding issues resolved but it took almost a year.
Oh, and the firmware for this·box was·written in C++ with OO methods all the way -- I've seen the source.· You'd have loved it, except for the times it didn't work.
That's from my old boss on a three dimensional radar project circa 1985.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Javelin is substandard Java. PBASIC is better than the Smile I had to learn as a teenager on the C64.
Spin/PASM on Propeller is mostly a very nice achievement.
It took a while, but I finally concluded C is not practical on the current Propeller because of code size and performance in any form (ImageCraft, Catalina, or otherwise). Even with a byte-code like emitter/interpreter which would allow bigger programs, performance would suffer and space would still be tight. It seems promoting C more than a check-off item (or possibly at all) is a mistake except maybe to die-hard fanatics. In retrospect, I'm honestly sorry to have ever been a fan of the combination. There are many other more satisfying platforms for C in the micro-controller class. Maybe Propeller II will be a better fit, but that is just an attention keeping fantasy until it goes on sale.
Spin/PASM is your niche' ... enjoy that for what it is and promote widely it for what you think it should be.
@Waltc, I agree some HLL stuff is missing, but I'm spoiled by abundant memory and advances in the art provided by machines well beyond the micro-controller class. I would also appreciate some method signature type-checking (and other errors/warnings) for the times when I forget. When it comes down to it though, it is the student's responsibility to seek knowledge and ability beyond that afforded by "academic leveling."
All I have to say is: relax and enjoy whichever tools make you happy. There is plenty of room for everyone.
There are going to be many new concepts in the future of programming techniques.
Just beware of paradigm shifts without a clutch!. Stay open to new concepts, but don't hesitate to take out the garbage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Why not make a C -> spin -> spin byte code compilier?
Problems fixed then, for most people at least.
I'm guessing parallax does not have the resources but maybe some other company would be interested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
> typing. I think it's called "innovation." You are saying this is a bad thing...?
Oh, you call that innovation!? Think about whom these weird operators that are flipped compared to other languages help:
A newbie to programming? No, because there is no background
A experienced programmer? No, because there is some background.
Look at how Obj-C made things. It requires more typing, but keeps the syntax simple an readable. Admittedly, things looks quite strange at the beginning.
> and even I still sometimes type "word" when I mean "long,"
How can this happen. When a word is always 16 bits? The problem here is, that two worlds are mixed. Byte is hardware-related, word is hardware-related, long is abstract. Stay within one context and things are clear. For µC-centric programming, types that show clearly what size they have is the way to go.
> Spin objects have public and private methods, ...
It doesn't support data-hiding. Private/public.
Also the lack of "header-files" doesn't make clear the encapsulation-principle. You have to wade through the complete source to find out what might be public or might be private.
That's an important element of objects. You *can* do OOP in any language.
What SPIN does are just codeblock, or reusable code. But then, it still lacks the headeer-thing.
> It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when
> they break.
An educational language should be very strict in all aspects. Admittedly, that's an impossible goal for µC. I do not think that C is good for teaching programming concepts. I still think, that Pascal (or Modula) is one of the best languages for starters. But again, not very well suited for µCs. So µCs arent the thing to start programming.
> I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Again, what can be done in SPIN on the Prop fits the platform quite well regarding size and speed.
> Oh, and the firmware for this box was written in C++ with OO methods all the way -- I've seen the source.
> You'd have loved it, except for the times it didn't work.
I'm not an OOP-advocate! I even think that real OOP is the wrong tool for µCs. C++ for the Prop would be completely useless (maybe the Prop II changes things). He's to small for that. But how about Occam?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Unnecessary? Yes. Why should I have to always write my function signatures out twice just so that I can use a function in a different module? Was bad enough in C, where at least the header file documented what was available in whatever other module. Goes completely crazy in C++ where half the implementation ends up in the header file and the private methods/properties have to be specified there as well. One of the most regular complaints I've heard about ADA is the verbose repetition required in ADA specs and bodies.
Guess many programmers share my loathing of header files hence the popularity of auto documenting tools like DoxyGen and IDE's that spoon feed function signatures as you type. Trouble is you still have to write them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually, the process by which Spin gets its operators is pretty straightforward:
- The ones that exist in BASIC are adopted straight, except for >= and <=.· The BASIC logical operators are the ones that coerce to -1, since it makes more sense to use the spelled out words like AND and NOT in IF statements.
- The separate bitwise logical operators, are taken from C-like languages, since SOMETHING has to be used and this is a place they are consistently found.· This set also includes equality and inequality.
- Operators not normally found in HLL's but available to the CPU are represented with various shorthand often used in CPU documentation, like >>, or those modified to provide an alternate version such as -> when necessary.
- The assignment form, which does not exist in any BASIC I've ever used, is created by appending = to the operator, which creates the problem with => and =<.· I suppose he could have done that the other way e.g. =+ instead lf +=, but if it was me I would have probably put the equal after too, since I read that as "plus (with assignment)" instead of "assignment (with plus)."
- The assignment character is made := to make it consistent with other assignment operators, boolean equality, and constant assignment.
If you keep this in mind, then moving to one of the languages that support a subset of Spin is pretty straightforward; I'm much more likely to trip up by leaving THEN or END IF out of a VB program after working in Spin than I am to try using +=.·> and even I still sometimes type "word" when I mean "long,"
How can this happen.
It happens because I've gone from the "default data size" being 16 bits in most of my work to 32 bits in Spin.· I have also typed "word" instead of "dword" for FASM.· Outside the specific context of a 32-bit processor where "word" is being used in its obsolete sense as "processor fetch size" I have never seen plain "word" used to denote 32 bits.· That's "dword" or "word32."· Put your x86 assembler in 386 mode -- which is a 32 bit processor by any meaningful definition -- and try assuming 4 bytes is a word and see how well it works.
An educational language should be very strict in all aspects
NO!· NO, NO, NO, NO, NO!· 232 times I say it, THIS IS COMPLETELY WRONG.· Strictness is a crutch.· If you learn to walk on crutches you will never be able to walk without them.· This is exactly why I think Spin is a GOOD language to learn with.· It is much easier than .asm but forces you to learn many of the same concepts in order to succeed.··It does this while exposing you to concepts which will be useful in more powerful HLL's such as·those parts of object orientation that·encourage code modularity and reuse.· It is a quicker path to being ready for the higher levels, where you can let the machine take care of things without becoming helpless when the machine surprises you.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Please re-read what I wrote, because I did not say it was a bad design.· A brilliant programmer made some mistakes which he would not have made if his programming environment and his education had not abstracted away some relatively simple things he could have easily learned and should have known.· He was brilliant and remade an industry but he embarrassed his company because the people who taught him showed him classes and polymorphism when they should have been teaching him how floating point math works.
You are trying to make more people who will screw up in the same ways.· Please stop.
I'm not an OOP-advocate!
So, you're just a contrarian?· You're certainly passionate in your insistence that Spin is a piece of Smile.
Please clarify about using Spin stubs and 32kb limit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
I am pleased these things are not on Propeller. Others here have noted the low overhead nature of SPIN, but I thought I would comment a bit further on it.
It seems to me SPIN contains just enough for people to build complex things --if they are careful. The balance of necessary overhead and practical code elements that do things is well realized in that a few lines of spin is productive to a degree not found often. As somewhat of a newbie, in that I've done programming on and off my whole life. Nick highlights something I think cannot be stated often enough about Propeller in general:
"Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula. How many people really know the limitations of floating point math? "
I'm regularly experiencing stuff like this, and it only happens in those kind of raw environments where a programmer is free enough to do stuff --and free enough to really $%*&#(*$W^ it up! This is a good thing. The lack of hardware FP and even multiply puts the focus back on computing math. This also is a really good thing. (and challenging for me personally, in that way I remember as a kid figuring out the implications of binary, with friends on a chalk board because we had no-one to guide us otherwise --each thing realized was like gold, and doors opened wide each time)
On this note, before I make my last point, there are builders and selectors. The selectors are not always happy with a Propeller + SPIN + PASM. The usual checklist of goodies is not well fleshed out, meaning some creative work is required, or glue chips are required to realize a solution. On the other hand, I've noted the builder types love the thing, and how it's designed is part of why. The silicon isn't all that rigid, and it's well engineered, meaning the more grey matter applied over time, the smaller, cheaper, and more robust the solution is. I see this as the very best of properties, and it's why I'm here enjoying with the rest of you. Our skill does not matter, but the journey does. It's is both practical and possible to just take an hour and try something on a Propeller, then walk away, with little other investment required. SPIN is a big part of that.
Has anyone noted the ease with which code can be combined into a greater whole on SPIN? If it had more overhead, this task would be onerous, like it is on just about every other "re-use oriented" environment I've experienced. What I find most intriguing here is that I might not like how some other code is built, but I find I can deal with it more rapidly in SPIN, and part of dealing is understanding mind you, than I've experienced before. So, there is your balanced point regarding structure -vs- free form / language best practice, etc...
On speed:
Unlike most, I see spin as quick! Hell, it runs like assembly language on my old computers! Where I come from, that's fast. Damn fast for such a simple, readable language. When used on multiple COGs, or coupled with PASM, it's then really fast. I guess these things are relative.
Perhaps many of the speed expectations are a function of not building out PASM where it would be most useful. On that note, has anyone noted the near 1:1 relationships between SPIN and PASM? This is so sweet, in that it's possible to use SPIN to proto something up, applying techniques to be used in PASM on a second pass. Again, the overhead would spoil this, if it were more inclusive.
So there's my contribution. Maybe I'll add this:
I was away from this hobby for a long time. I left right at the dawn of the PC, moving to higher level software and networked systems, up to and including big NUMA boxes with 30GB RAM, 16CPUs, multi this disk, network and one OS image (if it was an SGI that is), etc.... Over the years, I watched micros grow, saw cool projects, and thought about returning more than once. One of the things that stopped me was libraries, header files, and other cruft that took away from just doing stuff.
One look at the Prop, SPIN, PASM, and I was back in the game, able to do things and enjoy the medium with very little overall investment up front. On Propeller, that investment can occur on the back end, if somebody wants to, and that plus the very friendly design where a few parts on a bread board does interesting things with few hassles, means the barrier to entry is the lowest I've ever seen. I am here because of that, and actually thinking of branching out someday to a few other chips to build things. Having to go the other way may well result in just not doing it, because of that barrier to entry.
So I lied! One final point:
There is nothing on Propeller, and in SPIN in particular, that prevents one from writing advanced code. The overhead elements must be built by the author of course, but they can be built, and once they are, what is the difference then? The only thing I see is a bit of management required, but there is management at that level anyway, so why not then just manage and use the thing as it is meant to be used?
(I never really grokked language battles because of this)
So then, rather than shoe-horn propeller users in to some paradigm (hate that word, but it's appropriate here), the core elements exposed to us are about as complete as they can be in SPIN, without having to go down that road. Having met Chip and having discussed this "go your own way" approach to computing, does anyone really expect anything less? Here's the noodler: Would the mind that doesn't grok this be capable of the Propeller in the first place? I personally don't think so, and that's part of the attraction, IMHO. (and a nice compliment to Chip, who is probably grinning at this thread)
Edit: To sum up, from a step back, I see the Propeller as kind of an older school, hard core statement to the effect, "See guys? It just does not have to be ugly to kick some ***!". I've laughed more than once seeing somebody declare the thing a toy, then seeing their jaw drop at that "toy" doing some of the things we do here for entertainment.
Cheers all!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 11/2/2009 2:05:42 AM GMT
I have been programming since 1970 for fun - I had access to a Univac 1004 at work and used to use a small program to print out punched cards for our club sailing results. I went commercial hardware in 1974 and added programming in 1975. I have·professionally taught many·engineers·hardware maintenance and programmers programming courses on the Singer System Ten minicomputer. I have designed hardware and programmed using many micros since 1976.
As many of you will know, I studied Chip's Spin Interpreter and I had·a working version running about 20% faster before I optimised a little more and introduced a bug and got sidetracked. Chip's Interpreter is simply brilliant, although, like a lot of micros, squeezes a lot of code into the 496 cog longs and therefore makes some of it a little hard to read. I didn't have the same requirements as chip, so I was able to simplify and speedup·the code by placing the decode table in hub ram.
As for the comments about byte/word/long... A byte is 8 bits, word 16 bits, long 32 bits. Period - So get over it !· The jury is still out for 64 bits and this is not an issue here.
Now to SPIN as a language...
ADVANTAGES
DISADVANTAGES
The disadvantages of 1 & 2 can be sorted with a compiler change. I can get 20% speed improvement from my version of the interpreter but I don't think this is as much an issue as it is made out to be. If you require real speed, then PASM is required.
Some of us are trying to make the prop do things it was not ever meant to do. This is natural. And it is doing this extremely well
The prop is after all, a microcontroller. It has a lot more ram than most microcontrollers. And 8 processors if fantastic.
In summary, SPIN & PASM make a great mix for the prop.
Chip has done some amazing things here. If you don't like SPIN or PASM, use C (2 versions) or PBASIC when it's done. FemtoBasic is here, as are other languages. If you don't like any of them, go find another micro·
BTW - it was mentioned trolling through an object looking for PUBS. In the PropTool Editor, select the summary? option at the top (learn your tools)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Just to throw my 0000_0010 cents worth in - a byte was not always 8 bits. IIRC the original definition of a byte was the smallest addressible unit of storage - now almost universally 8 bits, but this standard only really developed since the advent of microprocessors. In the days of mainframes there were 6,7,8,9 and 10 & 12 bit bytes on various machines - for example, I worked on a CDC machine with 60 bit words, which consisted of 10 x 6 bit bytes. 8 bits is more correctly known as an "octet", but this term doesn't get used much outside the world of comms protocols these days.
As for SPIN as a language - like any language it does some things very well and other things badly. My biggest gripe at the moment is not with the language per se - it is that it has very few facilities to help you once your program gets beyond a couple of pages. That's the whole point about header files (in C) or package definitions vs package bodies (in Ada), or function prototypes (in various other languages). These are all mechanisms to help you cope once your code is not only too complex to fit on a screen, but perhaps also too complex to fit in any one person's head.
As for the "=>" vs ">=" debate, I always say "greater than or equal to" so that's how I expect to see it. The "=>" is standard mathematical notation for implication (a boolean operation).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, this is useful - but it a function of one particular IDE, not a function of the SPIN language. Also, it only works for the current file, and it doesn't know about PASM functions at all. How many programmers write their entire Propeller application in SPIN (no PASM) and also have the whole program in a single file?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It always seemed to me to be a quick hack onto a language (C for example) to enable compiling of user apps against available binary modules/libraries without a) having to rescan the module/library so the compiler can link things properly b) having to give the user the module/library source code.
I see no reason why this doesn't go the other way around, that is I write my module then the compiler generates the header file exposing all the things I specify as public for the user.
I defy anyone to use a complicated library nowadays with only the header files as a guide. For example the Qt tool kit. You would be wading though a ton of files to find out what is available and it would take forever to figure out how to use it. Hence, as I said before, the common use nowadays of auto documenting tools and spoon feeding IDEs.
Now how come things like the DoxyGen syntax for documenting code are not properly defined as part of the language already so that the compiler can generate nice header files and documentation?
Further to criticisms of Spin. Anyone dreaming or complaining about features lacking from Spin should have a good long hard look at the Spin byte codes and the Spin interpreter.
If the feature they require ends up needing extensions to the byte codes capability then they should think how they are going to add that to the interpreter in it's 496 longs.
If the feature simply just requires more code, say for example range checking all array accesses they should ponder if it is worth the trade off in available HUB space.
If it turns out to be feature than can be implemented within those constraints by a syntax/compiler change then we have something to consider.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm