Rant: SPIN syntax and language
Nick Mueller
Posts: 815
Sorry for the clear words!
That cost me some hours yesterday:
Why do the comparison operators have to be reversed in SPIN? Why the hell is the usual ">=" (and <=) an assignment? And not a comparision like in all the other languages I have worked with (Basic, Pascal, Modula-2, Eiffel, C, Objective-C, C++, Java, ...)?
It's getting completely wired with "=<=". Now <censored> is this? Oh, an assignment with equal or less. Boys, if you introduce new syntax, it shouldn't break existing habbits/rules. Something like "X:<= 3" would have done the job, wouldn't have broken standards and would have been easy to understand and read.
Oh, yes, because it is similar to "+=". Nice. So all the other languages that existed before and after did it wrong? 8-/.
I think I'll hit that trap some more times. Easy, if you are switching languages frequently or even have a project that needs programming one end in SPIN and the other one in C.
And why the indention-sensitive syntax? Doesn't make the parser simpler, doesn't make it easier to read, doesn't help at all. And you can't make an obfuscated-SPIN contest.
What happens if I edit the text with an other editor where tabs are 3 spaces and I replace 4 tabs with 12 blanks?
Still hitting the ";" at the end of a line from time to time.
And if I ever come across an "explanation" of the call stack that says that it needs to be bigger when an object is getting more complicated ... Needed for evaluating expressions ... So does an "a + b * c" require an extra long for the stack? Do I have to declare Guard-variables behind every stack and fill it with a pattern and frequently check wither it got corruped?
I'll do that as soon as I have an "#define debug" and "#ifdef debug"!
Oh and "long", "word", "byte". We know what a byte is. And a word is the smallest addressable size of memory. 32bits for the Propeller. Right? Wrong!
Next, local variables. Why the "|". A "VAR" would have done it. And if someone would have use a word err... long... *NO* word, a compiler errror does the job. Thus a next version of SPIN could have had different lengths of local vars.
And why aren't variables case sensitive? Line <> LiNE (Listindex No Equal)
And why don't hide local variables or parameters global vars?
And why can't I embed escape-chars in strings? string("AB\nC") or string("XY" $0A "Z")
For the next project, I'll switch to C ... SPIN is a dead-end road for me.
Anyhow, the hardware is really good!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
That cost me some hours yesterday:
Why do the comparison operators have to be reversed in SPIN? Why the hell is the usual ">=" (and <=) an assignment? And not a comparision like in all the other languages I have worked with (Basic, Pascal, Modula-2, Eiffel, C, Objective-C, C++, Java, ...)?
It's getting completely wired with "=<=". Now <censored> is this? Oh, an assignment with equal or less. Boys, if you introduce new syntax, it shouldn't break existing habbits/rules. Something like "X:<= 3" would have done the job, wouldn't have broken standards and would have been easy to understand and read.
Oh, yes, because it is similar to "+=". Nice. So all the other languages that existed before and after did it wrong? 8-/.
I think I'll hit that trap some more times. Easy, if you are switching languages frequently or even have a project that needs programming one end in SPIN and the other one in C.
And why the indention-sensitive syntax? Doesn't make the parser simpler, doesn't make it easier to read, doesn't help at all. And you can't make an obfuscated-SPIN contest.
What happens if I edit the text with an other editor where tabs are 3 spaces and I replace 4 tabs with 12 blanks?Still hitting the ";" at the end of a line from time to time.
And if I ever come across an "explanation" of the call stack that says that it needs to be bigger when an object is getting more complicated ... Needed for evaluating expressions ... So does an "a + b * c" require an extra long for the stack? Do I have to declare Guard-variables behind every stack and fill it with a pattern and frequently check wither it got corruped?
I'll do that as soon as I have an "#define debug" and "#ifdef debug"!
Oh and "long", "word", "byte". We know what a byte is. And a word is the smallest addressable size of memory. 32bits for the Propeller. Right? Wrong!
Next, local variables. Why the "|". A "VAR" would have done it. And if someone would have use a word err... long... *NO* word, a compiler errror does the job. Thus a next version of SPIN could have had different lengths of local vars.
And why aren't variables case sensitive? Line <> LiNE (Listindex No Equal)
And why don't hide local variables or parameters global vars?
And why can't I embed escape-chars in strings? string("AB\nC") or string("XY" $0A "Z")
For the next project, I'll switch to C ... SPIN is a dead-end road for me.
Anyhow, the hardware is really good!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Comments
It appears that Parallax are Pascal/Delphi people and so made Spin similar to that... But, I think that with a few simple changes SPIN (like you mentioned above) could be very close to C.
I'm still mad at my EE Department Chair for making me take Pascal classes (years ago) when I wanted to take C... Had to learn it on my own...
I suppose Pascal/Fortran are better for scientific programming, but for integer stuff, I think C is much better...
Still, all that said, Spin isn't so bad once you get used to it...
My #1 tip might be to turn on "Show Block Group Indicators" in the Preferences. I think this should have been turned on by default!
Post Edited (Rayman) : 11/30/2007 11:21:35 PM GMT
It seems to be a bit from pascal without some 'complications'. I'd have preferred pascal, really, but do not forget that the interpreter comes with the chip, built-in.
Yeah...personally, I wouldn't see myself using >= as an assignment operator either.· It effectively changes the type of the variable to a boolean on the fly, which isn't really good programming practice.· Once you define a variable to be a certain type, it's·best to keep it that type even if you're using a weakly typed language.· Also, the => operator looks a lot like an arrow to me, and Ruby uses it for something entirely different as well.· I usually stick to the assignment operators that resemble most other languages and avoid the cryptic ones unless there's no other way to do it.
I'm sure there were reasons to incorporate such non-standard operators in the language, but I'm not sure if the benefit outweighs the inconvenience to new programmers - which by the way are probably a large portion of the Propeller market.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Pascal? I do have about 15 years experience in Pascal and Modula-2. Thanks mom for giving me the language-card as a present for my Apple][noparse][[/noparse] and thus letting me learn Pascal! I can't recognize Pascal in SPIN.
Or is it Pacal-ish to you because of the "VAR"?
It's the misch-masch and introduction of features that are orthogonal to all the rest that I don't like. SPIN looks more like a hack than a design.
I'm not complaining about speed. I'm currently designing an Propeller-driven ignition system for up to 24 cylinders. It has ignition advance depending on load and RPM and lots of bells and whistles. I designed the software in SPIN, verified that all works as intended and will now have to port timing-critical parts to ASM. The Propeller was it that made me think to finally do that. It would have been a pain to do a similar task on a classical CPU. Parallel CPUs are so much fun and the key to simple solutions.
One cog does read the position sensor, one cog does calculate advance, one cog provides the signals for the spark coils, one does handle the RS232, one display values over RS232, one reads the ADC, ... And during testing, one cog simulates the signals of the position sensor. *THAT* is fun!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
What really bugs me is that no one ( except me it seems ) can write a parser for numbers which accepts all the common formats for hex - $123, &h123, 0x123, even h'123' - it's not hard to do. That always catches me out when moving between languages.
The one thing I don't understand is 'repeat v from a to b'; why not 'repeat v := a to b' ? Why not just create 'for' anyway.
On the other hand, I've found Spin to be a very productive environment to code in. So it's all swings and roundabouts. As it stands, I'm much more in favour of Spin than against.
I doubt Parallax is going to revise the SPIN language now that a code base exists.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Modula, Eiffel. Maybe others.
And if ":=" is enough to qualify a language as being "Pascal", you missed a lot. Sorry!
Pascal:
Functions, Procedures, nested Functions/Procs, local variables, name hiding, arrays start with index 1, ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
The point here is that we don't have a choice if we want to use the Propeller. They can't change SPIN now without breaking a lot of existing code. The object exchange and the hardware architecture that allows such code sharing is one area where the Propeller shines. Why change the language and leave this treasure trove of code useless?
I don't see people complaining so much about Propeller assembly as they do about SPIN. "Self-modifying code??? No interrupts??? No stack instructions?? Why can't it match the 8051 assembly code???"
Get over it. Propeller is a different chip, and SPIN is a different language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
For the record (though it's unlikely to dent your concerns), you can mix ASCII characters and byte constants within a string:
a := string("Hello, world.", $0D)If the symbol CR had been defined as a constant with the value $0D, you could've used that at the end of the line instead.
The use of escape sequences can easily be accommodated at runtime. My format object recognizes the usual suspects embedded within a string and does the "right thing" with them.
Spin, like any language, could be improved considerably, not so much by changing the extant syntax, but by extending it beyond where it is now. Frequently-requested language and IDE features include:
- Condiitonal compilation.
- Assembler macros.
- Better string handling, including runtime-capable string constructors.
- Inline dereferencing operators to make things like linked-list code more readable.
- Built-in DEBUG screen.
- Preprocessor hooks.
These could all be accommodated without changing the interpreter code or affecting backwards compatibility.Still and all, Spin is a real tour de force when you consider the size of its interpreter. But, now that the "oohs" and "ahs" have long since died out, it's natural to want more; and, hopefully, in time (Wow, it's been awhile, hasn't it?
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 11/30/2007 11:48:50 PM GMT
Thanks. I made the mistake to look in the manuals.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
So SPIN must be based on C, because of the "==".
Or it must be APL because it is interpreted.
Or can't be Pascal, because SPIN has a VarDecl "<Type> <VarName>"
Or is Smalltalk, because of the ":=".
Or Haskell, because of the "=>"
What's your point?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I do not like SPIN, too. I think from the point of language design you could have done much better. This is NOT a matter of byte code interpretation, but of compiler intelligence.
There is a main rule in language design: The programmer should never be surprised!
Which means, e.g.:
- only a few basic concepts
- fully orthogonal application of those concepts
- to be as close to the "main stream" as ever possible
As SPIN fails in all three aspects - and gives very litte in return - any criticism seems well founded.
But note it is not an impossible task to:
- write a fully independent interpreter (just 2 kB anyway!)
- write a compiler/IDE (based on ECLIPSE?) for a subset of any language of your choice.
It is true that there is a lot of code in the Object Library, but if objects contain substantial parts of assembly code their SPIN wrapper can easily be adapted to an interface to this "new" language.
1. Convert source to MFC and make it look and feel more like a standard Windows app.
2. delimit lines with ";" instead on new line
3. replace ":=" with "="
4. replace "<>" with "!="
4.1 replace "=>" with ">=", et al.
5. make everything case sensitive
6. use "{","}", instead of indentation
7. Add support for a mixed type structure in the DAT section
I think just doing this would make it close enough to C to make me happy...
Oh, I forgot:· I'd add a drop-down list of all proceedures and sections so you can jump around easier...
Post Edited (Rayman) : 12/1/2007 1:00:01 PM GMT
But I still find far more that I like about PropTool than I find lacking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
You could use kate and write your own highliter for it.
My point was not the IDE. I can live with that.
I also don't care what language SPIN looks like, as long as it stays with a *single* pattern and only introduces new syntax where necessary. Be it C or Pascal or whatever.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I have often told my friends that I love the Propeller because it put everybody back in First grade with me! And whether Chip intended that or not, it is where this controller excells in getting interest from new blood in the microcontroller field. With all the new interesting sciences to be found out there, from forensic, to nanowatt tech, It is no wonder why the step learning curve of existing embedded design is so scary to some freshman debateing on where to put their money!
And more to the point, I have never put down my Ham sandwich a cusing because I expected Ham to taste like PineApples.
One important thing to ask when critiquing any language is this: if it's the first language one learns (i.e. one comes to it without any preconceived notions), does it, by dint of its syntax and semantics, promote any bad programming habits? I can't honestly say that Spin does. On the contrary, as a GOTO-less language with enforced indentation, the novice programmer should come away with a better organizational sense than with BASIC, certainly, or even C. And still, with its minimum of "declaratory front-loading", one can just sit down and compose a Spin program onscreen with relative ease.
No language is perfect and, as I've alluded to before, Spin and its IDE could be much improved by extension. But there really isn't anything in Spin or its underlying interpreter that "poisons the well" or paints itself into a corner, thus mooting further enhancements.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 12/1/2007 6:28:54 PM GMT
If you read my points, you'll see that I DO use other editors. 2 out of 3 of the points are that PropTool doesn't work well with other editors.
As to SPIN, it's lacking in a few ways, but all in all, having written a number of programs with it, I'd say it has enabled me to be extremely productive. Which is more than I can say for most languages. It's a pragmatic language which fits the task it's designed for really well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Great. And how does that fit the subject?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
One can make an argument for not having ~, ++, += or assignments nested within assignments or conditionals but this applies to C and other languages. Whether it should be = or :=, == or =, != or <> is a matter of preference. A programmer doesn't need to use all that's available - if they wish to use var:=0 rather than var~ that's their choice - but it's true they need to be understood to be able to read others' code with ease.
Undoubtedly many of us would have done things differently if we were designing the high-level language. I can point to a number of missing features which can be problematic for some; no function pointers and no callbacks particularly ( plus non-language issues as conditional compilation ), but I don't really see how Spin can be said to "fail".
There's no need to be unpleasant. My post had two paragraphs, the first answering you. The second commenting on "SPIN syntax and language". Here's some more.
Indentation as block delimiter I love it! My other favourite language is Python which does the same thing. I indent my code to indicate nesting levels anyway, why should I have to indicate this information twice to the compiler. {} or BEGIN..END are a bore to type, and waste lines. Again, the only issue I have is with the IDE which by default has tab spacing set at 2 spaces, which is not enough to be clear at a glance. I set it to 4, and it's so much better.
; I haven't ever once wanted to split a SPIN statement over multiple lines. Because there's no calling of huge APIs with huge sets of parameters, statements just don't tend to be that long. And I certainly wouldn't want to put multiple statements on a single line. So again, the ; delimiter would just be telling the compiler a second time what I've already indicated by starting a new line.
:= or = The problem with C syntax is that a common bug is for people to use = in a comparison by mistake where they mean ==. At first glance it seems OK. But using := instead makes it very clear it's not a comparison.
<= >= These are a mistake. The SPIN meaning of a unary operator is probably very rarely used, and it's potential to create bizarre looking bugs means it's not worth it.
long, word, byte who cares what they are called so long as they are memorable? A word being 16 bits will be second nature to programmers who learned to program on any of the 8-bit micros or X86. Which is most people.
Local vars specified as byte or word Mostly useless, and an invitation for people to create pointlessly slow code. The prop always uses longs, so to use words or bytes in SPIN requires extra instructions. Whilst it is often worth taking the speed hit for arrays, it's rarely worth it for global scalars, and almost never worth it for locals, as the memory used is deallocated on exit from a method anyway. Even if you did allow for WORD and BYTE in the compiler, internally the SPIN VM would probably use longs anyway for the sake of making stack usage easy and fast.
Case insensitivity Good for keywords as it doesn't impose an arbitrary style on the programmer. Bad for identifiers. The best way is to be case sensitive for identifiers, but make identifiers that differ only by case illegal.
But generally speaking, the combination of SPIN and prop ASM I find to be absolutely fantastic. It's a great match for the propeller. I'm having fun and being productive at a level I haven't had for years. I have nothing to rant about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/2/2007 6:18:37 AM GMT
Over some decades of programming, I have developed my own coding style. Sure I do indent and keep the blocks, have only one statement per line. But not always.
One of my styles during debugging is to insert temporary statements and to place them at the very left. This way I can find them easily and quickly navigate through code. And quickly remove them. As they have to be compact for not to clutter the real code, they do have several statements per line. I don't need one telling me how my code has to look like. I already know that.
> {} or BEGIN..END are a bore to type, and waste lines.
One line lost. And begin/end really was boring.
> I haven't ever once wanted to split a SPIN statement over multiple lines.
A quick look at my current project: longest line is 120 chars. Good that I do have a 21" screen.
> := or = The problem with C syntax is that a common bug is for people to use = in a comparison by mistake where they
> mean ==. At first glance it seems OK. But using := instead makes it very clear it's not a comparison.
I don't care wether it is C-ish or Pascal-ish. But it has to stay with one pattern. It doesn't help anybody to introduce new rules that break existing ones.
> long, word, byte who cares what they are called so long as they are memorable?
Still, word is the processor's natural length of memory and would be 32 bits. Its only confusing to introduce new meanings.
> Local vars specified as byte or word Mostly useless, and an invitation for people to create pointlessly slow code.
My point was not so much having locals in different sizes, but hide their names to the outside. I'm running out if names for loop-counters ("i").
Seriously, why can't a parameter have the same name as the global, ift is the same thing.
And coming back to your argument of slow code. Well, smaller ints do exist in global RAM, why not in locals?
We have to distinguish between the goals one wants to reach. Speed or compactness.
> Case insensitivity Good for keywords as it doesn't impose an arbitrary style on the programmer. Bad for identifiers.
Not at all. I avoided a lot of errors by strict rules how to name identifiers.
Admittedly, the example I gave ("Line" vs. "LiNE") was not one of my most brilliant ones. To say the least.
> The best way is to be case sensitive for identifiers, but make identifiers that differ only by case illegal.
Not following the KISS principle.
I'm aware that the guys at Parallax will now call me names (and it is OK).
There's a nice tool when you design a language. It's called a syntax diagramm. When you draw it, you'll quickly discover oddities. I doubt that one exists for SPIN. There isn't even a BNF of SPIN.
> I'm having fun and being productive at a level I haven't had for years. I have nothing to rant about.
Again, I'm not complaining about the Propeller as a whole.
But there are some places that aren't very ummm ... streamlined.
Other examples:
* Why in ASM opcodes do follow the pattern <Destination>, <Source/Value> with the exception of WRLONG/WRxxx?
* The find-dialog in the IDE is almost useless because it is modal.
I just picked the SPIN-language for my rant.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Two. Unless using that goddamn awful practice of putting the opening brace on the end of the line before.
> I don't care wether it is C-ish or Pascal-ish. But it has to stay with one pattern. It doesn't help anybody to introduce new rules that break existing ones.
There aren't two patterns. Every language has it's own unique combination of elements.
>Still, word is the processor's natural length of memory and would be 32 bits. Its only confusing to introduce new meanings.
It takes more than that to confuse me.
>My point was not so much having locals in different sizes, but hide their names to the outside. I'm running out if names for loop-counters ("i").
Why on earth would you have "i" defined as a global in the first place. I use "i" everywhere, but it's always a local. If you really come up against it because you use a lot od short nondescript identifiers, pick a prefix to use for all globals. Like "g".
>Seriously, why can't a parameter have the same name as the global, ift is the same thing.
It's not the same thing.
>And coming back to your argument of slow code. Well, smaller ints do exist in global RAM, why not in locals?
Because globals can be arrays. Locals can't be. Hence "good idea to save space for arrays" vs "not worth saving space for scalars".
>Not at all. I avoided a lot of errors by strict rules how to name identifiers.
>Admittedly, the example I gave ("Line" vs. "LiNE") was not one of my most brilliant ones. To say the least.
Having identifiers only differentiated be case is never a brilliant idea.
>> The best way is to be case sensitive for identifiers, but make identifiers that differ only by case illegal.
>Not following the KISS principle.
Oh yes it is. Case sensitivity ensures that a program is always consistent about how it refers to an identifier. Making identifiers that only differ by case illegal catches potential bugs. Downside, none. Except for the programmer who has some very dodgy programming practices.
>* Why in ASM opcodes do follow the pattern <Destination>, <Source/Value> with the exception of WRLONG/WRxxx?
Why? Because it's consistent with the order of the bit fields in the instruction. Which matters if you are using self modifying code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
Post Edited (CardboardGuru) : 12/2/2007 3:18:18 PM GMT
>Two. Unless you use that goddamn awful practice of putting the opening brace on the end of the line before.
<G>. An example from Plum/Saks "C++ Programming guidelines". A good book, but ...
unsigned long token::hash() const { if (!hashed) { ((token *)this)->hash_value = .... } return hash_value }From Jensen/Wirth "Pascal user manual and report"
while not eoln(f) do begin write(f); get(f) {next character} end;I did *NOT* change the indention! I had some pain copying it!
So, I think it's best to leave formatting practice to the programmer and not the inventor of the language.
>> I don't care wether it is C-ish or Pascal-ish. But it has to stay with one pattern. It doesn't help anybody to
>> introduce new rules that break existing ones.
> There aren't two patterns. Every language has it's own unique combination of elements.
And they all keep with accepted standards. Why is Java so easy to read, despite being an own language? Why can you read even ADA if you do know Pascal? And why is Objective-C driving you nuts with all the [noparse]/noparse at the first look? Because it introduced a new concept that needed a different representation. SPIN doesn't have that much new concepts that cry for a new way of representing it. It's mostly only around the cogs. The rest is standard, or could be.
> Why on earth would you have "i" defined as a global in the first place.
I could have a global var named "CurrentSector" and pass that to PUBs where the parameter is called <drummRoll> "CurrentSector". It's got to be global, because 3 cogs work with it and change it during one PUB processes it. If I would mean the dynamic value, I'd pass a pointer to clarify that fact.
> Because globals can be arrays. Locals can't be.
You can have local arrays.
> If you think it's a good idea to ever have variables that differ only by case... words fail me.
I normaly wouldn't use them, it helps to detect Typos. And "pAST" (pointer to Average Settle Time) is something different then a flag called "past".
> Oh yes it is. Case sensitivity ensures that a program is always consistent about how it refers to an identifier.
> Making identifiers that only differ by case illegal catches potential bugs. Downside, none. Except for the programmer who
> has some very dodgy programming practices.
So, SPIN is just an educational language? I'm old enough to pick my var-names.
>>* Why in ASM opcodes do follow the pattern <Destination>, <Source/Value> with the exception of WRLONG/WRxxx?
> Why? Because it's consistent with the order of the bit fields in the instruction. Which matters if you are using self
> modifying code.
Can't see that dddd and ssss is flipped in the WRxxx OpCodes.
> What's that got to do with the topic of the thread?
That was your cookie for this Sunday.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
So the d-field contains the source data, and the s-field contains the destination. i.,e. The WRxxxx instructions use the bitfields in an opposite meaning from every other instruction. And that's the reason why the assembler does too.
>You can have local arrays.
Then we've both learned something. Still the idea holds that you don't tend to have a lot of local data and it's usually transitory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK