[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Merge objc-improvements-branch to mainline

From: Dietmar Planitzer
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: Thu, 25 Sep 2003 11:41:33 +0200

On Thursday, September 25, 2003, at 01:55  AM, Nicolas Roard wrote:

On 2003-09-24 18:24:44 +0000 Stan Shebs <address@hidden> wrote:

This has been one of the most heavily-requested features for ObjC. While
it's true that it's syntactic sugar, so is for(), and yet few suggest
that it should be removed from C. For that matter, many programmers
contend that ObjC and C++ are unnecessary syntactic sugar too... The
rationale for adding exception handling, aside from the incessant user
requests, is that it is hard to get right manually, plus the manual
solution involves fooling around with explicit flow control in the form
of setjmp/longjmp, which you really want to hide whenever possible.

What I don't understand, is that we _already_ have an exception system,
so what was those requests about ?
If NS_DURING/NS_HANDLER names scared programmers, well, we could
define them as @try ... @catch :-)
But I don't see what's so interesting with the new exception system, apart
to bring some incompatibilities ...
Someone could explain it to me ?

I'm one of those people who have been asking for this feature for years and I'm naturally happy that we finally have it now.

The current macro based exception implementation has at least two significant disadvantages: (1) it is unsafe and (2) very inefficient on RISC CPUs.

It is unsafe because you as the developer must be aware that you have to mark variables which are to be used in both the try and catch block as volatile. Otherwise, your application might crash if it tries to refer to one of those variables in the catch block because the compiler might try to read the variable value from a register which naturally contains random data when the catch block is entered by a thrown exception.

It is highly inefficient on RISC CPUs like the G4 or G5 PowerPC chips. In the case of the G4 the NS_DURING macro, because it calls setjmp(), saves roughly 100 registers to a memory buffer. Those are 32 32bit integer, 32 64bit floating point and 32 128bit vector registers plus machine state registers. The situtation is worse on a G5 with its 32bit 64bit integer registers.

It however, doesn't make the least sense to save 100% of the CPUs user state just because the catch handler might refer to 1 or 2 variables from the try block. It especially doesn't make sense to do this save operation no matter if an exception ever gets thrown or not. But this is exactly what NS_DURING is doing now - it always saves the whole user state although your code will hardly ever throw an exception. After all, exceptions are there for handling exceptional situations.

Exceptions are a flow control construct. This is one fundamental reason why they must be implemented by the compiler. This is also the only way to implement exceptions in both a safe and efficient way. I'm sorry, but hacking exceptions in on the library level as an after-thought doesn't make sense. Then its more honest to just not implement them at all.


Dietmar Planitzer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]