Spin Annoyances and Possible Compiler Help?

Martin_H · 2011-05-30 16:20

Spin isn't hard to learn, but I think it would be greatly improved with a lint like feature for the compiler. I say this because while debugging a Spin module I found a number of mistakes that could have been avoided with typing or a lint feature. Here are some of the gotchas I ran into:

* Spin does not appear to sign extend shorts when they are passed as parameters, nor does it give any warnings this is likely to produce a bug.

* Array access to variables which are not arrays works, doesn't get a warning, and who knows what it does. For example:

VAR
  long foo;

PUB main | idx, outval
  repeat idx from 0 to 3
    outval := foo[idx]
    pst.str(STRING("outval ="))
    pst.Dec(outval)  
    pst.NewLine

* Integer math operations can be invoked on floating point constants and are sure to return incorrect results. In some cases they are obvious, but in other cases are more subtle because I thought the compiler would generate a compile time constant.

PUB main | incr, index
  incr := 180 - pi  ' Just plain wrong 
  index : = pi/8.0  ' I need to debug this further, but I think FLOAT(pi/8.0) fixes it.

* Operators are a major head ache. Examples "=>" verus ">=" and || for absolute value. I think there's no fixing this.

Phil Pilgrim (PhiPi) · 2011-05-30 16:59

* Spin does not appear to sign extend shorts when they are passed as parameters, nor does it give any warnings this is likely to produce a bug.

There's no sign to extend in non-longs. Non-longs are always positive.

-Phil

Martin_H · 2011-05-30 18:12

Phil, by non-longs being unsigned do you mean the comparison operators treat them as unsigned? Because I'm pretty sure I've used two's compliment arithmetic on shorts and bytes. I don't think I did any comparisons, and only got into trouble when I passed them to another function. I converted all variables to longs at that point.

Phil Pilgrim (PhiPi) · 2011-05-30 18:27

Martin_H wrote:

Phil, by non-longs being unsigned do you mean the comparison operators treat them as unsigned? Because I'm pretty sure I've used two's compliment arithmetic on shorts and bytes.

Comparisons on bytes and words can only be unsigned, because bytes and words can only be positive -- unless explicitly sign-extended, viz:

if ((byte1 << 24 ~> 24) < (byte2 << 24 ~> 24))

-Phil

Ariba · 2011-05-30 20:55

... or simpler:

if ~byte1 < ~byte2

I think you can also use these sign-extension operators in methode parameters:

methodeCall(~byteVar,~~wordVar)

Array access to variables which are not arrays works, doesn't get a warning, and who knows what it does

It accesses the longs behind foo in the memory. If you define more long variables they are in the defined order in memory. If no more variables are definded then the stack follows behind foo.

Integer math operations can be invoked on floating point constants and are sure to return incorrect results

Yes, there is no float type (also not for constants) and anyway no type checking in Spin. If you work with Floats you need to know what you do. Or in other words: Spin gives you the freedom to do what you want.

Operators are a major head ache. Examples "=>" verus ">=" and || for absolute value. I think there's no fixing this

You can define your own methodes for these operators:

pub absolute(val)
  return ||val

 ...
 x := absolute(y)

Andy

Dave Hein · 2011-05-31 05:39

The Spin language doesn't have a way to declare a variable type, which makes it impossible for the compiler to do type-checking. Type-checking is very useful in other languages to catch problems with passing an int to a routine that expects a pointer or mixing signed and unsigned variables in an expression. These are common mistakes that are done by novices and experienced Spin programmers. It would be nice to add types to the Spin language to resolve these issues, and also provide an integrated floating point support. The type keywords could be made optional so that the current syntax would work, or programmer could take advantage of the type keywords for enhanced operation.

Martin_H · 2011-05-31 06:14

Andy, defining functions to clarify Spin syntax can help. But I'm using || operator in the most commonly used function in my code, so I'd prefer to avoid the additional call frame over heard. So I'll add another item to my Spin should be fixed list.

* Spin needs a macro feature to allow you define in line operators and functions. This can be done entirely in the compiler and be backwards compatible to earlier Spin programs and propeller chips.

Such a feature would also allow the definition of a signed and unsigned byte and short comparison operators which return bool inline. This way I could avoid forgetting the sign extension operator when working with bytes or shorts. Macros would also be useful in PASM.

I learned Spin so I could use Obex code and understand samples. But ultimately I may be happier if I switch to Catalina, as I'd avoid the need to port code to Spin, but bite off having to port code from Spin to C. It's hard to know which is the path of least resistance.

Dave Hein · 2011-05-31 09:11

Martin,

You could use cspin.

This way you can write code in C and interoperate with the Spin code in the OBEX. cspin does have known deficiencies, which are listed in it's readme file. However, it does implement most of the features of Spin plus structures and formatted I/O. You can declare "short" variables and the ~~ operator will automatically be used to do sign extension. Or you can declare unsigned short variables, which are identical to a Spin word. The default for "char" is to be unsigned so that it is more efficient in Spin. However, you can declare "signed char" variables as well.

Dave

Martin_H · 2011-05-31 10:12

Dave, I thought about cspin, but I'm a little concerned about complexity in my tool chain. I guess I'll take a look. If a Spin to C translator existed I might consider just jumping ship to Catalina right away.

Dave Hein · 2011-06-01 06:06

Martin, if you are more comfortable programming in C I would suggest that you use Catalina. C is a more complete language than Spin, and it provides more features and functionality than Spin. Catalina C runs much faster than Spin -- I think it's at least four times faster, but it may be even more than that. The only drawback to C is that it's not as compact as Spin. A large Spin program that fits in the Prop's 32K RAM will not fit if written in C. I think C takes around 2 to 3 times the memory that Spin uses.

I would suggest that you try cspin if you want to mix C and Spin code. At the very least, cspin can be used as a learning tool where you can compare the C and Spin source to see how things are written in each language.

Dr_Acula · 2011-06-01 06:23

But ultimately I may be happier if I switch to Catalina

Come over to Catalina *grin*.

I resisted for 2 years. Mainly because so much Obex code did not exist in C. But then I took the hard road and translated Obex code in to portable "cogject" code that can be loaded by either Spin or C. That solved some basics like a variety of video drivers, plus the ability to load and reload cogs many times from within code.

The catch with Catalina - you really need a board with an external ram, especially if you devote most of the propeller ram to a video buffer.

The upside is that the internet becomes your Obex, and there are vast libraries of C code.

localroger · 2011-06-01 09:00

The Spin expression evaluator is designed to be fast, compact, internally consistent, and educational. It is far more thoroughly thought out in all of these regards than the math evaluators for most languages, and that's what makes it so annoyingly different.

For example, how often have you done this in Basic? --> myval = myval + 1

That manages to waste typing, object code RAM, and CPU time all at the same time. Of course both C and Spin give you a better alternative: --> myval++

Super! But what's the C equivalent of this? --> myval += 4

OOPS, C doesn't have a way to do that. In fairness a good compiler will optimize to that, but you still have to type myval twice. And Spin is absolutely, ruthlessly consistent about this usage; every operator, including boolean and comparison operators, can be made into an assignment this way. And that's why you have to use =< instead of <=. Once you get used to it it makes better sense than the alternatives.

Speaking of which, back in Basic, how often have you inadvertently had what you thought was an assignment myvar = 3 turn into a Boolean comparison returning 0 or -1? C solves this too, by using == for comparison. But with Spin letting you turn any two-argument operator into an assignment, what is the meaning of a single =? For clarity, Spin doesn't go there; explicit variable assignment is := which can be thought of more as : being "Hi I'm a variable not doing anything special" with the appended = to "turn it into" an assignment.

So why oddities like // for MOD and || for ABS? Because the parser would split them if you tried to turn them into assignments with the appended =. It's terser and more powerful the Spin way.

Finally, all Spin math is PASM math, which is to say native 32-bit assembly math for any similar machine. Spin exists to teach as well as to implement functions, and to use it properly you have to learn how the computer really handles numbers. So Spin provides ~ and ~~ so you don't have to go through the shift gymnastics in Phil's example to prepare signed bytes and words for math, but you do have to be aware of the different types of math. Which means you are probably more aware of their limitations. Which is a good thing.

Dave Hein · 2011-06-01 09:27

Actually C does allow for myval += 4. Even better, if myval was declared as a long pointer (long *myval) then myval++ would automatically increment myval by 4 so that it points to the next long. It's true that C does not implement assignment operators that compare an integer value to another integer value, and then assign the logical result to the first integer value. To be honest, I rarely use an operation like that in my years of programming.

Spin is essentially a subset of C that uses long, usigned short and unsigned char variables. Spin doesn't contain structs, but uses VAR "objects" to do a similar thing. Spin is supposed to be easier to learn for novices than C. One of the main reasons is that it doesn't have data types. However the lack of data types and type-checking is precisely what causes novices and experienced programmers the most trouble.

Phil's example of how to handle signed words and bytes in Spin is not necessary in C. C has both signed short and signed char data types to handle that.

Martin_H · 2011-06-01 10:36

It's my understanding that the Basic Stamp is the micro-controller for new programmers, while the Propeller is targeted for more experienced users. So Spin being a teaching language seems like not the best idea. Experienced programmers are used to the concept of data types and warnings from a compiler. So additions like warnings and data types wouldn't be out of line for user expectations.

C has plenty of rough edges, so I won't hold it up as the perfect language*, nor is my intent to start a Spin versus C debate. I was hoping to point out that Spin has some rough edges that could likely be fixed by beefing up the compiler while keeping the interpreter and byte code fixed. Since the Propeller chip doesn't have a debugger, the earlier you catch errors the happier everyone will be. So to beat a dead horse:

It's hard to see array access to variables not of the array type (due to a storage allocation typo) is allowed or even useful. The compiler should block this.

In the constant section "aConstant = pi / 10" works, but in the program section "aVariable = pi / 10" yields a syntax error. So the syntax is inconstant, but adding the colon still doesn't work because the expression is not a constant. So it appears that an integer division operator is used at run time to generate the quotient. Again the compiler knows pi and 10.0 are floating point constants and should issue a warning. An optimizing compiler would figure out this was a constant floating point expression and do the work at compile time.

The sign extension syntax could likely be dropped from the language with the addition of signed/unsigned integer data types. So you would simplify the language syntax and prevent classes of bugs.

* The C language syntax was designed before modern optimizing compilers. C's language elements were designed to map directly onto machine instructions allowing programmers to tune code. Warp forward a few decades and we've found that programs often live longer than hardware, and code tuned for one platform isn't for a later one. But optimizing compilers solve this problem. So I doubt if C was invented today it's syntax would be as terse. The positive thing about C's syntax is that because C influenced many other languages, most people know it. So languages which piggy back on C syntax have a faster learning curve.

localroger · 2011-06-01 11:08

Dave Hein: Actually C does allow for myval += 4

Thanks for the correction. Makes sense considering how C was designed, but I missed that in the quick intros the few times I had to use the language.

Martin_H: t's my understanding that the Basic Stamp is the micro-controller for new programmers, while the Propeller is targeted for more experienced users.

I had the impression more that Parallax considers the Basic Stamp is the uC of the past, and the Propeller the uC of the future. While they have obviously committed to supporting their legacy products I suspect the whole point of developing their own CPU was to eventually use it for everything.

The question of whether and how to enforce data types has been going on roughly since the invention of FORTRAN. The pro typing argument is obvious enough; it would be simple enough to have the PropTool detect type mismatches, automatically insert the sign-extending codes when necessary, and throw an error if you confuse an array with a singleton. But the anti-typing argument is that there are other problems typing doesn't catch, like array and string bounds checking which must be done at runtime, often at noticeable cost in speed and memory usage, and at least sometimes the strategic decision to eschew such checking would make sense. The more work the compiler does for you the less practice you will get keeping track of such things yourself.

Phil Pilgrim (PhiPi) · 2011-06-01 11:17

Martin_H wrote:

It's hard to see array access to variables not of the array type (due to a storage allocation typo) is allowed or even useful. The compiler should block this.

Actually, this "feature" gets used to great advantage when communicating Spin method parameters to PASM code, via a generic "command" method. I would not want to see it go away. Of course, the "correct" way to do this is to alias an array to a list of discrete variables. But this is not something I would ever expect to see in Spin.

-Phil

Martin_H · 2011-06-01 11:54

localroger, I'm in the perfect is the enemy of the good camp. So some degree of compile time type validation which doesn't introduce a run time burden, nor require any changes to the propeller chip's Spin interpreter is better than nothing. Besides, the strong typing versus weak typing debate ended. Computer science has moved on to the dynamic typing versus static typing debate.

Phil, OK leave the feature, introduce a warning with an annotation that silences the warning.

I know I'm sounding like a broken record. But there's some concern on this forum that the Propeller chip has barriers to adoption. A thorny syntax and no lint feature might be one of them.

localroger · 2011-06-01 18:49

Martin_H: I'm in the perfect is the enemy of the good camp

Well, I'm not really in the enemy of anything camp; I see your point, and was just trying to suggest that there are legitimate reasons for why Spin looks the way it does. It's obviously possible to disagree with those reasons, and one response to that might be to lobby Brad of BST to put those features in his Spin compiler, just as he already excises unused code blocks. Education is a huge part of Parallax's business though, and I can see why they would tack to the side of forcing you to learn a bit in order to make it work. That is of course also why Spin parses indentation. Have you ever seen a botch job of pretend indentation by a real n00b in another language? In Spin you either make it look right or it doesn't work. I have experienced all of the mentioned annoyances of Spin for myself, but at the same time I understand that it is trying to teach me better habits. That might not be the best marketing approach for the semiconductor wing of the company in the future, but I also got from UPEW that Prop 2 might be a bit more versatile in the boot mech / interpreter department for rolling your own solutions.

Martin_H · 2011-06-02 05:13

localroger, the syntactically meaningful white space doesn't bother me as I indent anyway. Plus I've seen some unreadable PBasic code in these forums. Suggesting these points to Brad is a good idea. It would be a feather in his cap if BST was a better Spin compiler than the Spin compiler. That drive is how JVM languages like Groovy got started.

BradC · 2011-06-02 07:49

Thanks for your E-mail Martin, you were right in that I had not seen this thread.

On the point of bst compared to the Parallax compiler, it already does code folding, operator optimisation, unused code removal and a few little speed tweaks, and it does it twice as fast as the original compiler and on far more platforms. Not only that, but with the optimisations disabled it produces identical binary output for over 6000 files in my test suite.

It's mostly a question of motivation. I've put a lot of time and effort into bst (it calculates out in engineering hours as more than I paid for my house). In return I've received a number of personal e-mail assaults, witnessed massive amounts of pontification and hot air surrounding the tools and how much better other peoples tools would be (if they ever stopped to write them), numerous support issues by people who just don't read the damn documentation (the little of it there is) and been accused of "holding the community to ransom" with closed source code. Now, I know bst has bugs (lots of them in fact), but the fact it works for me and does what I need it to do has sadly become all I need from it.

I've tried to spend time away from the forum and re-set my expectations, but unfortunately I find when I return here I see the same irritants that sent me away in the first place, and so I just log out again. It's a shame, but I don't take criticism as well as perhaps I might, and I do take things very personally.

On the other hand, I've just invested in some more hardware to test bst on, and at some point in the not to distant future I have some bugs I'd like to iron out, but at the moment I'm quite happy bashing away on my own projects isolated from the "community" here in the forum.

I have taken your E-mail and added its contents to my long term todo list, but as I know Roy is porting the Parallax compiler to C for public release I suspect you'll get a chance to add your features before I will.

I very rarely check the forum, but I am mostly contactable by E-mail

Heater. · 2011-06-02 09:00

BradC,

That is one very sad and depressing picture you have painted there about the feedback you have received regarding BST.

I have to say I'm taken aback, even shocked, that any of that should happen.

I have been using BST since it first appeared and have always though that it is a wonderful thing. At the time, as a Linux user I was hard pressed to used the Propeller. BST was what it took to enable my use of the Propeller on any large scale.

It is clear that a lot of time, skill and effort has been put into BST by yourself. It's a great accomplishment and I for one am very grateful for it's existence.

I can perhaps understand that people would like BST to be open sourced, well they can like all they like, they have no right to demand anything and should certainly not get abusive about it. It's not as if they are forced to use it and you are making piles of money out of it.

I can perhaps understand that people would like feature x, y, z. As I said along time ago, if a program is good and useful it will have users, and those users will then have ideas...Strangely enough that kind of feedback is a compliment, it works, they like it, they want more. If only they could put it nicely.

The final, and most obnoxious group must be those who criticize everything and claim they would have done it much better whilst actually never having done anything. There seems to be a chorus of those around in all walks of life.

Bottom line is, thank you for BST. I'm sure there are many other Propeller users like myself who are extremely grateful to you.

Sapieha · 2011-06-02 09:49

Hi BradC Heater.

Apologies Brad - BUT that was not nice to hear. I use much BST and Like it - To bad You can't/will work more on it.

I'm not surprised at all. As I wrote on one another thread "It is some people around Parallax that have theirs private agenda in mind NOT Propellers else Parallax."
It is bad thing as that will NOT give community what them want - But what that people will. And I don't think at it in end will be good for Parallax.

Heater. wrote: »

BradC,

That is one very sad and depressing picture you have painted there about the feedback you have received regarding BST.

I have to say I'm taken aback, even shocked, that any of that should happen.

I have been using BST since it first appeared and have always though that it is a wonderful thing. At the time, as a Linux user I was hard pressed to used the Propeller. BST was what it took to enable my use of the Propeller on any large scale.

It is clear that a lot of time, skill and effort has been put into BST by yourself. It's a great accomplishment and I for one am very grateful for it's existence.

I can perhaps understand that people would like BST to be open sourced, well they can like all they like, they have no right to demand anything and should certainly not get abusive about it. It's not as if they are forced to use it and you are making piles of money out of it.

I can perhaps understand that people would like feature x, y, z. As I said along time ago, if a program is good and useful it will have users, and those users will then have ideas...Strangely enough that kind of feedback is a compliment, it works, they like it, they want more. If only they could put it nicely.

The final, and most obnoxious group must be those who criticize everything and claim they would have done it much better whilst actually never having done anything. There seems to be a chorus of those around in all walks of life.

Bottom line is, thank you for BST. I'm sure there are many other Propeller users like myself who are extremely grateful to you.

simonl · 2011-06-02 10:51

@BradC,

I'd like to echo everything @Heater just wrote. I have been using BST almost since you were kind enough to donate it to the community - mostly with PropBASIC - and for that I'd like to say a GREAT BIG THANK YOU.

Dave Hein · 2011-06-02 12:01

Brad, you have received a couple of nominations for a Golden Propeller Award.

Bill Henning · 2011-06-02 16:18

FYI,

BST is my Spin development tool of choice - I can't live without the embedded serial terminal.

Bill

p.s.

I think Parallax should license it from you, and save themselves a lot of effort.

BradC wrote: »

Thanks for your E-mail Martin, you were right in that I had not seen this thread.

On the point of bst compared to the Parallax compiler, it already does code folding, operator optimisation, unused code removal and a few little speed tweaks, and it does it twice as fast as the original compiler and on far more platforms. Not only that, but with the optimisations disabled it produces identical binary output for over 6000 files in my test suite.

It's mostly a question of motivation. I've put a lot of time and effort into bst (it calculates out in engineering hours as more than I paid for my house). In return I've received a number of personal e-mail assaults, witnessed massive amounts of pontification and hot air surrounding the tools and how much better other peoples tools would be (if they ever stopped to write them), numerous support issues by people who just don't read the damn documentation (the little of it there is) and been accused of "holding the community to ransom" with closed source code. Now, I know bst has bugs (lots of them in fact), but the fact it works for me and does what I need it to do has sadly become all I need from it.

I've tried to spend time away from the forum and re-set my expectations, but unfortunately I find when I return here I see the same irritants that sent me away in the first place, and so I just log out again. It's a shame, but I don't take criticism as well as perhaps I might, and I do take things very personally.

On the other hand, I've just invested in some more hardware to test bst on, and at some point in the not to distant future I have some bugs I'd like to iron out, but at the moment I'm quite happy bashing away on my own projects isolated from the "community" here in the forum.

I have taken your E-mail and added its contents to my long term todo list, but as I know Roy is porting the Parallax compiler to C for public release I suspect you'll get a chance to add your features before I will.

I very rarely check the forum, but I am mostly contactable by E-mail

potatohead · 2011-06-02 16:25

Oh man...

Not cool. Brad, I love BST, and frankly, would pay for it. Thanks for not completely closing the door. Hope some positive resolution can be found. Your contributions have a lot of value. Maybe it's possible to show that somehow. Think about it.

Phil Pilgrim (PhiPi) · 2011-06-02 16:54

Brad,

Please don't give up! Even as a non-BST user, I can appreciate it as a labor of love that's required an enormous amount of work and that has serious benefits for programmers. And I wish I could use it and take advantage of all the coolness, but the "officially sanctioned" stuff I write (e.g. for Parallax) has to be plain vanilla Spin/PASM. Hence my "Prop Tool handcuffs" and endless grousing about the IDE/compiler in the forum.

-Phil

Cluso99 · 2011-06-03 19:44

Brad,

I echo the replies above, beginning with heaters response. I am saddened you feel that way and the way you obviously feel / have been treated. You have produced a fantastic product in BST. I could not have achieved/done what I have without it. And I only use the GUI version under windoze. What about the other platform users who have no alternative to BST.

Noone has the right to expect you to...
- Release the code as open source
- Demand you fix bugs (not that I am aware of any)

Your responses to fixing problems and adding new features has always been admirable. BST has advanced the Prop 1 most likely more than any other tool or program for the prop!

IMHO, Catalina is the only other tool/program that has the capability to make such a profound impact on the Prop, but as yet has not realised that goal.

I am disappointed that Parallax have not used either the bst or homespun compiler as a basis for the new compiler. I guess they have their reasons.

Please hang in there mate... We miss you :depressed:

Mike Green · 2011-06-03 20:20

Ditto on Cluso99's comments and others before them. Hang in there. I happen to be a Mac user. I can also run Windows XP so I can use a variety of other tools. I'm still impressed how you've created this professional tool and made it available for free for others.

Spin Annoyances and Possible Compiler Help?

Comments