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
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: 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
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
Re: Too many opcodes
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. 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. Heck, why do we even have transcendental maths ops that take integer arguments or return integer results? Can't we kill the lot? For everything that's intrinsically a function on real numbers, just take have N and P register variants. Nicholas Clark
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.
eof opcode
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.
Brian Wheeler
[EMAIL PROTECTED]
cvs diff: Diffing .
cvs diff: Diffing ops
Index: ops/io.ops
===
RCS file: /cvs/public/parrot/ops/io.ops,v
retrieving revision 1.51
diff -u -r1.51 io.ops
--- ops/io.ops 29 Sep 2004 15:44:29 - 1.51
+++ ops/io.ops 24 Nov 2004 21:28:57 -
@@ -42,6 +42,19 @@
+=item Beof(out INT, in PMC)
+
+Check for end-of-file condition in IO object $2 and return the status
in $1
+
+=cut
+
+inline op eof(out INT, in PMC) :base_io {
+ $1 = PIO_eof(interpreter,$2);
+ goto NEXT();
+}
+
+
+
=item Bfdopen(out PMC, in INT, in STR)
Create ParrotIO object in $1 as a copy of file descriptor $2.
--
brian wheeler [EMAIL PROTECTED]
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
Will _anything_ be able to truly parse and understand perl?
Hi folks
I thought it was about time I brought some concerns I've been having
lately to the list. Not so much on any particular problem with perl6,
but on problems with perl5 we would seem to have the opportunity to fix
but aren't. (So far as I can tell).
One of the biggest problems I have had with perl5 is that nothing, not
even perl itself, can truly actually parse Perl source. By this, I
mean parse in the sense of reading a chunk of bytes of Perl source and
understanding what they mean. Call it document parsing if you wish.
perl itself would also appear unable to understand perl source, instead
doing what I would call RIBRIB parsing, Read a bit, run a bit. The
parsing of perl source is itself merely part of the first execution
phase (BEGIN).
If we leave source filters out of it for now, the main problems in
regards to document parsing in the current Perl is caused by the
interaction of prototypes and operator/operand context.
As the most common example, in order to know what the slash /
character is (division or regex), you have to know whether you are in
operator or operand context, which requires know what things are
parameters for subroutines and which aren't, and you can't keep track of
that without tracking all of the prototypes for every function both CORE
and in the symbol table as you go, and you can't do THAT without loading
every single module dependency and running a parse/BEGIN-phase-execution
on all of the files, and you can't do THAT without having a perl
interpreter to execute it all in.
Any attempt to use the perl interpreter to parse code to understand it
in any way is both unpredictable and dangerous, due to the common
situation of not having a platform that can fully run the code (and all
it's dependencies) and all the potentially dangerous side-effects.
If you can't load and BEGIN-phase-execute every single one of the
dependencies, you can't parse. At all... ever!
use Win32::Something;
1;
Unparsable on Unix...
use Win32::Something;
use Proc::ProcessTable;
1;
Unparsable on anything... even if I just want 1 syntax highlighted as
a number.
BEGIN { system 'rm -rf /'; }
1;
eeep!
If anyone checks in a broken version of a module into CVS that is part
of some large project you are working on, sorry can't parse anything any
more even to try to hunt down the problem.
For an more comprehensive example, take a look at Acme::BadExample,
which uses absolutely plain and simple syntax, yet is completely
unparsable. (The reward is as-yet unclaimed)
Go have a look now, I'll wait...
All of this creates HUGE headaches if we want to start adding some
intelligence to code analysis and manipulation. We've all seen the
lengths Komodo has had to go to by continuously running the code.
What few attempts there have been to modify code are fairly impotent.
While you _can_ get source back from B:: it isn't particularly useful
except as a way to serialise anonymous code for storage or transport.
Given $source, B:: throws away all syntax and commenting and POD and
__DATA__ and whatever is after __END__ and then dumps back out something
quite different from what went in. A sort of Frontpage effect. It's what
the program thinks is close enough to be the same, but definitely not
what you wanted.
Now, despite _all_ of these problems, the continuous insistence from the
entire Perl community that writing a perl parser is impossible (only
perl can parse Perl), and despite the fact I had seen several other
people try and fail, or give up, or not really get started, I decided to
redefine the problem slightly and have managed to get a working Perl
parser up and running.
Or at least, well enough to handle selfgol and 90% of CPAN (I haven't
really started working on corner cases yet, after which I expect to
reach about 99%), and to do so needing ONLY what is contained in the .pm
or .pl file and nothing else. The parser can read all of
Acme::BadExample safely and write it back out again unchanged.
In any case, it works and works well enough to start building a number
of cool toys on, such as normalisation and comparison of code, code
metrics (Leon had a play with this), syntax highlighting, style
analysis, the CPAN Cross Reference, and various other stuff that is
staying on the whiteboard until API-freeze is finished.
(back/forwardporting, refactoring, auto-documentation, smart perl diffs,
safe testing of code, better dependency and version extraction,
checkstyle, a refactoring perl editor ala IntelliJ IDEA, etc etc etc).
And most importantly, because it treats the Perl source as a document
(data structure) and not as code (procedural execution) it can serialise
back to the source code which will be identical to what it read in. That
is, it is totally round-trip safe (100% in testing of a CPAN subset of
5,500 perl files)
So $source - $DocumentObject - $source is safe.
Now of course, it is completely unable to deal with source filters.
There is some
[perl #32607] The preprocessor changes pmc to an identifier
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #32607] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32607 The preprocessor changes pmc to a previously used identifier: $ ./parrot -E -# invoke preprocessor pcc_sub _test .param string s1 .param pmc p2 end ^D # output: pcc_sub _test param string s1 param s1 p2 # this should be pmc p2 end $ ./parrot -V This is parrot version 0.1.1 built for i386-linux. Copyright (C) 2001-2004 The Perl Foundation. All Rights Reserved. [...] PASM/PIR compiler version 0.1.1. - same output with parrot 0.1.0 Thanks - Flavio S. Glock
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: [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: [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
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: Will _anything_ be able to truly parse and understand perl?
Adam Kennedy writes: perl itself would also appear unable to understand perl source, instead doing what I would call RIBRIB parsing, Read a bit, run a bit. RIBRIB? RABRAB, surely! Smylers
