Adding loop primitives/optimizations (was MakingSet/Dictionaryetc. loops more robust)

Andreas Raab andreas.raab at gmx.de
Wed Dec 1 22:52:36 UTC 2004


Joshua,

The real restriction is that primitives are *always* leafs. They never call 
back into the interpreter and even if they could (there are some really ugly 
attempts to make this work) there isn't a way to "return to a primitive 
invokation". That's the one that really kills you. Squeak doesn't run off 
the C stack meaning that neither a Squeak method invokation nor a method 
return have anything in common with a C function call or return. You could 
hack this via setjmp and longjmp and friends but that is likely slower than 
running Squeak bytecodes instead. Even if you did this you'd still have to 
deal with -say- the debugger and a whole lot of other "interesting" issues.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Joshua Scholar" <jscholar at access4less.net>
To: "John M McIntosh" <johnmci at smalltalkconsulting.com>; "The 
general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, December 01, 2004 11:32 PM
Subject: Re: Adding loop primitives/optimizations (was 
MakingSet/Dictionaryetc. loops more robust)


>I really should leave now, but I just wanted to point out that you
> misunderstood what Tim Rowledge and I were talking about.
>
> The problem here is an _primitive_ iterator over a _block of regular
> Smalltalk code_.  In this case, the plug-in has to call back into the
> interpreter (I hope there's a way to do that).
>
> What I was saying is that in this case, Slang/C code needs variables that
> count toward not collecting an object, because inside the plugin's code, 
> the
> interpreter is running in all it's glory.
>
> And you know what, it's not onerous at all for objects to be relocated, as
> long as the GC updates the registered Slang variables just like it updates
> the rest of the variables in the system.
>
> Ok, I can see that if you didn't design this sort of flexibility into the
> the VM then adding it could be a real job, but you know, it's a heavy
> restriction of Slang if this isn't possible.  Another way of looking at 
> it,
> mya be that these are primitives that should be integrated into the
> interpreter the way current invocation block code is, not considered a 
> plug
> in as such.
>
> Joshua Scholar
>
> 




More information about the Squeak-dev mailing list