On Tue, Feb 25, 2003 at 08:47:55AM +0100, Leopold Toetsch wrote:
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto. Consider the
following calling sequence:
b(arg) - Push Continuation A onto the continuation chain
On Mon, Feb 24, 2003 at 05:29:26PM +, Piers Cawley wrote:
[Tail-call optimization]
Under caller saves, this is easy to do. Under callee saves, b's second
call to c() cannot simply return to Continuation A but must unwind the
call stack via b to make sure that the right things are restored.
Juergen Boemmels [EMAIL PROTECTED] writes:
we can use imcc rather than assemble.pl as the default assembler for the
regression tests? imcc is a lot (20 times) faster.
make test IMCC=1
Leo had introduced this several days ago, shortly after the
macro-support for imcc went in.
Arggh,
Leopold Toetsch wrote:
- do register allocation for JIT in imcc
- use the first N registers as MAPped processor registers
I have committed the next bunch of changes and an updated jit.pod.
- it should now be platform independent, *but* other platforms have to
define what they consider as
David sent the following bits through the ether:
how can I test to determine the datatype of the object in P1?
You'd be wanting typeof. The following prints out PerlString, for
example:
new P0, .PerlArray
set P0[1], cat
set P0[2], 123
set P0[3], 456.789
Leopold Toetsch [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Steve Fink [EMAIL PROTECTED] writes:
... I didn't follow about how that interferes with tail-call
optimization. (To me, tail call optimization == replace recursive
call with a goto to the end of the function preamble)
Um... no.
David wrote:
How do you determine the datatype of a PMC? For example, if I create the
following array:
From docs/core_ops.pod (built from core.ops):
=item Btypeof(out STR, in PMC)
=item Btypeof(out INT, in PMC)
Return the type of PMC in $2.
The String result is the class name, the int
The Perl 6 summary for the week ending 20030223
Another week, another Perl 6 Summary, in which you'll find gratuitous
mentions of Leon Brocard, awed descriptions of what Leopold Tötsch got
up to and maybe even a summary of what's been happening in Perl 6 design
and development.
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Ok .. well I sort of understood that the first N registers will
be the ones MAPped ?. So I thought re-ordering/sorting was the
operation performed.
Yep. Register
On Tue, Feb 25, 2003 at 07:18:11PM +0100, Angel Faus wrote:
I believe it would be smarter if we instructed IMCC to generate code
that only uses N parrot registers (where N is the number of machine
register available). This way we avoid the risk of having to copy
twice the data.
It's not
Angel Faus wrote:
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
With your approach there are three levels of parrot registers:
- The first N registers, which in JIT will be mapped to physical
registers.
- The others 32 - N parrot registers, which will be in memory.
- The spilled
On Tuesday 25 February 2003 08:51, Leopold Toetsch wrote:
Angel Faus wrote:
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
With your approach there are three levels of parrot registers:
- The first N registers, which in JIT will be mapped to physical
registers.
- The
Leopold Toetsch wrote:
From docs/core_ops.pod (built from core.ops):
Thanks. I better upgrade my version, I'm not seeing it in 0.0.9.
-- David Cuny
Leon Brocard wrote:
You'd be wanting typeof.
Thanks.
ps i fixed your code
Thanks again. :-)
Anyone know about a Parrot Windows binary?
-- David Cuny
Jerome Vouillon [EMAIL PROTECTED] writes:
On Tue, Feb 25, 2003 at 08:47:55AM +0100, Leopold Toetsch wrote:
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto. Consider the
following calling sequence:
b(arg) -
David sent the following bits through the ether:
Thanks. I better upgrade my version, I'm not seeing it in 0.0.9.
It's been a while since 0.0.9 (errr, 20th Dec). A lot has changed
since then. Maybe it's time for a 0.1.0 release. What are we waiting
for? And why do we have so many version
Leon Brocard wrote:
It's been a while since 0.0.9 (errr, 20th Dec). A lot has changed
since then. Maybe it's time for a 0.1.0 release. What are we waiting
for?
Dan said: either exceptions or objects. Once we have one, we'll go to
0.1.0, and when the second will be implemented (order does not
On Tue, 25 Feb 2003, Jerome Quelin wrote:
I want to include concurrent-funge support.
I'm not even going to ask :-)
Simon
Phil Hassey wrote:
Not knowing much about virtual machine design... Here's a question --
Why do we have a set number of registers? Particularily since JITed code
ends up setting the register constraints again, I'm not sure why parrot
should set up register limit constraints first. Couldn't
At 4:52 PM + 2/25/03, Leon Brocard wrote:
David sent the following bits through the ether:
Thanks. I better upgrade my version, I'm not seeing it in 0.0.9.
It's been a while since 0.0.9 (errr, 20th Dec). A lot has changed
since then. Maybe it's time for a 0.1.0 release. What are we waiting
Dan Sugalski sent the following bits through the ether:
While I'll call C many things (not all of them repeatable) I'm not
sure toy is one of them. Nor Forth, Fortran, APL, COBOL, Lisp, or
Basic... :)
Granted, but those aren't the languages we're interested in. Parrot is
for dynamic
Steve Fink wrote:
On Feb-23, Leopold Toetsch wrote:
I think I kind of have a grasp on what's going on, now. So I've
attached two possible patches.
I'm currently on the imcc stuff and could have a more detailed look at
both patches after. But I think, both have the same effect on generated
I explained very badly. The issue is not spilling (at the parrot
level)
The problem is: if you only pick the highest priority parrot registers
and put them in real registers you are losing oportunities where
copying the date once will save you from copying it many times. You
are, in some
On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote:
[snip lots of good stuff]
All this is obviously machine dependent: the code generated should
only run in the machine it was compiled for. So we should always keep
the original imc code in case we copy the pbc file to another
Jerome Quelin [EMAIL PROTECTED] writes:
And even toy languages may benefit from objects (yes, I really need
objects in order to implement -98 version of Befunge, especially
since I want to include concurrent-funge support). Well, I could use
my own hand-crafted objects as a list of whatever,
Piers Cawley wrote:
[snip]
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto.
[snip]
In perl5, doing a tail call optimization can be done with just a simple
goto... well, 'goto subname', anyway. (Well, first you'd assign
Nicholas Clark wrote:
On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote:
[snip lots of good stuff]
All this is obviously machine dependent: the code generated should
only run in the machine it was compiled for. So we should always keep
the original imc code in case we copy the pbc
Benjamin Goldberg [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[snip]
Um... no. tail call optimization implies being able to replace *any*
tail call, not just a recursive one with a simple goto.
[snip]
In perl5, doing a tail call optimization can be done with just a simple
goto... well,
28 matches
Mail list logo
