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
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 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:
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
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
#
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
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
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 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
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
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. :)
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
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
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 clea
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
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
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 <[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 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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
