On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote:
> >>>>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
> SC> I can't make this make any sense. Could you try again?
>
> well, you should have been on the lists when this was being hammered
> around.
OK. I don't remember this being hammered around though.
> basically the emitted machine code for TIL is very simplified C
> routine calls and their argument setup and return. all the routine calls
> are to perl ops with just the minimal stack glue code in between them.
So you're talking about using a Forth style compiler to thread the
opcodes together.
Unfortunately, there's a slight problem with that:
*main::localtime = \&replacement;
memoize("factorial");
Once you've threaded the sub calls together, you've lost the indirection.
There's a discussion that Larry started this weekend on -internals.
Specifically:
Date: Mon, 23 Oct 2000 08:45:39 -0700 (PDT)
From: Larry Wall <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] (Adam Turoff)
Cc: Larry Wall <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Threaded Perl bytecode (was: Re: stackless python)
In-Reply-To: <[EMAIL PROTECTED]>
(from Adam Turoff on Sun, 22 Oct 2000 20:10:34 -0400)
Sender: [EMAIL PROTECTED]
Status: RO
Content-Length: 364
Lines: 9
Adam Turoff writes:
: If Perl bytecode were to become threaded, it would be rather troublesome.
Wasn't actually suggesting it, though similar issues also arise for
compiling down to efficient C, JVM, or C# IL. Optimizing for Least
Surprise means different things in different contexts, but I'd hate
for Perl 6 to be astonishingly slow at anything... :-)
Larry
Hope this helps.
Z.
