[EMAIL PROTECTED]:
# Sorry to disrupt your discussion with some loosely related
# question... Could anyone help me determine which development
# tools/IDEs are to be used when hacking at Parrot?
Whatever strikes your fancy. You could even use ed if you wanted
to--although I wouldn't recommend it
On Sat 06 Oct 2001 :58, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 05, 2001 at 05:18:07PM -0700, Zach Lipton wrote:
> > Because the need for a tinderbox testing platform is fairly urgent right now
> > for perl6, I am releasing my (place your favorite adjective in the blank
> > here
I've just committed some files which generate vtable.h; these were
actually left over from my experiments of a *long* time ago. [1] It
might need quite a few changes, but it's a good start, and I think
it's general enough to survive.
The next thing I want to do with it is have something akin to
for add we will end up with
void add( PMC* self, PMC* left, PMC* right );
does this represent:
self = left + right
or some other ordering?
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 10/6/2001 7:50 AM
Subject: vtable.h
I've just committed some files which genera
2 other things
1.) Will each different "type" of PMC have its own vtable, function
definitions, etc or will they all share everything with switches on type in
the function definitions.
2.) Can you give an idea of what you think the macro-ized function should
look like (an example would be great.
On Sat, Oct 06, 2001 at 08:11:30AM -0500, Gibbs Tanton - tgibbs wrote:
> void add( PMC* self, PMC* left, PMC* right );
> does this represent:
> self = left + right
Yes.
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
>> 2.) Can you give an idea of what you think the macro-ized function
should
>> look like (an example would be great.)
>No, because then you'll go away and implement it, and I want to
>encourage
>some fresh blood to do that. :)
Okey Dokey...I promise not to do it :)
>Seriously, before I do tha
I've modified Configure.pl to take defaults from a previous build (if
there was one). This should play nicely with hints, and '--defaults'
by doing the Right Thing. I've added a '--nopolicy' option to disable
this.
Patch below sig.
Alex Gough
--
W.W- "A little nonsense now and then is relishe
On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> Ops/sec:31,716,577.291820
Wowsers. What are you running that thing on?
For comparison, on this machine:
Parrot Ops/sec: 500.00
Python2 ops/sec: 3289276.607351
(Python 1 is slightly faster - at the moment.)
That's not f
On Sat, Oct 06, 2001 at 09:01:34AM -0500, Gibbs Tanton - tgibbs wrote:
> which doesn't look that bad. Really, I would imagine all of this would be
> autogenerated by process_opfunc.pl so it doesn't matter what the longhand
> looks like.
Not really; I expect that "external" code will also manipul
At 03:18 PM 10/6/2001 +0100, Simon Cozens wrote:
>On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> > Ops/sec:31,716,577.291820
>
>Wowsers. What are you running that thing on?
>
>For comparison, on this machine:
>Parrot Ops/sec: 500.00
>Python2 ops/sec: 3289276.607351
>(
On Saturday 06 October 2001 10:58 am, Dan Sugalski wrote:
>
> It's the function pointer indirection, to some extent. The switch dispatch
> loop should help some. Also I don't think you should make too many
> performance comparisons until we've got something equivalent to compare
> with.
Unless we
On 10/06/01 Simon Cozens wrote:
> On Sat, Oct 06, 2001 at 12:44:59AM -0400, Bryan C. Warnock wrote:
> > Ops/sec:31,716,577.291820
>
> Wowsers. What are you running that thing on?
>
> For comparison, on this machine:
> Parrot Ops/sec: 500.00
> Python2 ops/sec: 3289276.607351
> (Python 1
At 11:36 AM 10/6/2001 -0400, Bryan C. Warnock wrote:
>On Saturday 06 October 2001 10:58 am, Dan Sugalski wrote:
> >
> > It's the function pointer indirection, to some extent. The switch dispatch
> > loop should help some. Also I don't think you should make too many
> > performance comparisons unti
At 05:46 PM 10/6/2001 +0200, Paolo Molaro wrote:
>I get about the same number for Parrot on my K6-400, but
>compiling with -O2 gets it up to 11,500,000, so maybe your forgot
>to use -O2 or it may be the laptop in power-saving mode:-)
>The current mono interp can do at least twice that many ops
>us
On Oct 06, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> took up a
keyboard and banged out
> I think that changing from a function based implementation to a switch
> based
> implementation will help on many platforms. Someone did a patch on
> that,
> maybe we could update it and commit it.
I'll r
Index: vtable.tbl
===
RCS file: /home/perlcvs/parrot/vtable.tbl,v
retrieving revision 1.1
diff -u -r1.1 vtable.tbl
--- vtable.tbl 2001/10/06 12:41:57 1.1
+++ vtable.tbl 2001/10/06 16:56:14
@@ -35,5 +35,5 @@
void logical_or
On Sat, 6 Oct 2001, Simon Cozens wrote:
> On Sat, Oct 06, 2001 at 09:01:34AM -0500, Gibbs Tanton - tgibbs wrote:
> > Also, how will adds of different types be handled. In the above if pmc2 is
> > an int and pmc3 is a float we're going to have to know that and do a switch
> > or something to conv
On Sat, 6 Oct 2001, Michael Maraist wrote:
> My question at this point is if the PMC's are polymorphic like Perl5
> or if there is an explicit type type. Polymorphics can make for vary
> large vtable sub-arrays. (int, int_float, int_float_string,
> int_string, etc).
>
> If PMC-types are bit-mask
On Saturday 06 October 2001 01:13 pm, Michael Maraist wrote:
> So would it be something like(ultimtaely put into a macro):
> AUTO_OP add_p_p_p {
> if (!P1)
> CREATE_PMC(P1);
> if (!P2 || !P3)
> throw exception; // however this is done in Parrot
> P2->vtable->add[P3->type]->(interp, P
What are our short- and long-term goals for handling printf formats for
configurable types?
This fixes the ones not dependent on the answer above. I'm also wrapping
some lengthy lines. And why aren't the coding standards up on dev.perl.org?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Index: pac
mask and max_to_alloc are unitialized if the size requested is less that 1.
(Which it could be, since INTVAL is signed.) Of course, if it happens, you
should get what you deserve, but this at least horks them cleanly.
Creation of an UINTVAL (UNTVAL? :-) and subsequent patches will follow
pe
Index: packfile.c
===
RCS file: /home/perlcvs/parrot/packfile.c,v
retrieving revision 1.10
diff -u -r1.10 packfile.c
--- packfile.c 2001/10/06 00:57:43 1.10
+++ packfile.c 2001/10/06 17:53:04
@@ -1507,11 +1507,12 @@
if (!s
No, the behavior of malloc(0) is implementation defined.
-Original Message-
From: Bryan C. Warnock
To: [EMAIL PROTECTED]
Sent: 10/6/2001 12:43 PM
Subject: [PATCH] non-init var possibility
mask and max_to_alloc are unitialized if the size requested is less that
1.
(Which it could be, s
Thanks! Applied.
-Original Message-
From: Bryan C. Warnock
To: [EMAIL PROTECTED]
Sent: 10/6/2001 11:56 AM
Subject: [PATCH] vtable.tbl: REGEX pointer
Index: vtable.tbl
===
RCS file: /home/perlcvs/parrot/vtable.tbl,v
retrievi
I could help you with the process_op_func.pl thing.
Unless, you've already coded it yourself! :-).
Cheers,
Vladimir Bogdanov.
ps. have to figure how to get the WinCVS thing work...
can't seem to be able to access cvs.perl.org. I've used
the following set up:
CVSROOT = :pserver:[EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>
Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> No, the behavior of malloc(0) is implementation defined.
It is, yes, but there are only two legal results according to
the ISO C standard:
"If the size of the space requested is zero, the behavior is
Here's a replacement for my previous patch. This one includes the
following:
Makefile target for "lint" (runs lclint with some very permissive settings)
Fixes some ignored return values
A few minor casts.
--Josh
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Inde
1) Assuming a core set of unoverrideable opcodes 0-128 (so I don't need to
differentiate between core and alternate opcodes.)
2) Maintaining each operation as a block (so that any necessary variables
are declared locally to each case.)
3) Incrementing the pc pointer directly.
4) Accessing the ne
All --
I've had a couple of inspirations since the 0.0.2 release, and this
is the one I can do from home, without the op_info stuff from one
of my earlier patches.
Assume there is a configuration space of runops core behaviors that
is based on various settings of the interpreter flags. If there
On Saturday 06 October 2001 06:38 pm, Bryan C. Warnock wrote:
> 4) Accessing the necessary registers as current written (from the
> interpreter struct.)
The added benchmarks are the caching of the interpreter's register groups
within the runops_*_core. (You can't cache the register set itself, a
All --
My previous post included a patch. This one doesn't because I can't work
on this one away from my office. But, I'm going to put the idea out to
the list, and perhaps someone will beat me to trying it (but, do please
tell me if you are going to so I don't go duplicating your effort when
I g
Bryan --
> > 4) Accessing the necessary registers as current written (from the
> > interpreter struct.)
>
> The added benchmarks are the caching of the interpreter's register groups
> within the runops_*_core. (You can't cache the register set itself, as
> functions may manipulate the register
On Sunday 07 October 2001 01:16, Bryan C. Warnock wrote:
[...]
> One of the more interesting discoveries? Adding a 'default:' case to the
> switch slowed down the Linux runs by several percent.
In that, umh, case: do you have an explanation
or could you provide the code?
Buggs
On Saturday 06 October 2001 07:43 pm, Gregor N. Purdy wrote:
> The Crystalizing Loader proposal I just made would work better if the
> addresses to the current registers were always the same and pushing
> regs onto stacks made copies, rather than having the current reg file
> be the new set of reg
On Saturday 06 October 2001 08:05 pm, Buggs wrote:
> On Sunday 07 October 2001 01:16, Bryan C. Warnock wrote:
> [...]
>
> > One of the more interesting discoveries? Adding a 'default:' case to
> > the switch slowed down the Linux runs by several percent.
>
> In that, umh, case: do you have an exp
Bryan --
> ... But you did bring up one thing - you don't get a
> copy of the registers when you push. That makes it nigh impossible to pass
> values in the registers when you need to save the registers off. Dan?)
This is the part about the current design I have a hard time
understanding. T
On Saturday 06 October 2001 09:07 pm, Gregor N. Purdy wrote:
> > But before we going jumping the gun, let's see what straight registers
> > do. {dum de dum de dum...} Runs about the same for me. (A shade slower
> > on Linux.)
>
> Could you elaborate on this statement please? I'm not sure I follow
I tried removing the bounds checking and adding multiple DO_OPs inside the
while loop. with -O0 the loop unrolling helped, but removing the bounds
checking actually slowed it down. With -O3, neither one helped at all.
39 matches
Mail list logo
