Clinton A Pierce wrote: > > At 09:37 PM 6/21/2002 -0500, brian wheeler wrote: > >I've implemented a .include directive for the new assembler. It > >basically changes the preprocessor to shift through the source file, and > >when an include is found, the included file is unshifted to the > >beginning. > > To the beginning? Do we have any pre-processor directives (.constant, > etc...) that are sensitive to where they're done? > > Either way, I'm fine with it. As soon as it's in, I'll fix BASIC to remove > the hand-rolled .include stuff it has now.
I hadn't read the 'beginning' part, unfortunately. That actually could change a lot of things. If it's unshifted onto the beginning of the file, then each new file will become the main as it's unshifted onto the beginning. For example, any code outside of a macro declaration would get run before the main file, and potentially initialize in the wrong order. To be fair, this is more of a fault with the current assembler not having built-in support for subroutine boundaries. Correct me please, Brian, but I'm envisioning a situation like this: .include "foo.pasm" .include "bar.pasm" MAIN: print "hi" end Expanding to: Initialize_Bar: set I0,32 branch END_OF_BAR # This is, of course, something of a bogus mechanism to begin with, but it should make my point. .constant IO_VECTOR S31 # Some subroutines END_OF_BAR: Initialize_Foo: set I1,42 branch END_OF_FOO # See above comment .constant IO_VECTOR S30 END_OF_FOO: MAIN: print "hi" end The code is admittedly highly contrived, but note that initialization is being done in the wrong order with respect to the files (foo.pasm's init should be run then bar.pasm), and IO_VECTOR is defined to be S30 rather than S31. The Initialize_Bar and Initialize_Foo functions have just been called in the wrong order. Now, I realize that modifying that bit of the assembler to count its position in the array of lines is non-trivial, and that's entirely my fault. However, having it attach files to the beginning of the list would violate the principle of least surprise, and could cause problems with conditional macros, which I've designed but haven't seen a need to implement yet. If you wouldn't mind rewriting the patch so that it substitutes files inline at the point of .include'ing I'll be happy to revert the old patch and put your new one in. Sorry about the seeming change of mind, but this is what I get for affirming stuff at obscenely late hours. -- Jeff <[EMAIL PROTECTED]>
