On Sun, Feb 16, 2003 at 06:54:28PM +0100, Juergen Boemmels wrote: > 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.
You're going to hate me - I think I've got a source tree somewhere where I did get it to run on 5.005. I certainly had a good go at it. If you asked about this on list and I missed it, sorry. I believe that we do need to get down to just one interface, which logically should be written in C. Potentially then we might want to provide a perl binding to it, presumably via XS. But that comes later, if at all. > 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. Nice. This is good - make test seems to be much slower than make all Nicholas Clark
