User Spin Library / Search Path
hippy
Posts: 1,981
Is there anyway to specify a directory of Spin files which can contain objects to be automatically included when required beyond keeping them in the working directory or the Propeller Tool Library directory ?
I'm working on two separate projects which use a common object which itself is being worked on separately and I don't want to put it it in the Propeller Tool Library.
The string after the object's identifier is a filename ( the error message for putting \ in says so ) but there seems to be no way to specify a directory path in that string.
Have I missed a trick or is it something lacking in the Propeller Tool ?
I'm working on two separate projects which use a common object which itself is being worked on separately and I don't want to put it it in the Propeller Tool Library.
The string after the object's identifier is a filename ( the error message for putting \ in says so ) but there seems to be no way to specify a directory path in that string.
Have I missed a trick or is it something lacking in the Propeller Tool ?
Comments
Scott
I have a video driver object which includes quite advanced number formatting code and a PUB Demo routine so the object can be run standalone for testing / proving or included as a sub-object. I then create another video driver object, exactly the same again.
Then I create a higher level object which can select one of the two video drivers at run time and switch between them. Easy, but if I want to minimise code used ( consolidating the duplicated formatting routines in each video driver ) I have to move those routines up to the new parent object.
Again, easy enough to do but then it breaks the standalone nature of the video objects and any other application which relied on the video object having the formatting code in it.
Either that means having two very similar video driver objects or an intermediate object has to be created to use that video driver which provides the removed routines. That of course is very similar to the parent object for the two driver version but not quite.
No matter which way one goes one soon ends up with multiple objects which differ only slightly so bug fixing and enhancement means a whole set of object files all need updating and it's easy to miss one.
If one doesn't care about wasted memory and duplicated routines then it's no problem; simply include all formatting routines in every object, but that then carries the cost of editing every single object should those routines ever need altering.
Ideally an intermediate level object should work as an abstraction layer for top-level objects regardless of what's below, but that's not so simple because an intermediate object can only use objects it names and not all top-level objects need all bottom level objects so there needs to be a third level which directs the abstraction layer down to the bottom end video driver objects.
As long as one designs for two intermediate levels between top-level objects and the lowest level driver objects it's fine, but even then there is still unused code taking up space in the abstraction layer.
What's really needed is #if or, even better still, unused and dead code removal by the compiler.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
The only rule to be complied to is: USE NO VARs
In fact there is no need to use VARs at all (only if you WANT to have OBJECT members)
There is a trade-off when you need WORD or BYTE space and want to have the simple compiler support of autorecognizing these identifiers and using correct stride... This is more awkward with local variables or DAT variables to be used as BYTEs or WORDs
Post Edited (deSilva) : 10/24/2007 6:03:58 PM GMT
Have a look at the code for the I/O drivers in the Propeller OS (see Graham Stabler's sticky useful links list). The various I/O drivers allocate their work areas in the high end of RAM and do all their references via pointers in specific locations at the top of RAM. The drivers are split into an initialization and assembly portion and an API portion and the API portion has no VARs and can be referenced at multiple levels in the object structure. The downside of this is that there are interpretive code space optimizations for local variable and VAR section references that you can't take advantage of. Careful use of local variables can sometimes help there.
It could be as simple as a new version of the Spin Editor since those enhancements do not change the spin language.
One area that the conditional defines would be handy is in the video config. We have multiple boards out there with people trying to change the configs for the video settings. A common config section with #ifdef propRPM #ifdef proto #ifdef hydra would make life easier for everyone.
@ Mark : I agree entirely. It can be done with constants set true or false but that wastes a lot of memory and the constants have to be passed down the object chanin.