Doing amazing stuff in Spin
localroger
Posts: 3,451
Anybody remember my modular programming thread, with BufStrFmt and friends?
http://forums.parallax.com/showthread.php/149189-UPDATED-X2-with-examples-Modular-Programming-in-Spin
I have finally completed my first actual application with this technique, and it is AMAZING. With the low and mid-level pseudo-global user interface functions in place, the application code gets amazingly tight. When I started this project I was worried that I would run out of Hub RAM. As it turns out I'm just a tad past $6200, with features in the mix I hadn't expected to have room for.
I can't post the code because most of what I've done since the last thread is proprietary and it's for a custom board anyway. But the technique an absolutely stunning code shrinker.
For example, rather than hard-coding the ticket formats I created a keyword replacer (I've been using a similar technique in Visual Basic for years) which replaces {curly bracket} delimited keywords with data and also does some output control. This took only 400 BYTES of Hub RAM. It does require space for a key data table, which I could have placed on the stack in a large local array but I put in my other large PASM image, the dual port cog-RAM buffered serial driver, so that reprint is a one-call function.
But how do I get such a ticket image into the application? For testing I compiled it in with FILE under DAT, but then I added code to upload it to high EE, above the setups and stored incomplete trucks, via XMODEM through the scale serial port. This only took about another 400 bytes of Hub RAM, and the other system functions are easily disabled to let XMODEM do its thing by the simple expedient of NOT calling the system background process which is called from everywhere else to update the scale. The downloader even puts up a progress box and updates the block count on the screen as it runs. That feature adds less than 100 bytes to the raw XMODEM module, most of that the text template for the dialog box.
Throughout the application advanced UI functions which I'd have expected to take 1 to 2 K of byte code to implement get done in a couple of hundred bytes by using the shared mid-level UI code. For an application of this type, with a lot of user interface business logic, this has the effect of nearly doubling the effectiveness of Hub RAM. Splashing up a pop-up box which announces an error takes little more than the bytes comprising the message, and there are dozens of those things. While any of them is up the clock display continues to update and the scales stay serviced, because those objects are duplicated in dozens of places as they are needed to make such updating possible under different high level objects.
The only fly in the ointment is that the PropTool chokes trying to compile my code. It apparently runs out of memory internally because of all the duplicated objects. BST compiles it fine though.
http://forums.parallax.com/showthread.php/149189-UPDATED-X2-with-examples-Modular-Programming-in-Spin
I have finally completed my first actual application with this technique, and it is AMAZING. With the low and mid-level pseudo-global user interface functions in place, the application code gets amazingly tight. When I started this project I was worried that I would run out of Hub RAM. As it turns out I'm just a tad past $6200, with features in the mix I hadn't expected to have room for.
I can't post the code because most of what I've done since the last thread is proprietary and it's for a custom board anyway. But the technique an absolutely stunning code shrinker.
For example, rather than hard-coding the ticket formats I created a keyword replacer (I've been using a similar technique in Visual Basic for years) which replaces {curly bracket} delimited keywords with data and also does some output control. This took only 400 BYTES of Hub RAM. It does require space for a key data table, which I could have placed on the stack in a large local array but I put in my other large PASM image, the dual port cog-RAM buffered serial driver, so that reprint is a one-call function.
But how do I get such a ticket image into the application? For testing I compiled it in with FILE under DAT, but then I added code to upload it to high EE, above the setups and stored incomplete trucks, via XMODEM through the scale serial port. This only took about another 400 bytes of Hub RAM, and the other system functions are easily disabled to let XMODEM do its thing by the simple expedient of NOT calling the system background process which is called from everywhere else to update the scale. The downloader even puts up a progress box and updates the block count on the screen as it runs. That feature adds less than 100 bytes to the raw XMODEM module, most of that the text template for the dialog box.
Throughout the application advanced UI functions which I'd have expected to take 1 to 2 K of byte code to implement get done in a couple of hundred bytes by using the shared mid-level UI code. For an application of this type, with a lot of user interface business logic, this has the effect of nearly doubling the effectiveness of Hub RAM. Splashing up a pop-up box which announces an error takes little more than the bytes comprising the message, and there are dozens of those things. While any of them is up the clock display continues to update and the scales stay serviced, because those objects are duplicated in dozens of places as they are needed to make such updating possible under different high level objects.
The only fly in the ointment is that the PropTool chokes trying to compile my code. It apparently runs out of memory internally because of all the duplicated objects. BST compiles it fine though.
Comments
I keep meaning to go back through the thread you just mentioned to really understand what you're doing. I keep finding needs where both a parent object and a child object need access to a third object. I recall you have a nice way of handling this but I just haven't taken the time to really understand what you're doing.
Thanks for the reminder and the link. I do plan to study what you did.
In the other thread I did post a demo which runs on a DemoBoard which implements the basic technique and a fairly advanced set of UI functions. With such functions available pseudo-globally throughout my project I expected my application code to be very compact. The takeaway now that I've done an application is that I underestimated HOW compact it would be. All of the alternate approaches involve a lot of logic to relay function requests from where they are wanted to where they are, like mailboxes or implementing PUB functions in a long chain, or they require building elaborate state machines which require a lot of logic to examine state every time anything is done. With the modular technique the PC (current point in the executing program) can be the state and yet it can have access to whatever lower-level functions are needed regardless of what object happens to be executing. That would save code, I guessed, but I had no idea how much.
I use the strategies localroger suggested a lot in my projects. These are some extremely useful suggestions presented in these threads.
Thank you localroger for sharing your work!
What is a shame is that there has little to no effort put into PropTool (or replacement). bst and homespun added some features.
But what would have been nice would be
* conditional compilation eg ifdef etc (as in bst and homespun)
* simple macros
* Spin - additional improvement pass (see below)
The Spin improvement I mean is that another (optional) pass could significantly improve the run speed by examining the bytecode. Everything is passed on the stack. However, sometimes the stack is just used to pass a value from the result of one spin routine to another. Those push/pop pairs could be removed. I am certain there are other improvements that could also be made.
I made spin interpreter improvements too, which gained some free cog space. Also, some LMM sections could have been used for the lesser used bytecode routines.
Good for you Jon... I think you will really appreciate that you took the time to learn C.
I hope all is well with you and everyone else in the forum.
Ray
So, to use some boxing terms, SimpleIDE is doing some "rope a dope", while PropellerIDE is just starting to hang on to the ropes, and when the time comes, hopes that it will be a long ten count.
Ray
I'm curious: I've seen complaints from many people over the missing preprocessor in Spin, and yet OpenSpin has it. Why don't you use OpenSpin / PropellerIDE? It's a serious question, not a rhetorical one. Are there some features that PropTool has that PropellerIDE + OpenSpin doesn't? If it's something simple, maybe we could persuade Parallax to fund those features, or perhaps even raise the money ourselves. If enough people contribute $20 to a bug bounty on a feature, I suspect Brett or someone else would take it up.
IMHO it's a parallax problem to get behind. It's way too late now. Parallax had the opportunity to support bst and/or homespun, together with giving those guys access to PropTool instead of having to effectively reverse engineer it.
When I tried PropellerIDE it wasn't ready for prime time. Roy did a good job with OpenSpin, but way too late by the time conditional compilation was added. No point in changing from bst and/or homespun and/or PropTool when they do the job and no extras to entice a change. BTW I use all three, depending on what I am doing.
There is still no simple macros, and there is still no spin compiler speed up pass.
These things are the base requirements for a new processor, not a 10 year old one.
There is a lot of whining about what compiler does or doesn't do what from people who's primary contribution to the community is whining. Though I like PropellerIDE and continue to encourage updates, I still do my real work in Propeller Tool. Others use BST. There great thing is we have choices. We can program the Propeller in Spin, C/C++, BASIC, and even Forth -- and there's more than a few tools to suite our individual needs/desires.
At the end of the day, it only matters if the project works as intended. For me, Spin (and PASM) is the cleanest way to get there.
It's a shame things don't get updated with SimpleIDE more promptly. I have no idea what happened to the language translations. At least Finnish seems to have been lost along the way. But there we go.
Something about the Propeller inspires people to do these things, going back to the assembler by Cliff Biffle years ago.
I'm sure that C is wonderful if you take the time to learn it and take the time to put together the tools required to use it. The propeller tool was available and reliable when the Prop was first introduced. How long have these other efforts been going on?
Where do I download the toolset for PropellerIDE or SimpleIDE or whatever it's called?
Sandy
And so it goes with C++ and other languages.
Arguably micro-controller code is often so dependent on the machine it runs on that this wonderfulness of C hardly matters, the code is going to have to be adapted in a major way for any other machine. Think moving Arduino code to the Propeller.
But Assembler is also not so bad at being translated between micros, especially by a good assembler programmer.
I translated 68705U3S code (about 3.7KB) to Z8681 (???) in under half a day back in the latter 80's. It was modem AT code plus the Rockwell chips driver code for 2400 modems (oh how slow they seem by today's speeds).
Actually I wrote a conversion program in turbo pascal, with the Z8 modelling the 68705 register set.
So do I. Let's face it, despite the wonderful features of those other tools, the canonical Spin accepted by the Prop Tool compiler, is still the lingua franca of all Spin versions. I know that if the Prop Tool compiles my program, the other compilers will, too. And that's important.
-Phil
Ray
No Windows here and this certainly will not change...
...and after the BST disaster (no source, no updates, no future), I don't ever want binary-only distributed stuff again...
So "the other crappy tool sets" I can compile myself not only are very welcome here, they are essential.
*** Insert a huge applause for HomeSpun, OpenSpin, PropGCC, Spin2CPP, SpinSim, ... here! ***
And everyone else who has contributed so much the the Propeller ecosystem.
Indeed. I think I stated before, we're lucky to have as many choices as we do -- in large part to the efforts by David, Steve, Brad, Peter, Terry, Brett, and many others (whose names I don't know).
With a couple editor behavior tweaks, I would switch to PropellerIDE in a flash. Editors are highly personal; I really like the block selection (Alt+drag select) and smart tabs. I wish those behaviors were more commonplace in other Propeller-centric tools.
For the record, nobody should take my enjoyment of Spin, and preference of Propeller Tool (for the moment, anyway) as an indictment of anything else. That said, it does get a bit tedious to request an improvement in Spin which results in the barrage of "You should be programming in C!!!" commentary. I could program in C now. I choose not to -- again, for the moment, anyway -- because nobody has demonstrated to me that I could be more productive with my Propeller projects by doing so.