Too many opcodes
Below are some considerations WRT current opcode count.
leo
Too many opcodes
gcc 2.95.4 doesn't compile the switch core optimized. People have
repeatedly reported about troubles with the CGoto core - now the CGP
core is as big and compiles as slow.
I'm not speaking of the pain (and the additional coffee cups) it takes
here to recompile Parrot optimized on my AMD 800 and I'm doing that
frequently, believe me.
We have to reduce the opcode count drastically.
1) Opcode variants with constants
Dan has already stated that all binary opcodes with two constant
arguments can go away. The same applies to compare ops. Imcc can
handle that (and does it already, mostly)
2) Opcode variants with mixed arguments
Honestly
acos Nx, Iy
and tons of other such opcodes are just overkill. If I want a numeric
result, I just pass in a numeric argument. If people really want
that, imcc has already some hooks to create from above
set $N0, Iy
acos Nx, $N0
or convert an int constant to a double constant.
Well and above opcode isn't just one, these are two due to
constant/non-constant argument addressing.
3) Function-like opcodes
Stat, gmtime, seek, tell, send, poll, recv, gcd, lcm, pack, rand,
split, sleep, and what not are all functions in C or perl and any
other language I know. These are *not* opcodes in any hardware CPU I
know (maybe VAXens have it ;)
And most of these don't warrant the little speed gain as an opcode.
4) A scheme for calling functions.
a) we need a class for a namespace, e.g. the interpreter (Python might
have a math object for the call below:)
$P0 = getinterp
b) we do a method call
$N0 = $P0.sin(3.14)
c) add a method to classes/ParrotInterpreter.pmc:
METHOD FLOATVAL sin(FLOATVAL f) {
return sin(f);
}
d) and add the signature dIOd to call_list.txt.
e) a table of builtins
Quite easy and straightforward - and I hear all loudly crying - SLOW.
5) Ok - let's look (unoptimized build - see above ;) and parrot -C
(-j is the same, except that PIC is only hacked partially into -C)
Timings for 1 Meg sinus function opcodes [1] and methods [2]
sin opcode: 0.23 s
sin method: 3.20 s
Ok, too slow man. But here comes the PIC [4]:
sin method PIC: 0.50 s
sin method PIC no I0..I50.37 s [3]
PIC w inlining: 0.42 s
PIC w inlining no I0..I50.29 s [3]
So, it's slightly slower, but not much. Actually with the vastly
reduced run core size average execution speed could increase due to
less cache misses. But anyway the small advantage for all these opcodes
isn't worth the pain.
If you are unsure what PIC is, grep for the subject in p6i or consult
the recent summary, which has a link too.
Thanks for considering this approach,
leo
[1] opcode loop
n = 3.14
lp:
$N0 = sin n
dec i
if i goto lp
[2] method call loop
n = 3.14
$P0 = getinterp
lp:
$N0 = $P0.sin( n )
dec i
if i goto lp
[3] handcrafted code, which imcc can emit, when it's known that a
builtin NCI function with a known signature is called:
lp:
set N5, n
callmethodcc sin
dec i
if i, lp
# result in N5
[4] The opcode function - please note that for the non-inlined
case, one function fits all opcodes with the same signature.
Additionally the call overhead can be reduced by omitting the
interpreter and the object argument.
PC_METH_CALL_n_n:
{
FLOATVAL num;
#if PIC_INLINE
num = REG_NUM(5);
REG_NUM(5) = sin(num);
#else
Parrot_PIC *pic;
typedef FLOATVAL (*func_dd)(Interp*, PMC*, FLOATVAL);
func_dd f;
pic = (Parrot_PIC *) cur_opcode[1];
num = REG_NUM(5);
f = (func_dd)pic-f.real_function;
REG_NUM(5) = (f)(0, 0, num);
#endif
goto *((void*)*(cur_opcode += 2));
}
And we could provide a few opcodes with fixed signatures so that
function call register passing (in N5) isn't needed.
e.g.
call_dd(sin, Ndest, Nsrc)
Re: Lexicals, continuations, and register allocation
Matt Fowles [EMAIL PROTECTED] wrote: Leo~ On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: I've clearly stated that lexicals aka non-volatiles have distinct registers. Thus for these large subs, won't this be a large overhead? Why? It's actually less overhead. In the normal case these lexicals are created/stored in the scratchpad PMC array. So they have a storage, equally large anyway. Accessing these lexicals is an array lookup at best. Please look again at the picture I've drawn. This approach saves the scratchpad PMC (or better the array part of it) and the distinct non-volatile area, what we've now. It's cheaper. It was too slow - remember a factor of 5! Yes, but that is because we COPIED the data for every invocation. With what I am proposing we would only need to copy the data when invoking a full continuation That doesn't work. If you create a real continuation all continuations up the call chain have to be real continuations. And copying or not imposes different semantics on register usage. leo
Re: Lexicals, continuations, and register allocation
Bill Coffman wrote: On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Keep in mind that you don't actually have to add all those CFG edges. You already know precisely the effects of adding them. All non-volatile symbols (those crossing subs that might make continuation invocations) are garanteed to interfere. This is garanteed to be a clique in the interference graph. No need to actually add the CFG edges to know how the interference graph is effected. Possible, but just another special cased exception. With that you get two possible interferences of different kinds, with additional coding overhead ... It bothers me that this discussion is not including the concept of subs that don't call/invoke continuations. Remember the previous posts about adding a label, or setting a pragma? Sure. But I've no confirmation of a compiler writer that its possible. Annotating PIR can only work for nested closures. If libraries are involved you are out of luck. And we have such code already in library/Streams/Sub.imc. ... Also, if that sub is defined in the same imc source code, we can analyze it to see if there is a continuation there or not. And if not - see above. Another interesting thing about this problem is that these new CFG edges are rarely, or at least with low probability, ever travelled. We just don't know it, rare or not doesn't matter. ~Bill leo
Reserved Word Heartburn
IMCC yells at me when I say: .namespace [ Foo ] .sub new ... .end While it's tolerable for local symbols, subs really have to be named according to the interface. Is it possible to allow: .sub new ... .end ? Thanks, Luke
Namespace-sub invocation syntax?
Since there is a syntax for invoking subs: .sub foo # ... .end .sub bar foo() .end Should there be one for invoking a sub out of a namespace, say: .namespace [ Foo ] .sub bar # ... .end .namespace [ Baz ] .sub quux [ Foo, bar ]() .end ? On a related note, are we supposed to name our namespaces [ Foo, Bar ] or [ Foo::Bar ] nowadays? If the former, how do we name our classes? Do we have to mangle those ourselves, or is there a way to put a class in a namespace? Luke
Re: silent effects of opcodes
Quoth [EMAIL PROTECTED] (Leopold Toetsch): Ben Morrow wrote: Quoth [EMAIL PROTECTED]: RESUMABLE: func_that_might_loop_through_cc() possibly accompanied with another markup of the function call that loops back. That can't work, because *any* function might loop back, unless you want to analyse the entire logic flow of the called function Yes. In general that is true. The proposed markup would need that the HLL compiler spots all such places. I don't know if it's possible. It's not: consider the case of a function calling a method that hasn't even been written yet. That method, when written and compiled, could stuff its passed-in RC into some global (promoting it to a full continuation, of course) and some other random piece of code could then invoke it later. This is pretty unpleasant behaviour, of course; but we need to either define such cases carefully and outlaw them, or make them work. Effectively this means that all function calls need to be marked potentially resumable, except when all functions that could possibly get hold of our RC are compiled already and known not to do anything nasty with it. We can't even say that certain languages never use continutations so they don't need to pay the price, as cross-language method calls will presumably be possible, as will XS-like methods written in IMCC. Codepaths due to continuation invocation aren't arbitrary. The compiler should know affected subroutines and returns. This would work for lexically nested closure as in t/op/gc_13.imc. Yes; it's possible to make it work in the case of a single compilation unit which makes no calls outside itself, as all the required information is available at compile time. 2) Fetch all from lexicals/globals after a function call. Can you not make that re-fetch conditional on being invoked from a full (as opposed to a return) continuation, so it will only happen if someone's messing about with continuations? Unlikely, I think no. snippage This seems also hard to implement. Fair enough. It was just an idea. Ben -- You poor take courage, you rich take care: The Earth was made a common treasury for everyone to share All things in common, all people one. 'We come in peace'---the order came to cut them down. [EMAIL PROTECTED]
[perl #32590] how to set rihts for users
# New Ticket Created by prashanth babu # Please include the string: [perl #32590] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32590 hi everybody, how to set the rights for queues, groups and users.. parsu.
Re: Lexicals, continuations, and register allocation
Leopold Toetsch wrote: Sure. But I've no confirmation of a compiler writer that its possible. Annotating PIR can only work for nested closures. If libraries are involved you are out of luck. And we have such code already in library/Streams/Sub.imc. I've been thinking of what could be implemented using continuations. Some possible ideas: - multiple returns from regexp matches - lazy lists. In particular gather/take - junctions - coroutines - resumable exceptions Thing is, we can't know what the Real World perl6 code is going to look like. If it turns out that continuations are The Way to implement both junctions and gather/take construct, 'out of luck' is a good description of the ensuing fun and merryment. Basically, any PMC can be silently swapped with a junction, possibly making anything that uses it backtrack (what are the junctions supposed to be implemented as, anyway?) and I can imagine that lots of production perl6 code will have gather/takes all over the place - they look like an utterly nice way to construct a list. My point is that continuations are rare because mainstream languages (with a single exception) don't support them. BTW, I wonder if there are any research papers on the topic of register allocation in presence of continuations. I just looked at Citeseer, but a quick cursory search didn't come up with anything useful. Miro
Re: Lexicals, continuations, and register allocation
On Wed, Nov 24, 2004 at 09:39:27AM +0100, Leopold Toetsch wrote: Bill Coffman wrote: Another interesting thing about this problem is that these new CFG edges are rarely, or at least with low probability, ever travelled. We just don't know it, rare or not doesn't matter. I'm probably going to get shot for suggesting this, but if each interpreter has a count of the number of full continuations invoked (ie non-return continuations), then I think that we can know when we *haven't*. Which (I'm guessing - need a real finished parrot to know) won't be that often. So I'm thinking * counter incremented monotonically for every non-return continuation invocation * Store the value of this counter as part of sub entry * Check the value against the stored counter on sub return * If they differ, branch to slow case fixup code. (Well or branch round it if they are the same) Hmmm. But we still have to save all values out from registers before a call. Pah. May not be a great win. Nicholas Clark
Re: [perl #32590] how to set rihts for users
On Tue, Nov 23, 2004 at 11:40:07PM -0800, prashanth babu wrote: # New Ticket Created by prashanth babu # Please include the string: [perl #32590] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32590 Â hi everybody, how to set the rights for queues, groups and users.. It's unclear what the context of your question is. If you're asking about how to setup RT, you're asking in the wrong place. I'd suggest joining the appropriate RT mailing list and asking there. Details are here: http://www.bestpractical.com/rt/lists.html Nicholas Clark
Re: Namespace-sub invocation syntax?
Luke Palmer wrote: Since there is a syntax for invoking subs: .sub foo # ... .end .sub bar foo() .end Should there be one for invoking a sub out of a namespace, say: .namespace [ Foo ] .sub bar # ... .end .namespace [ Baz ] .sub quux [ Foo, bar ]() .end ? I would suggest a slightly adapted form: .sub quux [ Foo ] bar() .end if quux is in the same namespace (i.e. Foo), then this namespace specifier is not necessary, so that's a bit more clean when one does: .sub quux [ Foo ] bar() bar() .end I know it's not important at the moment, but this is what I would prefer. klaas-jan
Re: Namespace-sub invocation syntax?
Luke Palmer [EMAIL PROTECTED] wrote: Should there be one for invoking a sub out of a namespace, say: .namespace [ Baz ] .sub quux [ Foo, bar ]() Looks a bit strange. Class methods already have their namespaces. For subs we could do: .locale pmc ns, ns_foo ns = interpinfo .CURRENT_NAMESPACE# or .TOPLEVEL_NAMESPACE ns_foo = ns [Foo] ns_foo.bar() The namespace PMC provides the find_method() that's actually behind that call. With the additional benefit that it's using the method cache too. On a related note, are we supposed to name our namespaces [ Foo, Bar ] or [ Foo::Bar ] nowadays? Nested namspaces BTW: [ Foo; Bar ] aren't yet supported. Missing is also the namespace name mangling (appending a NUL). The colon separated thing is just one namespace - no nesting at all. ... If the former, how do we name our classes? Do we have to mangle those ourselves, or is there a way to put a class in a namespace? I think to create a nested class, we need something like: set_namespace [Foo] subclass cl, Foo, Bar ... .namespace [Foo ; Bar ] methods Luke leo
Re: Reserved Word Heartburn
Luke Palmer [EMAIL PROTECTED] wrote: IMCC yells at me when I say: .namespace [ Foo ] .sub new ... .end While it's tolerable for local symbols, subs really have to be named according to the interface. Is it possible to allow: .sub new ... .end Should be rather simple, yes. Good idea. Thanks, Luke leo
Re: Lexicals, continuations, and register allocation
Leopold Toetsch wrote: +-+--+ | ctp | interpreter state| +-+--+ | ++ | +--+-+---+--+ | prev | ctx | lexicals | volatiles| +--+-+---+--+ | p a r r o t r e g i s t e r s | A very strong architecture for sure. + no lexical fetch overhead That alone is worth the price of admission. No register allocator needed because the HLL only needs volatiles for anonymous temporaries which are easily allocated during expression parsing. I would make a couple changes: +-+--+ | ctp | interpreter state| +-+--+ | +--+--+-+---+--+ | caller's out | prev | ctx | lexicals | volatiles| +--+--+-+---+--+ Merge with the variable sized stack frame proposal and expose prev+ctx as registers. As long as an architecture change is on the table, might as well make it a doozy. (Caller's out may need to be padded if caller did not pass the right number of args.) Sorry for the de-lurk. I'll now return to hacking on my storage to storage VM which looks amazingly similar to Leo's VM. ;) - Ken
Re: Lexicals, continuations, and register allocation
On Wed, Nov 24, 2004 at 09:45:27AM -0500, Ken Fox wrote: As long as an architecture change is on the table, might as well make it a doozy. Quite a lot of us would just like parrot COMPLETE and CORRECT before starting to put a lot of effort into how fast it is. PLEASE can we get parrot functionally complete, THEN start refactoring it to go faster. Until such time as we have complete, functional high level language running on it, with real world programs (rather than benchmarks and torture tests) optimisations are likely to be premature, as we don't have complete or realistic data of what our true speed problems are. ONLY when we have a real language complete and running (and yes, 100% of python running seems to be the easiest one here) do I feel that we'll actually be justified in spending time and effort undoing things that work (albeit slowly) and redoing them. Currently we keep liking to generate a lot of heat (and little light) redoing things that are currently too slow, which I have NO DOUBT that we're going to want to re-redo later in the light of real data. Nicholas Clark
Re: Lexicals, continuations, and register allocation
Ken Fox [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: +-+--+ | ctp | interpreter state| +-+--+ | ++ | +--+-+---+--+ | prev | ctx | lexicals | volatiles| +--+-+---+--+ | p a r r o t r e g i s t e r s | A very strong architecture for sure. + no lexical fetch overhead That alone is worth the price of admission. No register allocator needed because the HLL only needs volatiles for anonymous temporaries which are easily allocated during expression parsing. Yep, I mentioned that. I would make a couple changes: [ ... ] I'm not gonna touch calling conventions. Actually by swapping the two register ranges above it's fully compatible. +-+--+ | ctp | interpreter state| +-+--+ | +--+--+-+---+--+ | caller's out | prev | ctx | lexicals | volatiles| +--+--+-+---+--+ Merge with the variable sized stack frame proposal and expose prev+ctx as registers. prev is the current (return) continuation, which is unvisible except for the returncc opcode. Exposing it means a visible full continuation with all the drawbacks. ctx has some stack top pointers e.g. for the control stack and other stuff. So Cpush ctx_ctrl, eh would push an exception handler. Other members are flags e.g. warnings on/off. This would be very similar to a hardware CPUs control registers: Cbor ctx_warn, .WARNING_UNDEF. Sorry for the de-lurk. I'd be glad to have you here. - Ken leo
Re: Lexicals, continuations, and register allocation
Nicholas Clark [EMAIL PROTECTED] wrote: I'm probably going to get shot for suggesting this, but if each interpreter has a count of the number of full continuations invoked (ie non-return continuations), then I think that we can know when we *haven't*. Nobody gets shot - and - interesting idea, but * If they differ, branch to slow case fixup code. Smells like duplicating the whole sub, which would make Evil Sub just more Evil. Hmmm. But we still have to save all values out from registers before a call. Pah. May not be a great win. Yep. Nicholas Clark leo
Re: Lexicals, continuations, and register allocation
Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Nov 24, 2004 at 09:45:27AM -0500, Ken Fox wrote: As long as an architecture change is on the table, might as well make it a doozy. Quite a lot of us would just like parrot COMPLETE and CORRECT before starting to put a lot of effort into how fast it is. Yes. Obviously my posting proposes a solution for the current incorrect behavior of continuations in combination with register re-allocation. And as a side effect it will make Dan's evils subs compile, because long-lived lexicals already have their storage aka register. Only temps need a register allocated. PLEASE can we get parrot functionally complete, THEN start refactoring it to go faster. Until such time as we have complete, functional high level language running on it, with real world programs (rather than benchmarks and torture tests) optimisations are likely to be premature, as we don't have complete or realistic data of what our true speed problems are. That's of course right. Nicholas Clark leo
Re: Lexicals, continuations, and register allocation
Leo~ On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: And as a side effect it will make Dan's evils subs compile, because long-lived lexicals already have their storage aka register. Only temps need a register allocated. What happens to temps that need to cross function calls in your scheme? Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Reserved Word Heartburn
Luke Palmer [EMAIL PROTECTED] wrote: ... Is it possible to allow: .sub new ... .end Done. Including: $I0 = new() Please note that currently the name of the PMC sub constant is passed to PackFile code via sprintf/sscanf. This means that spaces and such are not allowed, yet. BTW it would be great if someone could go through the imcc docs, a lot has changed recently, thanks. Thanks, Luke leo
Re: Lexicals, continuations, and register allocation
Matt Fowles [EMAIL PROTECTED] wrote: Leo~ On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: And as a side effect it will make Dan's evils subs compile, because long-lived lexicals already have their storage aka register. Only temps need a register allocated. What happens to temps that need to cross function calls in your scheme? These would go along with the lexicals in the non-volatile area. But such temps are rare (AFAIK). You need a HLL construct like: a = b + c + foo() giving something like this: a = new Undef $P0 = new Undef $P0 = b + c $P1 = foo() a = $P0 + $P1 The temp $P0 has to persist over the call and needs a permanent store too. Matt leo
Re: Lexicals, continuations, and register allocation
Leo~ On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Fowles [EMAIL PROTECTED] wrote: Leo~ On Wed, 24 Nov 2004 16:42:31 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: And as a side effect it will make Dan's evils subs compile, because long-lived lexicals already have their storage aka register. Only temps need a register allocated. What happens to temps that need to cross function calls in your scheme? These would go along with the lexicals in the non-volatile area. But such temps are rare (AFAIK). You need a HLL construct like: a = b + c + foo() I am not sure that they are as rare as you think. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: [perl #32418] Re: [PATCH] Register allocation patch - scales better to more symbols
Dan Sugalski [EMAIL PROTECTED] wrote: I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp error messages compiling the switch core if I turn on optimizations. I've checked in a hook in ops2c.pl that splits the switched core all 300 ops. If that works, we can provide some config support. You might also vary the 300 a bit. leo
Re: Lexicals, continuations, and register allocation
On Wed, 24 Nov 2004 09:39:27 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Bill Coffman wrote: On Tue, 23 Nov 2004 23:26:39 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Keep in mind that you don't actually have to add all those CFG edges. You already know precisely the effects of adding them. All non-volatile symbols (those crossing subs that might make continuation invocations) are garanteed to interfere. This is garanteed to be a clique in the interference graph. No need to actually add the CFG edges to know how the interference graph is effected. Possible, but just another special cased exception. With that you get two possible interferences of different kinds, with additional coding overhead ... Instead of n*(n-1) arcs for n continuation passing subs (both to and from), we can simply add a pseudo instruction. All n sub calls have arcs to that pseudo-instruction, and out from it, to the instruction after the sub call. This means only 2*n arcs (both to and from). Each continuation calling sub becomes a kind of wormhole. Any symbol crossing it, also crosses the pseudo-instruction. What makes it a little complicated is how do these ubiquetous symbols interact with the non-ubuiquitous? Those arcs are needed for this. I've no confirmation of a compiler writer that its possible. Annotating PIR can only work for nested closures. If libraries are involved you are out of luck. It was Larry Wall who suggested the pragma in the long thread, Continuations, basic blocks, loops and register allocation . Although his message is somewhat genaral, he indicates a prefernce for pragmas to turn off certain features that slow things down for correctness. [gmail works great for finding stuff like that] Bill
Re: Lexicals, continuations, and register allocation
On Wed, 2004-11-24 at 15:04 +, Nicholas Clark wrote: Quite a lot of us would just like parrot COMPLETE and CORRECT before starting to put a lot of effort into how fast it is. I'd settle for it compiling (#32514). If not for the broken build, I'd have poked at three or four small TODO items and bugs in the past couple of weeks. An appropriate hierarchy of c-words is: compiles - correct - complete - competitive First, Parrot must build on important platforms. Then it must pass the tests. Then it must have all of the important features for the current release. Only then (and maybe not even then, maybe for a future release) does it need optimization. -- c
Re: Lexicals, continuations, and register allocation
Matt Fowles [EMAIL PROTECTED] wrote: On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: a = b + c + foo() I am not sure that they are as rare as you think. Does it matter? They are no lexicals, you can't refetch them. So they get a distinct storage. When foo() is known to the compiler that it doesn't capture the continuation, the register can be reused else not. Matt leo
Re: Lexicals, continuations, and register allocation
Chromatic [EMAIL PROTECTED] wrote: On Wed, 2004-11-24 at 15:04 +, Nicholas Clark wrote: Quite a lot of us would just like parrot COMPLETE and CORRECT before starting to put a lot of effort into how fast it is. I'd settle for it compiling (#32514). Well, having just a short look at the error message seems to reveal that your as doesn't croak the comment for the unused macro. I'd just remove that and try again. I can't test it. ... If not for the broken build, I'd have poked at three or four small TODO items and bugs in the past couple of weeks. An appropriate hierarchy of c-words is: compiles - correct - complete - competitive But anyway, yes. First, Parrot must build on important platforms. Then it must pass the tests. First is true most of the time, except for such platform stuff. I test on two platforms, 3 computers. Tests are currently not passing due to obvious violations of the recent pdd03 changes. t/op/gc_13.imc would still fail because of continuation and register allocation, it's just using lexicals now. ... Then it must have all of the important features for the current release. Only then (and maybe not even then, maybe for a future release) does it need optimization. My mail - the originator of this thread, where this optimization philosophy discussion seems now to take place - doesn't propose an optimization, nor does it propose that scheme for that reason. The context layout I've shown is just a way (IMHO) to solve the correctness problem that currently exists. Honestly I would prefer to discuss that interpreter layout (or other realistic proposals that solve the problem). -- c leo
Re: Lexicals, continuations, and register allocation
Bill Coffman [EMAIL PROTECTED] wrote: two possible interferences of different kinds, with additional coding overhead ... ... What makes it a little complicated is how do these ubiquetous symbols interact with the non-ubuiquitous? Those arcs are needed for this. Yes that's what I've already stated above ;) It was Larry Wall who suggested the pragma in the long thread, Yes I've bookmarked it. But a pragma doesn't solve outside effects of libraries that just capture the continuation under your hood. And - again - refetching lexicals doesn't work for things that aren't lexicals, but just non-volatile temps. Bill leo
[off topic] an amusing side note
Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. Here's to hoping something sensible emerges from Parrot, at least. :) F.
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 03:42:48PM -0500, Felix Gallo wrote: Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. Here's to hoping something sensible emerges from Parrot, at least. :) The original is here: http://bleaklow.com/blog/archive/18.html I doubt that Alan objects to anyone saving his bandwidth. Nicholas Clark
Re: [off topic] an amusing side note
On 11/24/04 3:42 PM, Felix Gallo wrote: Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. I don't :) Judging by the Perl 6 RFCs, I think that book cover would be accurate if the community really did design Perl 6 in the absence of Larry. Fortunately, that's not the case. I think Perl 6 is a lot cleaner than Perl 5 in addition to being much more powerful. -John
Re: [perl #32514] Cannot Build Parrot on Linux PPC (nonvolatile registers)
Ah, I've made Parrot build again on Linux PPC (and make testj only has the expected t/library/streams.t failure present with make test too). The attached file works as the eventual src/platform_asm.s file, at least on my architecture. I'm not sure how to plug it in to the generated fileset cleanly, but that's a lot easier than trying to debug assembly code on a platform you don't have. Leo, what do you suggest to connect the dots here? -- c .macro RESTORE_NONVOLATILE_FLOATS lfdf14, -PPC_JIT_GP_REGISTER_SAVE_SPACE-1*8(r1) lfdf15, -PPC_JIT_GP_REGISTER_SAVE_SPACE-2*8(r1) lfdf16, -PPC_JIT_GP_REGISTER_SAVE_SPACE-3*8(r1) lfdf17, -PPC_JIT_GP_REGISTER_SAVE_SPACE-4*8(r1) lfdf18, -PPC_JIT_GP_REGISTER_SAVE_SPACE-5*8(r1) lfdf19, -PPC_JIT_GP_REGISTER_SAVE_SPACE-6*8(r1) lfdf20, -PPC_JIT_GP_REGISTER_SAVE_SPACE-7*8(r1) lfdf21, -PPC_JIT_GP_REGISTER_SAVE_SPACE-8*8(r1) lfdf22, -PPC_JIT_GP_REGISTER_SAVE_SPACE-9*8(r1) lfdf23, -PPC_JIT_GP_REGISTER_SAVE_SPACE-10*8(r1) lfdf24, -PPC_JIT_GP_REGISTER_SAVE_SPACE-11*8(r1) lfdf25, -PPC_JIT_GP_REGISTER_SAVE_SPACE-12*8(r1) lfdf26, -PPC_JIT_GP_REGISTER_SAVE_SPACE-13*8(r1) lfdf27, -PPC_JIT_GP_REGISTER_SAVE_SPACE-14*8(r1) lfdf28, -PPC_JIT_GP_REGISTER_SAVE_SPACE-15*8(r1) lfdf29, -PPC_JIT_GP_REGISTER_SAVE_SPACE-16*8(r1) lfdf30, -PPC_JIT_GP_REGISTER_SAVE_SPACE-17*8(r1) lfdf31, -PPC_JIT_GP_REGISTER_SAVE_SPACE-18*8(r1) .endm .text .align 12 .globl Parrot_ppc_jit_restore_nonvolatile_registers Parrot_ppc_jit_restore_nonvolatile_registers: lfd 14, -84(1) lfd 15, -92(1) lfd 16, -100(1) lfd 17, -108(1) lfd 18, -116(1) lfd 19, -124(1) lfd 20, -132(1) lfd 21, -140(1) lfd 22, -148(1) lfd 23, -156(1) lfd 24, -164(1) lfd 25, -172(1) lfd 26, -180(1) lfd 27, -188(1) lfd 28, -196(1) lfd 29, -204(1) lfd 30, -212(1) lfd 31, -220(1) blr
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 04:25:14PM -0500, John Siracusa wrote: On 11/24/04 3:42 PM, Felix Gallo wrote: Well, it's the first time *I've* seen it. http://otierney.net/images/perl6.gif I find it difficult to disagree, at the perl6 language level. I don't :) Judging by the Perl 6 RFCs, I think that book cover would be accurate if the community really did design Perl 6 in the absence of Larry. Fortunately, that's not the case. I think Perl 6 is a lot cleaner than Perl 5 in addition to being much more powerful. This would doubtless be a very long discussion :), so I will stop my contribution to the thread with the following notes: 1. I ran the Obfuscated Perl contest for many years, and even I draw the line at purposefully obfuscated language design documentation _release methods_. Sly obfuscated cuteness has gone from 'rife' to 'pathologically endemic', in both design and presentation. IMHO. 2. perl 6 is a lot cleaner than perl 5. It's also much, much larger than an already very large language. I've been programming and evangelizing Perl in organizations small and gigantic since 4.03x, and my eyes just glaze over at all the unnecessarily surfaced complexity bound to make reading other people's programs finally, at last, literally impossible: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html I'm not going to use perl 6. F.
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 06:30:29PM -0500, Felix Gallo wrote: 2. perl 6 is a lot cleaner than perl 5. It's also much, much larger than an already very large language. I've been programming and evangelizing Perl in organizations small and gigantic since 4.03x, and my eyes just glaze over at all the unnecessarily surfaced complexity bound to make reading other people's programs finally, at last, literally impossible: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html I'm not going to use perl 6. I doubt anyone will. We'll all be using subsets. Of course the subset that I use will probably be different from the subset used by the authors of the modules I'll be using. That's a potential headache but not a huge problem. I predict a burst of wild creativity from authors enjoying the exploration of all the wonderful tools in the perl6 toolbox. Then, after a year or three of fun, sawn off limbs, and bloodied fingers (and after a few good books get published) most of us will converge towards a common subset of accepted good practice. But we'll know that our new toolbox of choice is far deeper than our old one and will cope with a far wider range of projects. Tim.
[perl #32605] [TODO] Website examples, no PIR.
# New Ticket Created by Herbert Snorrason # Please include the string: [perl #32605] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32605 The parrotcode.org website has an 'Examples' section, which (currently) contains only PASM. PIR examples would need to be added.
Re: [off topic] an amusing side note
On 11/24/04 7:27 PM, Tim Bunce wrote: I predict a burst of wild creativity from authors enjoying the exploration of all the wonderful tools in the perl6 toolbox. Then, after a year or three of fun, sawn off limbs, and bloodied fingers (and after a few good books get published) most of us will converge towards a common subset of accepted good practice. ...much like what happened with Perl 5...although the last phase has been hampered somewhat but the utility of some of those early, crazy efforts :) -John
old parrot question?
hi,everyone. I am learning parrot0.0.1 source code. But i don't know padding in assemble.pl? $size += length($_) % $sizeof_packi; # Padding ??? why need to pad? who help ? bloves [EMAIL PROTECTED] 2004-11-25
Re: [off topic] an amusing side note
On Wed, Nov 24, 2004 at 06:30:29PM -0500, Felix Gallo wrote: 2. perl 6 is a lot cleaner than perl 5. It's also much, much larger than an already very large language. I've been programming and evangelizing Perl in organizations small and gigantic since 4.03x, and my eyes just glaze over at all the unnecessarily surfaced complexity bound to make reading other people's programs finally, at last, literally impossible: http://www.ozonehouse.com/mark/blog/code/PeriodicTable.html I'm not going to use perl 6. Now, think about what a similar table would look like for Perl 5. How different would it be? For extra credit, make one. As an exercise, go through those operators and remove all that are already in Perl 5 (such as cmp), or have an equivalent in Perl 5 (such as ?), or are a simple expansion of an operator (such as ?=). Another exercise, eliminate operators for operations you don't already do much of in Perl 5 (such as bitwise operations). For extra credit, note which operators are just altered versions of Perl 5 operators (such as +). For extra credit, make another list from that of those new operators which replace existing common idioms in Perl 5 (such as hyperoperators) and make them easier. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ The method employed I would gladly explain, While I have it so clear in my head, If I had but the time and you had but the brain-- But much yet remains to be said. -- Hunting of the Snark, Lewis Carroll
Re: [perl #32607] The preprocessor changes pmc to an identifier
Fglock @ Pucrs . Br [EMAIL PROTECTED] wrote: The preprocessor changes pmc to a previously used identifier: $ ./parrot -E -# invoke preprocessor Ouch, the preprocessor is far behind the current syntax. It needs either updating or disabling. Thanks for reporting, leo
Re: eof opcode
Brian Wheeler [EMAIL PROTECTED] wrote: I noticed a hole in the io.ops where the PIO stuff wasn't covered. This patch creates an eof opcode which checks for end of file. Please just use the eof method of the PIO object: $I0 = $P0.eof() leo
Re: [perl #32514] Cannot Build Parrot on Linux PPC (nonvolatile registers)
Chromatic [EMAIL PROTECTED] wrote: Ah, I've made Parrot build again on Linux PPC (and make testj only has the expected t/library/streams.t failure present with make test too). He he, great. The attached file works as the eventual src/platform_asm.s file, at least on my architecture. I'm not sure how to plug it in to the generated fileset cleanly, but that's a lot easier than trying to debug assembly code on a platform you don't have. Leo, what do you suggest to connect the dots here? Well, we need a more generic way to include such files. * platform_asm.s is just one file and depends on $platform. But we have as $jitarchname: ppc-darwin ppc-aix ppc-linux# AFAIK This file is common for all PPC JIT architectures. OTOH there is a config dispatch on $cpu in config/gen/cpu, but that is for C files. But as this asm.s is JIT-specific and needed for PPC it should be included by jit.pl. Where are the config hackers ;) leo
Re: Too many opcodes
Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Nov 24, 2004 at 09:20:42AM +0100, Leopold Toetsch wrote: 2) Opcode variants with mixed arguments Honestly acos Nx, Iy and tons of other such opcodes are just overkill. Heck, why do we even have transcendental maths ops that take integer arguments or return integer results? We have only the former. Returning integers would be still more silly. ... Can't we kill the lot? Well, sure. But: $ tail -1 ops/ops.num get_repr_s_p1532 We've additionally ~50 unblessed opcodes in experimental.ops. Now tossing just the integer variants of these transcendentals reduces the opcode count by 50. For everything that's intrinsically a function on real numbers, just take have N and P register variants. Ehem, that increaes the opcode count. And how do you override an opcode? What about: $P0 = new Complex $P0 = 1 + 2i $P1 = sin $P0 # now what I've shown a way to get rid of all these function-like opcodes. use overload 'sin' = \my_sin; becomes trivial then. 'sin' is a method call, always. And there is of course Python: r = math.sin(s) Nicholas Clark leo
