[WIP PATCH] core.ops split-up
Brent Dax
<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 <br...@brentdax.com>
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."
Brent Dax
# 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>.
The version I originally posted contained a patch to classes/timer.pmc,
basically disabling its guts. That was included by mistake--Parrot
won't compile on Windows without it. I just uploaded a new version that
doesn't contain that part. Sorry about that.
Benjamin Goldberg
With this increase in the number of files, I'm going to ask for
something I've thought of for a while, but not had the guts to ask for.
Could we try and clean up the parrot/ directory? Specifically, I'd like
all of the source code itself moved into a single subdirectory, leaving
at the toplevel only directories, the all-caps files, and a few others
(ChangeLog, Configure.pl, parrot.spec, and whatever else is really
needed to build and distribute parrot (make.pl?)).
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Benjamin Goldberg
Maybe someone should write a script like this:
#!/usr/local/bin/perl -wlpi.bak
s/
(\$?\w+) \s* -> \s* vtable \s* -> \s* (\w+) \s*
\( \s* (interp\w*) \s* , \s* \1 \s*,
/VTABLE_$2($3, $1,/xg;
__END__
[untested]
Then run it on all the code, except that which actually defines the
VTABLE_ macros.
Lars Balker Rasmussen
> (ChangeLog, Configure.pl, parrot.spec, and whatever else is really
> needed to build and distribute parrot (make.pl?)).
Nothing is currently using make.pl, and it's way out of date compared
to the configure system - delete it?
--
Lars Balker Rasmussen Consult::Perl
Leopold Toetsch
> Maybe someone should write a script like this:
> Then run it on all the code, except that which actually defines the
> VTABLE_ macros.
Direct access to vtable may only be used .ops files, where a similar
substitions is done by ops2c.pl. Changing the opsfiles needs adaption in
jit2h.pl too.
leo
Leopold Toetsch
> <brentdax> core.ops is...monolithic.
> <Dan> core.ops could use a good splitting out, definitely
That's ok for me.
leo
Leopold Toetsch
> Could we try and clean up the parrot/ directory? Specifically, I'd like
> all of the source code itself moved into a single subdirectory, leaving
> at the toplevel only directories, the all-caps files, and a few others
> (ChangeLog, Configure.pl, parrot.spec, and whatever else is really
> needed to build and distribute parrot (make.pl?)).
Yep. And move /languages/imcc to /src/imcc.
A separate build directory for the $(O) files would be fine too.
Or more drastically: build all generated files outside of the tree (like
e.g. gcc build does). This would allow to have multiple built
configurations (e.g. with different INTVAL/FLOATVAL size) in separate
directories.
leo
Leopold Toetsch
> Direct access to vtable may only be used .ops files,
s/\.ops/in .ops and .pmc/
Sorry,
leo
Dan Sugalski
>Benjamin Goldberg <ben.go...@hotpop.com> wrote:
>
>> Could we try and clean up the parrot/ directory? Specifically, I'd like
>> all of the source code itself moved into a single subdirectory, leaving
>> at the toplevel only directories, the all-caps files, and a few others
>> (ChangeLog, Configure.pl, parrot.spec, and whatever else is really
>> needed to build and distribute parrot (make.pl?)).
>
>Yep. And move /languages/imcc to /src/imcc.
>A separate build directory for the $(O) files would be fine too.
I'd rather move it to the same directory as the main parrot source,
since it's not really a separate thing.
If anyone's feeling ambitious, rough out a move plan. Which files
move where, and what the new dir structure is. If it's good, we'll
pass it on to the Keepers Of CVS so the files can move with their
metadata and history. Since that's a pain, I'd prefer to do it as few
times as possible.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
K.N.Vishwanath
Vish
Dan Sugalski
>How do I get out of this list please?
The mailing list software puts the list contact and unsubscribe
information in every message that goes out--it's in the headers. In
this case, the info is:
List-Unsubscribe: <mailto:perl6-interna...@perl.org>
Brent Dax
failing. object.t works for me (miracle of miracles, considering the
other test failures on Windows), but trans.t was easy to figure out--I'd
copied the transcendental ops from core.ops and never pasted them into
math.ops. *rolls eyes*
Anyway, a corrected patch that fixes the trans.t errors is up at
<http://filespace.brentdax.com/brentdax/coresplit.diff>. If it doesn't
apply the first time, try splitting the patch into several files and
applying them individually--apparently some copies of patch have trouble
with such a big diff.
I encourage people to test it out and tell me both how well it works and
what they think of the arrangement.
TIA,
Lars Balker Rasmussen
> Anyway, a corrected patch that fixes the trans.t errors is up at
> <http://filespace.brentdax.com/brentdax/coresplit.diff>.
Uh, there's still no "+inline op sin" in that file?
> If it doesn't
> apply the first time, try splitting the patch into several files and
> applying them individually--apparently some copies of patch have trouble
> with such a big diff.
On closer (and less sleepy-eyed) examination, the problem is
Windows/Unix interoperability. The following fix on the patch makes
it apply cleanly on my FreeBSD:
perl -pi -e 's/\r//; s,^--- NUL,--- /dev/null,' coresplit.diff
patch < coresplit.diff