Re: Behaviour of PMCs on assignment
And I show my ignorance yet again. I really need to do some serious
research into how things have changed...
Leopold Toetsch wrote:
It could work, if the sequence is:
$P0 = $P1 + $P2
null $P3
$P3 = $P0 + $P4
The C opcode cuts the life range of C<$P3> because of
its C specifier.
Hmmm...that might work.
But now we have the runtime overhead in each such vtable method (test
for PMCNULL) and one additional function argument to pass.
I don't see the additional argument--dest is already being passed to the
vtable methods. There's a new return value, but no new argument. There
is also a branch on dest == PMCNULL, which is rather suboptimal.
What if, by calling PMCNULL's set_(integer|string|float|pmc) vtable
methods, you actually allocate a new PMC of the appropriate type? In
other words, for null:
PMC* set_integer_native(INTVAL value) {
PMC* ret=pmc_new(INTERP, some_integer_type); /* Er... */
VTABLE_set_integer_native(INTERP, ret, value);
return ret;
}
And then for an integer type:
PMC* add(PMC* value, PMC* dest) {
/* A bunch of fancy logic that boils down to... */
return VTABLE_set_integer_native(INTERP, dest,
VTABLE_get_integer(INTERP, SELF) +
VTABLE_get_integer(INTERP, value)
);
}
Any other type's set_integer_native would be like:
PMC* set_integer_native(INTVAL value) {
PMC_int_val(SELF)=value;
return SELF;
}
(Plus or minus morphing code.)
The big problem is some_integer_type. I'm not really sure what to do
about that.
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: OpsFile hints - one more (perlish) task
I've been all over the ops2c system recently filling in the
documentation (it'll get committed this weekend sometime) so number 2
is something I can certainly do.
BTW is there a reason for the colon at the start of the hints?
Mike
On 27 Mar 2004, at 08:15, Leopold Toetsch wrote:
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An C register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range
of registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have
this autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the
C structure defined in F.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
Re: Windows tinder builds
Dan Sugalski <[EMAIL PROTECTED]> wrote: > The VS/.NET build works fine, though three of the tests fail for odd > reasons. t\op\string.t 1 256 1301 0.77% 123 Missing end t\pmc\perlnum.t 1 256361 2.78% 36 The ugly +/- zero test. Needs further investigation. t\pmc\perlstring.t1 256331 3.03% 30 Missing end leo
Re: MMD vtable functions in bytecode
Dan Sugalski <[EMAIL PROTECTED]> wrote: [ mmd functions ] Another question: ,--[ pdd15 ]-- |While vtable methods may take a continuation, those |continuations may not escape the vtable method's |execution. This is due to the way that vtable methods are |called by the interpreter--once a vtable method is exited |any continuation taken within it is no longer valid and |may not be used. `- This seems to indicate that there is no rule that this isn't allowed generally. You could therefore pass a local label address to another subroutine, which creates a Continuation and invokes that, or pass the Continuation to yet another sub, which the returns to the first. How should we prepare a proper context then, so that when taking the continuation, everything is restored? Its of course possible to achieve that in PASM somehow but you can't do that with PIR. I think, we need some higher-level constructs to deal with Continuations (s. also a recent discussion with Piers). Creating a continuation PMC is effectively the same as the call half of a function call, w/o the call itself. The destination label of a continuation is the other half of the function call, again w/o the call itself. E.g. set P17, P1 # preserve retc & self set P18, P2 pushtopp # setup context cont = newcont cont_label popttopp # restore contex ... # return or branch and: cont_label: poptopp set P1, P17 set P2, P18 But his scheme can only work, when the continuation label is in the same sub or method as the creation of the continuation. leo
Re: OpsFile hints - one more (perlish) task
Michael Scott <[EMAIL PROTECTED]> wrote: > I've been all over the ops2c system recently filling in the > documentation (it'll get committed this weekend sometime) so number 2 > is something I can certainly do. Great, thanks > BTW is there a reason for the colon at the start of the hints? Hysterically yes, s. perldoc Opcode. If Ponie ever needs it, we have some syntax for opcode classes. > Mike leo
Re: Behaviour of PMCs on assignment
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> And I show my ignorance yet again. I really need to do some serious
> research into how things have changed...
> Leopold Toetsch wrote:
>> It could work, if the sequence is:
>>
>>$P0 = $P1 + $P2
>>null $P3
>>$P3 = $P0 + $P4
>>
>> The C opcode cuts the life range of C<$P3> because of
>> its C specifier.
> Hmmm...that might work.
>> But now we have the runtime overhead in each such vtable method (test
>> for PMCNULL) and one additional function argument to pass.
> I don't see the additional argument--dest is already being passed to the
> vtable methods. There's a new return value, but no new argument. There
> is also a branch on dest == PMCNULL, which is rather suboptimal.
Yep.
> What if, by calling PMCNULL's set_(integer|string|float|pmc) vtable
> methods, you actually allocate a new PMC of the appropriate type? In
> other words, for null:
> PMC* set_integer_native(INTVAL value) {
> PMC* ret=pmc_new(INTERP, some_integer_type); /* Er... */
> VTABLE_set_integer_native(INTERP, ret, value);
> return ret;
> }
Well that seems to boil down to move the problem from PerlUndef to
PMCNULL. What is the approprate type? HLL should know it. It's getting
worse IMHO.
A PerlInt/PerlNum ... knows how to morph a destination PerlUndef to the
appropriate type. So should a Python scalar. Moving this to PMCNULL for
*all* different HLL scalars isn't really good.
leo
[PATCH] wrong type for "status" in platform/win32/exec.c
The second arg of GetExitCodeProcess should be a pointer to DWORD, not int,
this was causing a warning on mingw:
src/platform.c: In function `Parrot_Run_OS_Command':
src/platform.c:446: warning: passing arg 2 of `GetExitCodeProcess' from
incompatible pointer type
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html--- config/gen/platform/win32/exec.c~ Wed Mar 3 16:06:08 2004
+++ config/gen/platform/win32/exec.cSat Mar 27 10:29:10 2004
@@ -4,7 +4,7 @@
*/
INTVAL
Parrot_Run_OS_Command(Parrot_Interp interpreter, STRING *command) {
-int status = 0;
+DWORD status = 0;
STARTUPINFO si;
PROCESS_INFORMATION pi;
int free_it = 0;
Re: Behaviour of PMCs on assignment
Ergh. Once agian, sorry if this shows up twice. If someone can tell me a way to be subscribed to the list without actually getting every message (I prefer to read from the archive), that'd be great. Anyway... > This has come up before and the discussion > always semi-warnocks, but Yeah... > 1) Have a version of the binary vtable >methods that create the destination PMC > 2) Make a universal assignment PMC that >takes on the characteristics >of the RHS of the assignment > 3) Have a "this PMC intentionally left blank" >flag to mark blank PMCs >and have vtable methods check that first > #1 doubles the number of vtable entries. Ick. > #2 has the most overhead > #3 leaves it to the vtable methods to check, > which is error prone. Well, as I was saying last summer, #1 is really what the add instruction should have done in the first place, as that would make it behave the same way as it does for ints and floats (replacing the value, not altering the current one), and it is what most high level languages expect, anyway. However, my argument was mostly about the former (that opcode name and IMCC syntax should differentiate between the 2 types of behavior) rather than the latter (that there should be a non-destructive version of PMC add). The Right Thing to do would be to rename the current add op to "add_destructive" or something, and call the new one just "add", acting like add for ints and floats. The imcc "a = b + c" opererator would use the non-destructive version. But judging by the way I was pretty much ignored the first time, and that Dan's already using Parrot at work, and nobody wants to re-write the code they started working on last week, I don't expect that to actually happen. But it would be the Right Thing. whether or not any opcode renaming is done, I'd say that adding the non-destructive ops is probably the best thing to do, as HLLs are going to want them anyway. It certainly makes the compiler's job a lot easier, and would lead to much cleaner output. Otherwise these operations would have to be implemented as methods (or something) in any case where the compiler doesn't know *exactly* what kind of object an arithmetic operation will result in.Re: __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
Expletive/Objects and pdd15
In PDD 15 it says Creating a new class with attributes Adding the attributes a and b to the new class Foo: newclass $P0, "Foo" addattribute $P0, "a", "Foo::a" # This is offset 0 addattribute $P0, "b", "Foo::b" # This is offset 1 maybe I'm just being a numpty but should this not be Creating a new class with attributes Adding the attributes a and b to the new class Foo: newclass $P0, "Foo" addattribute $P0, "a" # "Foo::a" This is offset 0 addattribute $P0, "b" # "Foo::b" This is offset 1 I tried it the other way but could not add attributes to objects but I can do. newclass $P0, "Foo" addattribute $P0, "a" If this is the case there is a patch for pdd15 attached. Harry --- pdd15_objects.pod 2004-03-26 21:57:16.0 + +++ pdd15_objects_new.pod 2004-03-27 22:10:50.0 + @@ -441,8 +441,8 @@ Adding the attributes C and C to the new class C: newclass $P0, "Foo" - addattribute $P0, "a", "Foo::a" # This is offset 0 - addattribute $P0, "b", "Foo::b" # This is offset 1 + addattribute $P0, "a" # "Foo::a" This is offset 0 + addattribute $P0, "b" # "Foo::b" This is offset 1 =head2 Instantiating an object
[DOCS] lib/Parrot
Just committed some new docs for the Parrot::* modules. make html-clean; make html Mike
Re: Languages testing
over in perl-qa, a similar topic just came up, where Schwern answered:
{
Test::Harness just runs the tests you give it. Simplest thing to do is
to just write a little script that has the necessary logic to determine
what
set of tests to run and feed that file list to runtests().
}
However, I notice, looking through the Makefiles for the various
languages, that it's a real hodge-podge.
Some of them use Test::Harness in the Makefile to run their code, some
have their own harness, some eschew a harness and run their tests
individually.
Some just run examples, not tests at all (Bad!).
Attached, find a first pass at a "testall" script that does the best it
can to pull out the information from the various Makefiles and do a
single test harness. Put the script in languages/, and edit
languages/Makefile (or config/gen/makefiles/languages.in if you want it
to stick around) so that test: runs "$(PERL) testall" and doesn't
actually depend on any of the ".test" targets.
It currently sort of allows the following (though my logic isn't
perfect, it mostly works in my current local copy.) ways to specify
tests
+ calling Test::Harness with a glob() pattern.
+ specifying foo.t files somewhere in the test rule.
+ calling your own harness script. (t/harness) (must have a glob
pattern in there.)
As language authors move over to use the various Test modules, this
script /might/ add them to the test run transparently.
Probably the best thing is to agree on a standard way for languages to
run tests, however, that supports both an individual and combined
harness.
My best suggestion along those lines at the moment is to have
everyone's "make test" do "$(PERL) t/harness", which should use
Test::Harness to run their tests. Our global languages "make test" will
call "$(PERL) testall", which will call "$(PERL) t/harness -files" to
get a complete list of all test files required. It will then run its
own Test::Harness.
This approach requires that (a) people use the perl testing harness,
and (b) that their tests be agnostic about the directory they're run
from. (tcl, for example, currently fails every test when run from
"testall" because it does care.)
Feedback?
Oh, and btw:
Failed 77/85 test scripts, 9.41% okay. 195/196 subtests failed, 0.51%
okay.
(I think the astonishing part there is that something actually passed!
=-)
testall
Description: Binary data
On Friday, March 26, 2004, at 02:17 PM, Dan Sugalski wrote:
Another job for the intrepid configure and/or makefile hacker.
Right now, there's a languages-test target in the top level makefile.
This is good.
Unfortunately, the way it works is... sub-good. What it does is do a
"make test" in the languages directory, and that target runs each
language test in turn. Not bad in itself, but it has two problems:
1) tinderbox clients pick up the language test as OK, even when its
not. (cf the sprite/languages tinder build)
2) The language tests stop on the first language that dies hard, which
at the moment is perl 6
So, what I'd like is for someone to figure a way to get all the
languages test harnesses together under a single master harness, so
all the languages will have their tests run all the time, and so
tinderbox is happy with the results. (Get the first part done and I'll
work out the tinder part--that's doable)
--
Dan
--"it's like
this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
--
Will "Coke" Coledawill at coleda
dot com
Re: Languages testing
What, no one's awake? =-)
I've modified my local copy of tcl, and testall so that I can now do
any of the following, e.g. from the top level parrot directory.
cd languages && make test
cd languages/tcl && make test
cd languages && ./tcl/t/cmd_append.t
cd languages/tcl && ./t/cmd_append.t
cd languages/tcl/t && ./cmd_append.t
And all the tests that were gonna pass, do.
I ended up modifying testall to set an environment variable,
PARROT_LANGUAGE_HARNESS, when calling the individual harnesses
languages/tcl/t/harness then checks to see if that's set, and does:
if ($files_only) {
print join("\n",@files);
} else {
runtests(@files);
}
The individual tcl tests now all run parrot from the top level
directory - Here's how:
All of tcl/t/*.t tests use a module in that directory called
"run_.pm". To get both that and Test::More, regardless of where
they're called from, they have:
use lib qw(tcl/t t . ../lib ../../lib ../../lib);
which will find run_.pm regardless of which of the 3 directories
it's called from. Then, run_tcl.pm (e.g.) does:
use lib qw(../lib ../../lib ../../../lib);
use Parrot::Config;
my $path = $INC{"Parrot/Config.pm"};
$path =~ s:lib/Parrot/Config.pm$::;
to figure out the path to the parrot executable.
Is this too evil, or should I go ahead and nuke Russia --- er, I mean,
submit my tcl patches, and then patches to the other languages to make
them do the same?
Regards.
On Sunday, March 28, 2004, at 12:25 AM, Will Coleda wrote:
over in perl-qa, a similar topic just came up, where Schwern answered:
{
Test::Harness just runs the tests you give it. Simplest thing to do is
to just write a little script that has the necessary logic to
determine what
set of tests to run and feed that file list to runtests().
}
However, I notice, looking through the Makefiles for the various
languages, that it's a real hodge-podge.
Some of them use Test::Harness in the Makefile to run their code, some
have their own harness, some eschew a harness and run their tests
individually.
Some just run examples, not tests at all (Bad!).
Attached, find a first pass at a "testall" script that does the best
it can to pull out the information from the various Makefiles and do a
single test harness. Put the script in languages/, and edit
languages/Makefile (or config/gen/makefiles/languages.in if you want
it to stick around) so that test: runs "$(PERL) testall" and doesn't
actually depend on any of the ".test" targets.
It currently sort of allows the following (though my logic isn't
perfect, it mostly works in my current local copy.) ways to specify
tests
+ calling Test::Harness with a glob() pattern.
+ specifying foo.t files somewhere in the test rule.
+ calling your own harness script. (t/harness) (must have a glob
pattern in there.)
As language authors move over to use the various Test modules, this
script /might/ add them to the test run transparently.
Probably the best thing is to agree on a standard way for languages to
run tests, however, that supports both an individual and combined
harness.
My best suggestion along those lines at the moment is to have
everyone's "make test" do "$(PERL) t/harness", which should use
Test::Harness to run their tests. Our global languages "make test"
will call "$(PERL) testall", which will call "$(PERL) t/harness
-files" to get a complete list of all test files required. It will
then run its own Test::Harness.
This approach requires that (a) people use the perl testing harness,
and (b) that their tests be agnostic about the directory they're run
from. (tcl, for example, currently fails every test when run from
"testall" because it does care.)
Feedback?
Oh, and btw:
Failed 77/85 test scripts, 9.41% okay. 195/196 subtests failed, 0.51%
okay.
(I think the astonishing part there is that something actually passed!
=-)
On Friday, March 26, 2004, at 02:17 PM, Dan Sugalski wrote:
Another job for the intrepid configure and/or makefile hacker.
Right now, there's a languages-test target in the top level makefile.
This is good.
Unfortunately, the way it works is... sub-good. What it does is do a
"make test" in the languages directory, and that target runs each
language test in turn. Not bad in itself, but it has two problems:
1) tinderbox clients pick up the language test as OK, even when its
not. (cf the sprite/languages tinder build)
2) The language tests stop on the first language that dies hard,
which at the moment is perl 6
So, what I'd like is for someone to figure a way to get all the
languages test harnesses together under a single master harness, so
all the languages will have their tests run all the time, and so
tinderbox is happy with the results. (Get the first part done and
I'll work out the tinder part--that's doable)
--
Dan
--"it's like
this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
