PDA

View Full Version : Next Generation SPIN



jazzed
01-06-2009, 03:15 AM
There are some blaringly obvious missing features in the otherwise well done spin language. Asking Parallax to add features to current SPIN is probably an exercise in futility, or minimally an invitation of·derisive flames from forum fan-boys; still I must do this because I like the product and would like to see if there is a chance that feature omissions might be corrected so that I can feel free to become deeply entrenched and continue being repeat product buying customer rather than seeking alternatives.

A next generation SPIN and·Propeller ROM·might address the problems enumerated below.

A third party tool might be able to solve some issues in a nicely integrated way ... maybe some of the list has been addressed in recent developments. Many issues have been hashed over and over. Some issues could be addressed in tool "preferences", others require major hacking in the spin interpreter.

Anyway, here is the list of basic enhancements I would like to see by priority:
The ability to pass·an object pointer to another with full syntactic access of the passed object's public elements by the receiving object. Integrated object inheritance. The formal ability to use C-like·method pointers rather than obj hacks. Fully integrated IDE C-like preprocessor #defines and conditionals. Fully integrated IDE preprocessor #include statement for any valid code or #defines. The ability to specify a path for includes and library·objects. Device download speed/protocol error recovery for interfaces other than USB/COM port. The ability to selectively define VAR variables as public. The ability to create C-like VAR data-structures. A form·of·object polymorphism similar to Java abstract or interface classes. Pre-compile and post-compile tool command options for utilities (such as PhiPI's clean tool). ...

Any development organization has to draw a "water-line" for projects and features. If a good priority list can be presented from users, maybe there is a chance that something could be done.

There are other issues I'm sure that should be welcomed in open public discourse.

If there acceptable solutions available for any of these, please speak-up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

ErNa
01-06-2009, 04:10 AM
I think, these proposal have to be discussed. I miss pointers to methods, I miss include and conditionals. So I again created a CMap and I hope to reflect the discussion in this map to show, what it can be used for. And someone else will download the cmaptools and collaborate. cmapspublic3.ihmc.us/servlet/SBReadResourceServlet?rid=1231185663382_1377977913 _11599&partName=htmltext (http://cmapspublic3.ihmc.us/servlet/SBReadResourceServlet?rid=1231185663382_1377977913 _11599&partName=htmltext)

soshimo
01-06-2009, 04:26 AM
Well, as a newly annoited forum fan-boi I think I feel compelled to respond. First and foremost, there is nothing missing from the spin language. If you want to compare it to C or C++ (or even Java for that matter - but all those languages borrow from K&R's work so they are derivatives), then sure, there are features in the C derivatives that are not present in Spin. The reverse argument can also be made. Why do I even have to worry about pointers? The point (pun not intended) of a higher level language is to abstract hardware details - a pointer is very much a hardware detail since it represents a physical location on a device somewhere (or virtual location, but same thing). If you want a high level language, such a spin, then you want to abstract away the headaches of pointers. Why even work with pointers? If you can abstract the fact that I am allocating and deallocating memory (gc does that for java and cli managed languages) then I'm all for it - but why go back in time other than to satisfy some hubris? If you want fine level control over what your hardware and registers are doing - go to assembler. That was one of the main reasons C was invented - for some reason people didn't like looking at miles of spool fed paper with a bunch of mov ax,bx mov bx, [dx] add ax, bx all over it. It's much easer to read var += someothervar;. Also remember that Spin borrows a lot of it's syntax from BASIC while it borrows structure from Python (the indentation as a delimiter is very much Python) so again, it's like comparing apples to oranges. You wouldn't say, for example, that Python is incomplete because it lacks operator overloading. Just my 2$ (2 cents after inflation).

Phil Pilgrim (PhiPi)
01-06-2009, 04:31 AM
I think the best way to get such wishes granted is by "pulling", since "pushing" for new (and perceived as hypothetical) capabilities seldom works. Many of these suggestions and others can be accomplished by preprocessing. The idea is to implement them yourself to 1) demonstrate their superiority, 2) stimulate discussion, 3) gain acceptance, 4) come into universal use, and — finally — 5) achieve inclusion (even if begrudgingly http://forums.parallax.com/images/smilies/smile.gif ) as standard features of the language.

You have to work from the bottom up — not from the top down. It's a lot harder but, in the end, more effective.

-Phil

Oldbitcollector (Jeff)
01-06-2009, 04:34 AM
I can't see why some of the requests couldn't be just alterations to the Propeller Tool.
(or maybe some addition to BST, when BradC hits the ground again.)

Phil's got the right idea for approach to this... :)

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

soshimo
01-06-2009, 05:01 AM
/Concur w/ Phil and OBC

Take a look at the C compiler - that was a complete ground up development with very little input from the parallax team.

Keep in mind that Parallax is first, and foremost, a hardware company. They make great hardware with millions, if not billions of usages, and they target them for the masses, not some guy with a PhD in electrical engineering who can visualize what the electrons are doing on a substrate (though there are a few of those on these boards as well http://forums.parallax.com/images/smilies/scool.gif). The fact that they have such an awesome develoment tool is great - the fact that it's free is even better. Contrast this to say a PIC environment. What do you get for free with that? Assembler - that's it. Just Assembler - and some support for icd. If you want to write C you have to dish out some serious bucks and if you want to write BASIC - guess what? - you go find a BS or BS2 (which I believe used to be PIC devices with an embedded interpreter, not sure now if they went atmel rather than microchip or if they have their own dies).

I think, for what you get and what you can do, the price of entry is exteremely low. A quick anecdote to illustrate my point - I spent 2 weeks writing code/troubleshooting/pulling hair out to get my pic 877 to talk to an eeprom device. I was up and talking to eeprom, lcd, servos, and an rs232 breakout board I had created before all in under 24 hours with the propeller. I think I'll sacrifice some of the neat C syntax for that kind of rapid development.

waltc
01-06-2009, 05:02 AM
I second Phil's approach. Have one of the compiler writing savvy folks here code a Spin variant that incorporates all the OO enhancements.

Another way to go is to port Small-Talk or Objective-C.

Just my 2 cents.

soshimo
01-06-2009, 05:08 AM
Quick question, is the instruction set for the propeller documented somewhere? If I wanted to dust off my pascal compiler from college I would need the instruction set for the prop chip. Also, the compilers I've written were for CISC chips so there may be a bit of a challenge for RISC chips, for example, integer division or multiplication is usually an opcode on CISC chips. For RISC you would have to use a numerical method (or go brute force with subtraction for division and addition for multiplication) and that might make things more complex since it's not just a matter of loading up the ax and bx registers and calling an opcode.

Leon
01-06-2009, 05:09 AM
soshimo said...
/Concur w/ Phil and OBC

Take a look at the C compiler - that was a complete ground up development with very little input from the parallax team.

Keep in mind that Parallax is first, and foremost, a hardware company. They make great hardware with millions, if not billions of usages, and they target them for the masses, not some guy with a PhD in electrical engineering who can visualize what the electrons are doing on a substrate (though there are a few of those on these boards as well http://forums.parallax.com/images/smilies/scool.gif). The fact that they have such an awesome develoment tool is great - the fact that it's free is even better. Contrast this to say a PIC environment. What do you get for free with that? Assembler - that's it. Just Assembler - and some support for icd. If you want to write C you have to dish out some serious bucks and if you want to write BASIC - guess what? - you go find a BS or BS2 (which I believe used to be PIC devices with an embedded interpreter, not sure now if they went atmel rather than microchip or if they have their own dies).

I think, for what you get and what you can do, the price of entry is exteremely low. A quick anecdote to illustrate my point - I spent 2 weeks writing code/troubleshooting/pulling hair out to get my pic 877 to talk to an eeprom device. I was up and talking to eeprom, lcd, servos, and an rs232 breakout board I had created before all in under 24 hours with the propeller. I think I'll sacrifice some of the neat C syntax for that kind of rapid development.


There are free versions of the Microchip C18, C30 and C32 compilers. They are adequate for most people.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

soshimo
01-06-2009, 05:17 AM
@leon - yes free, but not optimizations and the extended instruction set of the pic18 devices in disabled. Plus it's C only. No C++, no classes, virtual functions or an of the other OOP principles you were looking for earlier (pointers are not an object oriented principle, they are a software abstraction of a hardware entity - a simulation if you will).

Now, I will concur that the AVR circles definitely trump both microchip and parallax in terms of open development. I can create my own tool chain using gcc and I can write in c/c++/assembler or any compilable language that gcc supports. There is a huge amount of support in terms of platform libraries for AVR. There is a big difference between that and the pic compilers though - I have yet to see a single open source pic compiler (and was actually tempted to write one at one time until I found AVR).

Leon
01-06-2009, 05:38 AM
C30 and C32 are gcc, and the sources are available. One or two people have built their own versions of C30. C++ isn't very good for embedded systems, they tried it for a military project where I once worked and had endless problems.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

soshimo
01-06-2009, 05:43 AM
I agree that C++ is not a very good language for embedded systems. It's bloated for a reason though and that reason is OO. The farther away from the metal you get, the more abstract you get, but also, the more resources you use to maintain that facade. It's a trade off with any language IMHO. You have to make the decision between ease of use and raw power, the two are usually mutually exclusive - at least that's what the last 15 years of developing in 6 different languages has taught me.

jazzed
01-06-2009, 07:05 AM
Fascinating responses :) I like it when the resume's come out. Some people reading this forum were cutting their programming teeth on toggle switches and punch cards. Thanks to our computing ancestors who said "wow, this stuff sucks so bad that the growth opportunities are tremendous" :)

SPIN should definitely not be C++ especially given the ways people abuse C++. Improvements can make SPIN more useful though. When folks are fully emersed in a language they find out about it's strengths and weaknesses. At some point you find yourself moving on to language 17 or language design number 4 or whatever.

Pointers are most new C programmers worst enemy and a good old friend otherwise unless you have to teach them :) Stripping semantics from pointers leaves you with indirect addressing on one extreme and objects on another. Object references are nothing more than glorified encapsulated pointers.

I am not an enemy of the market approach. Evaluating what is available is part of the market decision. The Propeller is an interesting chip and SPIN offers a fair solution given the size of Propeller memory. It is a good starter and a refreshing aside for the experienced offering some room for growth. Some things about it drive me crazy; other things make me happy.

Thing is I don't personally have time or drive to create bottom up solutions; those who do have time or make money on it can consider opportunities for improvements. Having seen Brad's development, maybe he will consider some of the list items. I'm just interested in having tools for creating reasonably maintainable and growing products.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Cluso99
01-06-2009, 07:49 AM
I haven't had time to digest this, but most are changes to the spin compiler.

I can change my version of the interpreter (ClusoInterpreter). I haven't touched it for over 3 months (just needs final debugging). I have room to implement extensions if they are valid and enough demand. There didn't seem to be enough interest for me to give it priority. I am expecting about a 20-30% speed improvement, but it will use 3KB of hub (2K for the code as the current Interpreter is in ROM) and 1KB for lookup tables.

Comments welcome http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

mpark
01-06-2009, 08:25 AM
I tried Phil's "push" approach by implementing experimental object-passing in Homespun, but apparently it's not what people wanted. Maybe my idea of passing objects is different.

soshimo
01-06-2009, 08:40 AM
@ jazzed - A quick comparison:

Enter the propeller. In a few hours I had a working prototype using a 3axis accelerometer via a wii nunchuck controller, an lcd, a ping sensor, and two servos in a pan/tilt configuration (I tried hooking up a glcd to implement a radar display but failed in that attempt, still working on it). Next I put TV and video out and shocked my family. All in a span of two days.

To contrast, I did an experiment and spent a week and a half learning how to build a tool chain correctly for avr, getting my makefile just right, hooking it up with an IDE I wrote for BrickOS a while back (gcc based so it was a no brainer and took all of about 4 hours), and then fiddled with bits and ports and datasheets. It took me almost 2 weeks to get everything the same as the propeller but the audio/video out (show me an avr chip - on it's own that is dip based that can generate COLOR video out and have bandwidth for more, for that matter, show me a pic that is dip based that runs at the props speed and has the computational power of 8 parallel cores - that's like saying a 586 is better than a dual core just because its harder to code for it).

Again, first day I got my prop, looked at datasheet for circuit - super simple - bread boarded it in about 10 minutes (had all parts but the chip) and had all that I mentioned above.

The point being that whether Spin is true OO or not - and I was one who posted early on asking about if it was truly OO - it still definitely has rapid application development potential. I think you can truly say that the propeller chip is the RAD pioneer of hardware. Nowhere else can you have complete working solutions in hours. That saves time which always equals money. I think the commercial applications still haven't been truly realized yet as this chip is capable of obsoleting existing know solutions for problems. Think of it this way - if you have multiple design problems that you have to meet, using the propeller you might be able to meet those objectives with a single drop in chip and since it's firmware based, upgrades can be made in the field for changing requirements.

Post Edited (soshimo) : 1/6/2009 12:53:29 AM GMT

jazzed
01-06-2009, 09:44 AM
@soshimo

Welcome to Propeller. Most of us who spend any time with Prop have been through that first experience. It was indeed nice to get something running quickly. I spent a day last week getting an ARM to load and run a program ... haven't thought about video on it yet because I turned to Propeller first to test some video ideas and hardware interface for my project because I have more of that hardware than I need ... and ran into some of the same old limitations I had forgotten about. I'm about a third through the SPIN version of the product, I'll do the ICCPROP version for speed (hoping I don't run out of memory as always) then I'll go back to the ARM development. Meanwhile it occured to me that a tool that generates certain SPIN code would be useful and I might try to productize that ... who knows.

True OO down to overloads, copy constructors, etc... is not important to me, but the convenience that inheritance provides a very useful place to put common attributes that I am currently having to replicate in each of about 15 files ... mostly getters and setters ... big waste. Just having the ability to make some object data public or inherit the the getters/setters would remove that problem although it would be less "safe". I don't expect to really need encapsulation.

@cluso I'm interested in your ideas on having the ability to handle the spin-centric issues. Have you ever considered doing a SPIN VM for other CPUs? That would make SPIN more attractive for multiple sourcing CPUs. One of the big advantages of C is most CPUs have a tool-chain - another is performance of course. Java found some success in VMs, but it is really too fat to be practical in standard or chopped down embedded form. SPIN is a good compromise as long as typical development expectations are met that bring SPIN out of "toy mode".

@mpark. I'll look into your threads to see if I can find your object passing implementation. I know that one can use DAT instead of VAR data for sharing an object as long as the object is set in the user file. The problem comes when one needs to choose a different spin object and 15 files need to be changed to use a different device driver. Just using a dummy API is not good enough if I remember unless you go to the trouble of using Stevenmess' DOL approach which is not attractive longer term. A preprocessor would help there, but that's still a pain in the rear for feature/maintenance unless it can mitigate change.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Paul Baker
01-06-2009, 10:15 AM
Phil has hit the target dead on, having been an "inside man" I can be an unofficial voice for Parallax in ths circumstance. Very few understand the true complexity of adding even the most trivial thing into the IDE (altering the compiler is pretty much out of the question, unless you guys want development of the next Propeller to grind to a halt).·It is complex·for a very simple reason: IT MUST WORK. This means exhaustive testing in every fathomable condition, and you're still guaranteed to miss a handful of situations you didn't anticipate. Implementing that list would take more than a man year to implement to Parallax's expectation of quality from it's products, and Jeff has many more responsibilites than just working on the Propeller Tool.

If you guys implement somthing in your independent tool chain and it blows up, it only impacts you and the few others that are using it, the same thing happens with the Tool and the consequences are dire. So implement it, show that it works, then show how it's indispesible in implementing a particular real world situation and not just another (older) way of skinning the same cat.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)


Post Edited (Paul Baker) : 1/6/2009 2:28:26 AM GMT

jazzed
01-06-2009, 11:44 AM
So the new way of skinning the cat is writing incomprehensible unmaintainable code ? LOLOLOL

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

soshimo
01-06-2009, 01:03 PM
So, only code that has inheritance and references is maintainable? Wow, I guess only a handful of people have it right and everyone else has it wrong. Oh, how inexperience blinds us so.

It's all in how you write the code. The most amazing tool will still be only as useful as a rock in the persons hands who doesn't know how to use it.

jazzed
01-06-2009, 01:20 PM
Nah, that was just an oblique reference to Paul's and other's apparent belief that anything predating Propeller is useless. Your last statment is acutely insightful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

SRLM
01-06-2009, 02:07 PM
Wait, what? Paul was simply mentioning that to add new functions requires alot of work to make sure that it is correctly implemented, and that a commercial application just requires much more testing. He didn't comment at all on the pros or cons of the actual spin code.

potatohead
01-06-2009, 02:08 PM
I didn't take it that way either. Older does not equal useless.

Really, there are two goals here. As the originators of the technology, Parallax has a burden to make it as robust and error free as possible. Propeller accomplishes both of these things extremely well.

As users, clearly we apply the tech to whatever our particular goal is, and we may or may not see value in the various levels of abstraction possible above PASM, and this is where the differences are.

SPIN and PASM are the two lowest level, necessary tools we need for implementing the technology. The Propeller IDE is the basic interface required to interact with those. PASM is more or less perfect. The instructions do what they are supposed to do, and the only bizzare case I've ever seen was that guy who picked just exactly the right waitvid timing to be confusing. (wish that had been explored some) This is a remarkable accomplishment! ...and I think it's very easy to go under appreciated, given the norm we are used to seeing; namely, complex CPU's with errata covering various bits here and there that can be tolerated, or are discovered after enough units are in play to be a problem.

SPIN is just as robust, and the combination of the two demonstrate a very low overhead. It is quite possible to just pick up a Propeller, grab the tool and the manual and have something fairly complex up and running, with out a whole lot of extra understanding being necessary. This too is a notable accomplishment, and it too goes under appreciated largely because most of the people I've met, who grok the Prop and are into it, are actually extremely sharp people!

And as such, they are needy! (as most sharp people are, because they can see the better path and just want it!)

The other factor is time. It took 8 years for the Propeller I to be realized. Part of the value of that lies in the fact that one person basically worked through all the design and a whole lot of the test cases and made sure the thing just worked. This does not happen often today. The power of good enough is all around us, and I don't know about you guys, but it's quite something to actually be working with some technology where "good enough" just didn't cut it.

All of this combined really gets us to where SPIN and PASM are today.

Both are complete. It is possible to do the things that need to be done. Had Parallax shot higher where the core set of tools is concerned, the time involved may well have exceeded the time that makes sense. There is a window for these things, and missing it means failure across the board, for all practical purposes.

Today, we are not significantly limited by the design. The on-chip interpreter can easily execute any object SPIN code, be it the reference SPIN, or some more feature packed derivative. PASM has proven quite robust in that I'm quite sure NOBODY thought about the Large Memory Model at the design stage, yet we have it, and between those three, the Propeller has quite an array of rapid, robust and well balanced options for encoding it.

One of the things that's nice about these core tools is that they are easy to understand. Overhead is low, output is clean, easy to read, and the file format allows for a mostly self-documenting code, including schematics, and other things. Quite a package actually. There are simple means and methods to make changes to larger bodies of code, and with 32K, just how large of a body of code will there be? (seriously)

When I look at C code, libraries and other more complex things, available on somewhat more complicated environments, I see the ability to re-use code quickly being possible, but really that is only realized when those contributing code do it in such a way that re-using it makes sense! (Frankly, I've not seen this happen as much as I would like, and unless it's all MY code, it's a bit of a wash, all things considered.)

In this environment, I don't see those advanced things, but I have to say this is probably the easiest system for simply re-purposing code period. To an experienced hand, I'm sure it seems hobbling in some ways, but to the rest of us, it's just great! I, and others here, have been able to just look at various bits of code, actually understand what was being done, cut 'n paste, or better just write something in the context of what we were doing, and have that happen without a whole lot of hassles. As other have said, I can honestly say, I don't miss makefiles, paths and such one bit. It's simple, and when things get big, there is an extremely solid case for doing some planning to account for it as there is leveraging some advanced features. Both take time away from the task at hand, meaning this is more of an artifact of one's preference and experience, rather than being some core limitation that's a problem.

The COGs bring a wrinkle to this as well. On an ordinary linear CPU, blending code together as one body makes a whole lot of sense. Why? Because there is only ONE CPU! In the end, it's got to all play together at the higher levels or there is more trouble than just writing it full on as one body would have. Libraries then do add a lot of value as they can be incorporated and provide some level of compartmentalization that keeps things sane.

On the Propeller, it's entirely possible to just snag some code that does something useful, and run it on that COG, and not worry so much about the greater code body interactions, because the compartmentalization happens at the hardware level. IMHO, this is why the simpler tools make so much sense on the Propeller, when they really wouldn't on other more traditional CPU designs.

Having said all of that, I think the difference in scale with Propeller II, will bring some of the greater issues into play as the scope of possible tasks grows to a point where more advanced tool chains make better sense. I suspect Parallax will still continue providing a baseline NECESSARY set of tools, allowing those with the greater needs to fill them as they see fit. The core ideas behind the tech won't change, so why would the tools?

So there it is. It's not really a matter of useless. Just different. That's kind of where we are with the Propeller. It's a very different CPU. Those differences will absolutely manifest themselves in the tool chains that people use to interact with it.

Frankly, I like SPIN + PASM. It's very potent. Some of the other things called for, like conditional compilation, would be great, but they are absolutely not necessary to just get it done. I do find it interesting that the lack of that feature, in particular, has kept code readable and somewhat easy to re-purpose. If there is no conditional building of the code, good commenting and use of constants and such make sense right? Well, those are exactly the things that make the code simple to pick up and use in the first place! That probably sounds like blasphemy, but it's absolutely true in my experience, and I didn't expect it. I know others here have experienced the same thing.

Considering the lack of these more advanced things "omissions" to be "corrected" is a bit off the mark generally speaking. There are different philosophies surrounding how these things are done. Given the differences between Propeller and many other micro-controller designs, I think it's safe to say the omissions were deliberate with an intent closer to what I posted above, rather than some short cuts, or other thing to be corrected.

There's more than one way to look at it, that's all. Don't take my post as a flame either! I don't mean it that way. Just thought another perspective might put some of the differences into a context that might make better sense.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/6/2009 6:32:45 AM GMT

waltc
01-06-2009, 02:35 PM
So implement it, show that it works, then show how it's indispesible in implementing a particular real world situation and not just another (older) way of skinning the same cat.

IMO Paul nailed it with that statement. Changes for the sake of changes isn't where its at.

That said, Spin is a nifty RAD language for micros more than anything else IMO. I'd love to see it on other micros like ARM and Coldfire.

ErNa
01-06-2009, 02:52 PM
I personally can not create an IDE from scratch. But I could analyze the code, make optimizations or expand features. But the propeller community is not an open source community. Everybody who contributes code in SPIN or ASM opens the sources. Sometimes it hinders the application of the propeller that code can't be protected. So, open SW has pros and cons.
I think it should be not to error-prone to make some additions to the IDE like conditional compilation for it changes not the SPIN language. So we should discuss two aspects: influencing the language and IDE

Post Edited (ErNa) : 1/6/2009 7:00:41 AM GMT

jazzed
01-06-2009, 03:02 PM
@SLRM I was referring to this statement: "Very few understand the true complexity of adding even the most trivial thing into the IDE".
Not having easy to maintain and test tools and intellectual property is evidence of bad engineering and management. That also causes horrible delivery schedules.

Spin is fine and is easy to use. It is just limiting in several ways. Of course it opens eyes too and that's great.

@potatohead your posts are always great reading. Thanks for taking time to write them. There are many C libraries that are written in haste to get products out. They sit there for years until a new feature is needed after a hack here and there. When it's time to enhance the library there are two choices: continue hacking or rewrite. One is extrodinarily lucky if only one or two files need changes. Often in the C world people don't think about the effects of spreading changes accross many files until the codebase is so bug infested that people start leaving the company as the cancer eats all fortunes and liesure.

But that all takes place in large teams. Spin is used in small efforts. It will be harder to scale because of limits. Ya, I hate strings and strings of #ifdef #elseif .... #endif, but this goes away with inheritance and polymorphism. Still #include and judicuous conditional use is very helpful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Cluso99
01-06-2009, 03:39 PM
I take Paul's comments differently. We can experiment with whatever we like, but Parallax will not endorse it unless they do exhaustive tests, and that will be at the expense of something else, like the PropII. Parallax - keep working on the PropII please http://forums.parallax.com/images/smilies/smile.gif

We can all try things (by using a conditional option). If it proves worthwhile, the users will decide to use the tools, and at no detriment to Parallax.

@jazzed: Spin on other processors: They use interrupts to control other features, and of course, they only have 1 cpu. I am not sure of the benefits for us or Parallax.

Currently I am busy doing a Cog emulation on the Xilinx Spartan 3A FPGA http://forums.parallax.com/images/smilies/smile.gif As I get further into it I continue to be amazed at what Chip has done (elegant and simple, yet so powerful and complex!!!) http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

soshimo
01-06-2009, 03:53 PM
Oh, BTW - there is a way to do some simple inheritance via containment. You can include a super object into a sub object and expose the methods you want to of the super objects instance (which is kept as part of that objects instance). It takes a bit more work, sure, but you can obtain the results you want of inheriting and extending functionality. You can even decide to hide certain implementations providing another layer of encapsulation.

potatohead
01-06-2009, 11:46 PM
@jazzed yeah, that's where it breaks down.

I think a pre-processor that does most of those things where the output is human readable SPIN, accepted by the propeller tool would be interesting. That way, the higher level constructs would be available, there would be some minor league overhead, but others choosing to just keep it simple and real, would still largely retain those favorable attributes present in the current environment.

As a counter point to your last post, it also goes away with a bit of planning too. As we move any direction away from the core set provided by Parallax, it's a matter of time. Just depends on how we all choose to spend it! And I think it's significant that this boundary was recognized as well as it was with the Propeller environment. I don't think that's an easy task.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/6/2009 4:16:45 PM GMT

heater
01-07-2009, 12:25 AM
By all means write an enhanced Spin compiler (Spin++) or perhaps some other new language that includes the features you want. mpark and BradC have show that it is possible.

What worries me is the resulting proliferation of languages fragments the community. Objects become incompatible. People don't want to have to learn many languages unnecessarily. Especially the traditional target audience of Parallax in education.

In a "professional" setting C might be preferred anyway.

I think what I am saying is that it is better to stick with Spin as it is as a standard. Any advancement of that standard would likely have to come from Parallax to stick.

Now a preprocessor I could probably welcome for handling those code configuration items like pin assignments or whether to use TV.Text or FullDuplex serial without having to hack the objects code. Use of such preprocessing tools could be added to BradC's IDE for example or used just from the command line.

There must already exist such preprocessors.

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

potatohead
01-07-2009, 01:48 AM
This is why propeller tool / human readable output is important. If one chooses to leverage a language fragment, their "source" may be of limited utility. However, the output of that would generally be as useful as most other SPIN code is. Result would be very little lost in terms of the growing body of available propeller code to draw from.

I got to thinking on this topic this morning. (sorry, I do that!)

The interaction among us and our experience levels highlights something else about the current reference Propeller environment that I believe is worth at least stating:

As I continue to learn more about this stuff, it has occured to me that most, if not all of my problems arise from either:

a. not having been exposed to the situation, so that's new learning

b. higher level feature dependency (just push the button without knowing what it does syndrome)

c. inexperience overall (just haven't done it enough to build body memory, meaning the mind is more engaged than it should be for the task at hand)

d. inability to obtain necessary information. (sparse documentation)

We are well down the path on d. Don't have that problem any more really. c. for me is a matter of time, no worries. b and a have relevance to this discussion!

Consider this thought exercise: (My day job involves adult learning advanced tools quite often, so that's where this is coming from.)

There was a time before the more advanced code constructs were available. Despite this, computing tasks were possible, meaning a lot of the work required to realize larger scale projects, in terms of either complexity or volume of code, was placed directly onto those working on the project. Habits then mattered. It's the usual lower level stuff, I'm sure most of us know well.

Those people, exposed to that time, carry forward and see the higher level advances as time savers, and use them when it makes sense. They can actually make that assessment because they understand how it's done at the lower levels, and can accomplish the goal sans the advanced constructs. Notably, the more advanced constructs evolved from those efforts to improve productivity. This is a necessary thing, however I don't think it's an exclusive thing, as in the lower level means and methods can be forgotten or marginalized.

Now, we've got people newer in the scene, who might not be getting that exposure to the degree that the old guard did! I could characterize myself as one of these people, as this is a hobby, potential career change situation for me. I love it, but have not practiced it in anything other than spotty ways since the 80's. So, I saw some stuff, missed out on other stuff. (that's just for context so this post is well understood)

So then, this newer group (and that's not a function of age, just exposure over time, and that's it) sees the higher level tools and learns to make use of them, but may not actually have been exposed to the lower level ways of doing things, just because. They then really cannot make that same assessment, and thus see these things as necessary.

I am absolutely not characterizing anyone here, just trying to make what I think is an interesting point.

So then, part of the Parallax business model is education. Specifically, it's education with practical uses attached. The idea being you can grok the stuff, then go out there and leverage that for your own purposes! Good stuff, BTW. Wish we had more companies like this.

In that spirit, doesn't it then make the best sense to focus on the core set of tools, so that said exposure is robust in this way?

As a circle around and look at my own growth, I think I'm in very little danger of developing a and b as greater things to be overcome at some future time, and I just can't see that as a bad thing overall. I'm also quite sure I would recommend a similar approach for others, as anything I've ever mastered in life has come down to understanding the core, fundamental things to a degree where little thought is required. In this, the current offering makes a huge amount of sense.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/6/2009 5:55:38 PM GMT

jazzed
01-07-2009, 02:30 AM
Cluso99 said> "Spin on other processors: They use interrupts to control other features, and of course, they only have 1 cpu. I am not sure of the benefits for us or Parallax."

The interrupts thingy is not a problem to me. Most single core CPU have multitasking o/s code support which can be leveraged in similar ways as using a separate cores. Propogating Spin to other platforms has enormous potential for Parallax. It's a market mind-share thingy. So many people here are so enamoured with Spin that it should indicate great potential for the language ....

@potatohead: There is a spin programming for beginners thread that is very good. There are many advanced programming threads. Techniques are available to solve some advanced problems that are not immediately obvious. Phil's Tricks & Traps thread is a great read.

@soshimo: I use the containment approach all the time. Main problem is one has to add more getter/setter accessors to access the "inherited" member properties - this eats up memory some, but is mostly a performance issue. Spin is already slow (fair optimization of speed/space) and adding another layer of method calls is just makes it worse. If you have a good example that solves this main problem, I'm all ears.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

soshimo
01-07-2009, 03:04 AM
@jazzed - From what I've heard the Spin interpreter is pretty tight and the amount of effort required just to gain even an extra 1% of performance is just cost prohibiting and wouldn't buy you much already since it's pretty efficient. Remember, these are ucontrollers running at 20MIPS (for each core), they are not intel core 2s running that are 18MIPS per MHZ (at 3.2GHZ they run over 50kMIPS). If you want tight efficient code, write assembler. That's pretty much been the case throughout history and still is today - most ASICS I've worked on have been at least 50% assembler (cell phone ASICS seem to be the exception, at least at Qualcomm/KWC it was mostly ANSI C - but some of the tightest C code I've ever seen). I don't mean to give you my resume, just want to give you my point of view in case it's skewed as I've been out of the wireless sector for about 4 years now and things may have changed significantly.

jazzed
01-07-2009, 03:51 AM
I recommend instumenting SPIN code with bit toggling and measuring with an o-scope so that you may understand.

Edit: Actually, there is a trick that I forgot that can make getter/setter time faster so the impact is much less. Requires more coding though. Look for Hippy's abort code: http://forums.parallax.com/showthread.php?p=575479

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Post Edited (jazzed) : 1/6/2009 8:07:21 PM GMT

soshimo
01-07-2009, 04:08 AM
Why don't you save me the time and effort (and cost to fix my borked oscope) and tell me what you found already? Or at least share a link that already has this information in case it's in some obviously obscure place.

Besides, how did this get from features of the language to optimizations of the Spin Interpreter? It's sounding a bit of an Ad Hominem. Shall we return to the original discussion of what the community wants? Which I think a lot have already spoken - they want to learn to harness the power of what they have now before looking behind other doors.

Post Edited (soshimo) : 1/6/2009 8:15:05 PM GMT

jazzed
01-07-2009, 04:18 AM
Sure. I'll produce before end of day tomorrow if I have enough time using analog scope readings. If you feel like it, you can reproduce similar results later with Paul's digital scope ... http://forums.parallax.com/forums/default.aspx?f=25&m=145310

Answering your edit: Because it follows on with an analysis of why inheritance or allowing some public variable access would be useful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Post Edited (jazzed) : 1/6/2009 8:24:42 PM GMT

RiJoRi
01-07-2009, 05:54 AM
Is there a way to call Propeller.exe and pass it the name of a SPIN file to load? If not, may I suggest this feature be added?

My background goes back to the "olde dayes" when in order to get an executable, you would edit the code, exit the editor, run the preprocessor, run the compiler, and run the linker, with pauses in between to fix any errors. IF Propeller.exe accepts a file name to load, then a number of tools can be run before the IDE. A couple of favorites would be LEO (http://sourceforge.net/projects/leo/), a preprocessor (I use mcpp from work, but there are many out there), and/or Draft Code Generator ( http://www.simtel.net/product.php?id=37145&sekid=0&SiteID=simtel.net)

--Rich

jazzed
01-07-2009, 06:16 AM
@RiJoRi
Try this: http://www.parallax.com/Portals/0/Downloads/sw/propeller/Propellent-v1.1.zip

Also ... this slipped my mind, but does work for scripting if you have a cpp preprocessor executable:
-------- spin fragment ----------
{
#ifdef ENABLE_SOME_FEATURE
}
' some spin code to enable here
{
#endif
//ENABLE_SOME_FEATURE
}

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

potatohead
01-07-2009, 07:31 AM
Well, on the topic of what is wanted. Simple, robust, lean.

That's my $.02

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Cluso99
01-07-2009, 10:41 AM
If you want to see how many prop instructions (hence cycles) per spin instruction, try my Spin debugger (see link in my signature). It counts the instructions (because it is actually single stepping through them).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

cruising (http://www.bluemagic.biz)]cruising[/url]

This is a bold test.

jazzed
01-08-2009, 11:36 AM
As promised, here are some relative spin measurements done with an O-Scope.
See the MethodCall.spin file for data.
Some result offer minor suprizes that affirm the value of examination.
Which is faster ceteris paribus?· "return value" or "result := value" ?

@Cluso99:
I would love to use your Interpreter/Debugger, but it's not clear what to use or how to do it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

jmg
01-09-2009, 09:27 AM
Some items are simpler than others

Certainly
4 # Fully integrated IDE C-like preprocessor #defines and conditionals.
5 # Fully integrated IDE preprocessor #include statement for any valid code or #defines.

should be safe and easy to add ?
(even if done with some 3rd party wrapers, but transparent in the IDE )

I'd find it very hard to work without conditional compiles in any language.

waltc
01-09-2009, 10:37 AM
If people need Make, #defines, C++ OOP features, conditional compilation, pre-processors, etc just use ImageCraft C or port over the GNU C++ tool set and Eclipse instead of mutating Spin into some sort of weird C++ subset.

The other thing that concerns me that by making Spin more complex and bug prone its going to drive away newbies when they see some the code gibberish that will be the result of this added complexity.

jazzed
01-09-2009, 01:09 PM
It's obvious there is nothing to fear on SPIN mutating ... or evolving for that matter.

My first post in this thread acknowledged the futility at the outset of asking for anything.
I welcome the fact that Parallax got beyond 20 goto 10 BASIC with Propeller ...
and if you really must have BASIC that's available too.

I will close with this in appreciation of the effort it took to make it happen:
The command line version of PropTool actually does address some items.
* The ability to specify a path for includes and library objects.
* Pre-compile and post-compile tool command ... not integrated but fine.
Again, one can force a precompiler to work outside the IDE as mentioned before.

It was never my intent by starting this thread to insult anyone. Don't take it that way.
I wish Parallax the best of luck in their increasingly competitve market niche.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

potatohead
01-09-2009, 01:10 PM
Agreed. Besides, these can just exist in custom posts!

From there, as long as the output is sane, anyone can pick up the output and use that, at a minimum. Spin is really clean. Love that part about it. It is just not hard to read or parse, but for all the little one or two character shortcuts.

Nice features though. Kind of hard not to add them. And if they are gonna be there, the shortcuts are probably better than longer keywords.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Joćo Geada
01-10-2009, 01:22 AM
Just to add a slightly different voice: I don't consider SPIN to be a particularly interesting language.

Look at the Arduino environment for a lesson on how C/C++ can be made user-friendly without loosing any of the capabilities of C.
And there is no lack of easy to use libraries to interface to all sorts of hardware etc with the arduino.

SPIN just another different programming language, with its own idiosyncrasies and real limitations and no great merit to overcome
the "its just different" hurdle.

I play with propellers for a hobby so it doesn't bug be overmuch. But I'm sure that for more commercial interests this could be a real problem.
This is a bit of a shame, as the propeller hardware is very interesting and a very different take on the compromises usually made when
designing a new microcontroller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Joćo