At 11:50 AM -0700 9/23/02, Jonathan Sillito wrote:
> > -Original Message-
>> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
>> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> > get_counter:
>> > new_pad 1
>>
>> Doesn't this violate the 'caller saves' principle, making it hard to
> -Original Message-
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
> > get_counter:
> > new_pad 1
>
> Doesn't this violate the 'caller saves' principle, making it hard to
> do tail call optimization? Would it make sense to move the cre
"Jonathan Sillito" <[EMAIL PROTECTED]> writes:
>> -Original Message-
>> From: Sean O'Rourke [mailto:[EMAIL PROTECTED]]
>>
>> I think I didn't look through the patch queue carefully enough ;). I
>> gather that it's accepted practice (or something like that) to use an
>> array of pointers i
On 17 Sep 2002, Juergen Boemmels wrote:
> You do something like push_pad implicitly in the Sub class, but
> without a corresponding op in core.ops, when you invoke the Sub.
> You also get the current lexical scope implicitly at Sub creation
> time. This may be intentional so that the bytecode cant
"Sean O'Rourke" <[EMAIL PROTECTED]> writes:
> > At the moment I try to use this to get functions working in Scheme. I
> > have something, that is somewhat working in gdb, but not ready yet.
>
> Maybe we need a "pad pumpkin" to avoid these kinds of race conditions.
My actual implementation is a
