> John, Tim,
>
> Thanks for the info. I've attached a modernized version for 3.6 which  
> fixes
> a number of issues I ran into when trying to use the 3.6 version:
> * SecurityPlugin>>primitiveCanWriteImage changed to use
> proxy->ioCanWriteImage but the proxy doesn't export it (why was this
> changed?) I reverted back to "self ioCanWriteImage".
> * "isUnwindMarked" was used for both a method name and a temp name  
> (leads to
> problems if it doesn't get inlined)
> * I also fixed the "nilObj" vs. "nilOop" issue reported by John
>

Hi, I'm not sure about the proxy->ioCanWriteImage, that looks like  
something in 3.6? Perhaps Tim can track
down the change.

I've been looking at commonReturn and started to wonder why the usage of

	localCntx _ localReturnContext.
	localVal _ localReturnValue.

Now you can only get to commonReturn say from
returnNil
	localReturnContext _ self sender.
	localReturnValue _ nilObj.
	self commonReturn.
by setting localReturnContext/Value then getting them into those local  
scoped variables. But why?
You see with the current VMMaker any sole usage of a instance variable  
in Interpreter will get folded
into a local variable versus a global if all references to that  
instance variable inline into a single C procedure.

Thus localReturnContext & localReturnValue are local variables in  
interpret()

However I'll point out that GCC and codewarrior with optimization  
decides we are idiots and ignores
the localCntx/Val constucts because they are read only and fold back to  
the localReturnContrext/Value
I did create a change set to do this, but then in doing this I reviewed  
the usage of externalizeIPandSP and decided one of the main usage is to  
avoid issues with positive32BitIntegerFor:

But one should note that as long as the value is a small integer then  
we could just special case the
allocation call to invoke externalizeIPandSP.

Which points to considering inlining the bit bytecode primitives, and  
primitivePointX & primitivePointY

Also this brought back another memory, I'm sure Anthony (years?) back  
pointed out that usage of
instantiateSmallClasssizeInBytesfill results in filling the allocated  
object with 0 or nil, but then we just fill the object with data right  
right away, this is silly. Think we could follow thru on his idea?


And why does signed32BitIntegerFor: use instantiateClass, versus   
instantiateSmallClasssizeInBytesfill?
which as ar  11/29/1999 22:01 as the author of last update
...
	newLargeInteger _
		self instantiateClass: largeClass indexableSize: 4.


--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===