On Oct 21, 2004, at 11:51 AM, Dan Sugalski wrote:
At 11:25 AM -0700 10/21/04, Bill Coffman wrote:
I read somewhere that the requirement for parrot code is that it
should be compliant with the ANSI C'89 standard. Can someone point me
to a description of the C89 spec, so I can make sure my reg_alloc
On Mon, Oct 18, 2004 at 04:43:12PM +0200, H.Merijn Brand wrote:
> > Please consider 0.50 very soon, in which you fix 'err' calls that are an
> > obvious mistake given defined-or functionality in blead and 5.8.x-dor:
>
> That would be too easy to call. here's a patch ...
Thank you. Patch provisio
On Thu, Oct 21, 2004 at 02:51:15PM -0400, Dan Sugalski wrote:
> At 11:25 AM -0700 10/21/04, Bill Coffman wrote:
> >I read somewhere that the requirement for parrot code is that it
> >should be compliant with the ANSI C'89 standard. Can someone point me
> >to a description of the C89 spec, so I can
At 11:25 AM -0700 10/21/04, Bill Coffman wrote:
I read somewhere that the requirement for parrot code is that it
should be compliant with the ANSI C'89 standard. Can someone point me
to a description of the C89 spec, so I can make sure my reg_alloc.c
patch is C89 compliant?
I don't think the ANSI
I read somewhere that the requirement for parrot code is that it
should be compliant with the ANSI C'89 standard. Can someone point me
to a description of the C89 spec, so I can make sure my reg_alloc.c
patch is C89 compliant?
Thanks,
- Bill
On Oct 21, 2004, at 8:34 AM, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like
to do with the interpreter, the register frame, and the register
backing stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date now
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd
like to do with the interpreter, the register frame, and the
register backing stack. I'll muddle it about some and see where it
goes.
JIT/i386 is up to date now
I almost forgot: there is F in CVS, which shows both
the current and a possible future register layout (-DINDIRECT). You can
time the normal function calling core with the mops benchmark by
compiling it with -DMOPS.
Have fun,
leo
At 9:24 AM -0700 10/21/04, Jeff Clites wrote:
I think there'll be two types of tie--tied variables (like Perl has
already), and tied namespaces (as supposedly some people really
need, though I don't fully know why). But even without the above
pathological case: with tied namespaces, a namespace
Leopold Toetsch wrote:
Is there a design reason for not having a chunked implementation?
Then you could use Array/PerlArray anyway (modulo the PerlUndef).
As I understood it, the language specific PMCs are planned to become
dynamic classes and are supposed to move to their respection languange/*
On Oct 21, 2004, at 4:13 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Oct 20, 2004, at 11:24 PM, Leopold Toetsch wrote:
And of course, lexicals and globals already have a storage, you don't
need to spill them.
I'm not sure that's true.
It should read: if there are lexical
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like to
do with the interpreter, the register frame, and the register backing
stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date now that is: it doesn't do any absolute register
addre
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
>> All tests pass normally, but I get 3 tests failing
>> under JIT
>>
>> t/op/interp.t #7
>> t/pmc/coroutine.t #10
>> t/pmc/exception.t #19
> ok, so I did investigate a little further. make testj
> works fine (all tests pass) if I don't pass the
> --o
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
> ok, so I did investigate a little further. make
> testj
> works fine (all tests pass) if I don't pass the
> --optimize flag to Configure.pl.
Ok, so optimizations break things - why not add more.
Interestingly, adding more aggressive options mak
At 12:51 PM -0500 10/20/04, Allen Short wrote:
On Tue, Oct 19, 2004 at 11:23:13AM +0200, Leopold Toetsch wrote:
* the import statement is simulated too by storing the lexicals into the
caller's frame. This would very likely be another Python opcode.
I should point out that this is much more li
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
>
> --- Joshua Gatcomb <[EMAIL PROTECTED]>
> wrote:
>
> >
> > 1. Transfer ICU 3.0 and build from source
> > 2. Do a fresh CVS checkout of parrot, transfer
> and
> > build
> >
> > $ perl Configure.pl --optimize
> >
> >
> > $ make
> >
> >
> >
--- Joshua Gatcomb <[EMAIL PROTECTED]>
wrote:
>
> 1. Transfer ICU 3.0 and build from source
> 2. Do a fresh CVS checkout of parrot, transfer and
> build
>
> $ perl Configure.pl --optimize
>
>
> $ make
>
>
> c++ -o parrot -L/usr/local/lib -Wl,-E -g imcc/main.o
> blibl/lib/libparrot.a -lnsl
At 11:17 PM +0200 10/20/04, Bernhard Schmalhofer wrote:
Hi,
I have started to work on some of the missing ops for the Resizable*Array
PMCs.
I noticed that, unlike the Array and PerlArray PMC, they currently do not
use the functionality from src/list.c.
This means that a ResizablePMCArray cannot be
On Tue, 19 Oct 2004, Austin Hastings wrote:
Yes: no traffic at all for quite a while...
Does this mean that we're done? :)
By any means... I don't think so! I wonder if this could in any way
support what occasionally trolls claim e.g. in clpmisc, i.e. that the Perl
community is devoted to the c
Yes, that's right folks - I said RedHat.
I got a shiny new development machine at work that I
can install anything I want on. The trouble is that
it doesn't have any net access so I have to transfer
everything via memory stick or CD. I just so happened
to have some RH CDs lying around, so that's
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Oct 20, 2004, at 11:24 PM, Leopold Toetsch wrote:
>> And of course, lexicals and globals already have a storage, you don't
>> need to spill them.
> I'm not sure that's true.
It should read: if there are lexical or global opcodes, lexicals and
globals h
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Just to clarify: This is the approach wherein each frame gets a fresh
> set of registers, and function call and return (or continuation
> invocation) copy the relevant registers between the register sets?
Yes. Function arguments and return values get copie
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> Is there a design reason for not having a chunked implementation?
Then you could use Array/PerlArray anyway (modulo the PerlUndef).
> One thing, that is propably hard to cover, is the method "sort" inherited
> from FixedPMCArray. It looks l
http://www.nntp.perl.org/group/perl.perl6.compiler -- It's there.
Correct, though, that it's not listed on the lists page...
On Thu, 21 Oct 2004 09:02:23 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it
> seems not to be gate
perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it
seems not to be gatewayed to nntp.perl.org. OTOH a lot of unused perl6
lists and newsgroups are there.
Finally I tried to subscribe already twice and got no answer.
Thanks,
leo
Hi,
I have started to work on some of the missing ops for the Resizable*Array
PMCs.
I noticed that, unlike the Array and PerlArray PMC, they currently do not
use the functionality from src/list.c.
This means that a ResizablePMCArray cannot be broken up in chunks and
set P0, .ResizablePMCArray
On Tue, Oct 19, 2004 at 11:23:13AM +0200, Leopold Toetsch wrote:
> * the import statement is simulated too by storing the lexicals into the
> caller's frame. This would very likely be another Python opcode.
I should point out that this is much more like Python's semantics for
"import *" than Da
On Oct 20, 2004, at 11:24 PM, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
And of course, lexicals and globals already have a storage, you don't
need to spill them.
I'm not sure that's true. If there's no 'eval' in scope, lexicals don't
have to live in pads--they could purely ex
On Oct 20, 2004, at 12:09 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok, shor
29 matches
Mail list logo
