Forum Update - Announcement about May 10th, 2018 update and your password.

Doing amazing stuff in Spin

localrogerlocalroger Posts: 3,063
edited November 2013 in Propeller 1 Vote Up0Vote Down
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.
«1

Comments

  • 60 Comments sorted by Date Added Votes
  • cavelambcavelamb Posts: 657
    edited October 2013 Vote Up0Vote Down
    How about ? do another project - that you CAN share...
  • Duane DegnDuane Degn Posts: 10,002
    edited October 2013 Vote Up0Vote Down
    I actually think about your modular code a lot.

    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.
  • localrogerlocalroger Posts: 3,063
    edited October 2013 Vote Up0Vote Down
    cavelamb wrote: »
    How about ? do another project - that you CAN share...

    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.
  • User NameUser Name Posts: 1,451
    edited October 2013 Vote Up0Vote Down
    How early in the development of your present application did PropTool break?
    Platåberget
  • localrogerlocalroger Posts: 3,063
    edited November 2013 Vote Up0Vote Down
    User Name, it got to the point where the final compiled program would have been about $3800 of $8000 longs. From the wording of the error message it seems that there is a 64K buffer within the PropTool which needs room for copies of all instances of every repeated object in order to construct the final image. It also gets very slow, with the progress bar retreating and retrenching repeatedly.
  • I wanted to bump this thread up to the top of the Propeller forum for those who may have missed seeing it.

    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!
  • Thanks Duane for letting me know someone got some use out of it. When I worked out these techniques forum interest in Spin was winding down fast and all the hotness was in the C world. But I still like Spin for Prop development, even though I wish it had better mechanisms for reclaiming PASM cog image space.
  • I'm learning C, but when I want to do real work with the Propeller, I use Spin. It's clean. It's elegant. It's tied to the Propeller's architecture.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • I love the mix of spin and pasm cogs. I am not a C fan but do like Basic (as in VB).

    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.
  • I'm learning C, but when I want to do real work with the Propeller, I use Spin. It's clean. It's elegant. It's tied to the Propeller's architecture.

    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.


    Novel Solutions - http://www.novelsolutionsonline.com/ - Machinery Design • - • Product Development
    "Necessity is the mother of invention." - Author unknown.

  • Cluso99 wrote: »
    I love the mix of spin and pasm cogs. I am not a C fan but do like Basic (as in VB).

    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.
    What about PropellerIDE? I thought that was supposed to be the replacement for PropTool. It has at least some of those features.

  • I am tinkering with Spin, but when real work has to be done, I use PropGCC, period. Nothing else has to be said. Now that PropellerIDE is on the ropes, again, I am getting to be less interested in Spin, again.

    Ray
  • Rsadeika wrote: »
    I am tinkering with Spin, but when real work has to be done, I use PropGCC, period. Nothing else has to be said. Now that PropellerIDE is on the ropes, again, I am getting to be less interested in Spin, again.

    Ray
    PropellerIDE is an open source project. Anyone can contribute. I'm not sure it's accurate to say it's "on the ropes".

  • PropellerIDE is an open source project. Anyone can contribute. I'm not sure it's accurate to say it's "on the ropes".
    "PropellerIDE is an open source project. Anyone can contribute.", yes that is true, but how many people jumped in to contribute in that last PropellerIDE dormant state? For that matter, how many people jumped in to contribute in SimpleIDE updates? SimpleIDE is of a major benefit to Parallax, and they do not even feel that is of any great importance to keep SimpleIDE updated on a timely basis.

    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
  • Cluso99 wrote: »
    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)
    OpenSpin has some of these features.

    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.
  • ersmith wrote: »
    Cluso99 wrote: »
    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)
    OpenSpin has some of these features.

    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.
  • JonnyMacJonnyMac Posts: 6,061
    edited September 2016 Vote Up0Vote Down
    Good for you Jon... I think you will really appreciate that you took the time to learn C.
    I'm a programmer and have long understood C well enough to translate useful routines to other languages. I honestly don't understand why so many people bang on about C being so wonderful. It isn't. To properly create a library I have to make TWO files? Why is that a good idea? (BTW, that is a rhetorical question and I don't require an answer).

    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.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • It's amazing we have so many tools to choose from. Prop Tool, BST, HomeSpun, SimpleIDE, PropellerIDE, prop-gcc, open spin, catalina....a bunch of other languages.

    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.



  • JonnyMac wrote: »
    I honestly don't understand why so many people bang on about C being so wonderful. It isn't.
    JonnyMac wrote: »
    I still do my real work in Propeller Tool

    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
    Infantryman's Axiom; Always cheat, always win.
  • C is wonderful if you like your code to be long lived, work on any OS/system that has a C compiler (Most useful things) and be usable on different architecture machines. There are C programs that started life decades ago that are still useful today because of this portability.

    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.

  • David BetzDavid Betz Posts: 12,201
    edited September 2016 Vote Up0Vote Down
    Heater. wrote: »
    C is wonderful if you like your code to be long lived, work on any OS/system that has a C compiler (Most useful things) and be usable on different architecture machines. There are C programs that started life decades ago that are still useful today because of this portability.

    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.
    However, knowing C can make it easier for a programmer to move from MCU to MCU since there is a C compiler for almost any processor. This translates to programmer portability even if the code itself does not translate well. I agree that C is not an ideal language but it usually does the job.

  • I agree that C gives a rather good example of portability of code between most micros. Unfortunately the P1 is not your typical micro and so its of lesser benefit, but there is still benefits for the main cog. The libraries might be better to be separate cogs in pasm.

    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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 21,968
    edited September 2016 Vote Up0Vote Down
    JonnyMac wrote:
    I still do my real work in Propeller Tool.

    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • David BetzDavid Betz Posts: 12,201
    edited September 2016 Vote Up0Vote Down
    deleted

  • Long Live Propeller Tool and Spin! Who cares about all the other crappy tool sets, Long Live Spin.

    Ray
  • yetiyeti Posts: 401
    edited September 2016 Vote Up0Vote Down
    Rsadeika wrote: »
    Long Live Propeller Tool and Spin! Who cares about all the other crappy tool sets, Long Live Spin.
    ;-)

    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! ***
    ◁ Stay OmmmmmmPtimistic! ▷ ◁ Facebook. ▷ ◁ Google. ▷ ◁ Microsoft. ▷ ◁ No Source – No Go! ▷ ◁ Please help: http://rosettacode.org/wiki/Category:Spin ▷ ◁ Why Asimov's Laws of Robotics Don't Work - Computerphile ▷ ◁ DNA is a four letter word. ▷
  • Quite so.
  • yeti wrote: »
    *** Insert a huge applause for HomeSpun, OpenSpin, PropGCC, Spin2CPP, SpinSim, ... here! ***
    Thank you! Many people have put a lot of time and effort into building tools for the Propeller. I'm proud to have been able to contribute a little myself and I'm thankful for the much larger contributions of many others.
  • And thank you. Very Much.

    And everyone else who has contributed so much the the Propeller ecosystem.
  • JonnyMacJonnyMac Posts: 6,061
    edited September 2016 Vote Up0Vote Down
    Heater. wrote: »
    And thank you. Very Much.

    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.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
Sign In or Register to comment.