[squeak-dev] Implementing control operators

Bert Freudenberg bert at freudenbergs.de
Thu Apr 14 11:45:45 UTC 2011


On 14.04.2011, at 13:11, Igor Stasenko wrote:

> On 14 April 2011 12:43, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 
>> On 14.04.2011, at 05:20, Ralph Johnson wrote:
>> 
>>> On Wed, Apr 13, 2011 at 5:42 PM, Frank Shearar
>>> <frank.shearar at angband.za.org> wrote:
>>> 
>>>> But I suppose I'm really asking this: is it _necessary_ to use primitive
>>>> 199, or could one in _principle_ implement exception handling solely by
>>>> in-image stack manipulation?
>>> 
>>> Yes, you can implement exception handling by normal Smalltalk code,
>>> without any special primitives.   Primitives make it go faster, and
>>> they are necessary to trap blocks that leave your exception handler,
>>> but the first dozen exception handling packages in Smalltalk (and
>>> before the ANSI standard there are a lot of incompatible exception
>>> handling systems for Smalltalk) all did it without primitives.
>>> 
>>> -Ralph Johnson
>> 
>> Squeak's exception-related primitives are purely an optimization:
>> 
>> SystemNavigation default browseAllSelect: [:ea | ea primitive between: 195 and: 197]
>> 
>> I just removed those three primitive invocations, and the system seemed to still work fine. Prims 198 and 199 are only used to mark methods, they don't actually do anything.
>> 
>> Unless I am mistaken, the interpreter itself knows nothing about exceptions.
>> 
> 
> afaik it knows, because when you do non-local returns
> or terminating a process,
> there is no way how ifCurtailed: or ensure: blocks can be evaluated
> without interpreter knowing
> that it should check these special contexts during unwinding the stack.

Ah, right, in #commonReturn it checks #isUnwindMarked: which tests for prim 198. So I should have said the interpreter knows next to nothing about exceptions ;)

Prim 199 however is only tested for in #isHandlerMarked: which is only used in primitiveFindHandlerContext which is optional.


- Bert -





More information about the Squeak-dev mailing list