Ok, I see how the CCodeGenerator is making this method work...but I
still don't see why it's necessary to do the #fetchNextBytecode first
(which isn't correct if you're running in Smalltalk).  Why can't the
#fetchNextBytecode be the last statement as it is in the
InterpreterSimulator version of this method?

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Stephen Pair
> Sent: Friday, September 06, 2002 3:00 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Interpreter>>pushReceiverVariableBytecode
> 
> 
> After much debugging, I finally noticed the comment about 
> currentBytecode in this method.  It seems to have bitten me 
> because I changed the implementation of pushReceiverVariable: 
> and apparently foiled whatever magic the CCodeGenerator is 
> doing to keep currentBytecode constant.  I have a couple of 
> questions about this:
> 
> A) What is the benefit of this re-ordering?
> B) Where is the magic in the CCodeGenerator that is keeping 
> currentBytecode constant?
> C) What restrictions do I have to live with in 
> #pushReceiverVariable: in order not to foil the CCodeGenerator?
> 
> Thanks,
> Stephen
> 
> ------------
> pushReceiverVariableBytecode
> 
> 	self fetchNextBytecode.
> 	"this bytecode will be expanded so that refs to 
> currentBytecode below will be constant"
> 	self pushReceiverVariable: (currentBytecode bitAnd: 16rF).
> 
> 
>