On Fri, 18 Mar 2011 19:07:39 +0100 "Pascal J. Bourguignon" <[email protected]> wrote:
> And similarly, the C standard doesn't specify either what happens when > you reference a slot in a vector beyond (or before) the bounds of the > vector (so called 'array' in C). > > It just happens that customers of C compilers tend to expect from their > compiler not to test out of bound errors. Indeed I don't expect C to check these at all. > In the case of Common Lisp, there's a declaration that allows the user > to tell the compiler what he'd like: > > (declaim (optimization (safety 0))) ; for no runtime out-of-bound error > checking > (declaim (optimization (safety 3))) ; for runtime out-of-bound error > checking > > The definition of levels 1 and 2 being left up to the implementation. I was not aware that (safety 0) allowed implementations to totally avoid bound checking. Thanks for this clarifiation; it's actually a nice feature. In this case safety was left at 1; is it still allright for SVREF to avoid boundary checks at this level? Perhaps a gray area since between 0 and 3 :) When I can, I'll then redo these tests on both SBCL and ECL using various safety levels to ensure that at level three boundary checks always be performed, and to list where at level 0 optimization could be improved. > Some other functions, when (safety 0) is specified, return an invalid > object. This might be better than either the original vector or an > element of the vector. However, SVREF is specified in such a way as to > be highly optimizable, so it is acceptable to make it faster and let it > return just what it has in the registers, even if it's the vector. This explains the unexpected SVREF results. Thanks again, -- Matt ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Ecls-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecls-list
