Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-04-04 Thread Matthew Mondor
On Sun, 3 Apr 2011 21:44:36 +0200 Juan Jose Garcia-Ripoll wrote: > This means AREF is always open-coded unless DEBUG >= 2. But open-coding only > means that AREF is translated into ROW-MAJOR-AREF and this one is only > inlined when safety settings are low and the type of the array is known in > a

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-04-03 Thread Juan Jose Garcia-Ripoll
On Sun, Apr 3, 2011 at 8:51 PM, Matthew Mondor wrote: > Yes, I think that I now understand this. It also appears that in some > particular cases AREF access will be inlined at safety=0, which is a > very nice thing too. > AREF is inlined in many cases, including multidimensional access, but the

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-04-03 Thread Matthew Mondor
On Sun, 3 Apr 2011 09:59:17 +0200 Juan Jose Garcia-Ripoll wrote: > > In SBCL, AREF, SVREF, CHAR, SCHAR will signal a uniform condition of > > type SB-INT:INVALID-ARRAY-INDEX-ERROR: > > > > Which version is this? I get this one with the latest update from Fink > > (handler-case (let ((a (make-a

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-04-03 Thread Juan Jose Garcia-Ripoll
On Fri, Mar 18, 2011 at 5:58 PM, Matthew Mondor wrote: > Hello, > > When looking at the HyperSpec on those functions, it seems undefined > what happens when a supplied index is not a "valid array index", thus, > from 0 below the array size. The exception is ELT, which should signal > a condition

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-03-18 Thread Matthew Mondor
On Fri, 18 Mar 2011 15:26:26 -0400 Matthew Mondor wrote: > Attached is the test CL code and the resulting C code with ECL. > So for the SVREF case indeed 0-1 safety levels allow better > optimization, and ecl_aref1() is used at higher levels. When I started looking at the array implementation, i

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-03-18 Thread Matthew Mondor
On Fri, 18 Mar 2011 14:42:04 -0400 Matthew Mondor wrote: > 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. Attached is the

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-03-18 Thread Matthew Mondor
On Fri, 18 Mar 2011 19:07:39 +0100 "Pascal J. Bourguignon" 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

Re: [Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-03-18 Thread Pascal J. Bourguignon
Matthew Mondor writes: > Hello, > > When looking at the HyperSpec on those functions, it seems undefined > what happens when a supplied index is not a "valid array index", thus, > from 0 below the array size. The exception is ELT, which should signal > a condition of type TYPE-ERROR. > > In prac

[Ecls-list] AREF/SVREF/CHAR/SCHAR/ELT and signals

2011-03-18 Thread Matthew Mondor
Hello, When looking at the HyperSpec on those functions, it seems undefined what happens when a supplied index is not a "valid array index", thus, from 0 below the array size. The exception is ELT, which should signal a condition of type TYPE-ERROR. In practice however, it seems that implementat