Re: Yet another switch/goto implementation
First of all you miss typed:
-if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
+if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
On Sat, 3 Nov 2001, Michael Fischer wrote:
> Ok, attached dispatch.diff is the smallest changes
> I could think of to get a Configure.pl time choice
> for func/switch/goto implementations of DO_OP.
>
> Diff made against a 9:45 PM EST copy from cvs.
>
> ISSUES:
>
> 1) goto is gcc-specific.
>
> 2) replaces interp_guts.h with do_op.h
No, it doesn't, it's still using DO_OP from interp_guts.h
>
> 3) the goto is done as a funciton definintion and
>a #define of DO_OP as said function. The whole
>business is written into do_op.h. Not the way to
>do it from best C practice, but it works without
>jiggering dependencies.
I really suggest that you do a do_op.c and a do_op.h and that you call
goto_op_dispatch directly from runops_core.c (from runops_t0p0b0_core),
because if I'm not wrong you are breaking -t ,-p and -b options.
>
> 4) the MOPS _don't_ improve
>Which means I'm probably missing something terribly
>important.
True, as I said before, and if I'm no missing something terribly
important :) , goto_op_dispatch never gets called, and the same actual
'func' dispatch method is always used no matter what you choused.
>
> 5) Not the cleanest implementation perhaps, but largely
>limited to ops2c.pl, and things should be fairly easy
>to track down.
>
I think your approuch is much better and cleaner than mine, my brain was
limited to unix :) so I never worried about anything besides gcc.
It would also be nice if you can decide which dispatch method use instead
of asking.
> 6) A few warnings about type mismatch when building with 'goto'
>Yet make, make test and mops.pbc run fine. Hmm.
>
> Share and enjoy.
>
> Michael
> --
> Michael Fischer 7.5 million years to run
> [EMAIL PROTECTED]printf "%d", 0x2a;
> -- deep thought
>
Daniel Grunblatt.
RE: [perl6]RE: Helping with configure
Zach Lipton:
# Ok, great. Thanks. I'll see what I can do.
#
# Random idea off the top of my head, note that this assumes
# that configure
# will use perl to work, if this is not going to be true, this
# probably won't
# work.
Well, for now we're using Perl for Configure, but that won't be possible
in the final version. Nasty bootsrapping issues with that. :^)
# I am the Bugzilla Installation Owner and have been tinkering
Cool, credentials... ;^)
# with similar
# things lately to setup a new install system for Bugzilla. I
# have sample code
# that would do part of the work, though it would need
# tinkering to work for
# parrot. The idea is to have the Configure.pl script itself
# run .cm files
# located in Config/, these .cm files (configuremodule) would
# do the actual
# work of configuration. The Conf.pm module would contain a set
# of API's for
# the .cm files to call. (this is all portable of course...) An
# example .cm
# file would be like:
#
# #Basicquestions.cm, by Zach Lipton
# #This file under some license TBA
# package Conf::Basicquestions;
# use Conf;
# my $output = >>"EOF";
# Now I need to ask you a few questions about your
# configuration so I can
# configure your copy of parrot.
# EOF;
# output(
# # the format for ask is ask(questionname,question,defaultanswer);
# ask('name','What is your name?','Larry Wall');
# ask('quest','What is your quest?','To build a better perl');
# ask('standards','What group creates many standards and sounds
# like falling
# off the bridge?','IEEE');
I'll have to remember that one... :^)
# # ask() will handle asking the question, supplying a default,
# and storing
# the answer in %c
# # the last .cm file will then generate conf files, makefiles, etc
#
# There are other API's in Conf.pm so I can sniff an answer
# from the env and
# then write:
# setconf('name','lwall');
#
# Based on sniffing for the current username, etc...
#
# So anyway, what do you think about this? Again, I have real
# code which I can
# supply, but am I way offbase here? To me, the main advantage
# is getting
# everything out of a "monster-script" and breaking it up into packages.
That's actually quite similar to the Configure.pl we currently have,
except for the modularity aspect.
I can see Configure split up into several CMs:
-manifest check
-defaults from Config.pm
-defaults from previous Parrot::Config
-defaults from the command line
-asking questions
-figuring out what headers are available
-first test program
-config.h
-Parrot::Types
-Parrot::Config
-second test program
-config.h again
-Makefile
I may decide to hack on this idea later. (Probably not, though--I'm
still having something resembling 'fun' with the regexp ops.)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
[PATCH] Computed goto, super-fast dispatching.
All:
Here's a list of the things I've been doing:
* Added ops2cgc.pl which generates core_cg_ops.c and core_cg_ops.h from
core.ops, and modified Makefile.in to use it. In core_cg_ops.c resides
cg_core which has an array with the addresses of the label of each opcode
and starts the execution "jumping" to the address in array[*cur_opcode].
* Modified interpreter.c to include core_cg_ops.h
* Modified runcore_ops.c to discard the actual dispatching method and call
cg_core, but left everything else untouched so that -b,-p and -t keep
working.
* Modified pbc2c.pl to use computed goto when handling jump or ret, may be
I can modified this once again not to define the array with the addresses
if it's not going to be used but I don't think that in real life a program
won't use jump or ret, am I right?
Hope some one find this usefull.
Actual dispatcher:
#./test_prog examples/assembly/mops.pbc
Iterations:1
Estimated ops: 3
Elapsed time: 22.642827
M op/s:13.249229
Actual dispatcher -O3:
#./test_prog examples/assembly/mops.pbc
Iterations:1
Estimated ops: 3
Elapsed time: 14.651587
M op/s:20.475598
With this patch:
#./test_prog examples/assembly/mops.pbc
Iterations:1
Estimated ops: 3
Elapsed time: 8.398673
M op/s:35.719929
With this patch and -O3:
#./test_prog examples/assembly/mops.pbc
Iterations:1
Estimated ops: 3
Elapsed time: 4.554578
M op/s:65.867792
With -O3:
#./mops
Iterations:1
Estimated ops: 3
Elapsed time: 1.023564
M op/s:293.093515
#java -Xint mops
Iterations:1
Estimated ops: 3
Elapsed time: 9.70542915344
M op/s:30.911900945224637
Daniel Grunblatt.
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.43
diff -u -r1.43 Makefile.in
--- Makefile.in 2001/11/02 12:11:15 1.43
+++ Makefile.in 2001/11/04 01:05:01
@@ -8,14 +8,15 @@
$(INC)/memory.h $(INC)/parrot.h $(INC)/stacks.h $(INC)/packfile.h \
$(INC)/global_setup.h $(INC)/vtable.h $(INC)/oplib/core_ops.h \
$(INC)/runops_cores.h $(INC)/trace.h $(INC)/oplib/vtable_ops.h \
-$(INC)/pmc.h $(INC)/resources.h $(INC)/platform.h
+$(INC)/pmc.h $(INC)/resources.h $(INC)/platform.h $(INC)/oplib/core_cg_ops.h
+
O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) \
core_ops$(O) memory$(O) packfile$(O) stacks$(O) string$(O) encoding$(O) \
chartype$(O) runops_cores$(O) trace$(O) vtable_ops$(O) classes/intclass$(O) \
encodings/singlebyte$(O) encodings/utf8$(O) encodings/utf16$(O) \
encodings/utf32$(O) chartypes/unicode$(O) chartypes/usascii$(O) resources$(O) \
-platform$(O)
+platform$(O) core_cg_ops$(O)
#DO NOT ADD C COMPILER FLAGS HERE
#Add them in Configure.pl--look for the
@@ -101,6 +102,11 @@
stacks$(O): $(H_FILES)
+core_cg_ops$(O): $(H_FILES) core_ops.c
+
+core_cg_ops.c $(INC)/oplib/core_cg_ops.h: core.ops ops2cgc.pl
+ $(PERL) ops2cgc.pl core.ops
+
core_ops$(O): $(H_FILES) core_ops.c
core_ops.c $(INC)/oplib/core_ops.h: core.ops ops2c.pl
@@ -130,8 +136,9 @@
cd docs; make
clean:
- $(RM_F) *$(O) *.s core_ops.c $(TEST_PROG) $(PDISASM) $(PDUMP)
+ $(RM_F) *$(O) *.s core_cg_ops.c core_ops.c $(TEST_PROG) $(PDISASM) $(PDUMP)
$(RM_F) $(INC)/vtable.h
+ $(RM_F) $(INC)/oplib/core_cg_ops.h
$(RM_F) $(INC)/oplib/core_ops.h
$(RM_F) $(INC)/oplib/vtable_ops.h vtable_ops.c vtable.ops
$(RM_F) $(TEST_PROG) $(PDISASM) $(PDUMP)
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.33
diff -u -r1.33 interpreter.c
--- interpreter.c 2001/10/26 18:58:02 1.33
+++ interpreter.c 2001/11/04 01:05:01
@@ -13,6 +13,7 @@
#include "parrot/parrot.h"
#include "parrot/interp_guts.h"
#include "parrot/oplib/core_ops.h"
+#include "parrot/oplib/core_cg_ops.h"
#include "parrot/runops_cores.h"
Index: pbc2c.pl
===
RCS file: /home/perlcvs/parrot/pbc2c.pl,v
retrieving revision 1.3
diff -u -r1.3 pbc2c.pl
--- pbc2c.pl2001/10/24 13:03:42 1.3
+++ pbc2c.pl2001/11/04 01:05:02
@@ -65,9 +65,11 @@
# compile_byte_code()
#
-my $pc;
+my $pc = 1;
+my $op;
my $new_pc = 1;
my @args = ();
+my @pcs = ();
sub compile_byte_code {
my ($pf) = @_;
@@ -85,11 +87,59 @@
int
main(int argc, char **argv) {
-inti;
+intcur_opcode;
struct Parrot_Interp * interpreter;
struct PackFile_Constant * c;
struct PackFile * pf;
+END_C
+my $cursor = 0;
+my $length = length($pf->byte_code);
+
+my $offset=0;
+
+my $op_code;
+my @addr;
+my
Re: [perl6]RE: Helping with configure
Ok, great. Thanks. I'll see what I can do.
Random idea off the top of my head, note that this assumes that configure
will use perl to work, if this is not going to be true, this probably won't
work.
I am the Bugzilla Installation Owner and have been tinkering with similar
things lately to setup a new install system for Bugzilla. I have sample code
that would do part of the work, though it would need tinkering to work for
parrot. The idea is to have the Configure.pl script itself run .cm files
located in Config/, these .cm files (configuremodule) would do the actual
work of configuration. The Conf.pm module would contain a set of API's for
the .cm files to call. (this is all portable of course...) An example .cm
file would be like:
#Basicquestions.cm, by Zach Lipton
#This file under some license TBA
package Conf::Basicquestions;
use Conf;
my $output = >>"EOF";
Now I need to ask you a few questions about your configuration so I can
configure your copy of parrot.
EOF;
output(
# the format for ask is ask(questionname,question,defaultanswer);
ask('name','What is your name?','Larry Wall');
ask('quest','What is your quest?','To build a better perl');
ask('standards','What group creates many standards and sounds like falling
off the bridge?','IEEE');
# ask() will handle asking the question, supplying a default, and storing
the answer in %c
# the last .cm file will then generate conf files, makefiles, etc
There are other API's in Conf.pm so I can sniff an answer from the env and
then write:
setconf('name','lwall');
Based on sniffing for the current username, etc...
So anyway, what do you think about this? Again, I have real code which I can
supply, but am I way offbase here? To me, the main advantage is getting
everything out of a "monster-script" and breaking it up into packages.
Zach
On 11/3/01 2:47 PM, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> Zach Lipton:
> # Hello everybody
> #
> # I am interested in helping out with configure. I don't know
> # too much about
> # parrot, but I have decent perl skills (I can do what I want
> # to do when I
> # want to do it) and am interested in helping out. What can I
> # do to help?
> # (time to spew the to-do list ;)
>
> Welcome to the team! Right now Configure is pretty stable. Most of the
> work in the internals at the moment seems to be Simon hacking away at
> getting PMCs (basically variables) working. You may just want to poke
> around the Parrot package for now and get familiar with things.
>
> Another thing you can try is implementing a little language for Parrot.
> There are a couple examples of these in the languages/ directory of the
> Parrot source distribution. Obviously you'll need to know Parrot
> assembly to do that, but it's really not as hard as you'd think--the
> sort of generalizations used for a Parrot compiler are often easier to
> deal with then trying to implement a specific algorithm in assembler.
> (Probably because Parrot is a pretty high-level sort of assembler.)
>
> Whatever you do, have fun, and Happy Hacking!
>
> --Brent Dax
> [EMAIL PROTECTED]
> Configure pumpking for Perl 6
>
> When I take action, I'm not going to fire a $2 million missile at a $10
> empty tent and hit a camel in the butt.
> --Dubya
>
Re: Opcode numbers
--- "Gregor N. Purdy" <[EMAIL PROTECTED]> wrote:
> Brian --
>
> > > None of these are issues with the approach I've been
> working on /
> > > advocating. I'm hoping we can avoid these altogether.
> > >
> >
> > I think this is a cool concept, but it seems like a lot
> of overhead with
> > the string lookups.
>
> I'm hoping we can keep the string lookups in order to
> sidestep the
> versioning issue. They can be made pretty cheap with a
> hashtable or search
> tree, and the lookups only happen once when we load. And,
> we may even be
> able to create the tree or hash table structure as part
> of the oplib.so,
> so we don't even have to pay to construct it at run time.
> I guess I'm
> making the provisional assumption that by the type we go
> out and
> dynamically load the oplib, a few op lookups by name
> won't be too big a
> deal if we are smart about it. Of course, I could be
> wrong, but I'd like
> to see it in action before passing judgement on it.
[snip]
Better than doing two string lookups for every op we use
("library", "op_name"), we can vector the library through
the fixup section. This is sort of how I at least envision
accessing global variables: the fixup has an entry
(PAR_FIXUP_GLOBVAR, strtab_ref("$foo")), where strtab_ref()
is the index of a string in the string table. So loading
another oplib becomes as simple as (PAR_FIXUP_OPLIB,
"core"). The individual op descriptors then simply
reference the fixup for that library, which after fixup
contains the global index of the library. Actually, if
libraries are good about not reusing op numbers, we don't
have to do _any_ string lookups. Since we're building each
module's op table at load time anyway, we don't loose any
cache space by not reusing op numbers, since unused ops
will never show up in any module's table.
e.g.
..use core
..use perl
set I0, 2
set I1, 3
add I3, I0, I1
fetch P0, "$foo"
inc P0
produces
# .section .fixup
PAR_FIXUP_OPLIB, 1
PAR_FIXUP_OPLIB, 2
PAR_FIXUP_OPTABLE_SIZE, 4 # put this here so .optable can
# be processed w/o any special
# cases and we can prealloc the
# table
PAR_FIXUP_VARREF, 3# this becomes the pointer to
the
# entry in the symbol table (not
# the variable itself - its slot
# in the table so that aliasing
# works right)
# .section .strtab
"core"
"perl"
"$foo"
# .section .optable
1, 54 # core::set_i_ic
1, 33 # core::add_i_i_i
2, 1 # perl::fetch_p_ic
2, 23 # perl::inc_p
# .section .text
# numbers are the actual opcode/operand values
1 0 2
1 1 3
2 3 0 1
3 0 4
4 0
By using this scheme we manage to not do _any_ string
lookups, and if we pick our base set of ops well enough
that we don't end up obsoleting many of them, we also won't
be using as much memory as the string lookups would
require.
-- BKS
__
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
Re: Opcode numbers
On Sat, Nov 03, 2001 at 09:40:14PM -0500, Gregor N. Purdy wrote: > Let me try to illustrate what I'm thinking a little more clearly. The > program: > > .use core > set I0, 5 > set I1, 37 > add I2, I0, I1 > print I2 > print "\n" > end > > would have an opcode_table in the packfile: > > 5# Number of opcodes > core, set_i_ic # Opcode 0 > core, add_i_i_i # Opcode 1 > core, print_i# Opcode 2 > core, print_sc # Opcode 3 > core, end# Opcode 4 Ahh, now I'm seeing what you're meaning is. I like. I like a lot. It seems quite elegant... though it also seems like it'd have a /lot/ of overhead. But we'll see. (It shouldn't be /too/ bad, because in a real system, we won't be loading all that many oplibs, I should think). -=- James Mastros
[PATCH] Assembler.pm modification
The included patch modifies Parrot::Assembler to open the Parrot::OpLib
directory and collect operations from the files in that directory,
instead of being hardwired to use only Parrot::OpLib::core.
Unfortunately relative paths can't be used because the assembler script
runs from different directories.
--
--Jeff
<[EMAIL PROTECTED]>
diff -ru parrot/Parrot/Assembler.pm parrot_orig/Parrot/Assembler.pm
--- parrot/Parrot/Assembler.pm Sat Nov 3 19:04:08 2001
+++ parrot_orig/Parrot/Assembler.pm Sat Nov 3 22:50:04 2001
@@ -33,7 +33,6 @@
use Getopt::Long;
use Parrot::Op;
-use Parrot::OpLib::core;
#use Parrot::Opcode;
@@ -290,10 +289,25 @@
my %opcodes;
-foreach my $op (@$Parrot::OpLib::core::ops) {
- $opcodes{$op->full_name} = $op;
+use Cwd;
+cwd()=~m,^(.*)/parrot,;
+my $oplib_path = "$1/parrot/Parrot/OpLib";
+
+opendir DIR,$oplib_path or
+ die "Couldn't open $oplib_path";
+my @op_packages = grep { -f "$oplib_path/$_" and !/^\./ }
+ readdir DIR;
+closedir DIR;
+s/\.pm// for @op_packages;
+
+{ no strict 'refs';
+ for(@op_packages) {
+require "$oplib_path/$_.pm";
+for(@${'Parrot::OpLib::'.$_.'::ops'}) {
+ $opcodes{$_->full_name}=$_;
+}
+ }
}
-
Yet another switch/goto implementation
Ok, attached dispatch.diff is the smallest changes
I could think of to get a Configure.pl time choice
for func/switch/goto implementations of DO_OP.
Diff made against a 9:45 PM EST copy from cvs.
ISSUES:
1) goto is gcc-specific.
2) replaces interp_guts.h with do_op.h
3) the goto is done as a funciton definintion and
a #define of DO_OP as said function. The whole
business is written into do_op.h. Not the way to
do it from best C practice, but it works without
jiggering dependencies.
4) the MOPS _don't_ improve
Which means I'm probably missing something terribly
important.
5) Not the cleanest implementation perhaps, but largely
limited to ops2c.pl, and things should be fairly easy
to track down.
6) A few warnings about type mismatch when building with 'goto'
Yet make, make test and mops.pbc run fine. Hmm.
Share and enjoy.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED]printf "%d", 0x2a;
-- deep thought
diff -ur parrot/Configure.pl parrot-with-dispatch/Configure.pl
--- parrot/Configure.pl Fri Nov 2 07:11:15 2001
+++ parrot-with-dispatch/Configure.pl Sat Nov 3 22:00:44 2001
@@ -91,6 +91,8 @@
numlow => '(~0xfff)',
strlow => '(~0xfff)',
pmclow => '(~0xfff)',
+
+do_op_t => 'func',
platform => 'linux',
cp => 'cp',
@@ -118,6 +120,16 @@
prompt("How big would you like integers to be?", 'iv');
prompt("And your floats?", 'nv');
prompt("What is your native opcode type?", 'opcode_t');
+prompt("Opcode dispatch by switch or function ('switch' or 'goto' or 'func')",
+'do_op_t');
+
+if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
+my $not_portable = "
+'goto' opcode dispatch available only with gcc (for now).
+Please rerun and select either 'func' or 'switch'. Sorry\n";
+die $not_portable;
+}
+
unless( $c{debugging} ) {
$c{ld_debug} = ' ';
diff -ur parrot/Makefile.in parrot-with-dispatch/Makefile.in
--- parrot/Makefile.in Fri Nov 2 07:11:15 2001
+++ parrot-with-dispatch/Makefile.inSat Nov 3 22:00:34 2001
@@ -29,6 +29,7 @@
PERL = ${perl}
TEST_PROG = test_prog${exe}
PDUMP = pdump${exe}
+DO_OP_T = ${do_op_t}
.c$(O):
$(CC) $(CFLAGS) ${ld_out}$@ -c $<
@@ -104,13 +105,13 @@
core_ops$(O): $(H_FILES) core_ops.c
core_ops.c $(INC)/oplib/core_ops.h: core.ops ops2c.pl
- $(PERL) ops2c.pl core.ops
+ $(PERL) ops2c.pl -t $(DO_OP_T) core.ops
vtable.ops: make_vtable_ops.pl
$(PERL) make_vtable_ops.pl > vtable.ops
vtable_ops.c $(INC)/oplib/vtable_ops.h: vtable.ops ops2c.pl
- $(PERL) ops2c.pl vtable.ops
+ $(PERL) ops2c.pl -t $(DO_OP_T) vtable.ops
$(INC)/config.h: Configure.pl config_h.in
$(PERL) Configure.pl
diff -ur parrot/interpreter.c parrot-with-dispatch/interpreter.c
--- parrot/interpreter.cFri Oct 26 14:58:02 2001
+++ parrot-with-dispatch/interpreter.c Sat Nov 3 22:00:54 2001
@@ -11,7 +11,7 @@
*/
#include "parrot/parrot.h"
-#include "parrot/interp_guts.h"
+#include "parrot/do_op.h"
#include "parrot/oplib/core_ops.h"
#include "parrot/runops_cores.h"
diff -ur parrot/ops2c.pl parrot-with-dispatch/ops2c.pl
--- parrot/ops2c.pl Wed Oct 17 20:21:03 2001
+++ parrot-with-dispatch/ops2c.pl Sat Nov 3 22:01:04 2001
@@ -1,15 +1,26 @@
#! /usr/bin/perl -w
+
+# vim: expandtab shiftwidth=4 ts=4:
#
# ops2c.pl
#
-# Generate a C header and source file from the operation definitions in
+# Generate a C header and source file from the operation definitions in,
# an .ops file.
#
use strict;
use Parrot::OpsFile;
+use Getopt::Std;
+
+use vars qw($opt_t);
+getopts('t:');
+die "You didn't specifiy how you want DO_OP written!\n
+Use the -t ['func' | 'switch' | 'goto' ] flag, please\n"
+unless $opt_t eq 'func' or $opt_t eq 'switch' or $opt_t eq 'goto';
+my $dispatch = $opt_t;
+
#
# Process command-line argument:
#
@@ -106,19 +117,49 @@
#
my @op_funcs;
+
+my %switch;
+my %goto;
+
my $index = 0;
+my @switch_source_subs = (
+\&map_ret_abs_switch,
+\&map_ret_rel_switch,
+\&map_arg_switch,
+\&map_res_abs_switch,
+\&map_res_rel_switch
+);
+my @goto_source_subs = (
+\&map_ret_abs_goto,
+\&map_ret_rel_goto,
+\&map_arg_switch,
+\&map_res_abs_goto,
+\&map_res_rel_goto
+);
+my @func_source_subs = (
+\&map_ret_abs,
+\&map_ret_rel,
+\&map_arg,
+\&map_res_abs,
+\&map_res_rel);
+
foreach my $op ($ops->ops) {
my $func_name = $op->func_name;
my $arg_types = "opcode_t *, struct Parrot_Interp *";
my $prototype = "opcode_t * $func_name ($arg_types)";
my $args = "opcode_t cur_opcode[], struct Parrot_Interp * interpreter";
my $definition = "opcode_t *\n$func_name ($args)";
-my $source = $op->source(\&map_ret_ab
Re: Opcode numbers
Brian -- > > None of these are issues with the approach I've been working on / > > advocating. I'm hoping we can avoid these altogether. > > > > I think this is a cool concept, but it seems like a lot of overhead with > the string lookups. I'm hoping we can keep the string lookups in order to sidestep the versioning issue. They can be made pretty cheap with a hashtable or search tree, and the lookups only happen once when we load. And, we may even be able to create the tree or hash table structure as part of the oplib.so, so we don't even have to pay to construct it at run time. I guess I'm making the provisional assumption that by the type we go out and dynamically load the oplib, a few op lookups by name won't be too big a deal if we are smart about it. Of course, I could be wrong, but I'd like to see it in action before passing judgement on it. [snip stuff about versioning] > Thoughts? Or am I too tired to be sending email? :) I think its a fine suggestion. I'm just hoping we don't end up having to go there. I like the simplicity of doing things by name. We don't have to care what else happens to an oplib as long as the ops we cared about are still there. Regards, -- Gregor
Re: Opcode numbers
On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> James --
>
> > We're going to have to think about assigning static opcode numbers,
> > instead of the current order-defined. For one thing, we're looking at
> > perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
> > need to:
> > 1) Define an ordering on things like open(i, s|sc, i|ic, i|ic).
> > 2) Define the notation for setting the opcode number in the .ops file.
> > 3) Define what the correct behavor is for when you have holes in the opcode
> >numbering.
>
> None of these are issues with the approach I've been working on /
> advocating. I'm hoping we can avoid these altogether.
>
I think this is a cool concept, but it seems like a lot of overhead with
the string lookups.
How about instead of the string lookups the ops remained a constant per
version.
Once the core is set up, it shouldn't change any, though we'll be adding
new ops later (and possibly be removing some). Given that, and since
the ops are created in a predictable fashion, why not create a version
number for "new" ops in the module. For example, if after the core is
stable we want to add a new debugging op called "dwim". We could add it
to the file (in any location) as:
AUTO_OP dwim() 1.1 {
}
Where 1.1 is the version number. All unversioned core ops (at last
count 292) would be generated first in the order they are defined. Then
all versioned ops in increasing version order in the order they are
defined. This way, version 1 core ops would be in the table from 1-292
and 1.1 ops might be in 293-333. We could specify ".use core 1" to
disallow dwim and friendsor to make backwards compatible code. By
default the whole table would be available.
It would provide some sanity checking without the overhead of doing a
bunch of string lookups on every load. Of course, its not perfect...
Thoughts? Or am I too tired to be sending email? :)
Brian
Re: Beginning of dynamic loading -- platform assistance needed
Thanks. Applied. On Sat, 3 Nov 2001, Jason Diamond wrote: > Here's a minimal patch for the dynamic loading functions on Win32. I punted > on properly implementing Parrot_dlerror for now but the other three should > work. > > How soon can you check in your ops so we can test these? > > Jason. > >
Re: Opcode numbers
James -- > We're going to have to think about assigning static opcode numbers, > instead of the current order-defined. For one thing, we're looking at > perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we > need to: > 1) Define an ordering on things like open(i, s|sc, i|ic, i|ic). > 2) Define the notation for setting the opcode number in the .ops file. > 3) Define what the correct behavor is for when you have holes in the opcode >numbering. None of these are issues with the approach I've been working on / advocating. I'm hoping we can avoid these altogether. Let me try to illustrate what I'm thinking a little more clearly. The program: .use core set I0, 5 set I1, 37 add I2, I0, I1 print I2 print "\n" end would have an opcode_table in the packfile: 5# Number of opcodes core, set_i_ic # Opcode 0 core, add_i_i_i # Opcode 1 core, print_i# Opcode 2 core, print_sc # Opcode 3 core, end# Opcode 4 NOTE: This is a logical view. The constant table would be: 7# Number of constants "\n" # Constant 0, STRING "core" # Constant 1, STRING "set_i_ic" # Constant 2, STRING "add_i_i_i" # Constant 3, STRING "print_i"# Constant 4, STRING "print_sc" # Constant 5, STRING "end"# Constant 6, STRING Which means the opcode_table would look more like this: 5 1, 2 1, 3 1, 4 1, 5 1, 6 (nice and compact). So, the byte code would look like this: 0, 0, 5 0, 1, 37 1, 2, 0, 1 2, 2 3, 0 4 I like this because it is very flexible and compact. Its easy to imagine how this would work with multiple oplibs, again only paying the cost for the ops *used* not the total number of ops in the oplibs. Oplibs are loaded in the interpreter by (the equivalent of) dlopen() and dlsym() calls to get the init function, which returns the pointer to the oplib structure, which contains pointers to the opfunc and opinfo arrays. Since we do lookups by name, these can be indexed by name (and in fact if we want to be really clever, we should be able to emit code via ops2c.pl that lays out a binary search tree or whatever right in the file). Then, we construct the custom opfunc and opinfo tables for a program by using its opcode table info to go get the struct and function pointers and put them together. We don't pay this cost at run time, but we do pay it at load time. The fortunate thing is that small programs pay a small cost and large programs pay a cost proportional to their complexity (assuming number of oplibs and number of ops used is a measure of complexity). This sounds appropriate to me. I have some parts of this working today, including the beginnings of the opcode_table addition to the packfile. The dynamic loading of the core oplib (only that one for now) is working totally fine. I haven't spent any time working on the code to handle multiple oplibs and optable merging yet. If you want to work together on this stuff, we could figure out a way to split things up. I've attached a patch for my current work-in-progress, which is actually broken right now (I've got family here from out of town so I can't dig in and find the problem right now). But, you can use it to see the current state of my thinking (just use it in a fresh sandbox, please). It was working fine a while ago, but the new opcode_table stuff is in its *very* early stages of coding, and there are still lots of holes left. Anyway, check it out, but please be kind given that it isn't intended to work yet... :) I've also attached a version of the patch from 2001-10-20 (which I think I posted once before) that worked at the time. That one only does dynamic loading, though, and doesn't have the starter code for the opcode_table segment of the packfile. Of course, if we don't go this way, then you are right about the issues. :) Regards, -- Gregor Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.35 diff -a -u -r1.35 Makefile.in --- Makefile.in 2001/10/18 11:33:47 1.35 +++ Makefile.in 2001/10/20 20:08:26 @@ -6,13 +6,15 @@ H_FILES = $(INC)/config.h $(INC)/exceptions.h $(INC)/io.h $(INC)/op.h \ $(INC)/register.h $(INC)/string.h $(INC)/events.h $(INC)/interpreter.h \ $(INC)/memory.h $(INC)/parrot.h $(INC)/stacks.h $(INC)/packfile.h \ -$(INC)/global_setup.h $(INC)/vtable.h $(INC)/oplib/core_ops.h \ -$(INC)/runops_cores.h $(INC)/trace.h $(INC)/oplib/vtable_ops.h +$(INC)/global_setup.h $(INC)/vtable.h \ +$(INC)/runops_cores.h $(INC)/trace.h +STRING_OBJS=string$(O) strnative$(O) strutf8$(O) strutf16$(O) strutf32$(O) \ +transcode$(O) + O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) \ -core_ops$(O) memory$(O) packfile$(O) stacks$(O) string$(O) strnative$(O) \ -strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) runops_cores$(O) \ -trace$(O) vtable_ops$(O) +m
Re: Beginning of dynamic loading -- platform assistance needed
Here's a minimal patch for the dynamic loading functions on Win32. I punted on properly implementing Parrot_dlerror for now but the other three should work. How soon can you check in your ops so we can test these? Jason. diff
Opcode numbers
Hey all. We're going to have to think about assigning static opcode numbers, instead of the current order-defined. For one thing, we're looking at perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we need to: 1) Define an ordering on things like open(i, s|sc, i|ic, i|ic). 2) Define the notation for setting the opcode number in the .ops file. 3) Define what the correct behavor is for when you have holes in the opcode numbering. -=- James Mastros
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 07:17:49PM -0500, Gregor N. Purdy wrote: > I've been working on this. I've added an opcode_table section that > contains (oplib, opindex) pairs (they are constant table string indexes to > allow lookup by name). The custom opcode table for the bytecode in the > packfile is produced by scanning this, loading oplibs as they are > referenced. The opcodes for the bytecode are presented in order, and only > the opcodes actually used need be mentioned. So, opcode N for one bytecode > chunk could be a totally different opcode from opcode N in a different > bytecode chunk. This sounds much better then either of my plans. (OTOH, I'd like to see the overhead from the larger number of opcode adds.) I'm going to keep working, and see how our implementations differ. -=- James Mastros
RE: Multi-oplibs 2: packfile format?
Brent -- > How about, instead of just saying 'oplib foo' in the bytecode header, we > say 'first N opcodes of oplib foo'? After all, you generally don't have > any use for opcodes added after you assembled. :^) I agree, although I take it further by allowing you to cherry-pick the ops you need out of the oplib. There should not be any runtime penalty for my approach. Smaller programs have (possibly) smaller opcode tables, and opfunc lookup is as deep as it is now because we flatten the custom opcode table at load time. Regards, -- Gregor
Re: Multi-oplibs 2: packfile format?
James -- > I'm having a parrot-project weekend, y'all might have noticed. Right now, > I'm thinking of multiple oplibs, specificly how to get the bytecode/packfile > to express it. I've been working on this. I've added an opcode_table section that contains (oplib, opindex) pairs (they are constant table string indexes to allow lookup by name). The custom opcode table for the bytecode in the packfile is produced by scanning this, loading oplibs as they are referenced. The opcodes for the bytecode are presented in order, and only the opcodes actually used need be mentioned. So, opcode N for one bytecode chunk could be a totally different opcode from opcode N in a different bytecode chunk. This may be too flexible for some people's liking, but I'd like to see it happen, hoping that we can create some special case capabilities for folks that want more optimization to do things in a more rigid manner. > Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify > the oplib (as an index to the table of oplibs, see the next para), the rest > can identify the opcode. This shouldn't be too bad a limit: 64k opcodes > perl oplib, 64k oplibs per packfile. > There should be a table of oplibs used (probably in the fixup section, but > possibly in imports) in the packfile. Each entry should have the name of > the oplib and a signature. (The index is implicitly inorder.) > > The number one problem I see with this is that when we can dynamicly load > bytecode, different peices might want to have different oplibs. The best > way I see to handle this is to know in the runops core that we're > dispatching to a different set of tables when we cross boundries between > opcode peices. > > I'm going to set about implementing this now. This should be fun... What do you think about what I've written above? Regards, -- Gregor
Re: This is probably a dumb question...
Brent -- > but how do I use an additional .ops file? I'd like to statically > link it in and use it alongside core.ops, but I can't figure it out. > The assembler can't find the opcodes, even after I run ops2pm. Is there > some magical command-line switch I'm not activating or something? This is a great question. The answer is that until we get dynamic loading working its not going to happen. You need a unified opcode list for the interpreter, which I suppose you could create by writing some throwaway code in the interpreter, hardcoding the scans of the particular oplibs you are merging. That code won't be *totally* throwaway because its the same code we need once we have dynamic loading. Now you know why I begged the question by committing some platform- specific dynamic loading stuff the other day. I'm very eager to get this stuff working, but we can't do it until we've got that worked out. I've got dynamic loading working here, and the next step is to dynamically load two oplibs and merge them to create the customized oplib for the bytecode we are executing. As for Simon's comment about getting the assembler to work: I haven't even tried that. If it works, its not on purpose :) Regards, -- Gregor
RE: Multi-oplibs 2: packfile format?
James Mastros: # On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote: # > Here's what I'm thinking: The high 16 bits (or so) of the # opcode can identify # > the oplib (as an index to the table of oplibs, see the next # para), the rest # > can identify the opcode. This shouldn't be too bad a # limit: 64k opcodes # > perl oplib, 64k oplibs per packfile. # Unfornatly, this seems to be a bit on the slow side: # (horrendous benchmarks cut) # # Right now, this is my DO_OPS: # pc = interpreter->opcode_funcs[*pc>>24][*pc&0xFFF](pc, interpreter); # I tried a 16/16 split as well, but core.ops is too big (293 # ops vs. 255 max). # I also tried a 17/15 split, which had about the same speed. # # Ideas? # # Right now, I'm thinking that the opcodes are going to be # assigned to oplibs # linearly (eg the last opcode in core.ops is 292, so the first # opcode in the # next oplib loaded will be 293). However, this means that oplibs can't # expand portably. It also just plain feels ugly. How about, instead of just saying 'oplib foo' in the bytecode header, we say 'first N opcodes of oplib foo'? After all, you generally don't have any use for opcodes added after you assembled. :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, I'm not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Re: Multi-oplibs 2: packfile format?
On Sat, 3 Nov 2001, Simon Cozens wrote: > On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote: > > Right now, I'm thinking that the opcodes are going to be assigned to oplibs > > linearly (eg the last opcode in core.ops is 292, so the first opcode in the > > next oplib loaded will be 293). > > I thought that Dan's plan was that oplibs *would* grow linearly. I could > be wrong, though. That's the plan, yep. We'll have to make it such that oplibs can tell us how many opcodes it has, as well as force placement of the oplib functions in the global (or scope-local) opcode table. Dan
RE: Helping with configure
On Sat, 3 Nov 2001, Brent Dax wrote: > Zach Lipton: > # Hello everybody > # > # I am interested in helping out with configure. I don't know > # too much about > # parrot, but I have decent perl skills (I can do what I want > # to do when I > # want to do it) and am interested in helping out. What can I > # do to help? > # (time to spew the to-do list ;) > > Welcome to the team! Right now Configure is pretty stable. Ah, but we can fix that! :) Seriously, configure could use: *) A more abstract makefile.in. "rm -r" is definitely not portable... *) A start in on probing the environment the way that perl 5's configure does. Doing this portably (heck, doing it at all) is a non-trivial task, but a good one. Dan
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote: > Right now, I'm thinking that the opcodes are going to be assigned to oplibs > linearly (eg the last opcode in core.ops is 292, so the first opcode in the > next oplib loaded will be 293). I thought that Dan's plan was that oplibs *would* grow linearly. I could be wrong, though. -- `After all, we're not all freaky perverts' - Thorfinn
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote: > Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify > the oplib (as an index to the table of oplibs, see the next para), the rest > can identify the opcode. This shouldn't be too bad a limit: 64k opcodes > perl oplib, 64k oplibs per packfile. Unfornatly, this seems to be a bit on the slow side: -g: lilith:/usr/src/parrot-multioplib$ test_prog examples/assembly/mops.pbc Iterations:1 Estimated ops: 3 Elapsed time: 30.220650 M op/s:9.926987 lilith:/usr/src/parrot$ test_prog examples/assembly/mops.pbc Iterations:1 Estimated ops: 3 Elapsed time: 27.459654 M op/s:10.925119 -O3: lilith:/usr/src/parrot-multioplib$ test_prog examples/assembly/mops.pbc Iterations:1 Estimated ops: 3 Elapsed time: 16.901975 M op/s:17.749405 lilith:/usr/src/parrot$ test_prog examples/assembly/mops.pbc Iterations:1 Estimated ops: 3 Elapsed time: 14.848314 M op/s:20.204314 Right now, this is my DO_OPS: pc = interpreter->opcode_funcs[*pc>>24][*pc&0xFFF](pc, interpreter); I tried a 16/16 split as well, but core.ops is too big (293 ops vs. 255 max). I also tried a 17/15 split, which had about the same speed. Ideas? Right now, I'm thinking that the opcodes are going to be assigned to oplibs linearly (eg the last opcode in core.ops is 292, so the first opcode in the next oplib loaded will be 293). However, this means that oplibs can't expand portably. It also just plain feels ugly. -=- James Mastros
RE: Helping with configure
Zach Lipton: # Hello everybody # # I am interested in helping out with configure. I don't know # too much about # parrot, but I have decent perl skills (I can do what I want # to do when I # want to do it) and am interested in helping out. What can I # do to help? # (time to spew the to-do list ;) Welcome to the team! Right now Configure is pretty stable. Most of the work in the internals at the moment seems to be Simon hacking away at getting PMCs (basically variables) working. You may just want to poke around the Parrot package for now and get familiar with things. Another thing you can try is implementing a little language for Parrot. There are a couple examples of these in the languages/ directory of the Parrot source distribution. Obviously you'll need to know Parrot assembly to do that, but it's really not as hard as you'd think--the sort of generalizations used for a Parrot compiler are often easier to deal with then trying to implement a specific algorithm in assembler. (Probably because Parrot is a pretty high-level sort of assembler.) Whatever you do, have fun, and Happy Hacking! --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, I'm not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 09:49:02PM +, Simon Cozens wrote: > Look at vtable.ops. However, this probably doesn't help because we don't > currently have an op that creates PMCs. Even worse, we never seem to do anything with vtable_opinfo (etc). That's the big reason that I started my current project now instead of later. -=- James Mastros
Re: Multi-oplibs 2: packfile format?
On Sat, 3 Nov 2001, Simon Cozens wrote: > On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote: > > No. I say this because I have /no idea/ how they fit into the rest of > > existance. To whit, I don't know how to access them from pasm. I'm not > > nearly good enough to be writing code that I can't test. > > Sombody care to clue me in? > > Look at vtable.ops. However, this probably doesn't help because we don't > currently have an op that creates PMCs. (Dan, how are PMCs going to enter > the system?) There's going to be a new op. Looks like: new Px, iy Creates a new PMC in register X, of type Y. Allocates a new PMC pointer, so if there's something in X already the pointer's overwritten. (Hopefully it's been saved or it'll be GC'd later) To start, the guaranteed PMC types are: < 0 : Reserved to the interpreter (sync objects and such) 0 : undef 1 : Perl scalar 2 : Perl array 3 : Perl hash 4 : Perl list and the rest'll have to be looked up by name from the big hash 'o loaded PMC types. When we have one. :) Anyone care to take a shot at the PMC versions of all the standard opcodes while we're at it? Dan
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote: > No. I say this because I have /no idea/ how they fit into the rest of > existance. To whit, I don't know how to access them from pasm. I'm not > nearly good enough to be writing code that I can't test. > Sombody care to clue me in? Look at vtable.ops. However, this probably doesn't help because we don't currently have an op that creates PMCs. (Dan, how are PMCs going to enter the system?) You're probably better off adding a temporary flag to test_main.c, as I did when I was adding string support. I'll try and look at this tomorrow, if I can. Simon 1 -- ADVERSITY: That Which Does Not Kill Me Postpones the Inevitable http://www.despair.com
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 09:00:25PM +, Simon Cozens wrote: > Cool. Any chance you could write some of the functions in > classes/scalarclass.c? :) No. I say this because I have /no idea/ how they fit into the rest of existance. To whit, I don't know how to access them from pasm. I'm not nearly good enough to be writing code that I can't test. Sombody care to clue me in? -=- James Mastros
Re: Multi-oplibs 2: packfile format?
On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote: > Hey all. > I'm having a parrot-project weekend, y'all might have noticed. Cool. Any chance you could write some of the functions in classes/scalarclass.c? :) More details coming soon, once Robert and I have finished playing with the request tracker. -- "Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers
Re: java vs. parrot mops
On Thu, Nov 01, 2001 at 12:18:18PM -0300, Daniel Grunblatt wrote:
> < while (pc) { DO_OP(pc, interpreter); }
> ---
> > just_do_it(interpreter,pc);
This is quite boring, I know, but could we have a definition of
this function? :)
(Also, I much prefer to see diffs in unified format - use the -u
flag to diff)
--
"I don't think so," said Rene Descartes. Just then, he vanished.
Multi-oplibs 2: packfile format?
Hey all. I'm having a parrot-project weekend, y'all might have noticed. Right now, I'm thinking of multiple oplibs, specificly how to get the bytecode/packfile to express it. Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify the oplib (as an index to the table of oplibs, see the next para), the rest can identify the opcode. This shouldn't be too bad a limit: 64k opcodes perl oplib, 64k oplibs per packfile. There should be a table of oplibs used (probably in the fixup section, but possibly in imports) in the packfile. Each entry should have the name of the oplib and a signature. (The index is implicitly inorder.) The number one problem I see with this is that when we can dynamicly load bytecode, different peices might want to have different oplibs. The best way I see to handle this is to know in the runops core that we're dispatching to a different set of tables when we cross boundries between opcode peices. I'm going to set about implementing this now. -=- James Mastros
Helping with configure
Hello everybody I am interested in helping out with configure. I don't know too much about parrot, but I have decent perl skills (I can do what I want to do when I want to do it) and am interested in helping out. What can I do to help? (time to spew the to-do list ;) Zach
pdump.pl
Hey all. This is a (fairly stupid) pbc dumper, including a dissassembler. I say fairly stupid because it creates code that won't assemble, because it tries to do a very literal translation back to pasm. Sample output (of the bytecode part; the rest is pretty non-contriversial): set_i_ic I0, 32 # 55 0 32 set_i_ic I1, 0 # 55 1 0 chr_s_i_sc S0, I0, str_const(0) # 185 0 0 0 print_sc str_const(1) # 27 1 gt_i_ic_ic I0, 99, 6 # 87 0 99 6 print_sc str_const(2) # 27 2 print_i I0 # 22 0 print_sc str_const(3) # 27 3 print_s S0 # 26 0 inc_iI0 # 124 0 add_i_i_ic I1, I1, 8 # 101 1 1 8 cmod_i_i_ic I2, I1, 80 # 106 2 1 80 print_sc str_const(4) # 27 4 set_i_ic I1, 0 # 55 1 0 lt_i_ic_ic I0, 127, -33 # 75 0 127 -33 print_sc str_const(4) # 27 4 end # 0 (As you can see, the formating is rather ugly, and it produces "str_const(n)" constructions instead of substituting in the constant's value. That's what is uncompileable. Surprisingly (to me, anyway), using a constant integer instead of a label works.) Hope that this is useful. -=- James Mastros pdump.pl
Re: This is probably a dumb question...
On Sat, Nov 03, 2001 at 09:46:06AM -0800, Brent Dax wrote: > but how do I use an additional .ops file? I'd like to statically > link it in and use it alongside core.ops, but I can't figure it out. To let the assembler know about it, add a line like use Parrot::OpLib::foo; to Parrot/Assemble.pm -- "You can have my Unix system when you pry it from my cold, dead fingers."
This is probably a dumb question...
but how do I use an additional .ops file? I'd like to statically link it in and use it alongside core.ops, but I can't figure it out. The assembler can't find the opcodes, even after I run ops2pm. Is there some magical command-line switch I'm not activating or something? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, Im not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Re: BIGNUM memory and questions (was Re: Rules for memory allocationand pointing)
On Sat, 3 Nov 2001, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> 2) A buffer object has the structure:
>
> DS> struct {
> DS>void *memory;
> DS>INTVAL size;
> DS> }
>
> some questions.
>
> i am declaring a BIGNUM struct which points to an array of BIGNUM_WORDs
> (longest native integers). do i have to declare it like that? or will
> the GC work with any pointer type and cast it for me?
The GC will cast appropriately.
> also since some platforms require alignment, will i be able to assure
> that buffer is BIGNUM_WORD aligned?
Good question. The buffer will have a guaranteed natural bast-case
alignment for the platform you're on. (We don't want to segfault because
we're misaligning an array of doubles or __int128s)
> finally, i need the size in BIGNUM_WORDs. so should i have both a byte
> size as you do and my own count of BIGNUM_WORDs?
Yep. Especially because the size is the total buffer size--if you're
using less, you'd want a separate length to note that.
> and since we are on this topic, how worried should i be about freeing or
> not? there will be times when the BIGNUM package will need to allocate
> BIGNUM temps and can then explicitly reuse or free them. should (some
> form of) free be called or should i let the memory leak for the GC to
> pick up later?
Just let it leak--the GC system will clean things up appropriately.
> there will also be needs for realloc type calls. will
> there be support for that?
Yup.
> what about allocating zeroed memory (i know
> bzero is easy to call) which make life simpler for BIGNUM?
Yup. Enough people will want it that it makes sense.
> BTW we have basic multiword BCD add subtract working. scaling and
> conversions are next.
Yay! Cool. The rest of the issues can be dealt with separately. (Sizes and
things will probably be something passed in at bignum construction time or
something like that)
Dan
RE: [Patch] Win32 Parrot_floatval_time Improved (1/1)
Richard J Cox: # Firstly, 8am code this morning builds on Win32 without # problem, other than # configure.pl not knowing that link is the linker (which # appears to be down # to ActiveState not knowing). Does it have to know? If so, set it in the hints file (hints/mswin32.pl). --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, I'm not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Re: Rules for memory allocation and pointing
At 03:19 AM 11/3/2001 -0500, Michael L Maraist wrote: >On Friday 02 November 2001 05:27 pm, Dan Sugalski wrote: >I hope rellocation can be handled efficiently. I have these images in my >head of multiple references to the same memory structure.. Relocating would >involve finding each and every referrer. That's a many to many association >O(n^2). Perhaps you suggest that PMC's themselves are not relocatable, and >thus only a single PMC referes to each object in relocation-space. The current plan is to have PMCs and buffer objects be non-moveable, so if multiple things wanted to point to a buffer they'd really point to the buffer object or the PMC. It's possible that PMCs and buffer objects will be relocatable too, but that's more work for the GC subsystem. Plus it places more restrictions on non-interpreter code caching pointers to things. Handling updating the pointers themselves isn't a big deal. That's a long-solved problem for copying collectors. >Sounds >like multiple heaps to me, but then there are advanced concepts like aliasing >/ shared data-structures, etc. I'm expecting we'll have multiple heaps, yep--if only so we can implement a generational GC system. Otherwise we need a pretty hefty temporary memory space. > > For a buffer to be considered 'live' it must be pointed to by a PMC either > > directly or via a single level of indirection. (If the PMC points to a > > buffer object that has an array of buffer pointers in it) For a PMC to be > > considered live it must be reachable via the interpreter's root set. > >I'm missing the implications of being "live" or not. If a buffer's not live, we ignore it and potentially stomp on it when we're allocating memory or going a compaction of the heap. > > There will be a mechanism to register PMCs with the interpreter to note > > they're pointed to by something that the interpreter can't reach. (For > > example, a structure in your extension code, or via a pointer stashed in > > the depths of a buffer object, or referenced by another interpreter) This > > "foreign access" registry is considered part of an interpreter's root set. > >Does this mean a flag exists such that when XS-code references a PMC it is >set? Nope. It means that if your extension code has something like: static PMC *cache; up at the top, you'd darned well better do a: Parrot_PMC_Register(cache); to tell us you're stowing away a pointer to a PMC, otherwise we'll GC/destruct the thing. >Lastly, is there any facility for private dynamic memory w/in XS code.. Such >as algorithms that don't utilize PMC structures; especially parrot-ignorant >algorithms. I assume they'd need heap-space avoided by the GC. Yep, traditional alloc/free memory will be available, as will immoveable memory (for those cases where you're passing it to an external library or interrupt handler or something). Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Beginning of dynamic loading -- platform assistance needed
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andy Dougherty) wrote: > On Fri, 2 Nov 2001, Jason Diamond wrote: > > > Then we could have a "driver" for each platform that consisted of > > nothing > > but #include's of other .c files. Making a directory for each > > platform might > > be appropriate if we do this. I bet that most of the posix "platform" > > source > > files would be #include'ed into each of the more specific drivers. > > But one big problem is you can't even name all the platforms! New > platforms appear all the time that you never heard of, and Parrot might > work perfectly well on them, but you don't even know of the platform's > existence at release time. > > Certainly platform-specific files are needed sometimes, but I've not > seen > anything that convinces me that a linux.c file does anything but open > the > floodgates to a maintenance job of maintaining lots of nearly-identical > files. I think the answer is not to assume 2 files (.c&.h) for each platform[1]. Rather a pool of files which configure picks from for the local platform (i.e. something has to know that Ynix uses Solaris like async-io while Znix uses Sys5 like async-io). For some platforms more will be needed (VMS being an obvious example) for others (*ix) fewer. On a previous project this is what I ended up with (some aspects of the systems were very different, some quite close). Which brings me around to the initial build of miniperl (to drive the full configure) which surely doesn't need most of the system dependent functions (e.g. no async-io, only the most simple of time/date functions). Having got a "largely platform independent build" perl we can then perform some data driven operations to work out (1) which modules to include, (2) build some headers (e.g. "platform.h" that includes the selected headers) and (3) what tools and options to use for the build. The question is where to draw the line between the different sub-platform files. (And quite possibily part of the answer is to share files where there are just minor differences[2]). [1] This also avoids having huge files for supporting platforms which need substantial code to achieve Perl6's common "OS abstraction layer". [2] E.g. Use RIO_FAST on one platform and R_IOFAST on another, but used in the same way. -- [EMAIL PROTECTED]
[Patch] Win32 Parrot_floatval_time Improved (1/1)
Firstly, 8am code this morning builds on Win32 without problem, other than configure.pl not knowing that link is the linker (which appears to be down to ActiveState not knowing). Thanks to Hong Zhang ([EMAIL PROTECTED]) for pointing out the GetSystemTimeAsFileTime API. Also adjusts zero time to 1970-01-01T00:00:00 (I can easily create the const for other time is something else is more appropriate). -- [EMAIL PROTECTED] win32_c.diff
Parrot Smoke Nov 2 20:00:01 2001 UTC aix 4.2.1.0
Automated smoke report for patch Nov 2 20:00:01 2001 UTC v0.02 on aix using xlc version 3.1.4.10 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- - - - - nv=double - - iv=int - - iv=int --define nv=double - - iv=long - ? iv=long --define nv=double | | | +- --debugging +--- normal
Parrot Smoke Nov 2 20:00:01 2001 UTC hpux 11.00
Automated smoke report for patch Nov 2 20:00:01 2001 UTC v0.02 on hpux using cc version B.11.11.02 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- - - - - nv=double - - iv=int - - iv=int --define nv=double - - iv=long - ? iv=long --define nv=double | | | +- --debugging +--- normal
