So Peter, what did you come up for your write up describing SPIN as a lnaguage? This thread collected a lot of opinions in a short time, and while many are conflicting, I still agree with many or most of them: SPIN is s pretty brilliant in that it is tailored to getting the most out of the prop for which it was designed, and is different from most other languages because of it, but its annoying when the things that LOOK the same in language X are actually different in SPIN. The elimination of interupts is a big deal, 8 cores and 32 bits cause many folks feel it is a memory limited workstation processor, while other feel it is a over powered micro controller. While SPIN is different, the prop itself tends to be easier to deal with than other micro controllers, and dealing with SPIN is much easier than dealling with C and its tool chain as on an AVR, etc, which can be PITA for someone unaccustomed (or lazy).
Where will your write-up appear? Is the datasheet for one of your custom modules?
Yeah, I was curuious too. My own take on was as a blend of several high level languages with similar operators to C++. Object based concepts familar to those that worked in OOP but limited in scope. Similar to Java in being a byte-code interpreted language. Easy to write like BASIC but with enough object-based concepts to ease modularity and portablilty. No type safety allows flexibilty and lots of rope to hang yourself with. The overall effect was to make it easy to step-into but sometimes the similar-but-different aspects can set a bear-trap or two and the >= / => thing is definately one of them.
The only thing I always dreaded on the Prop was the "stuck in the middle" feeling I get where a complex thing is easy to do in Spin but too slow, and PASM is way fast enough but doing something complex in PASM is a chore (for me). Sometimes another slower micro can still get the job done at the right speed and I never have to write a byte's worth of ASM code. SPIN and PASM really need to be understood together to get down to business on the Prop. I'm lacking seriously on the latter.
Languages themselves are not tokenized or untokenized. That characterization applies only to particular implementations. Spin could conceivably be compiled to x86 machine code, and C could just as well compile to Spin byte codes.
Not at all. A language is defined by its syntax, i.e. its lexical elements (e.g. if, repeat, return) and a grammar that defines legal combinations of those elements, plus its semantics (e.g. what does repeat do at an abstract level?). A particular implementation of a given language puts the semantics to work (e.g. how does repeat do what it does?). But the "how" part is not part of the language itself.
In English, for example, I could say, "Go to the store, and get me some beer." The syntax consists of the words and a grammar that allows only certain combinations of those words. The semantics reveal that I'm telling someone to transport themselves to the store, grab some beer, transport themselves back, and give the beer to me. To this point, the sentence, although in perfectly understandable English, is implementation-independent. It doesn't specify how to get to the store or whether the beer should be stolen or purchased. That's up to the agent who receives and implements the request -- the same as whether a language is compiled or interpreted is up to its implementation.
Not at all. A language is defined by its syntax, i.e. its lexical elements (e.g. if, repeat, return) and a grammar that defines legal combinations of those elements, plus its semantics (e.g. what does repeat do at an abstract level?). A particular implementation of a given language puts the semantics to work (e.g. how does repeat do what it does?). But the "how" part is not part of the language itself.
In English, for example, I could say, "Go to the store, and get me some beer." The syntax consists of the words and a grammar that allows only certain combinations of those words. The semantics reveal that I'm telling someone to transport themselves to the store, grab some beer, transport themselves back, and give the beer to me. To this point, the sentence, although in perfectly understandable English, is implementation-independent. It doesn't specify how to get to the store or whether the beer should be stolen or purchased. That's up to the agent who receives and implements the request -- the same as whether a language is compiled or interpreted is up to its implementation.
Apart from speed - and this is not always relevant because quite often the spin code is easier to do when all the time critical parts have been offloaded to other cogs running (mostly) pasm - the one thing that seems to have a common complaint is the syntax of spin.
What I would really like to see, is a basic like front-end syntax. I suggest basic because I think it is easier than C. It would not preclude a C like front-end [C like, not true C] as well. This front-end would just spit out a spin file and use the existing compilers to compile this to spin.
Why do I think this. Well, I have just been looking at the AVR, and well, I see all the complexities of just getting a led to flash (it didn't work with the included delay library routine!). What struck me when I first embarked upon the prop (BTW I was sold on the 8 cores and the instruction set before I saw PropTool) was the simple PropTool interface. It just worked with pretty much no learning. I just followed the tutorials that came with PropTool. OK, I am an experienced designer & programmer - BUT this was just SO SIMPLE.
If we could just remove a few complexities from the spin language, I think it could have some profound advantages for beginners. And I don't think what I am suggesting is all that complex.
BTW Sorry, I have not looked at the BASIC that we have on the prop. However, what I am suggesting is targetting that code to spin, not pasm/LMM. However, could this basic front-end be used as the front-end???
If we could just remove a few complexities from the spin language, I think it could have some profound advantages for beginners. And I don't think what I am suggesting is all that complex.
Could you describe what you think are the complexities of Spin? Is it the multitude of unfamiliar operators, the object syntax, the use of indenting to indicate block structure? Or is it something else? I'm not saying it isn't complex. I'm just trying to understand which of its features you'd like to simplify.
Could you describe what you think are the complexities of Spin?
Spin has many annoying things (like using indentation for scope), some just plain silly things (like using different syntax for declaring variables in VAR and DAT segments) and a few really crazy things (like using =< when it really means <= ... and then using <= to mean something else altogether!) - but the most complex things are undoubtedly the conceptual hurdles you have to get over ...
Understanding that Spin is interpreted but PASM is executed
Understanding the difference between Cog RAM and Hub RAM
Understanding why a VAR segment is different to a DAT segment
Understanding that PASM can use Cog RAM or Hub RAM but Spin can only use Hub RAM
Understanging how to launch and communicate between cogs (especially Spin cogs to PASM cogs or vice-versa)
Understanding that Spin objects are not true objects at all, but what other languages would call modules or packages
All these things seem to confuse the heck out of new users - but even worse, if they don't confuse you because Spin is your first language, then they will confuse you when you try to learn a second language!
Spin has many annoying things (like using indentation for scope)
'Hated it it at first -- seems natural now, and I quite like it.
some just plain silly things (like using different syntax for declaring variables in VAR and DAT segments)
'Never even thought about that as an annoyance somehow.
and a few really crazy things (like using =< when it really means <= ... and then using <= to mean something else altogether!)
Yeah, that's just nuts! What was Chip thinking?
Understanding that Spin is interpreted but PASM is executed.
'Not sure what the problem is with that.
Understanding the difference between Cog RAM and Hub RAM
That has nothing to do with the language but, rather, the hardware architecture.
Understanding that PASM can use Cog RAM or Hub RAM but Spin can only use Hub RAM.
Unless you're going the LMM route -- or accessing cog RAM in Spin above $1f0.
Understanging how to launch and communicate between cogs (especially Spin cogs to PASM cogs or vice-versa)
'Can be confusing to a newcomer; but, given the architecture, it's hard to imagine how to make it easier.
Understanding that Spin objects are not true objects at all, but what other languages would call modules or packages.
It's actually a little of each. I'd prefer to think of them as static objects, since there can be multiple, statically-allocated instances of them, unlike the case with simple modules.
Understanding that Spin is interpreted but PASM is executed
'Not sure what the problem is with that.
How many times have we had to field questions about why you can't call a PASM function from Spin? Or why you can't just execute a PASM instruction in the middle of a Spin function? This is the answer - but it can be conceptually difficult to grasp.
Understanding the difference between Cog RAM and Hub RAM
That has nothing to do with the language but, rather, the hardware architecture.
Perhaps, but this one seems to trip people up a lot when they first start using PASM - i.e. confusing a mov with a rdlong. Or confusing a cog address with a hub address.
I tend to regard PASM as part of the Spin language - you certainly need to know it to use the Prop effectively. But maybe you didn't mean to include PASM in your original question?
I tend to regard PASM as part of the Spin language ...
That's an interesting point of view, to be sure. I tend to think of Spin as a RAD language or a glue language for PASM. To me, the interesting stuff and heavy lifting get done in PASM with Spin as a convenient way to tie everything together or try new ideas quickly. So I guess I've never really thought of PASM as an extension -- or part -- of Spin, but something rather more separate, conjoined at the hip rather than the head. As a consequence of that, it's never occurred to me to want to embed PASM within Spin programs, for example.
... I guess I've never really thought of PASM as an extension -- or part -- of Spin, but something rather more separate, conjoined at the hip rather than the head.
I guess I tend to view it differently. To me, PASM is a necessary component of Spin. There ain't no such animal as a Spin compiler that doesn't also compile PASM (even Sphinx does!).
That is a very interesting point. Interesting enough, that I found it notable when Linus wrote his own macro-assembler to just deal with PASM. Didn't notice this until that day.
it's never occurred to me to want to embed PASM within Spin programs, for example.
I wanted to do this on the second day. When I first encountered the Propeller, I got the nature of the HUB and the COG fairly quickly, or so I thought. When it came time to inline something, as is my habit, (that I am breaking as quickly as I can) it all became clear. What I find interesting is how closely the two are related. SPIN seems a nice wrapper for PASM to me.
Re: The oddities in syntax. Yeah, I still have a cheater sheet handy and refer to it often. The worst though? The point Ross made about tripping people up on languages is totally spot on. I've been writing C again, looking to make use of larger programs, and I've got semi-colons in my SPIN code now, forgetting the colon, and mixing up all the operators! And in C, there is the colon right there where it should not be. Arrgh! So, I've two cheat sheets and I think I'm getting better at both, currently translating some VGA 8bpp graphics functions to SPIN, and compiling them in C. Happy days!
I have three cheat sheets that I refer to constantly:
1. The table of Spin operators and their precedence in the Propeller Manual is paper-clipped for quick access. I like to avoid parens whenever possible. It gives the impression that I really do know what all the precedence levels are. Plus, I'll never understand why -- or remember that -- ~> (with the musical "turn" symbol, i.e. tilde) shifts the minus sign, and -> (with the minus sign) causes rotation (i.e. turning).
The operators as Ross and others said that I think are the most difficult. I am quite happy about the forced indentation athough I do understand some dislike this. One annoyance is the varying syntax of the case statement between languages. Of course C would have to be the worst offender here - switch just doesnt make sense. Repeat is not quite the same either. I like the pub and pri - and i dislike the use of void in C. I dont really care for the braces in C to group. I prefer the endif style. Maybe that is my basic background coming through, but to be honest, basic is simpler than C.
I am quite happy about the forced indentation athough I do understand some dislike this.
I hated the idea of using indentation for block structure when I first saw it in Python and I wasn't happy about it in Spin either. However, when I started using Spin I found that I didn't really mind it at all. I don't think I'd ever design a language like that myself but I don't find it to be as much of a problem as I thought it would be. I think my main objection to it stemmed from the lack of agreement about how many spaces constitute a tab. I often try to edit C code that someone else has written with a different setting for tab spacing and the only thing that saves me is being able to do auto-formatting of the code. This isn't possible in a language that uses indentation for block structure. Anyway, I have only occasionally had that kind of problem with Spin probably because almost all Spin code is written with either the Propeller Tool or BST and both agree on tab spacing.
Indentation cuts way down on the number of characters to manage. That's the biggest gain I noted.
When working in a text editor that does not do what Prop Tool does, the indents can get confusing. I found "show spaces" in some editors to be a very nice alternative though.
I've come to really like that because it's clean. In the end, one has to look for some delimiter. Indent works the same as anything else. Just have to learn to see it.
The complex set of operators is daunting for the beginner. I remember largely ignoring them at first. One could show people a subset of SPIN, sufficient for many programs, then introduce them later as short cuts 'n tricks, or they can look them up in other programs they see, after they themselves can author and read their programs.
Them are NOT so unfamiliar as any maybe think --- Them are very familiar for people that work Verilog FPGA coding .
This is maybe little of topic --- But maybe will help many of people to understand operators in Spin/Pasm
Could you describe what you think are the complexities of Spin? Is it the multitude of unfamiliar operators, the object syntax, the use of indenting to indicate block structure? Or is it something else? I'm not saying it isn't complex. I'm just trying to understand which of its features you'd like to simplify.
Them are NOT so unfamiliar as any maybe think --- Them are very familiar for people that work Verilog FPGA coding .
This is maybe little of topic --- But maybe will help many of people to understand operators in Spin/Pasm
I hadn't considered that the operators may have come from Verilog. I've done only a small about of Verilog programming but enjoyed it very much. Your comment makes me want to go back and look at again. Thanks for point this out!
Them are very familiar for people that work Verilog FPGA coding
How many beginners would know Verilog anything? Yoiks!
As Phil said, SPIN gets you going and the tough stuff is done is PASM. Its more powerful than basic, but not so easy and doesn't aways get you all the way.
I think Spin is a nice language for beginners, but it could be even better if it had a just a few more features for error checking. Beginners often have problems with the following features:
- pointers
- => and =< versus >= and <=
- floating point values
- multiple instances of VAR variables
It would be useful if Spin had pointer and floating point attributes that could be assigned to variables. This way the compiler could determine if a program is using the variable in the wrong way and issue a warning. If would also be good to issue a warning if >= and <= were used in IF and WHILE expressions.
Multiple instances of objects is a useful feature of Spin, and it would be difficult to detect incorrect use. However, it might be possible to do this with standard objects such as FullDuplexSerial.
I hated the idea of using indentation for block structure when I first saw it in Python and I wasn't happy about it in Spin either. However, when I started using Spin I found that I didn't really mind it at all. I don't think I'd ever design a language like that myself but I don't find it to be as much of a problem as I thought it would be. I think my main objection to it stemmed from the lack of agreement about how many spaces constitute a tab. I often try to edit C code that someone else has written with a different setting for tab spacing and the only thing that saves me is being able to do auto-formatting of the code. This isn't possible in a language that uses indentation for block structure. Anyway, I have only occasionally had that kind of problem with Spin probably because almost all Spin code is written with either the Propeller Tool or BST and both agree on tab spacing.
I didn't like the blocking by indentation when I first saw it in python and don't like it any better in spin! I don't like the way a stray tab or space can change blocking and much prefer Perl style blocking.
I didn't like the blocking by indentation when I first saw it in python and don't like it any better in spin! I don't like the way a stray tab or space can change blocking and much prefer Perl style blocking.
Perl uses braces { }. To paraphrase 4x5n, I don't like the way a missing right brace can cause an error at the very end of the program and much prefer Spin style blocking.
Perl uses braces { }. To paraphrase 4x5n, I don't like the way a missing right brace can cause an error and much prefer Spin style blocking.
-Phil
Either seems to work. I prefer explicit delimiters, either braces like C or If / Else / EndIf self-delimiting syntax like most structured versions of Basic use but I don't have that much of a problem with using indenting either.
Comments
Where will your write-up appear? Is the datasheet for one of your custom modules?
The only thing I always dreaded on the Prop was the "stuck in the middle" feeling I get where a complex thing is easy to do in Spin but too slow, and PASM is way fast enough but doing something complex in PASM is a chore (for me). Sometimes another slower micro can still get the job done at the right speed and I never have to write a byte's worth of ASM code. SPIN and PASM really need to be understood together to get down to business on the Prop. I'm lacking seriously on the latter.
... Tim
-Phil
OK ... but doesn't java compile to run on a JRE? and wouldn't that be close to Spin byte codes? (from a particular point of view)
... Tim
-Phil
That's way over my head! ... would it be off topic to reply with what you mean?
... Tim
In English, for example, I could say, "Go to the store, and get me some beer." The syntax consists of the words and a grammar that allows only certain combinations of those words. The semantics reveal that I'm telling someone to transport themselves to the store, grab some beer, transport themselves back, and give the beer to me. To this point, the sentence, although in perfectly understandable English, is implementation-independent. It doesn't specify how to get to the store or whether the beer should be stolen or purchased. That's up to the agent who receives and implements the request -- the same as whether a language is compiled or interpreted is up to its implementation.
-Phil
Hey, free beer? Get some for me too!
Ross.
Apart from speed - and this is not always relevant because quite often the spin code is easier to do when all the time critical parts have been offloaded to other cogs running (mostly) pasm - the one thing that seems to have a common complaint is the syntax of spin.
What I would really like to see, is a basic like front-end syntax. I suggest basic because I think it is easier than C. It would not preclude a C like front-end [C like, not true C] as well. This front-end would just spit out a spin file and use the existing compilers to compile this to spin.
Why do I think this. Well, I have just been looking at the AVR, and well, I see all the complexities of just getting a led to flash (it didn't work with the included delay library routine!). What struck me when I first embarked upon the prop (BTW I was sold on the 8 cores and the instruction set before I saw PropTool) was the simple PropTool interface. It just worked with pretty much no learning. I just followed the tutorials that came with PropTool. OK, I am an experienced designer & programmer - BUT this was just SO SIMPLE.
If we could just remove a few complexities from the spin language, I think it could have some profound advantages for beginners. And I don't think what I am suggesting is all that complex.
BTW Sorry, I have not looked at the BASIC that we have on the prop. However, what I am suggesting is targetting that code to spin, not pasm/LMM. However, could this basic front-end be used as the front-end???
Thanks,
David
Spin has many annoying things (like using indentation for scope), some just plain silly things (like using different syntax for declaring variables in VAR and DAT segments) and a few really crazy things (like using =< when it really means <= ... and then using <= to mean something else altogether!) - but the most complex things are undoubtedly the conceptual hurdles you have to get over ...
- Understanding that Spin is interpreted but PASM is executed
- Understanding the difference between Cog RAM and Hub RAM
- Understanding why a VAR segment is different to a DAT segment
- Understanding that PASM can use Cog RAM or Hub RAM but Spin can only use Hub RAM
- Understanging how to launch and communicate between cogs (especially Spin cogs to PASM cogs or vice-versa)
- Understanding that Spin objects are not true objects at all, but what other languages would call modules or packages
All these things seem to confuse the heck out of new users - but even worse, if they don't confuse you because Spin is your first language, then they will confuse you when you try to learn a second language!Ross.
'Never even thought about that as an annoyance somehow.
Yeah, that's just nuts! What was Chip thinking?
'Not sure what the problem is with that.
That has nothing to do with the language but, rather, the hardware architecture.
Unless you're going the LMM route -- or accessing cog RAM in Spin above $1f0.
'Can be confusing to a newcomer; but, given the architecture, it's hard to imagine how to make it easier.
It's actually a little of each. I'd prefer to think of them as static objects, since there can be multiple, statically-allocated instances of them, unlike the case with simple modules.
-Phil
Perhaps, but this one seems to trip people up a lot when they first start using PASM - i.e. confusing a mov with a rdlong. Or confusing a cog address with a hub address.
I tend to regard PASM as part of the Spin language - you certainly need to know it to use the Prop effectively. But maybe you didn't mean to include PASM in your original question?
Ross.
-Phil
I guess I tend to view it differently. To me, PASM is a necessary component of Spin. There ain't no such animal as a Spin compiler that doesn't also compile PASM (even Sphinx does!).
I wanted to do this on the second day. When I first encountered the Propeller, I got the nature of the HUB and the COG fairly quickly, or so I thought. When it came time to inline something, as is my habit, (that I am breaking as quickly as I can) it all became clear. What I find interesting is how closely the two are related. SPIN seems a nice wrapper for PASM to me.
Re: The oddities in syntax. Yeah, I still have a cheater sheet handy and refer to it often. The worst though? The point Ross made about tripping people up on languages is totally spot on. I've been writing C again, looking to make use of larger programs, and I've got semi-colons in my SPIN code now, forgetting the colon, and mixing up all the operators! And in C, there is the colon right there where it should not be. Arrgh! So, I've two cheat sheets and I think I'm getting better at both, currently translating some VGA 8bpp graphics functions to SPIN, and compiling them in C. Happy days!
2. The single-page table of PASM opcodes.
3. A one-page summary of counter modes.
-Phil
ps sorry i am on a xoom and editting is poor.
When working in a text editor that does not do what Prop Tool does, the indents can get confusing. I found "show spaces" in some editors to be a very nice alternative though.
I've come to really like that because it's clean. In the end, one has to look for some delimiter. Indent works the same as anything else. Just have to learn to see it.
The complex set of operators is daunting for the beginner. I remember largely ignoring them at first. One could show people a subset of SPIN, sufficient for many programs, then introduce them later as short cuts 'n tricks, or they can look them up in other programs they see, after they themselves can author and read their programs.
Them are NOT so unfamiliar as any maybe think --- Them are very familiar for people that work Verilog FPGA coding .
This is maybe little of topic --- But maybe will help many of people to understand operators in Spin/Pasm
How many beginners would know Verilog anything? Yoiks!
As Phil said, SPIN gets you going and the tough stuff is done is PASM. Its more powerful than basic, but not so easy and doesn't aways get you all the way.
- pointers
- => and =< versus >= and <=
- floating point values
- multiple instances of VAR variables
It would be useful if Spin had pointer and floating point attributes that could be assigned to variables. This way the compiler could determine if a program is using the variable in the wrong way and issue a warning. If would also be good to issue a warning if >= and <= were used in IF and WHILE expressions.
Multiple instances of objects is a useful feature of Spin, and it would be difficult to detect incorrect use. However, it might be possible to do this with standard objects such as FullDuplexSerial.
I didn't like the blocking by indentation when I first saw it in python and don't like it any better in spin! I don't like the way a stray tab or space can change blocking and much prefer Perl style blocking.
-Phil