On Tue, Dec 09, 2008 at 05:35:13AM +0000, David-Sarah Hopwood wrote: > Jonathan S. Shapiro wrote: > > Note that the existence of a catch-all eliminates the possibility of more > > efficient compilation. > > It's never feasible to compile under the assumption that exceptions are > not thrown, because many common primitive operations (e.g. array index, > referencing a field or method of a nullable variable, etc.) can implicitly > throw exceptions. Whether exceptions are declared has nothing to do with > this, AFAICS.
Isn't BitC going to allow unsafe array accesses for performance critical code? Is it really realistic, performance-wise, to only support array accesses with bound checking? If supported, unsafe mode would be best set at a local level (a different type?), not as a compiler option (although separate compilation mitigates that). Obviously, there are various situations where an out-of-bound cannot happen (one may even have written a proof for it); also, there are many situations where a runtime exception is no more useful than a segmentation fault. So if I cannot do anything useful with the exception, there is little point in performing the corresponding runtime checks (division-by-zero and null-dereferencing are always caught, out-of-bounds may not). For example, in a kernel, what are you going to do with a division-by-zero exception? Modern processors will generate a fault for you anyway, and you can catch it and print a call trace to a console. As BitC aims to have similar performance to C, I was thinking so-called "unsafe" operations would be supported (I actually assumed it would be the default, instead aiming at static correctness). Will it be the case? Thanks. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
