Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> In message <0GST00803WSFCU at mta10.srv.hcvlny.cv.net>
>           Anthony Hannan <ajh18 at cornell.edu> wrote:
> 
> >  In particular, I want to avoid initializing all
> > temps to nil at the start of every method.  Most methods have no temps so
> > it is a waste for the VM to go through this loop even if it is empty.  Also,
> > since the nils will likely be overriden it is a waste to put nils in the stack
> > in the first place.
> Eek. Danger Will Robinson!
> 
> Those nils are there for a good reason. Well, several actually.
> First, leaving anything random in there may (depending upon many details
> of the precise manner in which contexts are handled) blow the poor GCs
> little brains out.

I know.  If I need to reserve temps I would put nils in them.  This
would be done by a special bytecode that would be executed first.

> Second, any reflection upon the context _must_ find things as they are
> supposed to be. LPD expressed this many years ago as "you can cheat but
> you mustn't get caught". This is not C land where people _expect_ to
> find junk everywhere.

I forgot to mention this but tempAt: would have to be smart, using the
compiler to help find where the temp is actually stored on the stack.

> And besides, if there are no temps it isn't
> exaclty going to take long time to do that loop 0 times, is it?

Well, also getting nilObj and extracting the numArgs from method header
would also be eliminated.  But maybe your right that it won't be worth
it.  Before changing the compiler I will test moving temp initialization
to a new bytecode and add that bytecode to the front of methods that
have temps.  Then I'll see if its much of an improvement.

Cheers,
Anthony