What do you think of having BITS & NIBBLES for Variable declarations?

DavidM

HI,

Q1) Would there be a benefit for a future version SPIN in having BIT's and NIBBLES as extra variable Definitions? BITs would be great for declaring BOOLEAN Variables. Nibbles would be great for space savings ( half a byte) especially in arrays.

Q2) While we are at it, What about a proper STRING variable declaration, where functions can use them as proper strings as apposed to the current method of cumbersome BYTE manipulations. especially when passing variables between objects.

Q3) Would there be a need to be able to declare our own 'BIT LEGNTH" of any size? ( I don't have any ideas how this could be done as far as syntax is concerned )

What do you think?

Dave M

MagIO2

The SPIN interpreter can not be changed, it's in the Propeller ROM. So all the functions you mention have to be compiled to existing bytecode. So, there is no difference in putting these functions into the compiler or in defining your own functions which do what you want. If you see a need in such functions build an object and put it in the Object Exchange.

What the SPIN-compiler provides is more or less a high-level version of low-level machine instructions (the operators, waitxxx) plus instructions a structured language needs (loop,if,case), plus some most-needed instructions to fill up the 512 longs of COG-RAM all of them placed in the SPIN interpreter.

Q1) Bits are supported by |< and bitwise operators. Define some constants for your bits and use operators like
bit_variable |= BLABLA_BIT
to set a bit .... clearing a single and checking for bits is easy as well. So, what's the benefit of boolean variables?
If you want a bit array, then define an array of longs named boolean and the needed functions to set, clear ... a single bit.

Q2) You can define strings: string( "Test string" )
This can be used in each string function and can be defined in the function-call as well. But you should keep in mind that SPIN is not an optimizing compiler. If you use the same string several times you really have n copies in HUB-RAM.

Q3) Don't really understand this question!

That's what I think. The current SPIN-compiler simply supports the most important things a programming language needs. For most other things the way to go is to create an object and use it like a library. string( "" ) of course could be easier by simply using "" ... but who cares.
Enhancing the programming language itself is not as valuable as an official support of macros for example .. or an include statement ...

DavidM

HI MagIO2,

Everything you have suggested I ALREADY DO and understand , I have bucket loads of routines for string manipulations, bit manipulations, bytes etc tonnes of the stuff ( i guess I could put some of these in an object for reuse, but as you said the INTERPRETER IS BUILT IN so theres no point asking then.

The benefits are cleaner and easier to use IDE/Code.

I did ask for macros ages ago, but nothing has happened! and still no prop 2 yet!

maybe the prop 2 will have support for more variable types? Its a good thing I didn't ask for FLOATING POINT numbers as a variable type then Is it?

regards

Dave M

heater

Spin is Spin. It's a brilliant implementation of a simple language that any non-programmer can get into relatively easily. It produces small code and allows you to do pretty much anything you can do in PASM all be it more slowly.

I am somewhat against the idea of Spin sprouting all kinds of new features syntactically or semantically. That would be sure to destroy the elegant simplicity of the thing and make it harder for those new to programming to get on with.

Anyone who has an introduction to micros and programming through the Propeller and Spin will eventually hit limits and start to dream of new conveniences along the lines of your suggestions. Every body does. That's why there are thousands of other languages out there that provide them in one way or another.

No, rather than bloat out Spin I think it is better to keep it as simple as it is. Anyone whose programming skills grow to the point that they start see the need for these missing features would be better served by moving to a new and standardized language that already has them.

By that time their skills would be such that they can handle all the extra complication that comes with such things.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

DavidM

Hi Heater,

Why would adding a few more ( I believe essential) variable types make the SPIN IDE BLOATED!!

I think it would make programming A LOT EASIER ESPECIALLY FOR BEGINNERS!

All I am asking for here is..

BOOLEAN (BITS), STRINGS, AND FLOATING POINT types.

We only have BYTES, WORDS, AND LONGS ( I hardly ever use WORDS by the way!)

Please don't get me wrong, I really like SPIN, but even after using it now for a few years, i can honestly say it needs these extra variable types. just to make programming even more enjoyable.

You said there are other languages out there, do you mean ones that work with the PROP??

regards

Dave M

Mike Green

It's a lot of effort (much more than you think) to add new data types (like single bit Booleans, Strings, and Floating Point) to the Propeller Tool. There's actually not much of a reason to have single bit Booleans. They're in Stamp Basic because of the need to make use of every last bit of variable memory on the Stamps. The Propeller, with its 32K of RAM, has little need for this as a basic data type. The same applies to nibbles. The actual storage units on the Propeller are BYTES, WORDS, and LONGS and those are what's supported in Spin.

If you do a lot of work with strings and floating point, use C. There are two C compilers for the Prop and one is free. Both are excellent and they have the usual C support for string values and floating point. C doesn't have the same support for strings that you'll find in Basic where strings are primitive values, dynamically allocated, etc. If you want that, try running either one of the Z80-CP/M emulators along with Microsoft Basic or SBASIC.

heater

DavidM. Never mind the IDE getting bloated. What we are discussing here is the Spin language itself becoming large and complicated. Adding different types to languages has proved to be the most common source of bugs in compilers, it seems to be hard to get right.

I also like to emphasise the simplicity of Spin for those new to programming and programming a micro-controller in particular.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dr_Acula

Thanks for the plug Mike!

@DavidM, come over to the Dark Side. (see attached)

We have a Propeller IDE with Strings. And Color! And C, Basic, Fortran, Forth, Pascal...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller