t\pmc\complexok
All tests successful.
Files=1, Tests=26, 3 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Seems to be fixed, should be closed.
> I've disabled all CVS write permissions as part of the transition.
> (Yes, this means wheels are turning.)
CVS will stay readable, but un-writable until tomorrow morning, when I
hope to announce SVN being up. The import is running while I sleep.
I caught I minor issue halfway into the previous
Will Coleda <[EMAIL PROTECTED]> wrote:
> +SKIP: { skip("No BigInt Lib configured", 1) if !$PConfig{gmp};
Good. Still better - as we eventually have more then one bigint lib
configurable - we should define a general 'HAS_BIGINT' for any of these
possible libs and test that symbol.
leo
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Yesterday on IRC chip and I went a bit through the following problem:
> --- integer.pmc 27 Mar 2005 13:14:18 - 1.25
> +++ integer.pmc 5 Apr 2005 16:02:26 - 1.26
> @@ -420,8 +420,23 @@
>
>void add (PMC* value, PMC*
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > + $(RM_F) $(IMCC_DIR)/imcparser.c
> > + $(RM_F) $(IMCC_DIR)/imclexer.c
>
> This isn't quite right, it works only if you have bison/flex and you
> did Configure.pl --maintainer
>
> If you don't change the files and just
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> cvsuser 05/04/04 13:03:46
> Modified:config/gen/makefiles root.in
> Log:
> When generating parser or lexer, remove target .c file first.
[ ... ]
> + $(RM_F) $(IMCC_DIR)/imcparser.c
> + $(RM_F) $(IMCC_DIR)/imclexer.c
This isn't qu
Will Coleda <[EMAIL PROTECTED]> wrote:
> cvsuser 05/04/04 07:13:43
> Fix calling signature so it's in line with leo's recent change of I->J.
>
> Index: parrotinterpreter.pmc
Argh. I must have again "fixed" parrotinterpreter.c - I do remember
these changes.
Thanks for the ci and sorry,
le
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 30, 2005 at 09:11:51AM +0200, Leopold Toetsch wrote:
>> Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
>> > +void freeze(visit_info *info) {
>> > +IMAGE_IO *io = info->image_io;
>> > +io->vtable->push_integer(INTERP,
On Wed, Mar 30, 2005 at 09:11:51AM +0200, Leopold Toetsch wrote:
> Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> > +void freeze(visit_info *info) {
> > +IMAGE_IO *io = info->image_io;
> > +io->vtable->push_integer(INTERP, io, PMC_int_val(SELF));
> > +STRING *
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> +void freeze(visit_info *info) {
> +IMAGE_IO *io = info->image_io;
> +io->vtable->push_integer(INTERP, io, PMC_int_val(SELF));
> +STRING * s = string_from_cstring(INTERP, PMC_data(SELF),
> PMC_int_val2(SELF)/BITS
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:19 PM +0100 3/19/05, Leopold Toetsch wrote:
>>1) builtin methods are living in a class namespace e.g.
>>
>> Float."cos"
>> ParrotIO."open" # unimplemented
> I'm way out of the loop and may have been dealt with in prior mail,
> but are we doing re
At 5:19 PM +0100 3/19/05, Leopold Toetsch wrote:
1) builtin methods are living in a class namespace e.g.
Float."cos"
ParrotIO."open" # unimplemented
I'm way out of the loop and may have been dealt with in prior mail,
but are we doing real method calls for cos() and suchlike things?
That seem
Bob Rogers <[EMAIL PROTECTED]> wrote:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>2) these methods can be called in various ways:
> This doesn't seem to be working for me.
Oops. I did obviously some changes in classes/nci.c instead of the pmc
file.
Thanks for reporting - fixed,
leo
On Thursday 17 March 2005 19:59, Bernhard Schmalhofer wrote:
> Â Generate 'parrot_compiler.pasm' from 'parrot_compiler.imc'.
Generating of pasm files from imc does not work, it is just a debugging aid.
> Â Added three tests, which try to run PASM, PIR and PAST from
> Â 'parrot_compiler.pasm'. Thes
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm currently working on some Parrot bits, including some more cleanup of
> the test suite.
> For that it would be convenient to have commit right in CVS and rights in
> the RequestTracker.
> Could a kind soul set that up? My user ID on auth
Sam Ruby <[EMAIL PROTECTED]> wrote:
> But then you effectively morph the resulting bound method into a NCI
> instead of a PyNCI with the following line of code:
> bound_meth->vtable = Parrot_base_vtables[enum_class_Bound_NCI];
Yes. That's a general problem in all places, where the Parrot core
cr
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
+else if (p->vtable->base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI c
Sam Ruby <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> +else if (p->vtable->base_type == enum_class_NCI) {
> It was requested[1] that I not add any Python specific methods to the
> NCI method... accordingly, the majority of Python methods are morphed to
> a PyNCI class which
[EMAIL PROTECTED] wrote:
+else if (p->vtable->base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI class which subclasses the base NCI class.
- Sam Ruby
[1]
On Wed, Jan 05, 2005 at 03:33:19PM -, Simon Glover wrote:
> cvsuser 05/01/05 07:33:19
>
> Modified:t/pmcperlarray.t
> Log:
>gcov now reports 100% of lines in perlarray.pmc have test coverage
Nice work.
Nicholas Clark
Simon Glover <[EMAIL PROTECTED]> wrote:
> Sorry about that - I converted the test from an existing one for
> ResizableFloatArray, but forgot that in the string case there's a
> much higher load on the GC system due to all the string headers.
Actually the problem aren't the string headers per s
On Tue, 4 Jan 2005, Nicholas Clark wrote:
> On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote:
>
> > +output_is(<<'CODE', <<'OUTPUT', 'pop many values');
> > + new P0, .ResizableStringArray
> > + set I0, 0
> > +L1: set S0, I0
> > + set P0[I0], S0
> > + inc
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote:
>> + lt I0, 10, L1
> ^this^
> really really hurts.
It's already reduced in CVS.
> Nicholas Clark
leo
On Mon, Jan 03, 2005 at 10:13:53PM -, Simon Glover wrote:
> +output_is(<<'CODE', <<'OUTPUT', 'pop many values');
> + new P0, .ResizableStringArray
> + set I0, 0
> +L1: set S0, I0
> + set P0[I0], S0
> + inc I0
> + lt I0, 10, L1
^this^
re
Sam Ruby <[EMAIL PROTECTED]> wrote:
> *** Note to Leo: take a look at the comment in complex.pmc as well as
> the new t/dynclass/pycomplex.t test. Bug in MMD inheritance?
Very likely yes. Creating even a correct static MMD table with proper
inheritance is a tedious job. Getting dynamic i
Sam Ruby <[EMAIL PROTECTED]> wrote:
> cvsuser 04/12/23 04:44:05
>
> Note: change to op issame to make use of VTABLE_is_same.
>inline op issame(out INT, in PMC, in PMC) {
> -$1 = $2 == $3;
> +if ($2 == $3)
> +$1 = 1;
> +else
> +$1 = VTABLE_is_
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
What is the rational for this pythonism in Parrot core?
+The line of code in test case t/pie/b3 that motivates this is:
+
+ print "using", cmp.__name__
+
+Where cmp may be a NCI subroutine.
Python's builtin "cmp" is basially a Sub PMC.
Sam Ruby wrote:
Leopold Toetsch wrote:
What is the rational for this pythonism in Parrot core?
+The line of code in test case t/pie/b3 that motivates this is:
+
+ print "using", cmp.__name__
+
+Where cmp may be a NCI subroutine.
Python's builtin "cmp" is basially a Sub PMC. Parrot Sub's have alre
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
--- nci.pmc7 May 2004 10:33:26 - 1.27
+++ nci.pmc20 Dec 2004 22:27:11 - 1.28
+=item C
+
+Return attribute named C.
+
+=cut
+
+*/
+
+PMC* get_attr_str(STRING* idx) {
+return VTABLE_getprop(
Sam Ruby <[EMAIL PROTECTED]> wrote:
> --- nci.pmc 7 May 2004 10:33:26 - 1.27
> +++ nci.pmc 20 Dec 2004 22:27:11 - 1.28
> +=item C
> +
> +Return attribute named C.
> +
> +=cut
> +
> +*/
> +
> +PMC* get_attr_str(STRING* idx) {
> +return VTABLE_g
Sam Ruby wrote:
Are namespaces subject to garbage collection? Classes may be created on
the fly in Python, and disapear just as quickly.
In Python as well as in Perl. We have to deal with that anyway. Perl6
has the notion of lexically scoped multimethods. Operator overloading
only for one speci
Leopold Toetsch wrote:
Python classes are not namespaces. Nor are they global. They are
dictionaries.
Or, the view is a dictionary-like. The dict is CPython's implementation.
I can imagine that Parrot's class namespaces work as well.
Are namespaces subject to garbage collection? Classes may be
Sam Ruby wrote:
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a global. I
want it stored as a property of a class object.
I presumed that ;) Well, due to the described p
Leopold Toetsch wrote:
Sam Ruby wrote:
My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a global. I
wa
Sam Ruby wrote:
Before this line is executed,
(gdb) p interpreter->ctx.bp
$1 = (struct parrot_regs_t *) 0x40b6bd88
After the above line is executed:
(gdb) p interpreter->ctx.bp
$2 = (struct parrot_regs_t *) 0x40b6bae8
Then is obviously your implementation of get_repr broken.
Two questions c
Sam Ruby wrote:
My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
From the perspective of Parrot, namespaces should be viewed a perfectly
reasonable mechanism fo
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
cvsuser 04/12/15 02:36:29
Modified:.vtable.tbl
Log:
stub in object vtables
[snip]
+void add_parent(PMC* parent)
+void become_parent(PMC* class)
+INTVAL class_type()
+void add_method(STRING* method)
+void r
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2->vtable->get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the "inline
Sam Ruby wrote:
Developers could declare such a dependency
with a IMCC macro, something like this:
.lib python_group
That could be
.class_mapping "Py", "python_group"
OTOH when the classes are built in dynclasses, we can as well hard-code
the entries. We'll see.
This would enable JITs to
Leopold Toetsch wrote:
1) There is a new opcode new Px, Sc:
new P0, "PyInt"
2) If the given class doesn't yet exist, Parrot_autoload_class is called
which has hardcode mapping for "Py" => "python_group", "Tcl" =>
"tcl_group". A bit hackish but working ...
Perhaps longer term, a change to the p
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2->vtable->get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the "inline" portion of the chan
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I don't understand this. At all. But the test case added to pyclass.t
(motivated by test 4 in pie/b3.t) only passes if this change to the
get_repr op is made.
[ ... ]
-op get_repr(out STR, in PMC) {
-$1 = $2->vtable->get_repr(int
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I don't understand this. At all. But the test case added to pyclass.t
> (motivated by test 4 in pie/b3.t) only passes if this change to the
> get_repr op is made.
[ ... ]
> -op get_repr(out STR, in PMC) {
> -$1 = $2->vtable->get_repr(interpret
Not quite:
ld: multiple definitions of symbol _PROXY_STRING
pyproxytype.o definition of _PROXY_STRING in section (__DATA,__common)
pyproxyclass.o definition of _PROXY_STRING in section (__DATA,__common)
Sam Ruby wrote:
cvsuser 04/12/13 19:12:07
Modified:dynclasses pyproxyclass.pmc pyproxy
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'll go back and all the necessary interpinfo calls, but I feel
compelled to ask: why isn't P2 passed?
P2 is a non-preserved register and as such rather improper to hold the
object throughout a whole method.
I wasn't assuming is lasted thro
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I'll go back and all the necessary interpinfo calls, but I feel
> compelled to ask: why isn't P2 passed?
P2 is a non-preserved register and as such rather improper to hold the
object throughout a whole method.
> ... It seems to me quite likely that
> most me
Leopold Toetsch wrote:
cvsuser 04/12/11 04:08:13
Modified:classes sub.pmc
imcc/t/syn op.t
runtime/parrot/library parrotlib.imc
src inter_run.c
t/op gc.t
t/pmcdelegate.t object-meths.t objects.t sub.t
On Sat, Dec 11, 2004 at 04:42:54AM +0100, Leopold Toetsch wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>
> > Just as C returns its first non-false argument, the interpretation
> > of C would be that it returns its single non-false argument, or 1 if
> > both (all?) arguments logically eva
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Just as C returns its first non-false argument, the interpretation
> of C would be that it returns its single non-false argument, or 1 if
> both (all?) arguments logically evaluate to false.
Yep, except *0* if both evaluate to either true or false.
Sam Ruby writes:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of Perl I have installed, I get "day" as the
On Fri, Dec 10, 2004 at 01:28:10PM -0500, Sam Ruby wrote:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of
[ From p6i ]
Patrick R. Michaud writes:
> On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> > Not quite. It gives one value if one is true or 0 (false). This is more
> > information then the perl5 implementation returns. The returned value (if
> > any) is still true but usable, if
On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> >> We need language lawyers ;)
>
> > IANAL, but I am a mathematician.Because C necessarily always
> > depends on *both* its arguments, analogies with C and C are
> > inappropriate.C cannot short-circuit, and it is not sensi
Mike Guy <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote
>> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
> has a different opinion then Parrot (or Perl6?).
> inline op xor(out INT, in INT, in INT) :base_core {
> $1 = ($2 && ! $3) ? $2 : ($3 && !
Mike Guy wrote:
Perl5 C always returns a "standard" boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Try:
perl -le "print 'day' xor 'night'"
On the version of Perl I have installed, I get "day" as the result.
- Sam Ruby
Precedence.
print("day\n" xor "night\n");
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]
Sent: Friday December 10, 2004 13:28
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject
Leopold Toetsch <[EMAIL PROTECTED]> wrote
> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 && ! $3) ? $2 : ($3 && ! $2) ? $3 : 0;
goto NEXT();
}
> We need la
Eirik Berg Hanssen <[EMAIL PROTECTED]> wrote:
> Which Perl5 (xor, undef) would this be? It does not look like the
> result is undef around here:
> [EMAIL PROTECTED]:~$ perl -le 'print defined($_)?"defined":"undef", ": «$_»"
> for map {(undef xor $_), ($_ xor undef), (undef ^ $_), ($_ ^ undef)}
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Sam Ruby <[EMAIL PROTECTED]> wrote:
>
>> I took a look into this. Apparently, in Perl5, the result of xor'ing
>> undef with anything is undef. I'm not suggesting that this is either
>> right or wrong (it actually was surprising to me),
>
> Yep. It do
Eirik Berg Hanssen wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of x
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> -=item C
> IMHO, all of these can go. The invoke methods need to be on the PMCs
> returned by get_class.
That's exactly how it worked - the PMCs get_class returns a PMC of the
same type, so they act as their own class. But the "i
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I took a look into this. Apparently, in Perl5, the result of xor'ing
> undef with anything is undef. I'm not suggesting that this is either
> right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of xor, nor does it
Leopold Toetsch wrote:
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong
inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
I took a look into this. Apparently, in Perl5, the r
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
leo
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Excellent!
Welcome.
> Question: what is the difference (conceptually) between "new" and
> "instantiate"? If they are different, these differences should be
> highlighted. If not, the opcode should be named the same in both cases.
$ perldoc -F ops/pmc.ops
Leopold Toetsch wrote:
I've added a few ops and methods:
* pow MMD function and opcodes
* hash vtable and opcode
Both aren't yet implemented in classes/*
The "new_extended" opcode and vtable got renamed to the more appropriate
"instantiate". classes/complex.pmc has an implementation of this method
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... This patch broke a lot of my code.
All opcode permutations [1] are still valid. Can you please provide a
PASM snippet that doesn't work anymore.
[1] except abs I, N which was the only opcode with an integer result for
a float argument and lcm N,I,I w
At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
Thomas Seiler <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
When is
There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.
Back-to-reading-mode-ly yours,
Michael
On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:29 AM +0100 11/28/04, Leopold Toetsch
Thomas Seiler <[EMAIL PROTECTED]> wrote:
> Another change that need more thought:
> * (is)?g[t,e] N, P variants are *not* redundant
Ops with PMCs aren't changed at all.
,--[ ABI_CHANGES ]-
| The compare and branch opcodes gt, ge, isgt, and isge for
Leopold Toetsch wrote:
[...]
Just if you had 32 N regs used before. It's using only one additional
register.
[...]
I did not touch any PMC ops.
You are of course right, maybe I hadn't had enough coffee this morning.
Sorry for the bother, and keep up the good work.
tom (who is going back into shy-
On Sunday 28 November 2004, Jens Rieks wrote:
> added new TODO test:
> new Px, Ix: argcP is wrong in __init method
minesweeper does not run because of this.
not ok 52 - __init argcP # TODO new Px, Ix: argcP is wrong in __init method
# Failed (TODO) test (t/pmc/objects.t at line 1712)
#
Leopold Toetsch wrote:
>I've checked in intial support for anonymous subroutines.
>
> .sub foo @ANON
>
>creates an anonymous subroutine.
On a semi-related note, can I get a classoffset without doing a hash
lookup? That is, can I store the class number I get assigned somewhere
for quick fetching?
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I can't seem to combine it with "non_prototyped".
.sub "foo" @ANON, non_prototyped
> - Sam Ruby
leo
Thomas Seiler <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>> At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
>>
>>> See also subject "Too many opcodes".
>>>
> >> [...]
> >>
>> Could you undo this please? Now is not the time to be trimming ops out.
When is the time? After another 1000 opc
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
OTOH, it won't hurt anyone and it is already in.
So why bother, unless of course there is a technical reaso
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
* other VMs might already have a negative opcode count w this change ;)
* there are 3 incompatible changes: see ABI_CHANGES
* all other removed opcodes get replaced with equivalent ops
* opcodes got renumbered a
Jens Rieks <[EMAIL PROTECTED]> wrote:
> On Saturday 27 November 2004, Leopold Toetsch wrote:
>> + gt I0, I1, L1 => lt I1, I0, L1
>> + isge I0, 100, I2 => isle I0, I2, 100
> But a>=b (gt I0, I1) is equivalence to b and not to b<=a (lt I1, I0)...? (The same for isge a, b <=> islt
On Sat, Nov 27, 2004 at 10:34:17AM +0100, Leopold Toetsch wrote:
> 1) Almost half of the non-PMC compare and branch opcodes according to:
>
> lt a, b, L1 => ge b, a, L1
I read this and thought of a subtle problem. So I tried some code, and I
surprised myself. I don't think that your logic is
On Saturday 27 November 2004, Leopold Toetsch wrote:
> Â + Âgt I0, I1, L1ÂÂ Â Â Â=> lt I1, I0, L1
> Â + Âisge I0, 100, I2 Â Â=> isle I0, I2, 100
But a>=b (gt I0, I1) is equivalence to b islt b, a)
jens
Leopold Toetsch writes:
> +if (arg->vtable->base_type == enum_class_Key) {
> +while (arg) {
> +UINTVAL flags = PObj_get_FLAGS(arg);
> +if (flags & KEY_register_FLAG) {
> +INTVAL
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Ever since this commit, I've been seeing the following:
> imcc/t/imcpasm/opt0.t2 512 62 33.33% 3 6
> imcc/t/imcpasm/optc.t1 256 61 16.67% 1
Ah, yes. My local parrot has already some of the next changes. So it
does already emit
Leopold Toetsch wrote:
cvsuser 04/11/19 08:28:06
Modified:imcc/t/imcpasm opt0.t optc.t pcc.t
imcc/t/syn bsr.t
Log:
replace invoke P1 in imcc tests
Revision ChangesPath
1.7 +2 -2 parrot/imcc/t/imcpasm/opt0.t
[snip]
- invoke P1/
+ returncc/
Ev
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
>>This would imply a distinct return opcode instead of C.
> That went in, or was supposed to go in, as part of moving the return
> continuation into the interpreter struct. I presume this hasn't
> happened
At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
+I if there are overflow parameters. Otherwise garbage
+=item I0
+
+=item I1-I4
I3 isn't always visible?
Effectively it is, yes.
> ... Fetching the return continuation
+may be expensive, and
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> +I if there are overflow parameters. Otherwise garbage
> +=item I0
> +
> +=item I1-I4
I3 isn't always visible?
> ... Fetching the return continuation
> +may be expensive, and should only be done if truly necessary.
Err, e.g. for returning fr
At 5:39 PM +0100 11/12/04, Leopold Toetsch wrote:
In that thread I also asked:
POSTCOMP subs are executed as soon as compilation is done, once again
with no parameters. Whether they do a whole lot is up in the air, but
that's not my problem, and it'll be useful for compile-and-go systems.
Can th
Leopold Toetsch wrote:
> Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
>
>
>> + if (/^\w+\s+(Parrot_\w+)\(/) {
>
>
> Can we be slightly less strict? Current publics that ought to be APIs
> include these prefixes:
That's a policy decision. I would make a different policy decision
(that i
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> + if (/^\w+\s+(Parrot_\w+)\(/) {
Can we be slightly less strict? Current publics that ought to be APIs
include these prefixes:
IMCC_ PASM/PIR compiler stuff
AST_AST compiler stuff
PF_ Packfile handling low level
PackFile_ sam
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>$P1 = interpinfo .INTERPINFO_CURRENT_CONT
>>$P1 = clone $P1
>>
>>I'm still inclined to make this sequence an opcode, though. The
>>cloning is still necessary, as the return continuation is returned.
> Hrm. I think the returned continuation should b
Piers Cawley <[EMAIL PROTECTED]> wrote:
> And, dammit, making a full continuation isn't something a programmer
> should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
(call
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
>>All~
>>
>>I don't like the idea of having to dig down through the entire return
>>chain promoting these guys. Is there a reason not to use DOD/GC to
>>recycle continuations?
>
> Yes. Speed.
>
> While you can
At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Yes. Speed.
While you can skip some of the digging (since you can stop at the
first pro
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to re
On Thu, Oct 28, 2004 at 10:06:05AM +0200, Leopold Toetsch wrote:
> * all JIT platforms except ppc and i386 are broken
>
> Takers wanted for JIT fixes. See jit/ppc/* for necessary changes.
This patch fixes JIT for the sparc platform (make testj passes
except for the streams and gc_10.pasm where it
Dan Sugalski wrote:
What're we looking at for performance impact on mops.pasm and the other
simple benchmarks?
I've now JITted mops.pasm (and other code) running with indirect
register access. It did slow down, but not because the additional
indirection (all inner loop code is still in register
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What're we looking at for performance impact on mops.pasm and the
> other simple benchmarks?
I didn't look yet. Compiling optimized takes ages here :) Anyway:
Estimate performance impact:
JIT mops.pasm 0 (i386, PPC)
CGP mops.pasm 0 - 1%
plain mo
At 3:33 PM +0200 10/22/04, Leopold Toetsch wrote:
A serious of patches has now eliminated all direct usage of Parrot
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
ind
1 - 100 of 635 matches
Mail list logo
