Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> The 'eval' compiler returns a bytecode segment without a constant table. The
> 'destroy' of the Eval PMC needs to handle that.
How that? Are there no constants? Anyway, switching to a new bytecode
segment does switch the constant table too, so all
Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> i was starting to play with parakeet, but unfortunately it keeps dying on
> me. this is from a cvs checkout from today:
It needs for sure some adaption WRT the changes in the
compreg/compile/invoke sequence aka "eval".
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:16 PM +0100 11/16/04, Leopold Toetsch wrote:
>>This would imply a distinct return opcode instead of C.
> That went in, or was supposed to go in, as part of moving the return
> continuation into the interpreter struct. I presume this hasn't
> happened
Matt Fowles <[EMAIL PROTECTED]> wrote:
> ... Thus you can consider all of the
> following questions (even though they will be phrased as statements).
> 1) After a full continuation is taken all of the registers must be
> considered invalid.
Calling a subroutine allocates a new register frame,
Due to adaptions to pdd03 the direct access to the return continuation
is deprecated.
Instead these constructs should be used:
1) PIR code
* return from a sub
.return()
.return(foo)
.return (foo, bar, baz)
...
* get the current continuation (for call/cc)
.include "interpinfo.pasm"
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch brings Parrot m4 to terms with recent "eval" changes. The compile
> function of the 'eval' compiler now returns an Eval PMC. The m4 macro "eval"
> is a simple interpreter of integer arithmetic expressions.
Thanks, applied.
leo
Parrot starts execution at the first sub (or that one denoted with
@MAIN). This subroutine is called with pdd03 calling conventions like
any other sub. So we have:
P5 ... argv array
I0 = 0, I3 = 1 ... one PMC argument passed
A tailcall at the end of main is a valid operation to represe
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a real
number.
How does it look like? Any results already?
Thanks,
leo
We should create some syntax to access the object in methods.
It used to be:
1)
self."bar"()
where "self" automagically expanded to P2.
The current offical way is this sequence
2)
.include "interpinfo.pasm"
$P0 = interpinfo .INTERPINFO_CURRENT_OBJECT
$P0."bar"()
This two-liner looks a b
I've now (locally here) extended Bill Coffman's register allocator by
one subroutine that actually decides to use non-volatiles or volatiles
according to pdd03. All variables that are live around a subroutine call
are e.g. allocated from R16..R31.
Variables not alive around a call (temps) are a
> >> Not quite. COND_WAIT takes an opaque type defined by the platform, that
> >> happens to be a mutex for the pthreads based implementation.
>
> > It should, but it doesn't. Here's the definition:
> > # define COND_WAIT(c,m) pthread_cond_wait(&c, &m)
>
> You are already in the POSIX specific p
Leo~
Thanks for the clarification.
Matt
On Wed, 17 Nov 2004 08:48:58 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles <[EMAIL PROTECTED]> wrote:
>
> > ... Thus you can consider all of the
> > following questions (even though they will be phrased as statements).
>
> > 1) After
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Nope, haven't had time, unfortunately. Work's been busy. Today, if I get
lucky.
--
At 11:00 AM +0100 11/17/04, Leopold Toetsch wrote:
We should create some syntax to access the object in methods.
Well, there are two issues here.
First is in pasm/bytecode. For that, fetching things explicitly with
interpinfo is just fine, so the code sequence:
interpinfo P16, .INTERPINFO_CU
Leopold Toetsch wrote:
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
The 'eval' compiler returns a bytecode segment without a constant table. The
'destroy' of the Eval PMC needs to handle that.
How that? Are there no constants? Anyway, switching to a new bytecode
segment does switch the constan
On Mon, 15 Nov 2004, Matt Fowles wrote:
> Languages with Object Support?
>Jeff Horwitz wondered if there were any languages with object support
>that he could bend to the evil ends of mod_parrot. While no one
>answered, I think Parakeet might be such a language...
parakeet's a newcom
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> How that? Are there no constants?
> Yes, there are no constants. The only thing the generated sub does, is
> to return an integer value, that was computed in the C-Code.
> Thus the m4 macro "eval( 1 ^ 3 )" compiles into
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ setp_ind troubles ]
I've found a way to force allocation to R16..R31 in the presence of this
opcode.
leo
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Yes, there has to be a separate thread to get signals, and each thread
> needs its own event queue, but why does the process have a global
> event_queue? I suppose there are generic events that could be handled
> just by the next thread to call check_even
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
>> >> Not quite. COND_WAIT takes an opaque type defined by the platform, that
>> >> happens to be a mutex for the pthreads based implementation.
>>
>> > It should, but it doesn't. Here's the definition:
>> > # define COND_WAIT(c,m) pthread_cond_wait(&c, &m)
On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I've now (locally here) extended Bill Coffman's register allocator by
> one subroutine that actually decides to use non-volatiles or volatiles
> according to pdd03. All variables that are live around a subroutine call
Bill Coffman <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> I've now (locally here) extended Bill Coffman's register allocator by
>> one subroutine that actually decides to use non-volatiles or volatiles
>> according to pdd03. All vari
At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
I've now (locally here) extended Bill Coffman's register allocator by
one subroutine that actually decides to use non-volatiles
At 2:14 PM +0100 11/17/04, Leopold Toetsch wrote:
Works fine *except* for the .flatten_arg directive. This directive
takes an argument array and expands the array contents to function
arguments in consecutive parrot registers. E.g.
.arg a=> P5
.flatten_arg array=> P6, P7,
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and
out of the sub, which is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either light-weight nor
faster. Here is a benchmark.
Below are 2 version
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
>>All registers are preserved, but some of these registers are used,
>>either by implict opcodes or as return values.
> Erm, no. Unused registers in the 0-15 range are explicitly garbage:
It was about usa
At 10:12 PM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
All registers are preserved, but some of these registers are used,
either by implict opcodes or as return values.
Erm, no. Unused registers in the 0-15 ra
Patrick R. Michaud wrote:
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
[EMAIL PROTECTED] pmichaud]$ parrot pmfact.imc #PIR
500500
5.819842
[EMAIL PROTECTED] pmichaud]$ parrot pmfactbsr.imc #bsr/ret
500500
2.010935
Ok:
$ parrot pmfactbsr.imc
500500
3.459947
$ parrot -Oc pmf
At 10:03 PM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and out of the sub, which
is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either light-weight nor
At 11:07 PM +0100 11/17/04, Leopold Toetsch wrote:
Please no premature optimizations.
It's important to note that
premature optimization == things Leo disapproves of
The bsr/ret version of things is fine. In the absolute best case
it'll be the same speed as tail calls, and in normal cases it'll
At 5:08 PM -0500 11/17/04, Dan Sugalski wrote:
Chopping out the multiplication (since that's a not-insignificant
amount of the runtime for the bsr/ret version) gives:
PIR:
real0m3.016s
user0m2.990s
sys 0m0.030s
bsr/ret
real0m0.344s
user0m0.340s
sys 0m0.010s
and with -Oc, f
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
> As already stated, I don't consider these as either light-weight nor
> faster. Here is a benchmark.
>
> Below are 2 version of a recursive factorial program. fact(100) is
> calculated 1000 times:
>
> PIR 1.1 s
> bsr/re
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> As already stated, I don't consider these as either light-weight nor
> faster. Here is a benchmark.
>
> Below are 2 version of a recursive factorial program. fact(100) is
> calculated 1000 times:
>
> PIR
On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
> BTW, it may be very possible for me to write the p6ge generator so
> that it can be switched between the PIR and bsr/ret calling conventions,
> so we don't need to resolve this entirely now. And we could then benchmark
> the t
So to generalize. The following registers are available, under the
following conditions:
* Registers R16-R31 are always available for the allocator.
* Registers R0-R15 are available between sub calls. That is, for any
symbol, whose life range does not cross a subroutine. (This implies
that all
At 2:02 PM -0800 11/17/04, Bill Coffman wrote:
So to generalize. The following registers are available, under the
following conditions:
* [NEW] If register 15 or below is used, it should be cleared out,
ZEROED, after it's last use and before the next sub call. This is for
security reasons. Obvio
> >* [NEW] If register 15 or below is used, it should be cleared out,
> >ZEROED, after it's last use and before the next sub call. This is for
> >security reasons. Obviously, these registers will not be the first
> >choice to use.
>
> Nope -- this isn't the job of the register allocator. We aren
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Since I understand the item about allocating registers between sub
> calls, I can probably implement that change, as I work through the
> control flow/data flow analysis.
This is already implemented, parts of it are in CVS.
> Sounds like everything else
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions and continuations should be the same problem -- the target
> is the start of a basic block. (Well, more than that, as they're
> places where calling conventions potentially kick in) This means the
> instruction immediately after a sub call start
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> BTW, it may be very possible for me to write the p6ge generator so
> that it can be switched between the PIR and bsr/ret calling conventions,
> so we don't need to resolve this entirely now. And we could then benchmark
> the two against each other.
40 matches
Mail list logo
