On Sat, 2002-06-22 at 13:06, Jeff wrote: > 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.
Its not backwards, it does the right thing. The "at the beginning" part is correct since the source is treated like a queue, and the first item is shifted off. When an .include is found, the file is inserted at the beginning of the queue, since all of the code prior to the .include have been removed (shifted) off. So this (also contrived) example works as expected: test.pasm -------------------------------------- print "yo!\n" ..include "foo.pasm" ..include "foo2.pasm" print "you are here\n" end -------------------------------------- foo.pasm -------------------------------------- print "hello " -------------------------------------- foo2.pasm -------------------------------------- print "world\n" -------------------------------------- Does that make more sense? Brian > -- > Jeff <[EMAIL PROTECTED]>
