NCI error during make
On OS X 10.2.6 (gcc 3.3) make dies with: perl build_nativecall.pl call_list.txt nci.c nci.c: In function `pcf_i_42p': nci.c:454: error: invalid lvalue in unary `'
Re: Trig functions for vtables
Brent Dax [EMAIL PROTECTED] wrote: Okay, reality check. How often are we going to use acosh? Is it really worth the space in the vtable for that few calls? And why can't we just use find_method? Dan was talking about one vtable slot, holding another vtable for trig and log functions. The newly added vtable-data seems to be that. This trig_log (or data) pointer is shared by all scalar classes. So that takes one additional pointer per vtable and one additional trig_vtable. WRT methods: I did propose a scheme, to implement trig and log methods via find_method, even with a rather low overhead of one *Array* lookup. Doing an hash lookup still suffers badly as shown in the constant key/string discussion, but would be possible too - if needed. I'm really starting to wonder: why do we have only one type of vtable? Why are Closures, Pointers, and Scratchpads forced to implement acosh, they won't. Vtable.tbl already divides vtables into sections. I suggest we take this a step further and express these sections in the vtables itself. Sections that a particular object didn't need would be loaded with a default, in which all of the methods would throw an exception. That's what happening anyway. All unimplemented stuff has a default hook throwing an exception. The result would mean that something like: pmc-vtable-add Might become: pmc-vtable-math-add Seems too expensive to me for the normal math stuff. And: pmc-vtable-add_keyed Forget add_keyed ;-) --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker leo
Re: Pondering argument passing
Steve Fink [EMAIL PROTECTED] wrote:
Just to be sure we're talking about the same thing:
sub f ($a, $b, $c) { ... }
$x = phase_of_moon('waxing') ? \f : \CORE::print;
$x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived functions calls happen too often, but
anyway ...
i.e., I'm calling f() without a prototype.
A builtin that took three parameters would expect them in P5, P6, and
P7. But how do I do that in IMCC for $x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED])?
I am
suggesting
.arg 3
.args _AV_x
.args _AV_y
with some deep magic going on under the hood to get them into the
correct registers, most probably by means of a new, specialized op
because the current way of doing it is ugly and slow.
The current way is to flatten @x and @y and pass the 2 lists, that's it.
That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
I'm not against a specialized .args directive, but first, we need the
normal cases. Then, we can think of optimizations.
You seem to be suggesting something like:
No. My suggestion didn't cover splat arrays. When you don't know, what
sub you are calling, you just have to flatten the splatted args -
currently.
Another question: E6 seems to indicate that splat flattening happens
before parameter binding:
,--[ E6 ]-
|This operator (known as splat) simply flattens its argument into a
|list. Since it's a unary operator, it does that flattening before the
|arguments are bound to their respective parameters.
`-
Before is of course not a definition, when the flattening should happen,
but it seems to indicate, that flattening is done in the caller.
And can the flattening have side effects? What about tied arrary
splats? I can imagine, that the called sub can't flatten the array
because of tieing.
All that stuff has to be defined first, then - when needed - we can
think of optimizations.
leo
Memory leaks
The short story: We have really too much leaks, everywhere: Failed 33/57 test scripts, 42.11% okay. 291/903 subtests failed, 67.77% okay. (A test is considered failing above, when it has more then 3 leaks (which are known to leak currently - the stdio handles)) The longer story: Parrot has sice some time the command line option --leak-test, which explicitely cleans (or should to) up all allocated interpreter structures. I ran testyamd (available in Parrot root), which calls run-yamd: YAMD is Yet Another Malloc Debugger. It can be found at http://www3.hmc.edu/~neldredge/yamd/. (this at least states the README) $ valgrind --leak-check=yes --show-reachable=yes parrot ... shows similar results, though there is currently no test wrapper available. Here is the full report Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/conv.t8 2048128 66.67% 5-12 t/op/globals.t 1 256 21 50.00% 2 t/op/ifunless.t2 512 62 33.33% 3 6 t/op/interp.t 4 1024 74 57.14% 1 4-6 t/op/lexicals.t1 256 61 16.67% 5 t/op/macro.t 15 384016 15 93.75% 1-4 6-16 t/op/rx.t 7 1792237 30.43% 8-9 12-14 21-22 t/op/stacks.t 18 460856 18 32.14% 6 12 17 23-24 26-28 40-41 43 45 51-56 t/op/string.t 24 6144 119 24 20.17% 12-13 20 24 28-29 33 59-63 71-72 77 81 83 87 94-95 98 110 113 116 t/op/time.t1 256 41 25.00% 4 t/op/trans.t 18 460818 18 100.00% 1-18 t/op/types.t 1 256 21 50.00% 1 t/pmc/array.t 6 1536126 50.00% 4-5 8-11 t/pmc/boolean.t1 256 61 16.67% 3 t/pmc/env.t3 768 53 60.00% 3-5 t/pmc/eval.t 3 768 33 100.00% 1-3 t/pmc/exception.t 17 435222 17 77.27% 3-4 6-14 16-17 19-22 t/pmc/intlist.t2 512 92 22.22% 3-4 t/pmc/io.t14 358420 14 70.00% 1-6 8-11 13 15 19-20 t/pmc/iter.t 8 2048108 80.00% 2-9 t/pmc/multiarray.t 2 512 32 66.67% 2-3 t/pmc/nci.t 11 281611 11 100.00% 1-11 t/pmc/orderedhash.t6 1536106 60.00% 2-3 5-8 t/pmc/perlarray.t 6 1536266 23.08% 5 15 22-25 t/pmc/perlhash.t 30 768030 30 100.00% 1-30 t/pmc/perlint.t4 1024184 22.22% 13-15 17 t/pmc/perlnum.t 27 691232 27 84.38% 1-16 21-22 24-32 t/pmc/perlstring.t 7 1792177 41.18% 1-3 9 11 13-14 t/pmc/pmc.t 33 844875 33 44.00% 2-3 8 12 18-20 23-26 29-33 38 41-43 45-50 53 55 57 59 71 73 75 t/pmc/prop.t 1 256 61 16.67% 6 t/pmc/sarray.t 2 512142 14.29% 2 11 t/pmc/scratchpad.t 5 1280 55 100.00% 1-5 t/pmc/timer.t 3 768 33 100.00% 1-3 14 subtests skipped. Failed 33/57 test scripts, 42.11% okay. 291/903 subtests failed, 67.77% okay. leo
Re: NCI error during make
Michael Scott [EMAIL PROTECTED] wrote: On OS X 10.2.6 (gcc 3.3) make dies with: perl build_nativecall.pl call_list.txt nci.c nci.c: In function `pcf_i_42p': nci.c:454: error: invalid lvalue in unary `' I see. Thanks fixed. leo
Re: Trig functions for vtables
On Mon, Sep 22, 2003 at 04:08:24PM -0600, Luke Palmer wrote: And let's not forget our handy trig identities. We definitely don't need all those vtable. Technically, all we need are sine and arccosine. I believe that atan2() is more useful than arccosine, as it returns information about which quadrant the angle is in (to save you working it out) Er, but this doesn't really add to the informed debate. [except that maybe Dan should be suggesting atan2() rather than arctangent] Nicholas Clark
Re: Trig functions for vtables
On Mon, 22 Sep 2003, Gregor N. Purdy wrote: On a related note, I wonder how all this fits in with methods and multimethods? One-arg vtable methods don't have to do multimethod stuff, since you're calling the vtable method on the argument, so it can do the right thing without checking. Two arg vtable methods get less pleasant. I've some code that should go in soon to start the multimethod dispatching in as fast and space-efficient way as I know how. Dan
Re: Pondering argument passing
On Tue, 23 Sep 2003, Leopold Toetsch wrote: Steve Fink [EMAIL PROTECTED] wrote: You seem to be suggesting something like: No. My suggestion didn't cover splat arrays. When you don't know, what sub you are calling, you just have to flatten the splatted args - currently. Another question: E6 seems to indicate that splat flattening happens before parameter binding: ,--[ E6 ]- |This operator (known as splat) simply flattens its argument into a |list. Since it's a unary operator, it does that flattening before the |arguments are bound to their respective parameters. `- Before is of course not a definition, when the flattening should happen, but it seems to indicate, that flattening is done in the caller. Caller flattens, callee binds. That way the caller can have pairs in the arrays in the parameters that'll bind in to named variables in the called function. And can the flattening have side effects? What about tied arrary splats? I can imagine, that the called sub can't flatten the array because of tieing. Right. All flattening happens in the caller. Dan
Re: parrot/t/src/hash.t
Here are some unit tests for the hash.h interface which are PerlHash free. It could be argued that they're superfluous, but given that there may well be other hash PMCs that use this code eventually, it might be worth testing it independently. Tests are always welcome. Thanks, applied. Mike leo
Namespaces and type prefixes
Okay, it's time to deal with a particularly unpleasant topic--cross-language namespace management. This is *only* for those cases where we need to look things up by name in some namespace (either global or lexical), and doesn't affect what we do with the PMC we get back once we've done that. Basically, the problem is this: Perl, along with a number of other languages, allows multiple things with the same name, as long as they're different types. (You can have an array and a sub with the same name, for example) Generally languages split at least the sub/function namespace out from the variable namespace, though some languages (notably perl) also split the variable namespace by broad type. Now, this wouldn't be a problem--we could segregate the namespaces, except... Introspecting facilities in those languages assume that there is a single unified namespace, rather than a type-split namespace, and there's some disagreement as to how many namespace types there should be. Perl gets around this by either two-levelling the names (so that there's a single entry for 'foo', and that PMC-equivalent is an array that has a slot for scalar, hash, array, sub, and so forth), and while we can do that, well... yech. (And I mean that sincerely) The proposal for *user* views (i.e. we can screw with what they ask for before we look) in perl 6 is to have separate entries in the namespace with an appropriate perl prefix, so if there's a $foo in your program, there's a $foo name in the name table. That, as you might expect, has just a *few* cross-language issues. Many other languages don't draw the subtype distinction that perl does--you're allowed one variable 'foo' and that's it, regardless of its type. Personally I'm currently of the opinion that we should split the namespace into functions/methods/subs and variables, either by convention with a prefix character or with an explicit parameter, and let the variables fend for themselves. Whatever language prefix (if any) gets used, and if people go dancing through someone else's namespace they may find things they didn't expect, well.. Here there be dragons. Marshmallows, anyone? A leading NULL byte for subs seems quite nice if we keep them in the same table as variables, or we can split the table in two. I'm currently pondering the namespace separator character as well. Perl uses :: between levels, and I've no idea off-hand what other languages use. Personally I'm tempted to use a null between levels and put in a translator layer in generated bytecode for symbolic access from HLLs. Dan
Calling conventions and return conventions
I've not got time yet to write this up formally, but There's no difference between calling a sub PMC with parameters and invoking a return continuation with return values. The return values for that continuation are just sent as parameters, as if you were calling it as a function. Yes, that means that if you do: $return_cont-(1, 2, 3); it's the same as: return (1,2,3); assuming $return_cont has your return continuation in it. If programs want to specify the types of the return values they can attach a prototype property to their return continuation, which can be queried the same (and yes, I know its unspecified) way that you can do it if you have a sub PMC. I'll update the PDD as soon as I can get time and some working brain cells. Dan
RE: Trig functions for vtables
Leopold Toetsch: # Dan was talking about one vtable slot, holding another vtable for trig # and log functions. The newly added vtable-data seems to be that. This # trig_log (or data) pointer is shared by all scalar classes. So that # takes one additional pointer per vtable and one additional trig_vtable. I didn't catch this bit before. # Vtable.tbl already divides vtables into sections. I suggest we take # this a step further and express these sections in the vtables itself. # Sections that a particular object didn't need would be loaded with a # default, in which all of the methods would throw an exception. # # That's what happening anyway. All unimplemented stuff has a default hook # throwing an exception. The indirection would allow for a default set. It's the difference between eight default pointers per vtable (to default sections) and eighty default pointers (to default implementations). If there are a lot of PMCs that use several sections of defaults (and this seems to be the case), it's a win spacewise. # The result would mean that something like: # pmc-vtable-add # # Might become: # pmc-vtable-math-add # # Seems too expensive to me for the normal math stuff. Perhaps, although one dereference doesn't seem to painful to me. Since we are doing trig in another section--I didn't catch that before--it seems that this'll be okay. However, I do encourage everyone to consider whether we should only be putting trig in separate tables, or if we should be putting other methods too, as I've proposed. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
RE: Trig functions for vtables
On Tue, 23 Sep 2003, Brent Dax wrote: Leopold Toetsch: # That's what happening anyway. All unimplemented stuff has a default hook # throwing an exception. The indirection would allow for a default set. It's the difference between eight default pointers per vtable (to default sections) and eighty default pointers (to default implementations). If there are a lot of PMCs that use several sections of defaults (and this seems to be the case), it's a win spacewise. Each indirection potentially blows the processor pipeline, which costs up to 15 cycles depending on the processor. It's not normally that bad, more like 5-7 cycles, but still, it's the equivalent of a fault to main memory. I'm comfortable burning the memory for now. We can revisit this later if it turns out to be a real problem, but until then things stay the way they are. Dan
Re: Trig functions for vtables
Brent Dax [EMAIL PROTECTED] wrote: # The result would mean that something like: # pmc-vtable-add # # Might become: # pmc-vtable-math-add # # Seems too expensive to me for the normal math stuff. Perhaps, although one dereference doesn't seem to painful to me. Is there any reason we can't do both? Many cpu architectures have variable length instructions (aka extension opcodes), why couldn't we have: pmc-vtable-add pmc-vtable-extensions.trig-cosine This way we get both fast core ops, and lesser ops with one extra indirection Dave.
Re: [RfT] Configure/Makefile changes towards Borland C++ Builder
Brent Dax [EMAIL PROTECTED] writes:
Steve Fink:
# Following things were done:
# - s,/,\${slash},g
#
# Ugh. How difficult would it be to have Configure do this rewriting
# automatically? (Or rewrite to whatever it is you need, instead)? This
# just clutters up the makefiles a little too much, IMO.
Well...
It's theoretically possible. However, it'll cause problems if we use
tools that require use of slashes on arguments (xcopy /e, for example,
which we might use to install modules at some point--and my
understanding is that VMS tools all use slashes exclusively).
Either we substitute before we interpolate things into the Makefile,
which'll miss any interpolated slashes (like the ones in the variable
that defines which PMC classes are compiled in), or we do so after,
which will hit all interpolated slashes (including command-line
switches). We can't have it both ways.
I tried the first way: substitute before interpolation. This means all
uservariables need to substitute slashes. Fortunatly there are not so
many.
But VMS brings up another point--can we afford to use a simple
substitution at all? After all, they use a completely different syntax
for paths, right?
How does VMS-make handle the directory case?
What seems far more promising to me is something in the cc wrapper we're
using. Similar wrappers for ld, ar, and the other build tools might be
in order. Nothing would please me more than a Makefile like:
.c$(O):
$(PERL) tools/build/calltool.pl cc $@ $
parrot$(EXE):
$(PERL) tools/build/calltool.pl ld parrot$(EXE)
$(O_FILES)
That could appear exactly the same in makefiles/root.in as in /Makefile.
All systems would use 'calltool.pl cc' to invoke the C compiler--it
wouldn't be 'calltool.pl cl' on Windows, or 'calltool.pl gcc' on
gcc-using systems. And 'calltool.pl' could convert paths on VMS or
Windows.
But this means that calltool.pl must be generated by Configure. The
diffrent Makerules are just hidden in calltool.pl.
*That* would make me a happy Configure hacker. :^)
--Brent Dax [EMAIL PROTECTED]
Perl and Parrot hacker
Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it.
Anyway please test the revisited patch
bye
bö
? bcc5.diff
? r.diff
Index: config/auto/sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.7
diff -u -r1.7 sizes.pl
--- config/auto/sizes.pl 27 Apr 2003 07:36:44 - 1.7
+++ config/auto/sizes.pl 23 Sep 2003 17:20:42 -
@@ -118,7 +118,7 @@
};
# clear int8_t on error
-if($@) {
+if($@ || !exists $results{hugeintval}) {
Configure::Data-set('int8_t' = undef);
next;
}
Index: config/gen/makefiles.pl
===
RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v
retrieving revision 1.17
diff -u -r1.17 makefiles.pl
--- config/gen/makefiles.pl 23 Jul 2003 14:38:23 - 1.17
+++ config/gen/makefiles.pl 23 Sep 2003 17:20:42 -
@@ -10,27 +10,27 @@
sub runstep {
genfile('config/gen/makefiles/root.in', 'Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/classes.in', 'classes/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/languages.in', 'languages/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/jako.in', 'languages/jako/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/miniperl.in', 'languages/miniperl/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/scheme.in','languages/scheme/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/perl6.in', 'languages/perl6/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/imcc.in', 'languages/imcc/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/bf.in','languages/bf/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/befunge.in', 'languages/befunge/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/ook.in', 'languages/ook/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
# set up docs/Makefile, partly based on the .ops in the root dir
Index:
[ANNOUNCE] Parrot::DWIM
As we don't have any libs yet, I thought, I start with an important one. It works like Acme::DWIM. Here is a sample run: $ cat hello.imc .pcc_sub _main prototyped .include DWIM.imc add $I0, 20, 22 print $I0 print \nHello Parrot!\n end .end $ parrot hello.imc 42 Hello Parrot! $ cat hello.imc .pcc_sub _main prototyped .include DWIM.imc # DWIM $I0, 20, 22 # DWIM $I0 # DWIM \nHello Parrot!\n # DWIM .end $ parrot hello.imc 42 Hello Parrot! So during the first run, the DWIM lib replaces all these nasty opcodes, which no one can remember, with the much more handsome DWIM comment. This makes for much simpler code: just fill in the proper operands. I should clean up and comment it a bit, then I could submit it - where? runtime/parrot/lib ? Have fun, leo
Loading up bytecode segments
I see we've got dynamically loaded bytecode segments. Good. What we don't have is those segments automatically running, something I think we need to have happen. When a bytecode segment is loaded, control should pass to the first executable instruction in it, and proceed until it hits an end. (I can see making this a ret instead) This seems simpler than having some sort of magic label, and will allow loaded bytecode segments to initialize themselves if that's what they need. Any objections, or shall I just make this happen? Dan
Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] wrote: I see we've got dynamically loaded bytecode segments. Good. What we don't have is those segments automatically running, something I think we need to have happen. When a bytecode segment is loaded, control should pass to the first executable instruction in it, and proceed until it hits an end. (I can see making this a ret instead) This seems simpler than having some sort of magic label, and will allow loaded bytecode segments to initialize themselves if that's what they need. But how to pass arguments then? Init code might need some. Any objections, or shall I just make this happen? I think a more flexible way is a magic label, or just __init which can be called explictely or even automatic - if such a label exists. Dan leo
This week's summary
The Perl 6 Summary of the week ending 20030921
Deadlines, I love the sound they make as they fly past.
Those of you who receive this summary via mail may have noticed that
this summary is a little late, with any luck it will make up for its
tardiness by being inaccurate and badly written as well.
I'm going to reinstitute the tradition of starting with the internals
list this week, so without further ado:
Pondering argument passing
Steve Fink pondered passing parameters properly, with a prototyped Perl
6 example. Perl 5 certainly, and Perl 6 possibly, allow you to ignore
any function prototype by calling the function like f(1,2). Steve had
concerns about what to do in the presence of 'splatted' argument lists.
(Consider
sub foo(@a, $b) {...}
@generated_arglist = ([1,2,3], 2);
Calling foo(@generated_arglist) will throw an error, because the
function is expecting an array followed by a scalar. However, you can
get around that by using the * (splat) operator, which tells Perl to
wait until runtime and then treat @generated_arglist as if it were a
list of arguments to the function, and check its contents against foo's
parameter list. In Perl 5, if you had a prototyped function sub foo(@$)
{...} you would work around the problem by calling it as
foo(@generated_arglist), but I have digressed a long way already.)
I'm not entirely sure I got what this thread was about. I've just had a
chat with Dan about it on IRC, and I think I'm a little wiser, but the
thread that arose from Steve's post gave me the impression of people
talking past each other a little.
http://xrl.us/t4x
Feature Freeze for 0.0.11
Steve Fink announced that Parrot was feature frozen in the wee small
hours of Monday morning (at least it was Monday morning if you live in
GMT; it was still Sunday if you're in Steve's timezone). Everyone set
about tidying things up, nailing bugs and generally getting Parrot's
house in order for a public release.
http://xrl.us/t4y
Some Parrot people are disgustingly young
In a move calculated to annoy your summarizer, Dan Sugalski pointed out
that Piers is now twice the age of Brent Dax. I thought it was bad
enough back when I was working with Leon Brocard, who is also
disgustingly young, but at least he was old enough to drink beer and
vote. (It's very important that you do the former before the latter
apparently).
Parrot musical chairs
Some time after the next Parrot release everything's going to get moved
around in the parrot directory tree so things make a little more sense.
Dan laid out his vision. Leo liked it. Looks like it'll be happening.
http://xrl.us/t4z
Sorting out dependencies
Andy Dougherty has been shaking the parrot tree with different versions
of Perl and found some incompatibilities between the jako and perl6
languages and Perl 5.005. A few patches and skipped tests solved that.
http://xrl.us/t42
Attaching Debuggers
Nicholas Clark passed on the concerns of a nameless interlocutor who had
expressed a desire for a Perl debugger which could attach itself to a
troubled running process. This is, after all, something that gdb can
already do for C programs. Dan punted on details, but thinks it should
be possible to implement. It's definitely post 0.0.11 though. Michal
Wallace pointed out that Python is very 'hooky' and supports this.
http://xrl.us/t43
Various fixes
Because most of the week was spent under a feature freeze, the vast
majority of this week's threads have been the kind of short lived
Patch! Applied! bugfix threads. Suffice to say, lots of bugs and
niggles got stamped on by the usual heroes plus a few more heroes for
good measure.
Parrot 0.0.11 Doubloon Released
Parrot 0.0.11 got released on Saturday, narrowly missing International
Talk Like a Pirate Day. It was almost immediately superceded by version
0.0.11.1 which fixed a slight oversight and introduced a new bug.
Breaking my 'midnight GMT cutoff' rule, the latest version, released is
actually 0.0.11.2, which deals with the fact that Parrot isn't set up to
handle 4 part version numbers.
http://xrl.us/t44
http://xrl.us/t45 -- The We really can't handle these version
numbers release
Meanwhile, in perl6-language
Disposable optimization
The increasingly poorly named Next Apocalypse thread went off into
discussing the possibilities of disposable optimizations that could get
thrown out when invariants that they depend on no longer hold. This
rapidly developed into serious blue sky stuff that I can't help but
think is a little premature. Fascinating certainly, but I would like a
working language before we got off making it do all sorts of clever
optimization stuff.
http://xrl.us/t46
Re: Loading up bytecode segments
At 11:13 PM +0200 9/23/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I see we've got dynamically loaded bytecode segments. Good. What we don't have is those segments automatically running, something I think we need to have happen. When a bytecode segment is loaded, control should pass to the first executable instruction in it, and proceed until it hits an end. (I can see making this a ret instead) This seems simpler than having some sort of magic label, and will allow loaded bytecode segments to initialize themselves if that's what they need. But how to pass arguments then? Init code might need some. What arguments, though? This is just a chance to give the segment an initialization run, nothing more. Any objections, or shall I just make this happen? I think a more flexible way is a magic label, or just __init which can be called explictely or even automatic - if such a label exists. Ick. No magic labels like that. I'd rather set it so we start executing at the beginning with some set parameters or something, and for segments with no initialization they can just ret back out or something. (I'm not sure full-on calling conventions are required here, but then I'm not sure they aren't either) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Problem building jako (perl version dependency?)
Andy --
Thanks. That was a strange one. No complaint by my Perl, even with
use warnings 'all';, but its definitely a typo (and now fixed, too).
Regards,
-- Gregor
On Mon, 2003-09-22 at 06:21, Andy Dougherty wrote:
On Thu, 18 Sep 2003, Gregor N. Purdy wrote:
Andy --
I didn't see anything wrong in the code, but I added some parens.
Let me know if you still have trouble...
Yup, still the same problem. Here's the line in question:
Can't modify subroutine entry in scalar assignment at lib/Jako/Symbol.pm
line 83, near 'arg';
sub is_variable { my $self = shift; return ($self-kind eq 'var') or
($self-kind = 'arg'); }
It's the ($self-kind = 'arg') assignment that's illegal under 5.00503.
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Hash tests fail (Win32)
hash_4.exe crashes, trying to read memory at 0x when running tests for hash. t/src/hash..NOK 5# Failed test (t/src/hash.t at line 163) # got: 'Can't spawn .\t\src\hash_4.exe: Bad file descriptor at lib/Parrot/Test.pm line 61. # ' # expected: '' # '.\t\src\hash_4.exe' failed with exit code 255 t/src/hash..ok 10/12
[ANNOUNCE] Another Trivia Language: URM
Hi, I'd like to add one more to the library of trivia languages. It is not as strange as Bf or Ook! and it is actually a real (teaching) language. Enter: URM URM is a language at least used in German universities to teach the basic principles of programming. URM stands for Universal Register Machine - it basically means that you have a couple of operations and an unlimited amount of registers to use for your programs. Here are the URLs More information: http://perl.thiesenweb.de/readme-urm.txt My initial package: http://perl.thiesenweb.de/urmc-0.1.tar.bz2 Have fun Marcus -- - |Marcus Thiesen ICQ# 108989768| - | www.thiesenweb.de | - 28A7 37CC AE2C BB6C D56D 8A3D E614 E56B 7546 75F2 signature.asc Description: This is a digitally signed message part
Re: Pondering argument passing
On Sep-23, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
Just to be sure we're talking about the same thing:
sub f ($a, $b, $c) { ... }
$x = phase_of_moon('waxing') ? \f : \CORE::print;
$x-(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived functions calls happen too often, but
anyway ...
i.e., I'm calling f() without a prototype.
A builtin that took three parameters would expect them in P5, P6, and
P7. But how do I do that in IMCC for $x-(3, [EMAIL PROTECTED], [EMAIL
PROTECTED])? I am
suggesting
.arg 3
.args _AV_x
.args _AV_y
with some deep magic going on under the hood to get them into the
correct registers, most probably by means of a new, specialized op
because the current way of doing it is ugly and slow.
The current way is to flatten @x and @y and pass the 2 lists, that's it.
That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
Ok, we don't seem to be communicating.
I am not talking about optimizations. I am talking about what is
possible. Currently, there is no way to do what you suggest with the
PCC support in IMCC. At compile-time, you do not know the value of i
(the length of @x), so there is no sequence of .arg statements that
work.
Unless I am badly misunderstanding things? I am under the impression
that the neither the .arg nor the .param directive may be mixed in
with regular instructions, so you cannot loop over the elements of an
array to flatten it.
I'm not against a specialized .args directive, but first, we need the
normal cases. Then, we can think of optimizations.
I proposed .args simply because it seemed easier to implement than
runtime .arg directives. Would you prefer that the call be done like
this?:
.pcc_begin non_prototyped
.arg 3
$I0 = 0
$I1 = _AV_x
_arg_loop:
if $I2 = $I0 goto _next_arg_1
.arg _AV_x[$I0]
$I0 = $I0 + 1
goto _arg_loop
_next_arg_1:
.
.
.
But in either case, please understand that I am asking for _a_ way of
doing this in IMCC; I don't care how slow it is, so long as it's
possible. If I am incorrect about that, and it *is* already possible,
please show me a code example.
Another question: E6 seems to indicate that splat flattening happens
before parameter binding:
,--[ E6 ]-
|This operator (known as splat) simply flattens its argument into a
|list. Since it's a unary operator, it does that flattening before the
|arguments are bound to their respective parameters.
`-
Before is of course not a definition, when the flattening should happen,
but it seems to indicate, that flattening is done in the caller.
And can the flattening have side effects? What about tied arrary
splats? I can imagine, that the called sub can't flatten the array
because of tieing.
Huh? If you're talking about f([EMAIL PROTECTED]), then the called sub cannot
flatten because it doesn't know whether it should or not. (Unless you
pass some magic extra parameter to all non-prototyped calls that says
which arguments to flatten, but that makes no sense.)
If you're talking about
sub foo ([EMAIL PROTECTED]) { ... }
foo(@x);
then it still makes no sense to flatten in the called sub, because you
could have just as easily called foo(1, 2, @x, @y, 3, 4), and so the
caller would have to bundle all of the args up in order to give the
callee something to flatten. (And the bundling would require the
flattening of @x and @y anyway, so you'll have to have
caller-flattening semantics no matter what.)
