Re: [DRAFT PPD] External Data Interfaces
On Sat, Aug 17, 2002 at 03:58:32PM -0700, Brent Dax wrote: > =head2 Strings > > Parrot-level Cs are to be represented by the type > C. This type is defined to be a pointer to a C parrot_string_t>. > > The functions for creating and manipulating Cs are listed > below. Is it worth arranging a reminder in here that as parrot is garbage collected there is no confusion about who owns pointers to blah? > =item C Parrot_Int len, Parrot_String enc)> > > Allocates a Parrot_String and sets it to the first C bytes of > C. C is the name of the encoding to use (e.g. "ASCII", > "UTF-8", "Shift-JIS"); if a case-insensitive match of this name doesn't > result in an encoding name that Parrot knows about, or if NULL is passed > as the encoding, the platform's default encoding is assumed.[1] Values > of NULL and 0 can be passed in for C and C if the user > desires an empty string. Should that char * be const char *? > Note that it is rarely a good idea to not specify the encoding if you're > using C and C. I'm a native English speaker and I'm finding that double negative hard to work out. Is there a clearer way to phrase it? > =item C dest, Parrot_String src)> > > Sets C to C and returns C. If C is NULL, a new > Parrot_String is allocated, operated on and returned. If C and > C are the same, this is a noop. This may or may not be a > copy-on-write set; the embedder should not care. "This might be a copy-on-write set" ... And do we need a RFC like definition of should/may/must/mustn't? In which case, surely that should read "the embedded must not care"? > B Is this a good policy? > > =item C Parrot_String dest, char* bytes, Parrot_Int len, char* enc)> > > Sets C to the first C bytes of C and returns C. > C is taken to be the encoding of C; the Parrot_String will > retain its original encoding. (Call C on the > Parrot_String first if you want to retain C.) Again, should that be const char *bytes? > =item C Parrot_String enc)> > > Transcode C to C. If C isn't recognized as a valid > encoding name by a case-insensitive match, or if it is NULL, the default > encoding is used. Encodings are specified in parrot strings (not char *) yet you state that it's case insensitive. Is case insensitivity well defined on an encoding basis, or is it actually dependent on the language level? [eg one might argue that in English þ and Þ aren't the same, but if the string is in ISO-8859-1 then Parrot isn't going to know whether the name was specified in English, German or Icelandic. I chose þ because I don't think there are any foreign words adopted into English spelled with thorn. Whereas I'd not be surprised if most other accented letters are used in some or other word] Independent of that, aren't we opening ourselves up to a big performance hit by doing case insensitive matching on arbitrary encodings (such as Unicode)? Which normal form were we going to do it in? And if the canonical name is defined in (say) ISO 8859-1 but their string is in Unicode, are we going to convert before deciding whether it is the same? And if they're in Shift-JIS but we're supplying it in ISO-8859-2 - that's 2 conversions? It seems faster having names as US-ASCII and being case insensitive, or having names case sensitive. > =item C str)> > > Returns the length of C in characters. Note that this is > "characters", not "bytes"; the string's encoding defines what > "character" means. Should you be clear what happens with combining characters? If so, that's "characters", not "bytes" or "glyphs", isn't it? Is there a cross reference to what a Parrot_UInt is? > =item C cstr)> > > Creates a Parrot_String from the given C string. Assumes the native > encoding. const char* ? > =item C vtable)> > > Creates a new Parrot_PMC using C. This can be used for > "private" PMC types. > > B Is this a good idea or not? Singletons are considered useful in some language, aren't they? Without this, would it be hard to efficiently create singletons? > =item C > > Calls the system C with C. Are you sure you want to set that in stone? "Calls the system malloc or equivalent" IIRC on Win32 perl5 supplies a malloc that tracks which (i)thread allocates memory, and frees all memory on ithread exit. And perl5 comes with its own malloc, which if often likes to use on *nix. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Reducing DOD runs by manual header freeing
On Sat, Aug 24, 2002 at 11:46:27PM -0400, Mike Lambert wrote: > Perhaps I do need a slower machine. I'm not normally one for > purchasing/developing on slower computers, howeverit's much slower > when I do that. :) Very true in the general case, but the testing stage (and also any benchmarking) would benefit from also being tried on a smaller machine. (Note smaller, not just slower - ie less ram so it might swap more, smaller CPU caches so it will show up if any algorithm has a large working set, etc) > Currently, I'm using a 1ghz p4 as my testbed, with 512mb ram. > Unfortunately, trying to copy/compile on a linux p2 350 would take longer, > as would trying to test on other architectures. I've toyed with the idea > of setting up dstributed benchmarking, where I can test smallish > benchmarks on a bunch of testdrive machines at once, to run overnight in > creating an 'ultimate single benchmark number' that means no more than any > other benchmark. :) Well, it would be more interesting as a comparative benchmark number, so something like: alpha arm i86 mipspa-risc ppc rs6000 sparc without foo:100 100 100 100 100 100 100 100 with foo1: 103 98 110 99 90 102 101 104 with foo2: 104 101 ... so you could see the effect of something across various architectures. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: DOD etc
On Sun, Aug 25, 2002 at 04:22:33PM +0100, Dave Mitchell wrote: > Well, if understood you correctly, then a single execution of > > my $fh = IO::File->new(...) > > anywhere in the program or its libraries would trigger this slow behaviour > for the rest of the program. I'd have thought that the above, or its Perl6 > moral equivalent, is a fairly common idiom. There may be too much book-keeping overhead in this, but 0: Default interpreter state is that a: there are no loose objects with deterministic destruction needed b: there are no rooted objects with deterministic destruction needed (the meaning latter becomes clear below) 1: when you create an object with deterministic destruction needed, it is flagged as such, and the interpreter is flagged as having one of these loose. 2: Likewise, if you ever assign an object with deterministic destruction needed, the interpreter is flagged as having one of these beasts loose. 3: And if you ever assign (and overwrite) a DD object, you need to do a DOD run (as you might just have removed the last reference to it) 4: At the end of a block, if there are no objects of either sort, you are happy - just let GC work If there are rooted objects with deterministic destruction needed, but no loose objects, then you need to force a DOD run. If there are loose objects, then you need to do a DOD run, *and* when you find any deterministic destruction objects around that have parents that aren't deterministic, then you need to propagate the deterministic flag upwards (recursively, unfortunately) to the root. You then clear the loose object flag. I think that the above probably slower. However, I believe that it is possible to optimise, in that if at block entry all deterministic destruction objects are rooted (so the loose flag is clear) and during that block you neither create any, nor assign to or from any, then at the end of the block you can not have caused any to go out of scope. (Actually, I think it's laxer than that - if you assign a DD object to another container already marked as DD, then you've not let any DD object become loose) Note that this optimisation relies on all containers of all objects that have deterministic destruction being marked as deterministic destruction. And also, the whole thing relies on checking the deterministic destruction flag on every object assignment. (ie this would be for everything that does a reference count increase or decrease in in perl5 of a DD object) If I've got the above correct, then you do have to pay a price on every assignment (to verify that you're not moving DD objects into non-DD objects, or overwriting a DD object) but apart from that you only have to force a DOD run at the first block exit after a DD assignment. So once you've done my $fh = IO::File->new(...) the DD flag is propagated up the symbol tables (or pads) to the root for wherever $fh is at the (forced) block exit DOD run, but after that you can leave blocks with forcing a DOD run, providing you don't assign to or from $fh; (Which I believe will be one of the two the common cases - these DD objects will either be very persistent, or will go out of scope at the end of the block that created them) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: DOD etc
On Sun, Aug 25, 2002 at 01:34:32PM -0400, Dan Sugalski wrote:
> At 4:22 PM +0100 8/25/02, Dave Mitchell wrote:
> >Well, if understood you correctly, then a single execution of
> >
> >my $fh = IO::File->new(...)
> >
> >anywhere in the program or its libraries would trigger this slow behaviour
> >for the rest of the program.
>
> No. That's why we make it a counter. When a DOD run is made we recalc
> the number of deterministci destructions needed.
But I believe that that means as long as something has an IO:File somewhere
in parrot, our DD-needed counter is non zero, and every block exit must be
a DOD run.
(although your counter is better than "the rest of the program", (for ever
and ever, world without end, Amen))
however, rambling further:
On Sun, Aug 25, 2002 at 05:27:14PM +0100, Nicholas Clark wrote:
> 0: Default interpreter state is that
>a: there are no loose objects with deterministic destruction needed
>b: there are no rooted objects with deterministic destruction needed
>
> (the meaning latter becomes clear below)
>
> 1: when you create an object with deterministic destruction needed, it is
>flagged as such, and the interpreter is flagged as having one of these
>loose.
> 2: Likewise, if you ever assign an object with deterministic destruction
>needed, the interpreter is flagged as having one of these beasts loose.
> 3: And if you ever assign (and overwrite) a DD object, you need to do a DOD
>run (as you might just have removed the last reference to it)
>
> 4: At the end of a block, if there are no objects of either sort, you are
>happy - just let GC work
>
>If there are rooted objects with deterministic destruction needed, but no
>loose objects, then you need to force a DOD run.
>
>If there are loose objects, then you need to do a DOD run, *and* when you
>find any deterministic destruction objects around that have parents that
>aren't deterministic, then you need to propagate the deterministic flag
>upwards (recursively, unfortunately) to the root.
>You then clear the loose object flag.
I think that rather than having a loose object flag, a loose object *counter*
would be better.
So this is a variant on your scheme. But I'm only counting the number of DD
objects that "loose" - by which I mean DD objects that aren't rooted in DD
objects (etc) back to "the root set". (whatever that might mean, but here
it means some top level container from which everything else hangs which is
treated as DD, but in reality never goes away for the life of the GC system)
I don't think you win at all this way if the compiler is puts ops in
to explicitly free DD objects for each reference it knows about when they
go out out of scope.
Say someone goes
{
my $fh = IO::File->new(...)
...
}
the compiler knows that $fh had a reference to the IO::File object, but
that reference has just been eliminated, so it's time to check. But if you
have an op saying "the IO::File formerly pointed to by $fh may be dead"
you still have to do a full DOD run to try to find it. And you have to
carry the DOD run to completion (rather being able to stop short at the
first point when you find a rooted reference to "the IO::File formerly
pointed to by $fh") because the block may have looked like this
{
my $fh = IO::File->new(...)
...
push @global1, $fh;
%global2{file} = $fh;
...
}
ie you need to ensure that both @global1 and %global2 have become marked as
DD, so that from here on the DD object is properly tracked.
But this all does smell of overhead - not as much as refcounting - because
for each object it's a 1 bit flag - but then again there's still DOD needed,
whereas refcounting doesn't need DOD.
(except to detect unreachable circular object loops)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: DOD etc
How does this work?
1 my $fh = IO::File->new(...);
# Compiler can know that the new object is still linked.
2 &some_sub ($fh); # Who knows? :-)
# Compiler will assume that new object is still linked.
3 undef $fh;
# Er? Need a DOD run right now, because that may have been the last link
# to it, and my impression was that "deterministic" meant that, not
# "at the end of the next block. I might be looping without ever leaving
# the block
4 @main::some_global = ();
# Need a DOD run right now, because how do I know if &some_sub stashed a
# link to it in the global array?
I think that if we have unrefcounted "deterministic destruction" objects
somewhere freely in the GC system, then we'll be needing a DOD run after
every statement (or, actually after any assignment within every statement)
if we want truly deterministic destruction.
Although it's probably possible reasonable not to DOD if &some_sub uses
%MY to mess around with its caller's lexicals (and undef $fh at line 2)
It might be nice to offer "very deterministic" destruction (as above, as
perl5), and laxer "at the end of a block" destruction.
Plus, we could get the dangling zero external reference loops immediately
(the ones perl5 misses) with a DOD run, or we could still do better than
perl5 by only guaranteeing to find them at some specified time later
("at DOD runs" being one time we could specify)
All ways of doing deterministic destruction seem to have considerable
overhead.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #16853] [PATCH] avoid touching files
On Thu, Aug 29, 2002 at 07:35:46PM +, Steve Fink wrote: > This patch makes re-running Configure.pl avoid updating the timestamps > on the generated .h (and many other) files iff the files did not > actually change. This is really only helpful to people who are working > on the Configure system and are sick of having to rebuild everything > to test their changes. It should be safe to apply for everyone, but I http://ccache.samba.org/ (I think the patch is a good idea. But also using ccache can seriously accelerate repeat build times. It's my second favourite development aid (after valgrind)) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Goal call for 0.0.9
On Mon, Sep 02, 2002 at 11:15:17AM -0700, Steve Fink wrote: > On Mon, Sep 02, 2002 at 08:25:30AM -0700, Sean O'Rourke wrote: > > On Mon, 2 Sep 2002, Dan Sugalski wrote: > > > > > Here's a call for potential goals for the 0.0.9 release of parrot. My list: > > > > > > *) Exceptions > > > *) initial PMC freeze/thaw API > > > *) Sub indicators in bytecode > > > *) On-the-fly bytecode section generation > > > > *) methods (in PASM and C) > > *) implementation of some methods for the Perl classes > > *) stashes > > *) Resolve the prompt finalization problem (good luck...) > *) PMC name, implementation cleanup > *) Filename, line number tracking *) Careful elimination of all compiler warnings, particularly on non x86 platforms, and for builds with non-default INTVAL size This is going to need some care to work out why some warnings happen, and find ways to re-order/re-pack/re-size structures to avoid both these gcc warnings: In file included from ../include/parrot/register.h:16, from ../include/parrot/interpreter.h:42, from ../include/parrot/parrot.h:160, from perlhash.c:24: .../include/parrot/string.h:59: warning: padding struct size to alignment boundary In file included from ../include/parrot/interpreter.h:51, from ../include/parrot/parrot.h:160, from perlhash.c:24: .../include/parrot/debug.h:53: warning: padding struct to align `value' over all platforms. (which will be fun) and I think *) Rationalisation of how we make bytecode I think that the assembler is slower than it could be. I feel that the "correct" solution is a perl front end talking to a C bytecode generation library. I feel the library ought to be common, so that it would be possible for imcc (or anything else) to use the bytecode generation library direct, rather than having to emit PASM only for it to be re-interpreted. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: core.ops ARGDIR
On Mon, Sep 02, 2002 at 09:49:25PM +0200, Leopold Toetsch wrote: > > This should be - from my (imcc) POV - reflected by these IN/OUT settings: > > op set(in PMC, in INT) > op set(in PMC, in STR) > op set(in PMC, in NUM) > op set(out PMC, in PMC) # ok, $1 points to $2 now Thinking about it, that actually seems correct. This alternative seems wrong: op set(inout PMC, in INT) op set(inout PMC, in STR) op set(inout PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now because I'm assuming that the input PMC register for the first three is unchanged. Or can there be situations where an assignment to a PMC changes the value of the register itself? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Parrot: maximizing the audience
On Wed, Sep 04, 2002 at 07:42:24AM -0400, Dan Sugalski wrote: > At 7:34 AM -0400 9/4/02, John Porter wrote: > >Sean O'Rourke wrote: > >> ... I don't see how giving the list a > >> different name will have any real effect ... > > > >? > > > >It will have a huge psychological effect, at least outside our tight > >little club. But if that's only as far as you can see... > > Really? At the moment, how many people outside the tight little club > actually care about the name of the mailing list? And how many more > would really care if we changed the name? I'd much prefer someone to implement something that allows python programs to run on parrot. Not that I've ever used python, let alone hacked its innards. My reasons are: 1: I'd like some other existing mainstream language to be working 2: The impression I get is that python would be the easiest. (in that it I believe that it has external bytecode of a well-known format) 3: It ought to be easier than either (full) perl5 or (not yet fully written) perl6 However, I confess I'm not sufficiently concerned about this to actually try it. (There are too many things I still want to do with the perl5, it seems) Nicholas Clark
Re: Parrot long-term goals/prospects
On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote: > 4) The *only* tools you will need to build parrot are a C compiler > environment and either a make tool or a shell I believe we may be able to get away without a make tool or a shell. It won't be pretty, but I see no reason why we can't automatically generate the default order of building things from source code scratch into a C program, which manually ask the user 1: build this C program from this single self contained C source file 2: run it, with the current directory being the parrot source directory and it bootstraps the rest. No use to anyone developing the parrot source code and wanting dependency checking, but that's not the intent of this. It's to get a parrot bytecode interpreter up to the point that it can run a make-like system supplied as parrot bytecode. Doesn't matter if it then needs to rebuild most things. (Everything else in Dan's message, which I read quickly, I agree with, at least in overview) Nicholas Clark
Re: [perl #17026] [PATCH] core.ops including #16838
On Thu, Sep 05, 2002 at 04:38:37AM -0400, Dan Sugalski wrote:
> At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
> >core.ops has currently:
> >
> >- obvious errors e.g.
> > -inline op mul (out PMC, out PMC, out PMC) {
> >
> >- wrong docu and minor typos e.g.
> > -=item B(in PMC, in STR)
> >
> >- and finally (as discussed in perl6-internals, "core ops ARGDIR"),
> >wrong ARGDIRs for PMCs:
>
> We need to nail down what the directions mean. The IMCC and JIT folks
> are the ones that care here. I've been working on the assumption that
> an out means that the register in question may change value, so it's
> not appropriate on, say, add P1, P2, P3, since the destination
> *register* doesn't change, just the value of the PMC in the register.
> This is different than, say, add I1, I2, I3 where the value in the
> destination register does change.
That makes it sound like we have (at least) 2 directions of out. We seem
to have
in the register is read,
(and the value pointed to by the register is read)
out1the register is written to
out2the value pointed to by the register is written to, but the register
itself is unchanged
and both are useful, but for different parts of optimisation. I suspect
(but I don't know about imcc, and I've not thought about it) that out2 is
useful for optimising how many PMCs you actually need to use as temporaries
in the first place, and out1 is useful for optimising how you map
temporaries to real parrot registers. But I'm guessing, and for JIT
purposes I think only need to know about out1.
Nicholas Clark
Re: [perl #17026] [PATCH] core.ops including #16838
On Thu, Sep 05, 2002 at 08:15:28AM -0400, Dan Sugalski wrote: > At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote: > >Dan Sugalski (via RT) wrote: > > > >We need to nail down what the directions mean. > > > > > >This is, what I'm trying to do since quite a time. > > > >... The IMCC and JIT folks are the ones that care here. > > > >Here is the IMCC folks speaking ;-) > > Sorry. I've been pathetically behind in my p6i mail lately. > > If in means no change, inout means register is the same but the > string/pmc may have mutated itself, and out means the register is > changed, then I'm cool with it. Go ahead and commit the patch. I believe applying the patch is the right thing, because it's progress on where we are, but I think (not fully formed yet) that we would benefit from finer granularity on what can get modified > Do be aware that *reading* from a PMC can potentially alter it, so: > >add inout P1, in P2, in P3 > > isn't necessarily a safe thing to assume. This is the "does a 'const' method mean that the memory representation of an object does not change, or only that the publicly accessible representation is unchanged" question, isn't it? [IIRC the question at one time was whether a const method in C++ could change the underlying object, providing the values returned by all public methods would not change as a result] The upshot of my thoughts is that I believe that the ops would benefit from having out (if not in as well) being broken down into (at least) 1: the value in the register did/didn't change 2: the value of the thing referenced by the register did/didn't change (possibly 2a and 2b being that the internals of the object didn't/might've changed) So then JITs, imcc and other things would know the difference between what these two do add inout_val P1, in P2, in P3 set out_reg P1, in P2 Nicholas Clark
kcachegrind for speed profiling?
Has anyone tried kcachegrind to speed profile parrot? Based on what the web page http://www.weidendorfers.de/kcachegrind/ says: The trace includes the number of instruction/data memory accesses and 1st/2nd level cache misses, and relates it to source lines and functions of the run program (a disadvantage is the slowdown involved the the processor emulation, it's unfortunately around 50 times slower). A patch for valgrind sources (see below) adds call tree tracing, i.e. how the functions call each other and how many events happen while running a function (including all called functions). this could be very useful for figuring out where parrot is slow. I've used the basic cachegrind interface to valgrind at work to figure out where I was doing things wrong w.r.t. memory, but kcachegrind is currently somewhat tricky for me, as no desktop machine I've got at home is running Linux on x86. Nicholas Clark
Re: [perl #17026] [PATCH] core.ops including #16838
On Fri, Sep 06, 2002 at 09:01:13PM +0200, Leopold Toetsch wrote:
> #17026 was reverted by committing minor print changes.
>
> Please clean up the mess, whoever did it.
It has been reverted, but not in the way you describe:
revision 1.208
date: 2002/09/06 07:26:22; author: mongo; state: Exp; lines: +4 -4
In tracking down a gc bug, I realized that the current throwaway
implementation of the print op could be replaced with a faster
throwaway implementation that avoids doing a string_to_cstring.
Note that both the original and new implementations are still buggy
with respect to supporting different encodings. I don't know if
printf("%s") is any better than fwrite in terms of at least vaguely
paying attention to your locale or whatever. If so, don't apply it.
(Courtesy of Steve Fink)
revision 1.207
date: 2002/09/06 01:52:06; author: mrjoltcola; state: Exp; lines: +86 -86
Update some ops' parameter attributes. Courtesy Leopold Toetsch.
revision 1.206
date: 2002/09/05 15:03:23; author: dan; state: Exp; lines: +16 -0
chr op, and scheme fixes
revision 1.205
date: 2002/09/05 14:54:00; author: educated_foo; state: Exp; lines: +86 -86
Fix argdirs for imcc (Leo Toetsch).
revision 1.205 is educated_foo applying your patch
revision 1.207 is mrjoltcola unapplying your patch (presumably by not realising
that it had been applied and assuming that it was reversed.
I do not remember seeing a thanks applied to the list, but even if sent, that
doesn't stop the race condition of two people trying to apply patches before
mail has propagated)
revision 1.208 (the minor print changes) is innocent.
I would prefer not to be the committer to fix this - I'd only become a
third person and add to the confusion.
Nicholas Clark
Re: Tinderbox turning green !
On Fri, Sep 06, 2002 at 07:37:48PM -0700, Steve Fink wrote:
> On Fri, Sep 06, 2002 at 09:32:27PM -0400, Andy Dougherty wrote:
> > On Thu, 5 Sep 2002, Andy Dougherty wrote:
> >
> > > Ok, with the alignment hack now in (see resources.c) and lots of various
> > > and sundry portability fixes, it looks like we're on our way to turning
> > > the tinderbox a lovely shade of green.
> >
> > AARGH! It appears I spoke too soon. I don't have easy access to check,
> > but it looks like my alignment patch (resources.c, header.h) is gone
> > so Tru64 and Solaris64 are having alignment problems again. Also, the
> > C++-style comment in multiarray.pmc is crashing the Solaris tinderbox.
> > (I sent in a patch for that #17034 which is listed as applied, but
> > I don't think it actually is.)
>
> I think the Secret Parrot Society has decided that a certain Mr. Andy
> Dougherty should not apply his own patches. That's two different
> people now who have helpfully applied your patches in reverse after
> you already committed them. Maybe you should start replying "Thanks,
> applied" to yourself in self-defense!
It's also now three different patches that have got applied, and then applied
in reverse by someone else.
I can't see how this can happen without one of the two committers trying
to apply the patch to their local source, seeing a warning from patch
Reversed (or previously applied) patch detected! Assume -R? [n]
and saying y.
So, if committers STOP at this point and check the CVS log for that file,
then they will either find
1: a log message saying that that patch has already been applied.
(log messages ought to be helpful enough to reveal this. if log messages
aren't, bad, but cvs diff with -r is your friend)
2: that it doesn't seem to be applied, in which case CHECK WITH THE AUTHOR
("Your patch appears to be reversed, is that correct?")
Note, I'm quite deliberately not including an option that says "so you think
you know what's up; go ahead in reverse"
I think that sending a thanks applied in reply to the patch and closing the
bug ticket (aargh, which I can't do, and I've forgotten the instructions how
to join that club) probably also help.
Actually, I think I might relax my above suggestions:
3: If the patch supplies more regression tests when applied in reverse, and
makes no note about removing regression tests, it is reasonable to assume
that it's been supplied in reverse.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
[PATCH] lsr for ARM jit
On Mon, Aug 19, 2002 at 09:24:47PM +, Jason Gloudon wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #16308]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16308 >
>
>
>
> This adds logical shift right opcodes. They are essential for bit shifting
> negative values without sign extension getting in the way.
Here are logical shift right opcodes for the ARM jit.
(Cargo cult coding)
I probably shouldn't have bothered with Parrot_lsr_i_ic_ic, particularly
as I feel that all two integer constant input permutation of integer binary
ops should not be autogenerated.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
--- jit/arm/core.jit~ Tue Aug 13 22:56:23 2002
+++ jit/arm/core.jitSat Sep 7 15:56:06 2002
@@ -506,6 +506,39 @@ Parrot_shr_i_ic_ic {
Parrot_jit_int_store(jit_info, interpreter, cond_AL, 1, r0);
}
+Parrot_lsr_i_i_i {
+Parrot_jit_int_load(jit_info, interpreter, cond_AL, 2, r0);
+Parrot_jit_int_load(jit_info, interpreter, cond_AL, 3, r1);
+jit_info->native_ptr
+ = emit_arith_reg_shift_reg (jit_info->native_ptr, cond_AL,
+ MOV, 0, r2, 0, r0, shift_LSR, r1);
+Parrot_jit_int_store(jit_info, interpreter, cond_AL, 1, r2);
+}
+Parrot_lsr_i_i_ic {
+Parrot_jit_int_load(jit_info, interpreter, cond_AL, 2, r0);
+jit_info->native_ptr
+ = emit_arith_reg_shift_const (jit_info->native_ptr, cond_AL,
+ MOV, 0, r2, 0, r0, shift_LSR,
+ *INT_CONST[3]);
+Parrot_jit_int_store(jit_info, interpreter, cond_AL, 1, r2);
+}
+Parrot_lsr_i_ic_i {
+Parrot_jit_int_load(jit_info, interpreter, cond_AL, 2, r0);
+Parrot_jit_int_load(jit_info, interpreter, cond_AL, 3, r1);
+jit_info->native_ptr
+ = emit_arith_reg_shift_reg (jit_info->native_ptr, cond_AL,
+ MOV, 0, r2, 0, r0, shift_LSR, r1);
+Parrot_jit_int_store(jit_info, interpreter, cond_AL, 1, r2);
+}
+Parrot_lsr_i_ic_ic {
+jit_info->native_ptr = emit_load_constant (jit_info->native_ptr,
+ interpreter,
+ cond_AL,
+ ((UINTVAL)*INT_CONST[2]) >>
+*INT_CONST[3],
+ r0);
+Parrot_jit_int_store(jit_info, interpreter, cond_AL, 1, r0);
+}
+
;;
; logical ops
;;
vi modelines for the boilerplate (was Re: [PATCH] COW for ithreads (was Re: what copies scalars in ithreads?))
from perl5-porters: On Sun, Sep 08, 2002 at 09:47:24PM +0200, Rafael Garcia-Suarez wrote: > Nicholas Clark wrote: > > Are we going to assimilate what parrot is doing in all its C files - > > > > /* > > * Local variables: > > * c-indentation-style: bsd > > * c-basic-offset: 4 > > * indent-tabs-mode: nil > > * End: > > * > > * vim: expandtab shiftwidth=4: > > */ > > > > at the end. IIRC this sets the indenting and tabbing behaviour for both emacs > > and vi (vim only?) > > For most vi versions the portable vi modeline would be > * vi: set expandtab shiftwidth=4: Would changing the parrot boilerplate in this way be a good idea? I don't know much about vi, so I've no idea myself. [I know that the that the correct incantation to escape from vi is :q!emacs^M :-) (actually I might confess under torture I know slightly more that that, but I don't use vi regularly)] Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Goal call for 0.0.9
On Mon, Sep 09, 2002 at 03:02:55PM -0400, Andy Dougherty wrote: > On Mon, 9 Sep 2002, Sean O'Rourke wrote: > > > On Mon, 9 Sep 2002, Andy Dougherty wrote: > > > > Now why that [languages] isn't part of the default build, I don't > > > know. > > > None of the stuff in languages/ is part of the default build, and I think > > it should stay that way. It seems like bad form to, by default, build > > parts of a package that the user may not want to use. > > Yes, I agree in general. But the down side is that it's neither built nor > tested by most users (including the tinderboxes!). On balance, I think we > should use bad form and build parts that users may not want to use in > order to give them a workout. For development and testing, I believe that we should exercise (and then exorcise) all the bugs in all the languages we can find. I guess it should be a configuration option of what to build, defaulting to everything portable. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: chr, ord etc
On Tue, Sep 10, 2002 at 07:26:58PM +0200, Peter Gibbs wrote: > Graham Barr wrote: > > > As well as supporting big/little endian specifically, should we support > "native" > > ie packed in the same endian as the machine the code is being run on. > > Certainly. I think we would want also want native sizes, so we can > ask for short, int, long etc and get the platform's size and byteorder. > If the concept gets accepted, then we can start extending. I think we also want unsigned (ie zero extension of values shorter than intval whereas the supplied code does sign extension of values shorter than intval) I'd quite like to see 2 bits as well as 1 (binary) and 4 (hex), but I'm not sure how useful they'd be in the general case, versus an op to unpack arbitrary bit lengths, but these are really more use for a function that unpacks to an array rather than 1 value. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [PATCH] Re: [perl #17091] 64-bit-int builds broken
On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote: > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since > the prototypes are hidden in the C file, not in a shared header file, the > compiler doesn't warn about them.) Upon reflection, however, since the extern prototypes in a C file not in a header === bad. Reward of 1 coffee to each person who can give any reason when it is not bad. Can we make it a coding standard that we never define prototypes for external functions in source files. If we need to share prototypes between more than one source file for parrot private functions then we should use a private header file. If we need prototypes for other people's missing prototypes then we should do that in some sort of common header file. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [RFC] building core.ops op_hash at runtime
On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote: > The op_code() function in op_lib_t does look up an op_info_table entry > by the op's full_name. To accomplish this, the current implementation > builds via ops2c.pl basically a static hash table, which get's appended > to core_ops.c and core_ops_prederef.c. > > My proposal is: build a hash table at runtime on the first invocation of > op_code() (which parrot doesn't do). > If no one has objections I'll send a patch. I like this idea. (but I've no idea of the subtle implications) Where you thinking of building the hash table in one hit using a linear parse over the op names the first time a lookup is requested? An alternative (more complex, may not be worth it) is to perform the hash construction in a lazy fashion: Initialise with a flag that says the hash isn't complete, and a pointer at the start of the linear list. When somewhere requests a name, look in the hash. If found, good Once the hash becomes flagged as complete you stop here, returning not found. Resume the linear search using the pointer. Hash everything you pass by that isn't what you're looking for. If you find it, good. hash it too, save the new pointer, return the result. If you hit the end, flag the hash as complete, return failure. ex::lib::zip is using this approach to scan the directory of the zip file its stuffed in @INC on perl (5.8 or later). I don't know if it's faster, but it feels nicer :-) Nicholas Clark
Re: [perl #17194] ScanMail Message: To Sender, action taken by attachment blocking.
This: On Thu, Sep 12, 2002 at 01:36:14PM +, System Attendant wrote: > # New Ticket Created by System Attendant > # Please include the string: [perl #17194] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17194 > > > > ScanMail for Microsoft Exchange has blocked a file attachment(s). > > Place = [EMAIL PROTECTED] > Sender = Leopold Toetsch > Subject = [perl #17193] [PATCH] Re: Howto packout _SC / _NC KEYs > Delivery Time = September 12, 2002 (Thursday) 09:33:34 > > Action on file attachment(s): > Quarantine 'packout.c.diff' to C:\Program > Files\Trend\Smex\blocked_attachments at Marc Belgrave > > Message from recipient's administrator: > As part of Algorithmics Security Policy on e-mail, this attachment has been > blocked from entering our mail system. The attachment name can be found in > this message. For Algorithmics Employees who require more information on > how to send and receive e-mail with attachments, please refer to the > following: http://algoweb/it/docs/documentation/virus-faq.html . For > people external to Algorithmics, please contact the intended recipient for > further informaton. is getting trying. Do we have any official public LARTing policy on braindead systems that mail back to the list? [IIRC there was an "NT VirusWall" that was getting upset on p5p, thinking that several lines in perlbug's output looked like buffer overrun attempts. It also got very irritating] Nicholas Clark
Re: [perl #17346] [PATCH] return undef for negative indices
On Mon, Sep 16, 2002 at 05:32:23PM -0700, Sean O'Rourke wrote:
> You're right -- right now "@a" is deemed "implicit call to join(' ', @a)"
> context, but that's mostly because it's what perl 5 does.
Strictly perl5 is join ($", @a), $" defaults to ' ' and rarely is changed.
(except by golfers and obfuscators. And several that I met at YAPC::EU are
excited by the golfing and obfuscating possibilities of perl6. Be afraid)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Perl 6 Summary for week ending 2002-09-15
On Wed, Sep 18, 2002 at 04:42:13PM +0100, Piers Cawley wrote: > Steve Fink committed his IntList patch, and Josef Höök queried the > creation of an intlist.c file in the parrot core, as his matrix patch > had been rejected for doing something similar. Nobody has responded to > this yet... I can't find the original message now, but I don't remember an answer appearing. This is frustrating as the question raised was a good one for which I didn't have an answer (and I'm not the right person to make a decision anyway.) > Dan Sugalski turned 35 on the 12th. I turned 35 on the 15th. Did I miss > anyone else's birthday? Not yet - but I almost did. :-) I only remembered at the airport yesterday that it was my 30th birthday. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17549] [PATCH] direct accesss for intlist 10 times faster
Disclaimer: I am very out of touch with what's actually going on on perl6-internals at the moment. (And even more out of touch with the source code) On Tue, Sep 24, 2002 at 04:56:25AM +, Leopold Toetsch wrote: > +return list->chunk_list[idx / INTLIST_CHUNK_SIZE]; On Tue, Sep 24, 2002 at 05:22:33PM +0200, Leopold Toetsch wrote: > Sean O'Rourke wrote: > >If we expect these (especially shift) to be as frequent as push/pop, and > >we want fast indexing as well, then maybe something like the SGI STL > >implementation of a dequeue (dequeueue?) would be best: keep an array of > >(pointers to) fixed-size chunks (rather than intlist's linked-list). > > > Exactly this is, what my recent patch actually did: list->chunk_list > holds pointers to chunks, an index lookup is one "div" more expensive > then in array. I see that you define INTLIST_CHUNK_SIZE as 256 currently. Do all compiler optimisers pick up on the fact that this is a multiple of 2, and can be converted to a shift (probably faster)? Would it be wise to express it as log base 2 in the header, and explicitly write it as a shift here (and idx = idx % INTLIST_CHUNK_SIZE; becomes a logical and) ? > >This would also allow gaps in the middle to remain unallocated, and could > >speed up some splices. > > > Yep. With some additional overhead we could also have sparse arrays and > cheap splice. I like the sound of sparse arrays. I suspect that by having arrays stored in chunks, we also have cheaper extension (no need to allocate a new huge block for 1024 elements, and copy 512 into it, merely allocate another 256 and chain them on the end) at the cost of one indirection more on lookup, and more wasted overhead by having smaller blocks. (or are they fixed size, and so come from an arena?) > >It's an improvement over the current implementation, but I don't think > >it's the best solution for perlarray's requirements: > > > >1 - front insertion/removal > >2 - back insertion/removal > >3 - indexing > >4 - less-frequent insertion/removal in the middle (splice) > > > >The current approach is necessarily bad for 1, good for 3, and > >unnecessarily bad for 2. IntList is good for 1 and 2, but bad for 3. I'm guessing that the current implementation is a contiguous array that extends at the end. That's not necessarily bad for front insertion if you can store pointers to both the true start of allocated space and the current first element, and move the current first element around for front insertion and removal. (OK, with some major copying needed occasionally) I believe that perl5 is using this approach. (but I've not checked) > >Both are not-so-hot for 4, but I don't think a lot of people use splice. > > > Also for splice the chunk based solution is much better. For the case where you are splicing in or out elements equal to the chunk size, it's easy to see that you can just drop or gain entire chunk. Why is it better for splices of arbitrary sizes? It's not obvious to me that there is any particular advantage or disadvantage of a chunked approach for this. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Would a getting started guide help
I think a getting started guide would help a lot. On Sat, Sep 28, 2002 at 10:46:36PM -0400, Erik Lechak wrote: > 3)Do I have to use pod? No offense, but I can't stand pod. The pdd > design document states that pod is the "...documentation language for > All Things Perl", but this is Parrot not Perl. And this document would > not be a design doc. If Parrot is supposed to be a cross language VM, > why do people need to know pod to read (or write) the docs? I know that > it is easy to convert pod to an easy to read format, but would a > developer with little perl experience know that? Parrot is trying to > encourage developers from areas other than perl, so why discourage them > by introducing them to parrot with pod documents. Well, POD is supposed to be easy, and by implication easy to learn. But that's irrelevant if you already know it and know you don't like it. In my opinion it makes sense to have one documentation format consistently (in the same way that we intend to have one true C indenting style) What documentation format(s) do you like? Is there an easy way to convert them, or a subset of them, losslessly to and from POD? If we provided tools with parrot to do that, then (assuming we stick with POD as the documenting format) it would allow you (and everyone else who shares your preferences whom we hope to recruit) to write documentation in the way that feels natural to you by converting the POD documentation to whatever, editing that, and converting the changed version back. This would mean that the round trip conversion had to be lossless and (almost) canonical form, so that a diff of the original POD against the round trip would be empty, and I guess that possible in theory. However, are there any useful (not POD) documentation formats for which it's practical? > Could there possibly be a parrot comment style? It could be used > instead of other comment styles internal to parrot. Use it in the > c-code, the perl code, the parrot assembly code, and to write the > documentation. Then a (perl) preprocessor could strip it out before it > is compiled or run. Normally I would not suggest such a thing, but > there is a lot of code generation and manipulation going on anyway. It > could allow for document generation of all the parrot source, assembly, > tests, and documents into a javadoc-like html reference. Or maybe I'm > just dreaming. It's not clear to me what you think might work well for this. Do you have any suggestions - either of what we could do, or what there is already that is bad (and why)? > Please go easy on me for not liking pod. Well, you were crafty enough not to say why you don't like pod, which makes it hard for anyone to work out how to respond to your heresy. :-) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [INFO] news about Lea allocator
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
>
> Some remarks:
> - it's totally stable now, runs all tests (parrot and perl6)
> - memory consumption is like CVS or much less ...
> - ... if resources.c is unpatched (#17702)
> - runs almost[1] everything in almost the same time
> And last but not least, LEA allocator doesn't invalidate pointers due to
> copying data around (except realloc of course) - so e.g. hash.c or
> others could be optimized.
>
> Please have a closer look at it.
> void
> add_free_buffer(struct Parrot_Interp *interpreter,
> -struct Small_Object_Pool *pool, void *buffer)
> +struct Small_Object_Pool *pool, void *buff)
> {
> -((Buffer *)buffer)->flags = BUFFER_on_free_list_FLAG;
> +Buffer * buffer = buff;
> +if (buffer->bufstart && !(buffer->flags &
> +(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
> +free(buffer->bufstart);
> +}
> +buffer->bufstart = 0;
> +buffer->flags = BUFFER_on_free_list_FLAG;
> /* Use the right length */
> -((Buffer *)buffer)->buflen = 0;
> +buffer->buflen = 0;
The article doesn't mention garbage collection at all, and neither your
remarks nor your patch explains how it is now done. Is all garbage being
collected via that one free(buffer->bufstart); in the patch above?
I'm confused, and would appreciate hints about how to become less confused.
Nicholas Clark
Re: core.ops ate my (miniscule) RAM
On Wed, Oct 02, 2002 at 08:26:20AM -0700, Brent Dax wrote: > David Chan: > # I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of > # RAM, gcc 2.95.4, linux 2.2.17 and parrot out of CVS. Without > # swap, when I do "make", compiling core_ops_cg.c fails due to > # lack of memory. Which is unsurprising, as it is pretty big. > # It works if I use a 70 MB swap partition. > > The computed-goto core (in core_ops_cg.c) can't be split. But as Brent explained to me in an e-mail a while back ( http:[EMAIL PROTECTED]/msg11197.html ) You can pass Configure a flag to disable computed goto (--cgoto=0) ie run Configure.pm as ./Configure.pl --cgoto=0 You don't need to build the computed goto core to have a working parrot. There are other (slightly slower at run time) cores it also builds. Nicholas Clark
Re: [INFO] news about Lea allocator
On Wed, Oct 02, 2002 at 03:46:33PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> >>+if (buffer->bufstart && !(buffer->flags &
> >>+(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
> >>+free(buffer->bufstart);
> >>+}
>
> >The article doesn't mention garbage collection at all, and neither your
> >remarks nor your patch explains how it is now done. Is all garbage being
> >collected via that one free(buffer->bufstart); in the patch above?
> >I'm confused, and would appreciate hints about how to become less confused.
> What about reading this page and downloading the file ;-)
I did. I thought that GC referred to the idea of making (in C terms) free()
a no-op, and arranging to automatically free() any memory that the allocator
knows has leaked. And yet all I saw in your patch *was* a call to free.
Which in C terms scares me, as *how* can the allocator know for sure?
Sure it can stack walk, and probe all the CPU registers for pointers to buffers,
but there are defined C behaviours you can do (such as storing only a pointer
somewhere into your buffer at fixed known-to-you offset.
Or storing your only pointer somewhere weird, such as mmaped memory (or shared
memory, or somewhere not in the stack or heap), or worse still in a file,
database, or somewhere outside your memory space. It's not leaked - your
pathological but correct program knows how to get the pointer back
On Wed, Oct 02, 2002 at 04:01:02PM +0200, Leopold Toetsch wrote:
> Jason Gloudon wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
>
>
> >Whatever source you are using cannot be the original Lea malloc, since it
> >does
> >not do garbage collection.
>
>
> * VERSION 2.7.2 Sat Aug 17 09:07:30 2002 Doug Lea (dl at gee)
>
> There seems to be no need for real GC, since fragmentation is ~3% or lower.
Jason's thoughts echo mine. However, I see the confusion about what is meant
by GC. He and I are thinking about malloc/realloc/free level garbage collection.
On Wed, Oct 02, 2002 at 07:46:07PM +0200, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> >Since all pool memory has to be anchored with buffers, and allocation
> >has to use buffers, the GC issues get subsumed into DOD runs, which is
> >OK--memory allocation, reallocation, and freeing will all be actively
> >traceable so we shouldn't leak, at least if we don't leak buffers.
>
>
> Yes, this were my thoughts WRT GC
So we only need at parrot level to garbage collect our buffers, as the only
thing we allocate and hand out to code is buffers? If so, this explains my
confusion.
> Yes, when our interface is malloc/realloc/free, any allocator could be
> plugged in.
Which is what I was thinking when I left work. If we're only allocating,
tracking and garbage collecting buffers, what stops us having the option
of getting and returning memory from the system's malloc()?
That way we could offer a smaller footprint parrot for tight platforms by
not providing our own allocator code. [With the assumption that our own code
is faster for our needs than system malloc, but let's prove that :-) And
anyone benchmarking this please try on HP/UX. It has an interesting malloc
that seems to cope with pathologically bad code loops that do repeated
realloc()s one thing bigger each time. I'd love to see the source to that,
because I suspect that this choice of behaviour and the performance it gave
to inefficiently written code made HP the sale to the firm I worked out.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17739] [PATCH] Tests for assign ops
On Thu, Oct 03, 2002 at 08:02:59PM +, Simon Glover wrote: > # New Ticket Created by Simon Glover > # Please include the string: [perl #17739] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17739 > > > > > Patch below adds tests for assign_p_i, assign_p_n and assign_p_s. > (There's no test for assign_p_p because the scalar PMCs don't support > it yet). Thanks, applied. But the bug isn't marked as such because I've not yet worked out how to do that. I like tests. They can (usually) be applied without having to wonder about whether the change they represent has design implications. Or actually having to understand that much of the code base (which I really don't at the moment) I don't feel qualified to apply various of the outstanding patches, for both the above reasons. use more 'executive dictatorial decisions'; Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17766] [PATCH] memory_internals.pod
home belongs > +this string. You shouldn't copy the same string to different places, Now, during GC (or freeing buffers) the problem arises: to whom does this string belong? > +The malloc()/free() approach stores a usage flag there. Only if all > +users of this string are dead, one and only one buffer header using this > +string, is allowed to free this string. And additionally this header is string is allowed to free this string. You use commas more frequently than I would. That's the first where I found it actually confused me. (In this case, sufficiently that I thought that there was an word missing from the last clause of the sentence, and had to re-read it twice) > +All spelling errors belong to those, who honestly collected them, as well as > +all errors related to my abuse of the English language - I'm not natively > +speaking it. > + > +To minimize this bugs section - please patch this document and keep it > +up to date - thanks. Oops. Does that mean I should have just committed it, and then committed my suggested changes? > +Leopold T?tsch <[EMAIL PROTECTED]> Erk. What did my mailer do. The raw message is: -- attachment 1 -- url: http://rt.perl.org/rt2/attach/39249/31851/1c9a63/memory_internals_pod.patch =_1033809707-24225-0 Content-Type: text/plain; name="memory_internals_pod.patch" Content-Disposition: inline; filename="memory_internals_pod.patch" Content-Transfer-Encoding: base64 Content-Description: memory_internals_pod.patch It seems that RT doesn't specify an encoding on its attachments, and my copy of mutt takes a rather conservative view about what they might be. I presume that that should be Leopold Tötsch Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17766] [PATCH] memory_internals.pod
On Sat, Oct 05, 2002 at 10:32:41AM -0700, Brent Dax wrote: > Why not just drop the 'therefore'? > > Objects in all pools not alive are considered dead. > > Are the objects not alive or the pools? If it's the objects, is the "in > all pools" necessary? Yes, I'm just starting to wonder what it means, now it is out of context. > Seeing the "normal" doesn't make you reinterpret the rest of the > statement, because it's just confirming an assumption you already made. I think you've convinced me. > I don't like the "DOD runs detect which objects are no longer being > used" sentence--at first read, I interpret 'runs' as a verb and 'detect' > as the beginning of a noun phrase, which yields a meaningless sentence. > Is there a problem with the sentence "DOD detects which objects are no > longer being used"? Only that it's better and you thought of it, not me :-) > # underlying allocator collects these pieces, where > # possible coalesces them > # to form bigger pieces, and then puts them on free lists, > # sorted by their > # sizes. Eventually, when a new malloc() arrives, it gives > # them back to > # parrot. > > There isn't really anything *wrong* with that fragment, but it could be > (IMHO) better: > > underlying allocator collects these pieces, coalesces them if > possible to form bigger pieces, and then puts them on free > lists, > sorted by size. Eventually, when a new allocation request > arrives, it may give them back to Parrot. I think yours is better because it seems clearer, probably because it flows more smoothly and eliminates some words (without changing the meaning) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17766] [PATCH] memory_internals.pod
On Sat, Oct 05, 2002 at 09:21:47AM +, Leopold Toetsch wrote: > Attached docu is for review and might also go in. > Suggestions, bugfixes, comments welcome. > > leo > > PS sorry, no MANIFEST update, mine differs too much ... Thanks applied. Plus MANIFEST Corrections from myself and Brent Dax then added. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: RFC: static line number information
On Mon, Oct 07, 2002 at 08:27:29PM +0200, Juergen Boemmels wrote: > But there must also be a way the higher level languages can assign > line numbers. Maybe C-like > #line 1 "foo.c" > directives are a solution. > or create dedicated assembler macros > ..line > ..file > (maybe) .column ooh. nice. That's built in full debugging support for befunge, isn't it? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Eliminate padding warnings
On Wed, Oct 09, 2002 at 02:14:50AM -0400, Tanton Gibbs wrote:
> There were a number of warnings which read something like
> "structure padded for alignment of member value in debug.h"
>
> This can be trivially fixed by reordering the structure members ( I hope).
> This patch works fine on cygwin, but I would like to see some other
> platforms (especially 64 bit) try it out to see
> 1.) does it compile without those warnings (although, there will be
> structure padding warnings, just not for individual members).
on ARM, lots of these two:
In file included from ../include/parrot/register.h:16,
from ../include/parrot/interpreter.h:42,
from ../include/parrot/parrot.h:160,
from array.c:27:
.../include/parrot/string.h:59: warning: padding struct size to alignment boundary
In file included from ../include/parrot/interpreter.h:51,
from ../include/parrot/parrot.h:160,
from array.c:27:
.../include/parrot/debug.h:55: warning: padding struct size to alignment boundary
/usr/local/bin/perl5.8.0 pmc2c.pl boolean.pmc
string.h:
56 /* Tail added to end of string buffers; used for COW GC */
57 struct Buffer_Tail {
58 unsigned char flags;
59 };
on ARM structures all align on 4 bytes, and so pad to a multiple of 4 bytes
Even that one.
Yep. legal ANSI C.
Likewise
debug.c:
50 typedef struct PDB_condition {
51 void*value;
52 PDB_condition_ptr next;
53 unsigned short type;
54 unsigned char reg;
55 } PDB_condition_t;
In order, the other significant compiler warnings I see are:
perlhash.pmc: In function `Parrot_PerlHash_get_pmc_keyed':
perlhash.pmc:192: warning: passing arg 2 of pointer to function from incompatible
pointer type
191 return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
192 entry, nextkey);
No idea
All 4 structs end with char members:
include/parrot/jit.h:36: warning: padding struct size to alignment boundary
include/parrot/jit.h:128: warning: padding struct size to alignment boundary
include/parrot/jit.h:150: warning: padding struct size to alignment boundary
include/parrot/jit.h:205: warning: padding struct size to alignment boundary
resources.c: In function `mem_allocate':
resources.c:147: warning: cast increases required alignment of target type
resources.c: In function `compact_pool':
resources.c:231: warning: cast increases required alignment of target type
resources.c:261: warning: cast increases required alignment of target type
resources.c:288: warning: cast increases required alignment of target type
resources.c:307: warning: cast increases required alignment of target type
147 ((struct Buffer_Tail*)((char *)return_val + size - 1))->flags = 0;
231 (struct Buffer_Tail *)((char *)b->bufstart +b->buflen);
259 struct Buffer_Tail *new_tail =
260 (struct Buffer_Tail *)((char *)cur_spot +
261 b->buflen);
288 b = (Buffer *)((char*)b + object_size);
307 (struct Buffer_Tail *)((char *)cur_spot + b->buflen);
headers.c: In function `add_extra_buffer_header':
headers.c:424: warning: cast increases required alignment of target type
424 ptr = (void**)((char*)headers->bufstart + headers->buflen - sizeof(void*));
dod.c: In function `free_unused_buffers':
dod.c:431: warning: cast increases required alignment of target type
431 b = (Buffer *)((char *)b + object_size);
> 2.) does it pass all tests
Yes. (well, no change - there's one failure I really must find tuits to
investigate, which I put down either to compiler or local hardware bug,
but your patch doesn't change that)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, Oct 09, 2002 at 04:42:36PM -0400, Andy Dougherty wrote:
> On Wed, 9 Oct 2002, Andy Dougherty wrote:
>
> > diff -r -u parrot-orig/t/src/sprintf.t parrot-andy/t/src/sprintf.t
>
> > + dval = 1.0e6;
> > + S = Parrot_sprintf_c(interpreter, "== %g\n", dval);
> > + printf("%g %s", dval, string_to_cstring(interpreter, S));
>
> Aargh. I forgot Microsoft's C library is going to render that as 1e+006,
> not 1e+06. Rats. What's needed instead is a strcmp() on the Parrot
> and stdio values. I'll work up something tomorrow.
They're not C99 conformant.
(I'm told that they were on the committee, so they missed fixing the standard
to make their code conformant. Now they have to do the opposite)
Then again, fflush(NULL) and a certain other OS is only about to become C89
conformant.
Ho hum. I suspect pigs will fly before any platform becomes totally C99
conformant, so we'll have to work round something from everyone.
Which reminds me, not sure if this is relevant yet, but there's some or other
platform that p5p encountered that can't simply copy whatever it is the opaque
type va_list expands to there.
There's a perl5 Configure symbol need_va_copy which indicates whether a
special macro needs to be used.
(and any platform that can't cope with free(NULL) deserves to crash and burn)
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17844] [PATCH] Avoid JIT on Sparc with 64-bit INTVAL and 32-bit pointers
On Thu, Oct 10, 2002 at 06:52:25PM +, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #17844]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17844 >
>
>
> The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the
> Sparc jit.
>
> diff -r -u parrot-orig/config/auto/jit.pl parrot-andy/config/auto/jit.pl
> --- parrot-orig/config/auto/jit.plThu Aug 8 23:18:04 2002
> +++ parrot-andy/config/auto/jit.plThu Oct 10 14:02:14 2002
> @@ -62,6 +62,10 @@
>
>if (-e "jit/$cpuarch/core.jit") {
> $jitcapable = 1;
> +if ($cpuarch =~ /sun4|sparc64/ &&
> + Configure::Data->get('intvalsize') > Configure::Data->get('ptrsize')) {
> + $jitcapable = 0;
> + }
>}
Whilst this patch is not wrong, it's curing the symptom rather than the case.
The x86 JIT doesn't work very well with 64 bit INTVAL either (fails stuff
then seems to lock up in a busy CPU loop in integer.t 35/37)
Really we ought to be naming our JITs based on (something like) perl5
archnames - ie CPU, INTVAL size, NUMVAL size, pointer size, and possibly
other fundamental things if they exist.
Nicholas Clark
Re: [PATCH] Removing two-arg ne
On Fri, Oct 11, 2002 at 01:30:33PM -0400, Dan Sugalski wrote: > At 7:10 PM +0200 10/10/02, Leopold Toetsch wrote: > > > >There are also 2 operand math operations of dubious achievement: > >Each of them will be doubled for each RHS INT argument giving ~25 opcodes. > > Those are all for the: > >a op= b > > form. There's a minor benefit to keeping them. I would like to kill all generated variants of all the 3 argument opcodes where both input arguments are constants. They truly are superfluous. > >I would kill these too. > >IMHO a smaller core will perform better, then the above saving of 1 > >operand in the byte code can achieve. > > Maybe, but I'm unconvinced. We are going to do a cull of the opcodes > before release, but I'm not inclined to do it now, and I'm not really > sure that there'll be any speed win at all from it. Size win, yes, > but still, not much. (And we do want the two-arg forms that use PMCs, It should make the computed goto core compile more rapidly. It might also make the computed goto core run more efficiently, as by being smaller it will bring more frequently used opcodes closer together. (Although we can probably have a larger effect by specificy a sort order either by iterative benchmarking the speed of parrot with different orders, or by code coverage profiling to find the most common opcodes.) Not much gain, but it might be worth it if we can automate the discovery process. Does anyone know a good way of doing permutations with a genetic algorithm? I think that a good way to represent a permutations such that similar permutations have similar genes would be more effective than an efficient way to convert a number to a permutation. And I don't know of either. (I don't know an efficient way to turn the number 105124 into the 105124th permutation of 60 things. divide by 60, take remainder; divide by 59, take remainder; etc doesn't feel efficient at all. Is the correct answer use more 'Knuth' ?) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [PATCH] Removing two-arg ne
On Fri, Oct 11, 2002 at 05:01:49PM -0400, Dan Sugalski wrote: > At 9:02 PM +0100 10/11/02, Nicholas Clark wrote: > >I would like to kill all generated variants of all the 3 argument opcodes > >where both input arguments are constants. They truly are superfluous. > > Where both operands are ints or nums, I think it's a good idea. I'm > less sure in the case where there's a PMC or string involved, as > there may be some assumption of runtime behaviour (in the case of > constant PMCs that might have some methods overloaded) or strings > where the compiler is expecting runtime conversion to happen before > whatever gets done. I think I agree with this reasoning. I was really thinking of the ints as being easiest to bump off, providing we can be sure that things will consistently for bytecode compile on a 32 bit parrot, but run by a 64 bit parrot (or likewise for different length floating point) IIRC C99 states that the pre-processor must do all calculations in its longest int type, and it's sort of related. I think we'd need to state that constant folding will be done at compile time, and will be done at the precision of the compiling parrot. > >It should make the computed goto core compile more rapidly. > > True, though I'm not hugely worried about this, as it happens only once. Per user who compiles parrot. The current computed goto code hurts my desktop at work (128M RAM, x86 linux) and with more ops it will get worse. It may turn out that gcc improves to the point that it can build measurably better code for specific CPUs, but distributions/*BSDs require a lowest common denominator build (typically 486 in the x86 family, isn't it?) In which case many people may gain quite a lot by building their own custom parrot, and they're going to notice the compile time. I admit this is low down any list of priorities, but it ought to be somewhere. I find with my work code (the C, not perl related) that gcc3.2 with all the stops out generates code that was about 5% faster than deadrat's (default 2.96 heresy non-)gcc. And at YAPC::EU someone reported that (IIRC) he'd seen 12% speedup from newer gcc and option tweaking. And getting even 5% without changing your perl6 code or parrot's code is nice. However, the more interesting thing about getting compile times down is you get more smoke in finite time. (And also developers get more done if they spend less time waiting for the compiler. BUT EVERYONE SHOULD ALREADY BE USING ccache AS THAT MAKES REBUILDS AND EDITING COMMENTS DAMN FAST (unless they can think of good reason not to)) > True. I think reordering is a bigger win, honestly. Lightly used > opcode functions won't get swapped in until they're really needed. More free speedup. I had this crazier idea - experiment with splitting every parrot function out into its own object file, and see what happens with permuting the order of all of them. But I think I need a lot of tuits, and a decent way of doing permutations with genetic algorithms. (I've got access to a fast machine, but it will have to stop smoking perl5 for the duration). Although potentially I'll end up with an order optimised for x86 FreeBSD, which should keep the Linux vs FreeBSD performance arms race going nicely. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: signal 11 when run on x86, JIT enabled
On Sun, Oct 13, 2002 at 03:06:48AM -0700, Steve Fink wrote: > On Fri, Oct 11, 2002 at 05:05:56PM -0700, Joe Wilson wrote: > > Perhaps this is a known issue... > > > > Most parrot programs seem to crash on x86 when the latest CVS parrot > > is compiled with "-O2" or "-g -O2" and when JIT is enabled. > > The programs appear to run to completion and only crash prior to exitting. > > Repeatable on both Cygwin and Linux x86. > > When JIT is not used, everything is fine. > > Ugh. That was a hairy one to track down. I have committed a fix. The > cause of the above problem was that the JIT was trampling over some > x86 registers that are supposed to be callee-saved in the cdecl > calling convention. By the time I finally figured that out, though, I > had fixed several other pretty major bugs in the jit. I'm seeing this on x86 FreeBSD with the JIT: t/op/interp.NOK 2# Failed test (t/op/interp.t at line 21) Use of uninitialized value in concatenation (.) or string at lib/Test/Builder.pm line 999. # 'ok 1 # ok 2 # ok 3 # ok 3 # ' # doesn't match '/^ok\s1\n # (?:PC=8.*)?\n # ok\s2\n # (?:PC=11.*)?\n # (?:PC=13.*)?\n # ok\s3\n$/x # ' # Looks like you failed 1 tests of 2. t/op/interp.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay is this to be expected? It's now the only regression test that fails under the JIT. Previously I think several were, but I can't remember for sure. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17936] [PATCH] MANIFEST
On Mon, Oct 14, 2002 at 11:06:05PM +, Jürgen Bömmels wrote: > # New Ticket Created by J?rgen B?mmels > # Please include the string: [perl #17936] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17936 > > > > There are again some files missing in MANIFEST. > > HINT: I have still [perl #16839] in my tree, so errors like this are really > easy to recognize. This has been applied, hasn't it? [Am I supposed to check somewhere other than the mailing list to learn this?] There still appear to be 996 files in the icu/ tree that aren't in MANIFEST. Should something be done about them? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17896] [PATCH] PerlHash tests
On Sun, Oct 13, 2002 at 04:29:09PM +, Simon Glover wrote: > # New Ticket Created by Simon Glover > # Please include the string: [perl #17896] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17896 > > > > > This patch: > > i) Adds several new tests for PerlHash, specifically: > - storing scalar PMCs, and retrieving their values into PMC > registers and into INT/NUM/STRING registers as appropriate > > (Some of this is already tested in the clone test, but really >deserves a stand-alone test) > > - retrieving undefined values > > - if (PerlHash), unless(PerlHash) > > ii) Removes one test -- the former test no. 1 -- which tests exactly the > same functionality as a (more complete) later test > > iii) Reorders the tests into a more rational order: we now test simple > things (like getting & setting STRINGs, INTs & NUMs) near the top, and > more complex things (clone, compound keys etc.) near the end. I find > this makes it easier to figure out what we're actually testing. Thanks applied. IIRC I had to tell patch to ignore whitespace. I'm not sure if it's your mailer, RT, or some combination that is causing this. Is your mailer using format flowed? [this seems to be becoming increasingly common due to OS X] Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17901] [PATCH] More PMC tests
On Sun, Oct 13, 2002 at 11:45:06PM +, Simon Glover wrote: > # New Ticket Created by Simon Glover > # Please include the string: [perl #17901] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17901 > > > > > Patch below adds tests for the eq, ne, lt, le, gt, ge & neg ops for > PerlInts and PerlNums. Thanks, applied. > -use Parrot::Test tests => 72; > +use Parrot::Test tests => 79; with "fuzz" (there were 4 more tests) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17903] [PATCH] sprintf test
On Mon, Oct 14, 2002 at 12:09:54AM +, Simon Glover wrote: > Here's a brief test for the PMC, PMC, PMC form of the sprintf op; > as an added bonus, it also tests two of the formats not previously > tested (%b and %o). Thanks, applied Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17935] [PATCH] Remove a warning
On Mon, Oct 14, 2002 at 10:47:48PM +, Jürgen Bömmels wrote: > /usr/local/bin/gcc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline >-Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W >-Wno-unused -Wsign-compare -Wformat-security -Wpacked -Wdisabled-optimization -Werror >-Wno-padded -Wno-format-nonliteral -Wno-cast-qual -I../include -o default.o -c >default.c > cc1: warnings being treated as errors > default.pmc: In function `caller': > default.pmc:21: warning: return discards qualifiers from pointer target type > make[1]: *** [default.o] Error 1 > > attached patch fixes this problem. Thanks, applied Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17907] [PATCH docs/parrot_assembly.pod] Minor typos and consistencies
On Mon, Oct 14, 2002 at 02:31:53AM +, chromatic wrote: > I've been browsing the docs, and took the time to do a bit of copyediting. > There's room for more consistency -- sometimes the registers are called 'X' > and 'Y' and other times 'x' and 'y'. Yes, I did notice this. Is there any sort of case convention we should be following, such as upper case for registers, and lower case for anything else? > Most of the patch is just prettification, from an English-language point of > view. Thanks, applied Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [CVS ci] list / array
On Wed, Oct 16, 2002 at 10:29:39PM +0200, Leopold Toetsch wrote: > Success ;-) reports, especially from non intel - welcome. Linux Bagpuss.unfortu.net 2.4.18-rmk7 #10 Sun Jun 23 21:43:05 BST 2002 armv4l unknown Strictly it's not Intel, because the StrongARM was made by DEC. Oh, hang on, you meant non-x86. Well, it's definitely not *that*. :-) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [perl #17899] [PATCH] .include macros (and misc. documentation)
On Sun, Oct 13, 2002 at 10:16:04PM +, Simon Glover wrote: > This patch: > > 1) Fixes some minor nits in the assembler documentation (mostly POD > formatting issues) > > 2) Documents the .include macro > > 3) Fixes a bug in the code that handles includes: we weren't stripping > off extraneous whitespace, so macros in included files weren't being > recognised as such. > > 4) Adds two tests for .include to macro.t Thanks, applied > NB Patches attached rather than appended, in an effort to avoid mailer > mangling Applied cleanly. Nicholas Clark
Re: [perl #18006] [PATCH] Improved stack direction test
On Fri, Oct 18, 2002 at 07:36:40PM +, Andy Dougherty wrote: > This patch ought to be harmless. I'd appreciate it if someone else could > give it a try, and, if it works, go ahead and commit it. Works fine on x86 (Debian GNU/Linux), arm (er Debian GNU/Linux) and sparc (guess?). I didn't try it on the PPC Linux (well, GNU-know-who/Linux) machine I have access to because several tests are already failing due to va_args. [I don't really have enough viable access to do much more than run tests there. It would be easier if I visited it in person] I haven't committed it. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl #] [PATCH] sprintf test
On Thu, Oct 17, 2002 at 12:07:57AM -0700, Steve Fink wrote: > On Wed, Oct 16, 2002 at 09:19:45PM +0100, Nicholas Clark wrote: > > On Mon, Oct 14, 2002 at 12:09:54AM +, Simon Glover wrote: > > > Here's a brief test for the PMC, PMC, PMC form of the sprintf op; > > > as an added bonus, it also tests two of the formats not previously > > > tested (%b and %o). > > > > Thanks, applied > > Can you (and everyone else) also update RT when applying patches? The > process, as I understand it, is: Thanks for this clear explanation of the process. I knew I was supposed to do "something" but it was never quite clear what. > 3. If the patch has a ticket number associated with it, find it in the > list at <http://www.parrotcode.org/openpatches>. Click on the > appropriate ticket link. I found the search by patch number can be useful when the patch number isn't obviously in the list of recent open patches > To explain the comment in #2 -- currently, RT helpfully re-opens a > ticket if there is further discussion after the ticket is closed > (resolved). So if you do the RT stuff first, and then send a "Thanks, > applied" message to the list, Mr. RT_System will reset the status to > "Open". Robert's going to disable this eventually, but he is currently > laboring under the misconception that his life involves a purpose > other than maintaining software for Parrot. I'm sure he'll return to > insanity soon, but even then he has some other stuff to get to first. Well, he has been very helpful in getting http://www.perl.org/advocacy/spoofathon/ up and fixing my content errors. Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [PATCH] lsr for ARM jit
On Sat, Sep 07, 2002 at 04:39:52PM +0100, Nicholas Clark wrote: > Here are logical shift right opcodes for the ARM jit. > (Cargo cult coding) Thanks, applied Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Another vtable update
On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: > I'm currently committing the new splice vtable method for array classes. > And finally, PMCs are currently only copied in, not cloned - I don't > know, what is correct. "clone" is a deep copy? whereas "copied" means that another reference to the same object is stored? If so, I'd say that if only one option is available, then it should be copied. Because "cloning" sounds potentially expensive, and this way splicing temporaries into an array wouldn't cause the creation of a clone, only to destroy the original. [And something that does need a clone spliced in can explicitly call a clone op, and then splice that in] I'm not sure if having clone and copy variants of splice would be worth it. [Mainly because I'm worried if we're going a bit far on the number of ops we've got] Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Another vtable update
On Mon, Oct 21, 2002 at 04:54:48PM -0400, Dan Sugalski wrote: > At 9:27 PM +0100 10/21/02, Nicholas Clark wrote: > >On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: > > > >> I'm currently committing the new splice vtable method for array classes. > >> And finally, PMCs are currently only copied in, not cloned - I don't > >> know, what is correct. > > > >"clone" is a deep copy? whereas "copied" means that another reference to > >the > >same object is stored? > > > >If so, I'd say that if only one option is available, then it should be > >copied. > > Copying is the right thing to do here. If the compiler wants to put > copies of things into an aggregate, it can make copies first. You keep using that word. I do not think that it means what you think it means. :-) [I take it that you mean: copying the PMC in is the right thing to do where. If the compiler wants to put a copy of the value into an aggregate, it can make a deep copy first ] Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
On Thu, Oct 24, 2002 at 06:16:55PM -0400, Jason Gloudon wrote: > On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote: > > It shouldn't at all. It does the check once, when parrot starts up. > > It will. If you read the following paragraph I explained why it will be slower, > and it has nothing to do with how often the check is performed. > > STACK_DIR is a compile time constant, so the multiplies in the following code > are eliminated by the compiler if it does any optimization. By making > STACK_DIR a variable, the compiler is no longer able to do this and has to > generate code to do multiplies. > > for (cur_var_ptr = lo_var_ptr; > (ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR) < > (ptrdiff_t)(hi_var_ptr * PARROT_STACK_DIR); > cur_var_ptr = (size_t)( (ptrdiff_t)cur_var_ptr + > PARROT_STACK_DIR * PARROT_PTR_ALIGNMENT ) What is wrong with any of 1: Duplicating the above loop (which isn't large), one for upwards stack, the other for downwards stack, and switching (outside) between the two based on an if statement on a global stack direction variable. (Globals bad, I know, but I assume that no-one has yet made an INTERCAL-eqse OS where the stack direction can change between threads of the same process) That gets the if test outside the loop, and keeps the loop construction optimisable at compile time 2: Pulling all of trace_system_stack out into its own source file, compiling it twice (once for up, once for down) with different names, and choosing the correct function pointer once based on a run time test 3: Keeping things as it is, and having miniparrot #define PARROT_STACK_DIR as a global variable containing the (run time determined) stack direction, whereas configured parrot #defines it as -1 or +1 Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl x18078] Patty's login stuff
On Fri, Oct 25, 2002 at 07:55:45AM -0400, Bryan C. Warnock wrote: > On Thu, 2002-10-24 at 19:15, Robert Spier wrote: > > -R (pondering his next move in the unending war against spam) > > Nukes. my thoughts entirely > -- > Bryan C. Warnock > bwarnock@(gtemail.net|raba.com) When the spammers figure out how to parse regexps to get the address out, are you going to start using pathological expressions with greedy matches inside nested captures that will tie them up until the heat death of the universe? :-) Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Execute in place?
On Fri, Oct 25, 2002 at 09:15:07PM +1000, Rhys Weatherley wrote: > A "trick" that I've found very useful in the past is to design > the bytecode format so that it can be mmap'ed into a block of > memory, and then executed almost immediately with the minimum > number of fixups. Rather than copying the instructions, you > execute them directly out of the mmap'ed region. [snip advantages of a read only mmap over other options] > Just an idea. Apologies if I'm rehashing something that has > already been discussed previously and discarded. IIRC speed is parrot's number 2 priority (after correctness), so anything that makes parrot faster is good. I remember that a while back Dan was suggesting some change or addition to the bytecode format that would have meant that the file could not have been mapped read only. Two people (I was one) commented that this was a bad thing, because being able to mmap read only was very useful, for the reasons you describe. I wasn't aware that the bytecode format had changed sufficiently to preclude mapping the whole file in read only (even if the current reader doesn't do this), but I admit that I've not been following changes closely. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [CVS ci] multiarray
On Sat, Oct 26, 2002 at 01:13:12PM +0200, Leopold Toetsch wrote: > I committed a new multiarray.pmc, now based on list.c. It's not totally > finished yet (the clone codes needs some polishing to call the init_pmc > method) and needs a lot more tests. > > But I hate failing tests ... Make the tests that you know are currently failing TODO tests? I believe that this is the purpose of the TODO feature. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Copyright notices and license stuff
On Sat, Oct 26, 2002 at 03:17:56PM -0400, Dan Sugalski wrote: > Please note that we're seriously considering moving to either a BSD ?? curious - this is the first I've been aware of this idea, so I wonder who the "we" is. Or what the cause for the formal change is? ["formal" because my reading of the artistic licence is that you can do pretty much anything with perl5 code providing you don't call it perl, and you credit the author. Hence saying the licence is BSD rather than "GPL + artistic" makes no pragmatic difference, as best I can tell. Except that other people (and other people's legal departments) may have a better idea of where they stand with a BSD licence] > One thing we will definitely be doing is officially restricting the > scope of the license leakage. Parrot's license will explicitly not > cover generated bytecode, nor will it cover the internal > representation of anyone's source, much in the way that gcc's license > doesn't apply to the object files it generates (and unlike the way > gcc's license does apply to its internal representations of things) What's the significance in the internal representation? (I can't see why it matters, but presumably it does matter to someone for some reason important to them, otherwise it would never have become significant enough to need this explicit clarification.) Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Draft sketch of bytecode generation
On Sun, Oct 27, 2002 at 11:54:08AM -0500, Dan Sugalski wrote: > The bytecode segments can hold more than just bytecode. They can also > hold the source that corresponds to the generated bytecode, the AST > for the source that corresponds to the generated bytecode, the line > number information for the generated bytecode (for error reporting), > and potentially some pieces of raw binary data, both for program > needs and potential future expansion. On a serious note, I think column number information for syntax errors (if available) would be useful for languages such as perl (and not just Befunge) For example, it would let a single stepping debugger show you progress through the statement. > =item Add binary data chunk to segment > > Add in some raw binary data to the bytecode segment For each call this puts the binary into its own chunk? If not, what's wrong with having binary data stored as a "string" in the string constant pool? Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Of mops and microops
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote: > Dan Sugalski wrote: > > I'm currently leaning against it only because it doesn't ultimately help > > the JIT. What we have now is wildly cool and damn useful (and has anyone > > heard from Daniel lately, BTW?) but there's room for more optimizations. > > > Yes, that's correct. JIT wouldn't profit currently. But with an > optimized stream of (micro-)Ops, having optimzed fetch/store opcodes not > in (basic-) block but finer granularity, JIT could profit too. Also the > JIT-optimizer now run at load time would be done at compile time, so JIT > startup time would be cut down. But then you end up with a messier two level register spillage problem at compile time, don't you? Which values to spill from fast to slow registers, and which values to spill further from slow to stack? And is there much literature on this sort of thing? > My hack with the 3 globals includes obviously some cheating, globals are > a nono, when having multiple interpreters. But nethertheless we could > produce an optimized PBC stream, where the 3*4 registers are treated as > "fast" registers, with load/store to the 32*4 slower registers only when > necessary. This would also fit neatly with my proposal WRT keyed access. And the fast registers are going to be called ax, bx, cx and dx? :-) > I was also thinking of the various fixed sized integer ops for JVM or > C#. The load/store ops would prepare integers of needed size and do sign > extension when necessary. I've had 3 drafts at responding to this, and I conclude "my brain hurts" I don't see an "obvious" clean solution to this, specifically 64 bit ops that run correctly on 32 bit native systems, but take advantage of 64 bit native systems. Nicholas Clark
Re: [CVS ci] string_str_index
On Wed, Oct 30, 2002 at 11:13:09AM +0100, Leopold Toetsch wrote: > I moved the two - almost identical - op bodys out of core.ops > and called this functions string_str_index... > > and did introduce a new warning WRT const. > > - const is currently used in some string.c functions rather inconsistently > - should we remove it alltogether > - introduce a dummy CONST define as hint for the programmer > - insert more const decls (e.g. string_trans_code doesn't modify its > src, so ... I'd prefer more real and explicit use of const, and correcting all const-ness mistakes, rather than leaving it as a hint to the programmer. It's possible that compilers will be able to optimise better if they know something is const. Also, no-one commented on my suggestion a long time back to remove -fno-strict-aliasing from gcc's flags. In theory we're stopping some possible gcc optimisations with this. Nicholas Clark
Re: cvs commit: parrot/include/parrot datatypes.h
On Sat, Nov 02, 2002 at 05:46:07AM -, [EMAIL PROTECTED] wrote: > cvsuser 02/11/01 21:46:07 > > Modified:include/parrot datatypes.h > Log: > Fixed errors flagged by "make check_source" Is it sensible to arrange for CVS to refuse to commit C files unless they pass the source check? [I believe that this is technically easy to implement with little effort, but probably undesirable] Can we tinder box files (or auto e-mail blame for every commit that fails?) [I don't know if this can be done without effort] Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
[COMMIT] t/src/manifest.t
I added a local to $_ in t/src/manifest.t to avoid an undef warning in 5.005_03's File::Find Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Need for fingerprinting? [was: Re: What to do if Digest::MD5 is unavailable?]
On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote: > While I don't think I'm sophisticated enough to pull it off on my own, I > do think it should be possible to use what was learned to build the JIT > system to build the equivalent of a CG core on the fly, given its > structure. I think the information and basic capabilities are already > there: The JIT system knows already how to compile a sequence of ops to > machine code -- using this plus enough know-how to plop in the right JMP > instructions pretty much gets you there. A possible limitation to the I'm not convinced. Compiling the computed goto core with any sort of optimisation turns on *really* hurts the machine. I think it's over a minute even a 733 MHz PIII, and it happily pages everything else out while it's doing it. :-( I doubt that the GC core's stats look anywhere near as impressive for the unoptimised case. [And I'm not at a machine were I can easily generate some] This makes me think that it would be hard to "just in time" > coolness, here: I think the JIT system bails out for the non-inline ops > and just calls the opfunc (please forgive if my understanding of what JIT > does and doesn't do is out of date). I think the CG core doesn't have to > take the hit of that extra indirection for non-inline ops. If so, then the > hypothetical dynamic core construction approach just described would > approach the speed of the CG core, but would fall somewhat short on > workloads that involve lots of non-inline ops (FWIW, there are more inline > ops than not in the current *.ops files). I believe that your understanding of the JIT and the GC cores are still correct. The problem would be solved if we had some nice way of getting the C compiler to generate us nice stub versions of all the non-inline ops functions, which we could then place inline. However, I suspect that part of the speed of the CG core comes from the compiler (this is always gcc?) being able to do away with the function call and function return overheads between the ops it has inlined in the GC core. I've no idea if gcc is allowed to re-order the op blocks in the CG core. If not, then we might be able to pick apart the blocks it compiles (for units for the JIT to use) by putting in custom asm statements between each, which our assembler (or machine code) parser spots and uses as delimiters (hmm. particularly if we have header and trailer asm statements that are actually just assembly language comments with marker text that gcc passes through undigested. This would let us annotate the assembler output of gcc) Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl #18219] on_exit not portable
On Mon, Nov 04, 2002 at 07:45:46PM -0500, Josh Wilmes wrote: > At 18:57 on 11/04/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > atexit is not an alternative, because we might have multiple > > interpreters to clean up like in t/op/interp_2. > > So the issue here is that on_exit can take a parameter to be passed into > the handler function, right? > > We could implement our own version of on_exit that registered the handlers/ > arguments in a linked list or something, and have a single atexit() handler > call them on our behalf. > > However, that still assumes we have atexit() everywhere. This appears to > not be true on SunOS at least- apparently it has on_exit, though. IIRC ANSI C89 says that the library provides atexit() If SunOS doesn't want to be C89 compliant, then I have no qualms about telling the first SunOS porter that we'd be pleased to accept patches from *them* to work around it. (And the return value from sprintf in SunOS, if we need that.) > But, it seems like we can make this work everywhere if we move to using a > platform.c Parrot_on_exit() and Parrot_exit() rather than any kind of > native on_exit/atexit/exit functions. That seems to be a better plan. > Then we can make them all DTRT everywhere, I think... either with our > without atexit(). > > If this (Parrot_exit/Parrot_on_exit) is a reasonable way to do things, I > can probably come up with a patch later this week, if nobody else jumps on > it ;-) I'm not jumping. Sorry. Nicholas Clark PS Yes, I may sound beligerant and unhelpful. But implementors have had >12 years to get C89 correct. C99 is more complex - I wonder how long long that will take... -- Slide rules better than perl? http://www.perl.org/advocacy/spoofathon/
NULL (was Re: cvs commit: parrot interpreter.c stacks.c)
On Sat, Nov 09, 2002 at 11:09:39AM -, [EMAIL PROTECTED] wrote: > -/* Initialize the integer register chunk */ > -interpreter->ctx.int_reg_base->used = 0; > +/* Initialize the register chunks */ >interpreter->ctx.int_reg_base->free = FRAMES_PER_INT_REG_CHUNK; > -interpreter->ctx.int_reg_base->next = NULL; > -interpreter->ctx.int_reg_base->prev = NULL; By doing this you are assuming that the in memory representation of a NULL pointer is all bits NULL. This isn't guaranteed. (What *is* guaranteed by the standard is that a NULL pointer casts to 0, and that all other pointers cast to non-zero) It's not likely to be a portability problem, as I seem to remember that the C FAQ is only able to mention one very obscure platform where NULL was not all bits zero in memory. (Sorry, not online at the moment, so no URL) However, I have a niggling thought that someone telling me that some compiler product in memory leak debug mode (possibly a Microsoft compiler) was able to have NULL pointers *not* stored as all bits zero in memory, and so could fault confusion between 0 and NULL I believe that a bigger assumption (not sure if we're making it; didn't spot it) is that float 0.0 and double 0.0 are written as all bits zero in memory. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [CVS ci] (was: NULL (was Re: cvs commit: parrot interpreter.c stacks.c))
On Sun, Nov 10, 2002 at 12:15:06PM +0100, Leopold Toetsch wrote: > Leopold Toetsch wrote: > > >Nicholas Clark wrote: > > > >>It's not likely to be a portability problem, > > > >To NULL or not to NULL, this is the question. > > I introduced a macro, depending on a symbol HAS_NON_ZERO_NULL, which > should be set for these architecures. > > Currently interpreter.c only, other files will follow, if people are ok > with this. I think that this is a good idea, and was going to suggest it myself. [bah. you beat me too it :-)] Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Selfbootstrapping compilers (Was: faq)
On Wed, Nov 13, 2002 at 08:25:52AM -0800, Brent Dax wrote: > Gopal V: > # If memory serves me right, Markus Laire wrote: > # > Miniparrot can then be used to build everything else, including full > # > parrot, perl6, other parrot-supported languaged, etc.. > # > > # > This 2nd step might be e.g. Bytecode-compiled perl6-program which is > # > simple enough to work with miniparrot. > # > # Please for heaven's sake don't write a perl6 compiler in > # perl6 ... It's > # *very* frustrating if I have to download version 1 to compile > # 1.1 and so on... (imagine compiling CVS head with a chain of > > We have to--otherwise we can't have the self-modifying parser Larry > desperately wants. But don't worry--we'll ship it already bytecompiled. This is actually very similar to perl5, which strictly you can't actually build from scratch without an existing copy of perl5. However, all the header files generated by perl scripts (the target make regen_headers) are shipped with the source kit. Once you've built a perl5 from the distribution source you can actually run (by hand) them without installing that perl, if you really want to. I believe that this is directly comparable with shipping the perl6 parser precompiled. It also means that we must be careful to prevent the compiled perl6 parser becoming trojaned (as cc and login reportedly were on early unix systems). Yes, I've only thought of this because of the recent tcpdump trojan. But I think it's something we need to bear in mind. Nicholas Clark
Re: Selfbootstrapping compilers (Was: faq)
On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote: > The goal is for Parrot to require a C compiler and a platform shell > or Make tool (either one) and that's it. We will ship with bytecode > files that have the bits needed for the build precompiled, so if the > perl compiler's partially written in perl, we'll ship a perl6.pbc in > the distribution. I believe that it can be done with just a C compiler. (no make tool or shell needed). If we use an equipped machine to unroll the makefile into the correct steps (in the correct order), and turn that into C code that runs each in turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool) Please archive this message and hold it against me when the time comes, and you're looking for someone to prove it by making it work. Nicholas Clark -- vapourware better than perl?http://www.perl.org/advocacy/spoofathon/
Re: Selfbootstrapping compilers (Was: faq)
On Thu, Nov 14, 2002 at 03:09:54PM +0530, Gopal V wrote: > Also perl6c.pbc shouldn't really worry about trojaned stuff in it as you're > not using an external bootstrapper (unlike gcc using cc) I don't think you're totally correct. You are still relying on an external bootstrapper, although it's from a source you (think you) trust - the parrot distribution. If someone cracks the parrot distribution's server, and installs a trojaned perl6c.pbc that contains extra routines to recognise when it is compiling perl6c.pl, then the running perl6 compiler could interest its extra routines into the bytecode of the perl6 compiler. And again next generation. And again next ... In the same way that the self-replication code for cc worked. Nicholas Clark
Re: Quick note on JIT bits
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote: > On Thursday 14 November 2002 10:32, Leopold Toetsch wrote: > > Daniel Grunblatt wrote: > > > On Thursday 14 November 2002 05:14, Leopold Toetsch wrote: > > >>What JIT needs to know is the location of the resume opcode, to mark it > > >>as a jump target properly, so that processor registers can be setup > > >>correctly. > > > > > > Well, any opcode could be a target, so I suggest to build something like > > > a section entrance code that given the PC could load the apropiate > > > registers and jump to the middle of a jitted section. Yes, it will be > > > slow but we are talking about exceptions here. Can any opcode be a resume target without knowing that it is a resume target? If yes, we have a nasty time being a JIT. If we know all resume targets in advance (care of the compiler or assembler labels, even if all resume targets includes "all opcodes that follow any opcode that could throw an exception") then I think life is a lot easier. [which is probably what the bits I've snipped were saying] In my mind there seem to be two classes of things: ops that could throw exceptions ops that could be the resume target of exceptions I'm assuming that we can only resume on op boundaries. (so a division by zero exception has to resume after the op. er. what happens on some sort of PMC fetch exception. Can it resume internally? ) > > There must be some code, that installs the exception handler. This code > > has the address of the exception handler, which JIT has to know too. > > Being prepared to enter at arbitrary places in JIT would inhibit > > processor register usage totally, or wouldn't be any win. > > > > Either I didn't make my self clear (sorry) or my understanding of exceptions > is wrong ... probably both. > > When, say, div throws an exception it will longjmp to the handler, that > handler will know where to continue the execution of the program, right? so > after doing its job it will have to call a function that given a PC will load > the cpu registers as needed and jump into the jitted code again but if there > was no exception the jitted code executes as usual. This sounds horribly like the C rule of don't rely on automatic variables after the return from longjump. No. I don't have an answer. Nicholas Clark
Re: Quick note on JIT bits
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote: > The question is "without knowing". I think the resume address is known > (somewhere at least) because the exception handler has to be set up. If I understand it correctly, the way recent Linux handles page faulting in the kernel may be of use. It takes advantage of the ELF format to generate an list of fixup routines, one per place that could fault, ordered by the fault address. If the instruction at that address faults, the code called by the MMU searches the list, to find the correct fixup code. The fixup code is run, and execution resumes. This makes fixup slower than inline explicit check code, but fixup happens so rarely that the removal of lots of instances of explicit check code is a net win. I wonder if we could use the same idea in the JIT, with out of band exception fixup code (or tables, or whatever) that the JIT exception handler uses to restart. I'm making the assumption that exceptions can happen in many places, but rarely do, so we can ill afford to make the direct code slower to cope with them, and that it doesn't matter if it takes a lot of effort to handle them when they happen. Nicholas Clark -- perl1 better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [RFC] unified core.jit
On Tue, Nov 19, 2002 at 03:40:33PM -0300, Daniel Grunblatt wrote: > On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote: > > We could do it like parrot (dest, src, src) too, but I want really a > > unique naming convention. > > > > leo > > Cool, let's do it like parrot. Good call. I think it's the least confusing way round. At worst parrot assembler and the JIT share the same ordering, and the platform's native assembler is the other way. At best all three are the same way round. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl 6 Test Organization
On Thu, Nov 14, 2002 at 08:53:02PM -0800, chromatic wrote: > Brent Dax had a nice suggestion for Perl 6 test organization. I like it > tremendously. > > I repost it here to solicit comments -- to make this work, I'll need to change Did anyone comment on it? It seems a sane to me, and I certainly can't suggest a better way to do it. [I'll quote the rest of the message so that everyone can read it again if they want to] > the Perl 6 test harness to find all of the tests. I'll also need to create > several different subdirectories as appropriate. Rearranging things after the > fact is a bit of a chore with CVS (if you want to keep revision history), so I > welcome feedback. > > Brent's post follows. > > On Tue, 12 Nov 2002 10:01:44 +, Brent Dax wrote: > > > I don't see why we can't do this. > > > > t/ > > var/ > > scalar/ > > string/ > > to_bool.t > > from_bool.t > > ... > > regress.t > > num/ > > bool/ > > ref/ > > typed/ > > prop/ > > taint/ > > array/ > > normal/ > > sized/ > > typed/ > > hash/ > > normal/ > > restricted/ > > typed/ > > code/ > > normal/ > > proto/ > > vari/ > > curry/ > > anonymous/ > > placehold/ > > oper/ > > normal/ > > arithmetic.t > > string.t > > list.t > > logic.t > > junction.t > > misc.t > > vector/ > > arithmetic.t > > string.t > > list.t > > junction.t > > misc.t > > regex/ > > alone/ > > grammar/ > > TestGrm/ > > module/ > > TestMod/ > > meta.t > > export.t > > globals.t > > class/ > > TestCls/ > > ... > > > > -- c Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: C#/Parrot Status
On Sun, Nov 24, 2002 at 10:33:23PM +0100, Florian Weimer wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > .NET has exception-throwing versions of its math operations. If you do > > an add of two 8-bit integers and the result overflows, you should get > > an exception (if you've used the "check overflow" versions of the ops) > > Actually, I thought about implementing Ada. The standard requires the > following: > > 20. For a signed integer type, the exception Constraint_Error is > raised by the execution of an operation that cannot deliver the > correct result because it is outside the base range of the type. > > And this is painfully to implement if the machine doesn't support it > (e.g. by overflow flags or trapping arithmetic). For integer maths if the machine uses 2s complement arithmetic I believe it's not that painful. (And even if it doesn't it's not hugely painful) [ie I think I know how to do it] Floating point fills me with fear. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: long double error
On Sun, Nov 24, 2002 at 07:02:11PM -0500, David Robins wrote:
> Actually it looks like the problem is in assemble.pl's sub constant_table;
> even though $PConfig{numvalsize} is 12, $PConfig{packtype_n} is 'd' and
> pack('d',$n) uses 8 bytes. This is after hacking NUMVAL_SIZE to 12,
> though, which explains why it wasn't caught in config/auto/pack.pl.
> perldoc for pack shows no way to pack a native NV. Should assemble.pl be
> using packout.c via XS/Inline? If this is decided to be the way to go then
> I'd be glad to work on a patch to do it.
'D' will pack long doubles on perl 5.8.0 (and later) if the perl is built
with NVs as long doubles. (ie -Duselongdouble at Configure time)
The long vaunted plan to actually make everything that outputs bytecode use
one C library (with a perl interface) might be a better way to properly
solve this.
Nicholas Clark
Re: C#/Parrot Status
On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote: > Gopal V wrote: > > > /* > > ** dotgnu.ops > > */ > > Thanks applied, I'm surprised that you did your regression tests longhand, rather than having a data table in perl of input and expected output, and auto-generating parrot code. Is there any speed advantage in truncating by casting via a C type [eg a = (int)(short) b] rather than and on a bitmask [eg a = b & 0x] ? We're going to have to do that latter to make it work on Crays anyway, so is a conditional compile to chose between the two worth it? Nicholas Clark
Re: C#/Parrot Status
On Mon, Nov 25, 2002 at 11:29:01AM -0500, Dan Sugalski wrote: > At 4:04 PM + 11/25/02, Nicholas Clark wrote: > >Is there any speed advantage in truncating by casting via a C type > >[eg a = (int)(short) b] > >rather than and on a bitmask > >[eg a = b & 0x] > >? > > > >We're going to have to do that latter to make it work on Crays anyway, so is > >a conditional compile to chose between the two worth it? > > The bitmask doesn't sign-extend where the casting will, which could > be an issue. That still lets us halve our conditional code. :-) (do all the unsigned with masks) And we ought to make a generic "safe" version of the code for signed truncation that works for platforms that are any or all of the following holds 1: no type of that size (eg Crays) 2: signed integer truncation (UTS) [and other OSes on S/390 processors?] 3: not 2s complement [no examples] Nicholas Clark
Re: C#/Parrot Status
On Mon, Nov 25, 2002 at 04:39:23PM +, Nicholas Clark wrote: > And we ought to make a generic "safe" version of the code for signed > truncation that works for platforms that are any or all of the following > holds > > 1: no type of that size (eg Crays) > 2: signed integer truncation (UTS) [and other OSes on S/390 processors?] > 3: not 2s complement [no examples] oops. forgot one: 4: nasal demons (Irix64) (doing stuff on out of range signed values is undefined behaviour, IIRC) Nicholas Clark
Re: C#/Parrot Status
On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> > I'm surprised that you did your regression tests longhand, rather than having
> > a data table in perl of input and expected output, and auto-generating parrot
> > code.
>
>
> Writing a few explicit tests is faster ;-)
Good answer.
When I have tuits (little white things made of ice, commonly found in hell)
I'll re-write your tests as autogenerated from a table of pathological cases.
> > Is there any speed advantage in truncating by casting via a C type
> > [eg a = (int)(short) b]
> > rather than and on a bitmask
> > [eg a = b & 0x]
> > ?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
> This is listed to take 3 cycles which "and mem" needs too. Inkluding
> sign extension would be slower then.
and gcc's optimiser is not clever enough to spot bit & cases that are not
equivalent to this? :-(
> > We're going to have to do that latter to make it work on Crays anyway, so is
> > a conditional compile to chose between the two worth it?
>
>
> My Cray is currently out of order ;-) What is special with it?
sizeof(short) == 8
[sizeof (int) == 8 for that matter, and the elements of a sockaddr_in
structure are bitfields, so you can't take the address of them.]
Nicholas Clark
Re: cvs commit: parrot/docs jit.pod
On Tue, Nov 26, 2002 at 09:55:00AM -, Leopold Toetsch wrote: > +B > + > +The Ith integer or floating processor register, mapped in this section. > + > +Note: The register with the physical number zero can not be mapped. > + > +=begin unimp > + Why can't it be mapped? Fundamental implementation constraints (using zero to flag something else?) This will impact performance, although whether it's not actually measurable, slight, or moderate, I don't know. ["patches welcome"?] Nicholas Clark
Re: cvs commit: parrot/docs jit.pod
On Tue, Nov 26, 2002 at 01:51:47PM +0100, Leopold Toetsch wrote: > Either we fix this, or the registers have to be renumbered, so that reg > #0 is not used. The emit_code for registers could take care of this. That's a crafty trick. nothing wrong with that :-) > Currently no architecture has this problem, register #0 is used as > scratch register. > > i386 uses register numbers 1 higher then actual, though EAX nether gets > mapped. > > > > ["patches welcome"?] > > > Always, but as currently no architecture is concerned ... Valid point. But I was envisaging for ARM that r12 or r14 ought to be the scratch register. The way the ABI works, with r12 trashed on function call entry, but r0 used to return values from functions means that r12 is available within an op, while mapping r0 to a parrot register for the first JITted op after an external call could save 1 register move. Nicholas Clark
Re: Directory renaming
On Thu, Nov 28, 2002 at 06:22:56PM +0100, Jerome Quelin wrote: > Hi, > > Would it be possible to rename the $PARROT/languages/Befunge-93 > directory into $PARROT/languages/befunge ? > Indeed, as soon as parrot will support objects, I'll implement the > befunge 98 specs, and the same interpreter will be able to interpret 93 > ou 98 befunge code... > I'm sorry, 'cause I know cvs does not handle very well directory > renaming. This seems to be a good idea. I'd commit it, except that it needs more than commit access to move a directory with CVS. Who has enough shell access to cvs.perl.org to do this? [assuming it does want to be done?] Nicholas Clark
Re: Directory renaming
On Fri, Nov 29, 2002 at 10:14:39AM -0800, Robert Spier wrote:
> Nicholas Clark writes:
> >This seems to be a good idea. I'd commit it, except that it needs more
> >than commit access to move a directory with CVS. Who has enough shell
> >access to cvs.perl.org to do this? [assuming it does want to be done?]
>
> That would be my job.
>
> It's done.
Thank you.
Would it also be your job to do porting of subversion to VMS, so that we
could consider replacing CVS with something that lets clients do directory
moves? :-)
Nicholas Clark
PS No I'm not serious about it being your job. But following a chat on IRC
it seems that the most obvious thing which immediately rules out subversion
for parrot purposes is that (currently) it would not seem to work on VMS.
More subtle reasons not to use it may become apparent if/when that one is
solved. Special VMS tuits ("TUITS" ?) appear to be even less common than
common-or-garden tuits.
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl #18773] [PATCH] introducing debug features in befunge
On Sat, Nov 30, 2002 at 10:56:50AM +, Jerome Quelin wrote: > The following patch introduces a new file in the befunge interpreter > that will hold all the debug-related material. Thanks applied. > Soon, we'll have a fully-functionnal debugger within the befunge > interpreter with breakpoints, dumping the playfield, status line, and > even more... How exciting! Er, how scary. Nicholas Clark
Re: [PASM] about pushi and popi
On Sat, Nov 30, 2002 at 11:15:28AM +0100, Jerome Quelin wrote: > When I want to save all the integer registers, I'm using pushi, > restoring them later with popi. > When I'm doing a pushi, the old values of the registers are still > present, but I'm wondering wether I can rely on this behavior, or if > it's accidental and may be removed with another implementation? I don't think that any real, er I mean "hardware", CPU scrubs registers when you push them - it's effectively a copy of the register onto the stack. I was thinking that maybe the JIT can benefit from it actually not being guaranteed, as it would let a CPU register mapping system drop the association of CPU register and parrot register at that point. But then I thought that it doesn't matter anyway - for most cases the JIT should have enough trace flow to know whether the register contents are not going to get used again (in which case it can break the mapping). [With the corollary that if the values in them are re-used, then clearly the mapping must continue] So I think it would be sensible to defined that you can rely on this, as it is the least surprising behaviour. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: C#/Parrot Status
On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> >Is there any speed advantage in truncating by casting via a C type
> >[eg a = (int)(short) b]
> >rather than and on a bitmask
> >[eg a = b & 0x]
> >?
>
>
> gcc uses MOVSX (movs{b,w}l), move byte/word with sign extend to 32 bit.
> This is listed to take 3 cycles which "and mem" needs too. Inkluding
> sign extension would be slower then.
What I didn't notice was that the 8 bit signed ops cast via char.
This isn't portable, as char is unsigned on PPC and ARM (and possibly other
platforms.) I've committed this:
--- dotgnu.ops~ Tue Nov 26 18:56:43 2002
+++ dotgnu.ops Sat Nov 30 16:09:08 2002
@@ -18,13 +18,13 @@ Additional opcodes for C# compilation ne
=cut
inline op conv_i1(inout INT) {
- $1 = (INTVAL)((char)($1));
+ $1 = (INTVAL)((signed char)($1));
goto NEXT();
}
inline op conv_i1_ovf(inout INT) {
if($1 >= -128 && $1 <= 127) {
-$1 = (INTVAL)((char)($1));
+$1 = (INTVAL)((signed char)($1));
}
else {
internal_exception(1, "Overflow exception for conv_i1_ovf\n");
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl #18793] [PATCH] befunge now supports step by step execution
On Sun, Dec 01, 2002 at 09:10:29AM +, Jerome Quelin wrote: > >From the Changes file: > - debugger can now interact with user. > - debugger can dump playfield. > - debugger can print information about current IP. > - debugger can execute a befunge program step by step. Thanks applied. Nicholas Clark
Re: [perl #18566] [PATCH] Brainfuck support
On Thu, Nov 21, 2002 at 12:54:17PM +, Leon Brocard wrote: > # New Ticket Created by Leon Brocard > # Please include the string: [perl #18566] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=18566 > > > > I've posted a Brainfuck interpreter on list in the past, but it kept > on getting made out of date. I think it thus makes sense to host it in > the Parrot distribution, in languages/brainfuck/, so please check out > the attached files. Thanks applied I added an ID tag to brainfuck.pasm, and replaced the Makefile with a configure generated Makefile (so that $(PERL) is set correctly) Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: parrot organization
On Tue, Dec 03, 2002 at 05:09:43PM -0500, Dan Sugalski wrote: > At 5:03 PM -0500 12/3/02, Michael Collins wrote: > >The principal coders, do they work on this project full-time? > > Not for pay, no. I'm not sure anyone works on it full-time, though I > may come closest. The perl foundation was able to provide some grants towards work on this project and perl6. However, fund raising wasn't sufficient to keep grants going full time. > >And is there any source of funding for this project? > > Nope. Well, the perl foundation gave grants based on the cash pledges it received (via http://www.perlfoundation.org/index.cgi?page=contrib ) > >The website states that Dan Sugalski is the principal designer but there seem > >to be many coders who contribute significantly. > > > >How did the principal coders receive their designation? However, if people not yet involved feel they want to offer to contribute something to the project, time (working on things that need doing) is more valuable than money, in my opinion. (Both are nice, but if it's one or the other, directed time will get things further). My opinion is my opinion - I'm not anything official on the parrot project, nor am I anything in the perl foundation. Nicholas Clark
Re: logical_not issue
On Fri, Dec 06, 2002 at 05:01:21PM -0500, Dan Sugalski wrote:
> It is OK for an undef value to be true, though. That's not only
> allowable, it has to be allowed. For perl, at least, it's how Larry
> plans on getting around the "function returns undef, but it's a real
> undef value, not a false 'I didn't work' value" issues we have in
> perl 5 now.
Are you sure you want to spell that concept "true"?
Because then if &foo can legitimately return numbers, strings and undefs
does it return
"pie" "pie"
2 2
undef: undef but true,
0 0
"" ""
so now
if (&foo(...)) {
warn "Bang!"
}
warns on traditional true values, and undef?
So the caller then needs to launder the true property from undef before putting
it somewhere else? That feels like a pain.
Or does it return
"pie" "pie"
2 2
undef: undef but true,
0 0 but true
"" "" but true
which makes
if (&foo)) {
warn "Bang!";
}
consistently noisy?
It seems to me that the distinction between intentional undef and failure
undef needs to be made with some property other than "true". It feels like
the distinction between doesn't exist and exists but undef in a hash, the value
returned off the end of an array, or (maybe) the different between the empty
list () and the list (undef)
undef but valid. Or maybe undef but invalid for the failure case?
[so that by default things have no properties]
It's like the argument about the meaning(s) of NULL in SQL, isn't it?
"I just don't know", "known - this isn't applicable" and "this isn't valid"
This is more a perl6 language message, isn't it? If it can't quickly be
quashed, should it migrate there?
Nicholas Clark
--
Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: A work list! (Coming soon)
On Mon, Dec 09, 2002 at 01:40:37PM -0500, Dan Sugalski wrote:
> What I'd like is for folks to take the next day or three to think of
> the things that they need parrot to do that aren't working or
> designed yet, and throw them at the list. (Try against the latest
> CVS, just to make sure that it's not gotten done when you weren't
> looking) In the mean time I'll work on my list, and we'll get a Big
> List 'O Things, throw them into RT, and start digging through them.
This is possibly a big stuff wish list. I'm not sure how many are on the "maybe
never" list.
Apart from the obvious ("moon on a stick", "a pony", "Quantum Larry (writing
the apocolypses in parallel universes in constant time)") I'd like
Exceptions that can be thrown from C
Regression tests for all the ops (even if not all the cases within them)
Regression tests that cause 100% code coverage (that's probably impossible to
ever get to, but it's a number to aim at)
A unified parrot bytecode generation library (probably in C, but with a perl
interface)
The assembler, IMCC and anything else all using the unified bytecode generation
library
No C compiler warnings on a single platform
No C compiler warnings on any platform
ppc linux to pass (copying varargs issue; probably not hard)
JIT to be aware of different sized integers, floats
computed goto core to compile with less resources
all the little languages that have test suites to be built and run as part of
the tinderbox (with a target in the standard makefile to do this)
JIT to be run as part of the tinderbox (I don't think it is currently)
Fleshing out what parrot IO should do. Particularly how it relates to async IO,
event loops, and the perl5.8 IO layer system
A Java bytecode to parrot bytecode translator
Loading dynamic opcode libraries
Foreign opcode translation (at load time or runtime)
A z-code interpreter (based on the two previous items)
Implementation of an existing general purpose scripting language on parrot
(such as Python or Ruby)
I may have forgotten some things :-)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Curses Life
On Tue, Dec 10, 2002 at 06:04:44PM +, Piers Cawley wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > At 4:45 PM + 12/5/02, Leon Brocard wrote: > >>Leon Brocard sent the following bits through the ether: > >>Ah, well, I gave up on SDL as it was a little complicated. Instead, I > >>played with curses. Please find attached a cute little curses life > >>program loading and calling curses at runtime with dlfunc. > >> > >>Oh, and I made the shape a small spaceship as it's more interesting. > > > > Leon, you're really scary, y'know that? :) > > I've suggested he work on getting Readline working next. Then, once > he's done the zmachine loader and got a zmachine opcode set up and > running... and then all get digressed into playing http://astray.com/Bookshop.z5 (see http://london.pm.org/pipermail/london.pm/Week-of-Mon-20010924/005441.html ) Nicholas Clark
Re: [perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
On Fri, Dec 13, 2002 at 09:16:34AM -0500, Simon Glover wrote:
> On Thu, 12 Dec 2002, Sean O'Rourke wrote:
> > The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
> > to pointers in a platform-independent way. Works for me on Linux-ppc.
> > Could someone with another CPU give it a spin and/or make sure I hid the
> > macro in the right part of {config/,lib/Parrot/Configure,...}?
>
> Works fine for me on Linux/x86.
Works fine for me on Linux/sparc and sparc Solaris
This is failing for me on both sparc machines:
t/pmc/perlhash..NOK 17# got: ''
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
The Solaris box has:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs
gcc version 2.95.3 20010315 (release)
The Debian box has:
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
On Sat, Dec 14, 2002 at 05:14:15PM -0500, Dan Sugalski wrote: > It crashes rather badly in a number of spots on OS X, unfortunately. > I've also noticed that we have no Win32 systems in the tinderbox. Are > we building OK on Win32 anywhere? s/Win32//g :-( *percy* parrot 5 red, 14 orange, 0 green: TD-Corvette (Test Failed), +TD-Thunderbird (Burning), *percy* TD-Camaro (Test Failed), drinky-drinky (Burning), TD-Viper (Test +Failed), *percy* TD-ParkAvenue (Test Failed), frivolous (Test Failed), TD-Miata (Test +Failed), *percy* TD-Camry (Test Failed), TD-Millenia (Burning), TD-Firebird (Test +Failed), *percy* TD-Continental (Burning), TD-Ferrari (Test Failed), TD-Celica (Test +Failed), *percy* glastig (Test Failed), TD-Seville (Test Failed), galactic-tcc +(Burning), frivolous (Test Failed), *percy* galactic-lcc (Test Failed) Nicholas Clark
Re: [COMMIT] interpreter.c bugfix
On Sat, Dec 14, 2002 at 06:51:19PM -0500, Simon Glover wrote:
>
> I've just commited the appended fix, which should hopefully reduce the
> number of failures in the Tinderbox.
Brilliant! A FreeBSD box I've got access to is now much happier.
Previously many many things were failing.
[Not perfect, as a cvs up and then make all test did give this:
t/pmc/nci...# Failed test (t/pmc/nci.t at line 307)
# got: 'Shared object "libnci.so" not found
# '
# expected: 'loaded
# dlfunced
# ok 1
# ok 2
# '
# Failed test (t/pmc/nci.t at line 342)
# got: 'Shared object "libnci.so" not found
# '
# expected: 'loaded
# dlfunced
# ok 1
# ok 2
# ok 3
# ok 4
# '
# Looks like you failed 2 tests of 11.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 10-11
Failed 2/11 tests, 81.82% okay (-9 skipped tests: 0 okay, 0.00%)
]
Nicholas Clark
Re: [perl #19179] [PATCH] creating string_max_bytes()
On Mon, Dec 16, 2002 at 01:07:36PM +, mcharity @ vendian. org wrote: This question is actually independent of the patch (which looks good) >simply returns the C it is passed; C, on the >other hand, returns three times the value that it is passed because a >UTF8 character may occupy up to three bytes. Should that really be the number 3? I thought that the UTF8 representation of code points outside the base Unicode plane could get longer than that. Nicholas Clark
Re: [perl #19183] languages/perl6/t/compiler.t -- multiple ways to spell "Inf"
On Mon, Dec 16, 2002 at 03:25:36PM +, Andy Dougherty wrote: > On Solaris 8, with Sun's Workshop Compiler, using Sun's supplied > 5.00503, I get the following test failure in > > t/compiler/1# Failed test (t/compiler/1.t at line 306) > # got: '7.00 9.00 4.00 > # 7.00 9.00 4.00 > # 10.00 18.00 0.00 > # 32.00 729.00 1.00 > # 0.40 0.50 Inf > # 1.00 0.00 0.00 > # 3.00 3.00 -4.00 > # ' > # expected: '7.00 9.00 4.00 > # 7.00 9.00 4.00 > # 10.00 18.00 0.00 > # 32.00 729.00 1.00 > # 0.40 0.50 inf > # 1.00 0.00 0.00 > # 3.00 3.00 -4.00 > # ' > # Looks like you failed 1 tests of 14. > dubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED test 14 > Failed 1/14 tests, 92.86% okay I also see this on FreeBSD. At first I was tempted to change the expected to a regexp with case insensitivity on the inf, but then I wondered: The inf appears to be the output of 6/undef. Does the perl6 language mandate that infinity is to appear as a specific case sensitive spelling? [This may well be a perl6 language question] Also, is the first of these a bug? $ ./perl6 -e 'print 3/undef; print "\n"' Can't call method "tree" on an undefined value at ./perl6 line 342. $ ./perl6 -e 'print 3/$n; print "\n"' Inf Nicholas Clark
Re: [perl #19187] t/src/sprintf errors with 64-bit ints:
On Mon, Dec 16, 2002 at 03:34:34PM +, Andy Dougherty wrote: > On Solaris 8, with Sun's Workshop Compiler, using 64-bit long longs as > INTVAL, I get the following test failure in t/src/sprintf. It looks > like something is getting passed a 64-bit integer quantity but only taking > the first 32-bits (i.e. an int or long) to do the printing. On i386, > this ends up not mattering since those 32-bits are the significant ones. > A SPARC, however, is the other-endian, so those first 32 bits are all > zeros. I don't have time to track this down further myself. > > t/src/sprintf...# Failed test (t/src/sprintf.t at line 9) > # got: 'C I can't replicate this on ppc linux, due to varargs still not seeming to work t/src/sprintf...# Failed test (t/src/sprintf.t at line 9) # got: '' I don't (yet) have a 64 bit perl on the slow sparc boxes I have access to. Nicholas Clark
Re: Minimum requirements reminder
On Mon, Dec 16, 2002 at 06:57:40PM -0500, Dan Sugalski wrote: > Folks, > > Just a reminder--our minimum requirements for build, at the moment, > is an ANSI89 compliant C compiler (Hosted version, I think--whatever > has a full set of headers) and perl 5.005_03. At some point we may > raise the perl minimum to 5.6.0, but not right yet. That does mean > some of the new features of perl, such as warnings or regex objects, > can't be used. qr came in at 5.005, presumably 5.005_00 $ perl5.00503 -wle '$a = qr/[^white]/; print "Got qr" if "black" =~ $a' Got qr I presume you mean 5.005, rather than no qr because we want 5.004. Nicholas Clark
