Re: .include directive for new assembler
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.
Re: .include directive for new assembler
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]
Re: .include directive for new assembler
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]
Re: .include directive for new assembler
brian wheeler wrote: Its not backwards, it does the right thing. Okay, I believe you now :) I was thinking that the insert was done at the beginning of the -file-, not the insertion point of the file. If you haven't committed, feel free to do so. I shouldn't have stuck my nose in :) 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]
[netlabs #726] -fno-strict-aliasing (fwd)
# New Ticket Created by Josh Wilmes # Please include the string: [netlabs #726] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=726 --- Forwarded Message Date:Tue, 11 Jun 2002 15:21:06 +0100 From:Nicholas Clark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: -fno-strict-aliasing Configure.pl is pulling perl5's C compiler flags in without question. perl5 is defining -fno-strict-aliasing on gcc. 1: As parrot is trying to be as clean as possible in its source, and rules about aliasing (and what a compiler may assume) is part of ANSI C, why do we need this flag? 2: Is it possible to get gcc (or any other compiler) to issue warnings where it detects that strict aliasing would (or might) change the program result? Nicholas Clark --- End of Forwarded Message
Re: .include directive for new assembler
On Sat, 2002-06-22 at 20:12, Jeff wrote: brian wheeler wrote: Its not backwards, it does the right thing. Okay, I believe you now :) I was thinking that the insert was done at the beginning of the -file-, not the insertion point of the file. If you haven't committed, feel free to do so. I shouldn't have stuck my nose in :) no problem! I have a tendency to not actually test my code thoroughly! Brian 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]
Re: Web info for perl6
H.Merijn Brand writes: http://www.perl.org/perl6 is a bit behind. Anyone care to update and include apo-5? And Damian's tour info. I've added Apoc 5. Patches for tour info welcome. -R
