On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
>> *How* are they "fundamentally different"?
>
>Perl's "local" variables are dynamically scoped. This means that
>they are *globally visible* -- you never know where the actual
>variable you're using came from. If you set a "local" variable,
>all
On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote:
>The less real question, "Should pads be hashes or arrays", can be answered
>by "whichever is ultimately cheaper". My bet is we'll probably keep the
>array structure with embedded names, and do a linear search for those rare
>times you're
I'm trying to get my head round the relationship between pad lexicals,
pad tmps, and registers (if any).
The PMC registers are just a way of allowing the the address of a PMC to
be passed to an op, and possibly remembered for soonish reuse, right?
So presumably we still have the equivalent of a
On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> I'm trying to get my head round the relationship between pad lexicals,
> pad tmps, and registers (if any).
It's exactly the same as the relationship between auto variables, C
temporaries and machine registers.
Simon
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 11:05:37AM +0100, Dave Mitchell wrote:
> > I'm trying to get my head round the relationship between pad lexicals,
> > pad tmps, and registers (if any).
>
> It's exactly the same as the relationship between auto variables, C
> tempo
Dave Mitchell wrote:
> Hmmm, except that at the hardware level, registers can store the actual
> temporary values themselves
register struct value *hardware_registers_can_be_pointers_too;
The PMC registers act like pointer-to-struct registers. Other register
sets can hold immediate values. This
whoops, forgot to CC the list
- Begin Forwarded Message -
Date: Thu, 6 Sep 2001 14:32:19 +0100 (BST)
From: Dave Mitchell
Subject: Re: pads and lexicals
To: [EMAIL PROTECTED]
Content-MD5: iVd18ng5xfzBBgJHSPdShg==
Ken Fox <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wro
Bart Lateur wrote:
> On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
> > The concept isn't the same. "local" variables are globals.
>
> This is nonsense.
> ...
> How are globals conceptually different than, say, globally scoped
> lexicals? Your description of global variables might just as we
On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> The Perl equivalent $a = $a + $a*$b requires a
> temporary PMC to store the intermediate result ($a*$b)
Probably a temporary INT or NUM register, in fact. But I see
your point. I wouldn't be surprised if some of the PMC registers
ha
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:35:53PM +0100, Dave Mitchell wrote:
> > The Perl equivalent $a = $a + $a*$b requires a
> > temporary PMC to store the intermediate result ($a*$b)
>
> Probably a temporary INT or NUM register, in fact. But I see
> your point. I w
Dave Mitchell wrote:
> The Perl equivalent $a = $a + $a*$b requires a
> temporary PMC to store the intermediate result ($a*$b). I'm asking
> where this tmp PMC comes from.
The PMC will stashed in a register. The PMC's value will be
stored either on the heap or in a special memory pool reserved
fo
On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> So I guess I'm asking whether we're abandoning the Perl 5 concept
> of a pad full of tmp targets, each hardcoded as the target for individual
> ops to store their tmp results in.
Not entirely; the last thing we want to be doing is c
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > of a pad full of tmp targets, each hardcoded as the target for individual
> > ops to store their tmp results in.
>
> N
On Sun, Sep 02, 2001 at 11:56:10PM +0100, Simon Cozens wrote:
> Here's the first of a bunch of things I'm writing which should give you
> practical information to get you up to speed on what we're going to be doing
> with Parrot so we can get you coding away. :) Think of them as having a
> Apocaly
Dave Mitchell wrote:
> So how does that all work then? What does the parrot assembler for
>
> foo($x+1, $x+2, , $x+65)
The arg list will be on the stack. Parrot just allocates new PMCs and
pushes the PMC on the stack.
I assume it will look something like
new_pmc pmc_register[0]
a
Simon Cozens wrote:
> I want to get on with writing all the other documents like this one, but
> I don't want the questions raised in this thread to go undocumented and
> unanswered. I would *love* it if someone could volunteer to send me a patch
> to the original document tightening it up in the
On Thu, Sep 06, 2001 at 10:46:56AM -0400, Ken Fox wrote:
> Sure. I can do that while *waiting patiently* for Parrot to be
> released. ;)
Don't tell Nat I said this, but we're hoping for around the
beginning of next week.
Simon
At 10:44 AM 9/6/2001 +0200, Bart Lateur wrote:
>On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote:
>
> >The less real question, "Should pads be hashes or arrays", can be answered
> >by "whichever is ultimately cheaper". My bet is we'll probably keep the
> >array structure with embedded names,
At 10:41 AM 9/6/2001 +0200, Bart Lateur wrote:
>Firs of all, currently, you can localize an element from a hash or an
>array, even if the variable is lexically scoped.
This doesn't actually have anything to do with lexicals, globals, or pads.
And the reason the keyword local works on elements of
At 10:45 AM 9/6/2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
No, it won't ac
At 05:08 PM 9/5/2001 -0500, David L. Nicol wrote:
>what if:
>
> *> there is a way to say that no new classes will be introduced
Then pigs will probably be dive-bombing the Concorde, and demons ice
skating. This is the language Damian programs in, after all... :)
At 03:21 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
> > > So I guess I'm asking whether we're abandoning the Perl 5 concept
> > > of a pad full of tmp targets, each hardcoded as the target for
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
Subject: pads and lexicals
>
> Dave "confused as always" M.
>
I just wanted to say that I'm really enjoying this pad/lexical thread.
There's a lot of info passing back and forth that I don't believe is clearly
documented in perlguts, etc. I expect
At 10:11 AM 9/6/2001 -0500, Garrett Goebel wrote:
>I just wanted to say that I'm really enjoying this pad/lexical thread.
>
>There's a lot of info passing back and forth that I don't believe is clearly
>documented in perlguts, etc. I expect when this thread runs its course,
>you'll be a whole lot
On 09/05/01 Nick Ing-Simmons wrote:
> >It's easier to generate code for a stack machine
>
> True, but it is easier to generate FAST code for a register machine.
> A stack machine forces a lot of book-keeping either run-time inc/dec of sp,
> or alternatively compile-time what-is-offset-now stuff
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> Where do they come from? Leave a plate of milk and cookies on your back
> porch and the Temp PMC Gnomes will bring them. :)
Ah, things are starting to make sense!
> ne
On 09/05/01 Dan Sugalski wrote:
> >It's easier to generate code for a stack machine
>
> So? Take a look at all the stack-based interpreters. I can name a bunch,
> including perl. They're all slow. Some slower than others, and perl tends
> to be the fastest of the bunch, but they're all slow.
H
At 05:00 PM 9/6/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > What we're going to do is have a get_temp opcode to fetch temporary PMCs.
> > Where do they come from? Leave a plate of milk and cookies on your back
> > porch and the Temp PMC Gnomes will bring them. :)
Paolo Molaro wrote:
> If anyone has any
> evidence that coding a stack-based virtual machine or a register one
> provides for better instructions scheduling in the dispatch code,
> please step forward.
I think we're going to have some evidence in a few weeks. I'm not
sure which side the evidence
On Thu, Sep 06, 2001 at 12:13:11PM -0400, Dan Sugalski wrote:
> Hmmm. Yes, in fact it should. That code will end up with a list of 65
> identical scalars in it. Bad Dan! No cookie for me.
Damn. I guess that means we have to write a compiler after all. I was
looking forward to having Dan assemble
On 09/05/01 Hong Zhang wrote:
> I think we need to get some initial performance characteristics of register
> machine vs stack machine before we go too far. There is not much points left
> debating in email list.
Unfortunately getting meaningful figures is quite hard, there are
so many thing to t
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/05/01 Dan Sugalski wrote:
> > >It's easier to generate code for a stack machine
> >
> > So? Take a look at all the stack-based interpreters. I can name a bunch,
> > including perl. They're all slow. Some slower than others, and perl tends
> >
At 10:45 AM 09-06-2001 -0400, Ken Fox wrote:
>Dave Mitchell wrote:
> > So how does that all work then? What does the parrot assembler for
> >
> > foo($x+1, $x+2, , $x+65)
>
>The arg list will be on the stack. Parrot just allocates new PMCs and
>pushes the PMC on the stack.
>
>I assume it
(Firstly, I'd say trust Nick's expertise--he has spent a good-sized chunk
of his career doing software simulations of CPUs, and knows whereof he
speaks, both in terms of software running on hardware and software running
on software)
At 05:33 PM 9/6/2001 +0200, Paolo Molaro wrote:
>I believe th
Dan Sugalski wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Where do they come from? Leave a plate of milk and cookies on your back
> > > porch and the Temp PMC Gnomes will bring them. :)
> Bad Dan! No cookie for me.
You aren't fooling anybody anymore... You might just as well stop the
At 01:21 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > Where do they come from? Leave a plate of milk and cookies on your back
> > > > porch and the Temp PMC Gnomes will bring them. :)
>
> > Bad Dan! No cookie for me.
>
>You aren't foo
At 06:12 PM 9/6/2001 +0200, Paolo Molaro wrote:
>As I said in another mail, I think the stack-based approach will not
>be necessarily faster, but it will allow more optimizations down the path.
>It may well be 20 % slower in some cases when interpreted, but if it allows
>me to easily JIT it and ge
Dave Mitchell:
# Simon Cozens <[EMAIL PROTECTED]> wrote:
# > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote:
# > > So I guess I'm asking whether we're abandoning the Perl 5 concept
# > > of a pad full of tmp targets, each hardcoded as the
# target for individual
# > > ops to store t
On 09/06/01 Dan Sugalski wrote:
> >The original mono interpreter (that didn't implement all the semantics
> >required by IL code that slow down interpretation) ran about 4 times
> >faster than perl/python on benchmarks dominated by branches, function
> >calls,
> >integer ops or fp ops.
>
> Right
On 09/06/01 Dan Sugalski wrote:
> Okay, I just did a test run, converting my sample program from interpreted
> to compiled. (Hand-conversion, unfortunately, to C that went through GCC)
>
> Went from 2.72M ops/sec to the equivalent of 22.5M ops/sec. And with -O3 on
> it went to 120M ops/sec. The
Dan Sugalski:
...
# new P0, list# New list in P0
# get_lex P1, $x # Find $x
# get_type I0, P1 # Get $x's type
# set_i I1, 1 # Set our loop var
# $10: new P2, I0 # Get a temp of the same type as $x
#
At 09:11 PM 9/6/2001 +0200, Paolo Molaro wrote:
>On 09/06/01 Dan Sugalski wrote:
> > >The original mono interpreter (that didn't implement all the semantics
> > >required by IL code that slow down interpretation) ran about 4 times
> > >faster than perl/python on benchmarks dominated by branches, f
At 09:22 PM 9/6/2001 +0200, Paolo Molaro wrote:
>A 10x slowdown on that kind of code is normal for an interpreter
>(where 10x can range from 5x to 20x, depending on the semantics).
If we're in the normal range, then, I'm happy.
Well, until we get equivalent benchmarks for Mono, in which case I s
At 12:34 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
>...
># new P0, list# New list in P0
># get_lex P1, $x # Find $x
># get_type I0, P1 # Get $x's type
># set_i I1, 1 # Set our loop var
># $10: new P2, I0
At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
>If foo is an unprototyped function (and thus takes a list in P0) we can
>immediately push the values of those calculations on to the list,
>something like (in a lame pseudo-assembler that doesn't use the right
>names for instructions):
FWIW, it's:
Dan Sugalski:
# At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
# >If foo is an unprototyped function (and thus takes a list in
# P0) we can
# >immediately push the values of those calculations on to the list,
# >something like (in a lame pseudo-assembler that doesn't use the right
# >names for instr
At 01:43 PM 9/6/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 12:04 PM 9/6/2001 -0700, Brent Dax wrote:
># >In the more general case, however (say, $x*1+$x*2+...$x*65) that's an
># >interesting question. Could we just do some fun stuff with
># lists? What
># >do real CPUs do?
>#
># Real CPUs
On 09/06/01 Dan Sugalski wrote:
> Then I'm impressed. I expect you've done some things that I haven't yet.
The only optimizations that interpreter had, were computed goto and
allocating the eval stack with alloca() instead of malloc().
Of course, now it's slower, because I implemented the full s
I had a thought this morning on funtion/struct/global
prefixes for Parrot. If we really plan to also run
Python/Ruby/whatever on it, it does not look good for the
entire API to be prefixed with "perl_". We really (IMHO)
ought to pick something else so that we don't give people a
convenient target
49 matches
Mail list logo
