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.
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
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
> >* [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
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
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
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
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 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
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
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 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
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: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
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
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
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,
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
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
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
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)
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
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
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
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
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
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
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
> >> 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
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
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
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
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
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
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"
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
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,
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
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
40 matches
Mail list logo
