>
>
> I did primitive error codes at Cadence and they'll very probably b  
> making it into Cog real soon now.  They're simpler than  
> VisualWorks', being only symbols.  So extracting more information,  
> such as a related error code requires a subsequent call.  But I  
> think the work I'm doing right now on eliminating pushRemappableOop:/ 
> popRemappableOop will enable me to have a structured object with a  
> name and parameters, which is more generally useful.

So.... what is the anticipated way that will work? I'm not sure I see  
the need for a two step process anyway.

The version we did at Interval in 98 was very simple, providing a call  
for prims to stuff some object (we used SmallInts in prcatice, but  
anything was allowed) into the first slot in the context that got  
activated on the fail. We extended the primitive declaration pragma to  
allow optional naming of the tempvar - default was 'errorValue' I  
think - and that was it. Code following the prim call could use or  
ignore the temp.
>
>
> A nice thing is that the code is forwards and backewards  
> compatible.  One can use the VM to run older images.  One can run  
> images that contain the primitive error code on older VMs, where one  
> simply gets a nil error code on primitive failure.
>
Sure, if the temp is used by return-code-unaware methods in an older  
image then it can't make much difference because it would be assumed  
nil as normal. Running new images on older VMs isn't something we've  
ever much bothered with for Squeak so don't worry about it.

I'm going to guess that "work I'm doing right now on eliminating  
pushRemappableOop:/popRemappableOop" relates to getting allocations  
out of primitives as much as possible, right?  That would be nice.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother," said Pooh, reading his bank statement from Barings.