I looked that the usage of externalizeIPandSP a few months back and
found that in all cases the callout to an external routine "might"  
trigger a
memory allocation which *might* cause a GC event.  Mind I did submit a  
patch
to drag point x point y fully into the interpret loop.

In some cases one could specialize and inline the allocation so that you
only do the externalizeIPandSP when and if you do an allocation which  
fails
and then triggers a GC event.

Like for example primitiveBitShift or bytecodePrimBitAnd  which do the  
externalize because it invokes positive32BitIntegerFor which might*  
allocation a large positive integer.

MMm a bit of work, hard to measure, one could remove 6 memory loads and  
a subroutine call
  for say bytecodePrimBitAnd if you consider cases where C <- A & B  
produce smallIntegers.
But would that make things (micro/macro benchmarks) run faster? Don't  
think so.
Still a nice tuning exercise.

On Monday, September 15, 2003, at 11:15  PM, Ian Piumarta wrote:

> On Mon, 15 Sep 2003, Tim Rowledge wrote:
>> "Andreas Raab" <andreas.raab at gmx.de> wrote:
>>> No problem really. Just a few cycles spent doing the  
>>> externalizeIPandSP, a
>> So don't do the externalizeIPandSP. Pass them as args; we've already
>> gone to some trouble to get them into registers whenever possible so
>> calling primAt(ip, sp) or whatever isn't likely to be a problem.  
>> Except
>> perhaps
>
> when the prim triggers a GC.
>
> Ian
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===