IDE Feature Request: include files or something similar for cross-bank program

daniel

The only other discussion I found (using forum Search) on this particular forum (BASIC Stamp) of this request occurs at the fourth message in thread http://forums.parallax.com/showthread.php?p=527631.· I exclude the various comments made about how messing up the cross-bank variable ordering can cause one to have an interesting day.

If this feature is already underdevelopment, thank you.

If not, please consider this a request for a means of simplifying cross-bank programming.· I see two possible workable·solutions.·

First possibility, allow for the use of INCLUDE files, as do many other programming languages.· These could be restricted to non-code content, and single-level (non-recursive) inclusion.

Second possibility, create a program section in the bank 0 source code, delimited by a pair of keywords (or as an additional file entry on the $STAMP directive), where in any PIN, CON, or VAR definitions will be automaticaly shared between all of the program banks.· I'd suggest the tokens #COMMON and #ENDCOMMON as the delimiters (or the additional $STAMP file could be identified as COMMON=filename).· As I would view the implementation, this section would be flagged as an error if the $STAMP directive does not suggest a multibank situation, or if the section was included in any program slot other than the bank 0 slot.

The reason for the request is that I have a application that will have a massive amount of CON definitions to assist with the manipulation of cross-bank procedure calls, a modest virtual memory management system, and a mechanism to return from POLLIN interrupts.· The current requirement to manually copy this list to all banks will be fraught with angst and error, especially considering that this (rather large) application is going to be developed in a RAD-like fashion (i.e., many intermediate stages as the parts are prototyped, and then committed).

I do not particularily require execuable code to be shared in this fashion, as there will be very little common code between the program slots in this particular application.· However, I can see that allowing executable code in an include file mechanism could do a lot for code reuse--allow a library of reusable routines to be crafted.· Even so, my need is for easing the management of crossbank usage of PIN, CON, and VAR symbol names.

If you wish additional discussion of this request, please let me know.

BTW, if something like this already exists, I have overlooked it, so please enlighten me.

Daniel

Tracy Allen

I'd like that too but have no idea how hard it would be to implement in the IDE. I've gotten used to doing without, working around with a template that contains my main set of variables and constants and the machinery for doing the cross bank stuff. That reduces but does not eliminate the angst and error, and that would be especially true where new stuff comes in, in RADish intermediate stages, as you say. It is intitially ad hoc problem solving, resolving specific issues, and will only later (maybe) becomes systematic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Bruce Bates

Daniel -

There is little doubt I'll probably catch some flak for this, but here goes nothing. If you're looking for something like this in the near term, I'd suggest the following, unless you get a clear indication from Parallax that something like what you're suggesting will appear in the next release of the Stamp Editor. I can't tell you how many times I've started this project, only to be rebuffed by Microsoft's announcement of yet another level of "standard compiler" maddness, as there seems to be no such thing as a Microsoft compiler standard that lasts more than 24 months <sigh>. As such, freeware source code becomes a real problem.

The thought that went behind the format of the $STAMP and similar '{...} directives, is both interesting and really quite helpful. For all intents and purposes (although at first glance it may not look like it), these are nothing but COMMENTS, period!

By PBASIC definition, ANY characters, numbers, text, etc preceeded by a single quote ( " ' " ) are treated as comments, up to the end of the logical line. There is nothing to say however that there can't be SPECIALIZED comments, and that's how the Stamp Editor Directives came into being. They are essentially non-executable, non code producing editor/compiler "instructions". If the proper keywords aren't contained within the required Stamp Directive Format (see above), then they are PURE comments plain and simple. Why is this helpful?

Let's suppose you put something like the following in a PBASIC Stamp program:

'{$STAMP BS2}
'{$PBASIC 2.5}
'*** Declare Standard Variables and Constants ***
'{#COPY "Base_Defs.INC" }
...
'*** Include Standard Routines ***
'{#INCLUDE "Base_Code.INC" }
...
END

Will it pass muster, as it sits, without producing an error? Yes it will. Is that true of any past version of the Stamp Editor? Yes it is, since as stated earlier it's "nothing but a comment". IMHO that's one of the major reasons why that particular character string and particular format was originally chosen.

Why have it closely resemble something so potentially dangerous as a Stamp Directive? Simply put, so you can use it now, and update it later, when the function is hopefully embedded in the Stamp Editor. But why use something so clearly near to a Stamp Editor keyword? Because it has inherent protection and thus shouldn't impact or be impacted by, any future Stamp Directives which may come to pass, so long as the present "syntactical rules" remain the same, which one would expect they would.

Why incorporate the "#" sub-parameter? To provide a simple means of "catching it" (standardized delimiter) in the line parsing routine. The "#" is part of an existing leading parameter (ex. #IF), but not as a subparamter. Those directives which are of the format "{$...}" presently head in one direction for processing, and those which are of the format "{#... }" might head in another. It also feeds into the "standard usage" (in general) of other computer languages, which may make it more palatible and easy to remember.

How does one incorporate these new functions then? A simple text pre-procesor which scans only for the indicated keywords. All other lines of data (source ccode) are passed on, as is, to the output routine. If the respective keywords are found, the indicated file is opened, read, the included data is sent to the output processor, and at EOD the data file is closed, and the input processing is resumed at the next line.

When I originally set out to do this, the "{$...}" Stamp Editor directive didn't even exist, so it was MUCH MORE labor intensive to incorporate INCLUDE/COPY into a pre-processor. At that time, a full fledged syntax scaner and line parser was required. The fairly recent, and inadvertant "gift" of the Stamp Directive has made it a much easier task. Sadly, I don't own an appropriate Microsoft assembler or compiler to provide such a pre-processing routine as I outlined. I QUIT buying Microsoft Compilers after losing my shirt on an investment in Visual Basic Ver 3 <argh>.

Regards,

Bruce Bates