<brentdax> core.ops is...monolithic.
        <Dan> core.ops could use a good splitting out, definitely

At 108k, core.ops is the second largest file in the Parrot distribution.
It's larger than all but five or six C files in bleadperl.  It has
nearly five hundred more lines than pp.c--and that's with several lines
of macros per opcode.

core.ops is also a file that gets hacked on a lot--at version 311, it
has nearly twice as many revisions as its nearest competitor
(interpreter.c, at version 171).  As of this writing, it was involved in
the most recent commit to touch the root directory.

Finally, core.ops is one of the most important parts of the
distribution, for reasons that should be easy to understand.

I understand that Parrot's nature--its language-independence, its
register-based nature, etc.--requires more opcodes than Perl 5, and I
don't mind that.  What I do mind is that core.ops has become
unmanageably large.  I believe it's time to split it up.

Since I don't think it's polite to flood peoples' mailboxes, I have
uploaded the 205 kb (9213 line) patch to
<http://filespace.brentdax.com/brentdax/coresplit.diff>.  It moves most
of core.ops into nine other opcode files; seven are brand new, while two
are dramatically expanded from their previous lives.  core.ops remains,
containing the first eight opcodes, basic control flow operations
(including subroutine operations), and interpreter introspection.

The ten files affected are:
        core.ops   [20k] contracted
        math.ops   [17k] expanded
        pmc.ops    [ 9k] expanded
        sys.ops    [ 9k] new
        set.ops    [ 9k] new
        cmp.ops    [ 8k] new
        string.ops [13k] new
        bit.ops    [ 5k] new
        stack.ops  [14k] new
        var.ops    [ 5k] new

With the patch, rx.ops becomes the largest opcode file, at 25k.  (Sizes
here assume that 1000 bytes=1k, because 'dir' is stupid and I'm too lazy
to round properly.)

This patch is *not* complete, as the documentation needs a lot of fixing
up.  However, I'd like to know what people think of the general idea of
splitting core.ops, and of the arrangement I've chosen.  Other than the
documentation, the patch should work fine--but note that this patch
*will* change the opcode numbers, so you'll have to re-assemble all your
Parrot bytecode files.

Configure will automatically detect the new opcode files and include
them in the build, and a MANIFEST patch is also included.  Test pass
rate is 96.49%, which is roughly as expected on my Windows 2000 system;
I don't know how well it works on a system with less "noise" in the
tests.

Please test this out and let me know if it works or not, as well as if
I've split things well.

--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
 
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."

Reply via email to