On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
> G'day all.
>
> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>
> > 3) We're having a new rule--you may *not* take a continuation from
> > within an opcode function! This is probably one of those "Well, Duh!"
>
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
> 3) We're having a new rule--you may *not* take a continuation from
> within an opcode function! This is probably one of those "Well, Duh!"
> things but better to have it up front.
I see why you say this, but I'm not su
G'day all.
On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
> >> I've applied this, with the exception of the branch and bsr ops.
[...]
On Mon, Apr 22, 2002 at 11:01:35AM -0400, Dan Sugalski wrote:
> The branches are relative to the current PC, the jumps take
> absolute addresse
Dan Sugalski:
# Okay, I've been thinking about subroutines lately. A lot. I had
# planned on putting them off a bit until we'd gotten scratchpads and
# globals done, but I thin I'd as soon get this off for discussion, so
# maybe we can have the rough edges worked out by the time we have
# hash
Okay, I've been thinking about subroutines lately. A lot. I had
planned on putting them off a bit until we'd gotten scratchpads and
globals done, but I thin I'd as soon get this off for discussion, so
maybe we can have the rough edges worked out by the time we have
hashes.
Subroutines, genera
At 12:03 PM +1000 4/19/02, Andrew J Bromage wrote:
>G'day all.
>
>On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
>
>> I've applied this, with the exception of the branch and bsr ops. At
>> the moment, I agree--I can't see any case where "if" or "gte" needs
>> to have a variable t
I don't have the time right now to do this myself, so here is a simple
idea to evaluate.
Currently, the computed goto decode and dispatch is essentially:
goto *ops_addr[ *cur_opcode ];
Now a big part of the gain of the prederef runops core comes from decoding each
op once instead of each time
Two more problems found in string.c; these relate to the creation of
temporary strings to hold results of transcoding, in string_concat and
string_compare.
As per the latest (I think) decision from Dan ("Avoiding the deadlands", 9th
April: http://www.mail-archive.com/perl6-internals@perl.org/msg0
