Fandom

Scratchpad

PropellerSpinEnhancements

215,724pages on
this wiki
Add New Page
Discuss this page0 Share

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

PropellerSpinEnhancements at Wikia


Welcome to the PropellerSpinEnhancements mini wiki at Scratchpad!

You can use the box below to create new pages for this mini-wiki. Make sure you type [[Category:PropellerSpinEnhancements]] on the page before you save it to make it part of the PropellerSpinEnhancements wiki (preload can be enabled to automate this task, by clicking this link and saving that page. Afterwards, you may need to purge this page, if you still see this message).

Here are some ideas for enhancements to Spin, the Propeller Programming Language created by Parallax.

ObjectSharing

We also need a method for conditional compilation and the like, but this is just an idea off the top of my head. Feel free to edit.

(Initial version by rokicki)

I think that the intention here can be accomplished with simple macro substitution during compilation if the ability is added to pass text parameters to object references. Conditional compilation and general macro substitution are all extremely useful and should be added anyway if you're going to add any macro capability. I think that the OBJ declarations should allow additional parameters (in addition to the file name) whether positional or keyword and the root object (selected for compilation) should be able to have parameters passed from the compiler's GUI (maybe set in an optional subwindow or menu item). Maybe the macro parameters passed to the root object could be global while any parameters specified in an OBJ declaration would be local to that object (unless passed further explicitly).

If you look at the Propeller OS sources, there already is something of this sort in that there is now a single program interface (API) to the keyboard and display. The actual low level drivers are different for the Demo Board and Hydra keyboard drivers and for the TV and VGA drivers, but the API routines work through a common data interface. With the current SPIN design, both low level drivers in each case have to be loaded, but only one of each pair is started in a cog. It would be better for macro substitution or conditional compilation to be available so that only the low level driver that's needed would be compiled. The only determining statement would have to be the OBJ declaration where one of two file names would be used. This avoids the issue with start and stop since there may be a low level driver independent start and stop method in the API object and a driver dependent start and stop method in the actual driver. In the case of the OS, the start method is in the low-level driver since it's very driver dependent while the stop method is in the API since there are no specific low level driver dependencies. In the OS, neither the assembly driver nor the start routines are needed once the OS is running. Programs running under the OS only need to reference the APIs which access the common data structures through high memory fixed pointers.

{comments by Mike Green}

Also on Fandom

Random wikia