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]