Nicholas Clark <[EMAIL PROTECTED]> writes: > On Sat, Feb 15, 2003 at 12:10:11PM -0500, Dan Sugalski wrote: > > I'd half-wondered if this would ever come up. > > > > Back in the beginning we decided that, while the assembler would > > support macros (over some disagreement) since it was an end-user tool > > and end users might use macros, any internal assembler wouldn't since > > it was meant to be a quick and simple thing. I'd planned on keeping > > that, but seeing as how we're going to have languages as complex as > > perl built in, I'm not sure there's much reason to maintain the > > disparity.
At the moment there are three completly independ ways of bytecode generation: a Perl Interface PackFile.pm which is as far I can see not used any more, the assemble.pl and the C-interface. Reducing this to just one C-interface would simplify the bytecode changes as discussed in the thread "bytecode metadata". And please dont suggest XS, I tried days to get PakFile2.xs running on a perl 5.005 system. So my patch introduces a way to bring all this bytecode interfaces back to one, nearly runs the whole testsuite, and has the nice effect that its nearly tripples the speed relative to a normal make test. > My understanding (could be wrong; I suspect there are enough truly > knowledgeable people here to correct me) is that the GNU assembler can run in > a "fast" mode that disallows most complex constructions, gcc's standard > output is consistent with the constraints of this mode, and gcc will attempt > to run in this more if possible. Concerning the speed issue, I really don't think macros slow down imcc much. It is only contained in the lexer, and it only adds two codepathes to imcc.l, one that recognizes the spezial word ".macro" which calls a function read_macro. But this is only needed if you actually use macros. The other thing is when reading a .identifier, then a function expand_macro is called, and if this fails an error is signaled. As it macro_expansion only delayes error reporting a little, I don't think this is a speed problem either. One thing that might cost speed is the introduction of the new startcondition <macro>. This will increase the sizes of the flex-tables and so may slow down yylex by reduced locality. Its possible to create a own macro_lex function and take this out of yylex entirely but I think this is a kind of premature optimization. > Does the -a flag on imcc mean that we can run without the macros, and hence > run faster? No, it turns on assembly mode. bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
