Re: [Ecls-list] SSE error in build

2011-03-05 Thread Alexander Gavrilov 
> On Wed, Mar 2, 2011 at 9:40 PM, Alexander Gavrilov 
> wrote:
> > As an alternative, if there is a way to fuse the constant with
> > the unboxing operation, the unboxed value can probably be represented
> > as an expression using a couple of C intrinsic functions.
> >
> 
> ... this might be a better solution. ECL currently provides various hooks
> for inlining functions. One I like quite much is the use of compiler macros.
> You could replace current sse compilations with compiler macros that inline
> the constants as C expressions.

I've implemented a c-inline based representation for SSE constants
(code inspired by the optimizable constants feature). The only downside
I see is that if the constant happens to actually be used in boxed form
(e.g. in a macro or something), it will likely be boxed every time
it is evaluated instead of once.

Patch attached, together with two other minor tweaks.

Alexander

P.S. When I was writing that static constant code I was still trying
 hard not to use the cast intrinsics. Now that I'm already using
 them, there is no point in avoiding them only for the constants.
From e990f71a273f00d4a86add9e39f9d7e005dc809e Mon Sep 17 00:00:00 2001
From: Alexander Gavrilov 
Date: Sat, 5 Mar 2011 21:05:25 +0300
Subject: [PATCH 1/3] Make THE actually produce the warning if the intersection is empty.

---
 src/cmp/cmpspecial.lsp |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/cmp/cmpspecial.lsp b/src/cmp/cmpspecial.lsp
index acd27d8..48f00ea 100644
--- a/src/cmp/cmpspecial.lsp
+++ b/src/cmp/cmpspecial.lsp
@@ -27,7 +27,8 @@
   (let* ((form (c1expr (second args)))
 	 (the-type (first args))
 	 type)
-(if (setf type (values-type-and the-type (c1form-primary-type form)))
+(setf type (values-type-and the-type (c1form-primary-type form)))
+(if (values-type-primary-type type)
 (setf (c1form-type form) type)
   (cmpwarn "Type mismatch was found in ~s." (cons 'THE args)))
 form))
-- 
1.7.2.3

From e25e2ec1b25eb06927355cb9155b96d7051f2fe6 Mon Sep 17 00:00:00 2001
From: Alexander Gavrilov 
Date: Sat, 5 Mar 2011 21:11:58 +0300
Subject: [PATCH 2/3] Use a c-inline transformation to represent SSE constants in code.

---
 src/cmp/cmpct.lsp |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/src/cmp/cmpct.lsp b/src/cmp/cmpct.lsp
index e35f8da..8276eeb 100644
--- a/src/cmp/cmpct.lsp
+++ b/src/cmp/cmpct.lsp
@@ -40,12 +40,29 @@
((typep val 'LONG-FLOAT)
 (make-c1form* 'LOCATION :type 'LONG-FLOAT
 		  :args (list 'LONG-FLOAT-VALUE val (add-object val
+   #+sse2
+   ((typep val 'EXT:SSE-PACK)
+(c1constant-value/sse val))
(always
 (make-c1form* 'LOCATION :type (object-type val)
 		  :args (add-object val)))
(only-small-values nil)
(t nil)))
 
+#+sse2
+(defun c1constant-value/sse (value)
+  (let* ((bytes (ext:sse-pack-to-vector value '(unsigned-byte 8)))
+ (elt-type (ext:sse-pack-element-type value)))
+(multiple-value-bind (wrapper rtype)
+(case elt-type
+  (single-float (values "_mm_castsi128_ps" :float-sse-pack))
+  (double-float (values "_mm_castsi128_pd" :double-sse-pack))
+  (otherwise(values "" :int-sse-pack)))
+  (c1expr `(c-inline () () ,rtype
+ ,(format nil "~A(_mm_setr_epi8(~{~A~^,~}))"
+  wrapper (coerce bytes 'list))
+ :one-liner t :side-effects nil)
+
 ;;;;;;;
 ;;;
 ;;; KNOWN OPTIMIZABLE CONSTANTS
-- 
1.7.2.3

From d8bff7e8f900c6b2a6a763f666c3d62c92950454 Mon Sep 17 00:00:00 2001
From: Alexander Gavrilov 
Date: Sat, 5 Mar 2011 21:20:44 +0300
Subject: [PATCH 3/3] Add errno.h to unixsys.d

---
 src/c/unixsys.d |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/c/unixsys.d b/src/c/unixsys.d
index 8af6b61..545ab83 100755
--- a/src/c/unixsys.d
+++ b/src/c/unixsys.d
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* to see whether we have SIGCHLD */
-- 
1.7.2.3

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] SSE error in build

2011-03-02 Thread Alexander Gavrilov 
> ;;; Compiling (DEF-UTILITY NEG-SS ...).
> 
> Condition of type: SIMPLE-ERROR
> Cannot externalize object #
> Available restarts:

That's probably because of the change below. SSE packs can currently
only be compiled as static constants, and this really should be the
way they are handled: that negation operation is really supposed
to compile down to one XORPS instruction.

As an alternative, if there is a way to fuse the constant with
the unboxing operation, the unboxed value can probably be represented
as an expression using a couple of C intrinsic functions.

Alexander


Author: Juan Jose Garcia Ripoll   2011-01-23 
23:43:37

Do not use static constants when compiling Lisp code other than ECL's core

-- src/cmp/cmpwt.lsp --
index 24eab26..e316dbd 100644
@@ -280,7 +280,9 @@
   nil
   #-:msvc
   ;; FIXME! The Microsoft compiler does not allow static initialization of bit 
fields.
-  (unless (or *compiler-constants* (not (listp *static-constants*)))
+  (unless (or *compiler-constants*
+  (not *use-static-constants-p*)
+  (not (listp *static-constants*)))
 (let ((record (find object *static-constants* :key #'first :test #'equal)))
   (if record
   (second record)



--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Fwd: ECL specific changes for CFFI

2010-11-04 Thread Alexander Gavrilov 
> -- Forwarded message --
> From: Juan Jose Garcia-Ripoll 
> Date: Sun, Apr 25, 2010 at 2:47 PM
> Subject: ECL specific changes for CFFI
> To: cffi-de...@common-lisp.net
> 
> 
> * At the low level ECL has two different foreign function interfaces: one
> used in the interpreter and relying on an external library (libffi) and
> another one, much simpler, using the C compiler. Right now CFFI was only
> using the former unless it was not available. I provide a patch that chooses
> the interface depending on the use of the code: interpreter or compiled.
> (patch attached).

Hi,

I've found a problem with this change:

The dffi-function-pointer-call function should be put under #+dffi,
or CFFI fails to compile due to the si:call-cfun symbol being missing.
Also, it seems that the #-dffi/#+dffi logic is reversed in the
#-ecl-with-backend branch of produce-function-pointer-call.

Alexander

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Another delay...

2010-10-02 Thread Alexander Gavrilov 
Hi, here's one more issue, in this case more convoluted:

If a library load fails for some reason, any subsequent
load failure will cause a strange error about failing
to copy some temporary files, instead of a normal message.
This happens because a block with a NULL handle is
pushed onto the library list, and the second failed
load goes into the 'same handle found' branch.

This fixes it:

@@ -257,11 +257,14 @@ ecl_library_open(cl_object filename, bool force_reload) {
 goto DO_LOAD;
 }
block = other;
} else {
si_set_finalizer(block, Ct);
-   cl_core.libraries = CONS(block, cl_core.libraries);
+   if (block->cblock.handle != NULL)
+   cl_core.libraries = CONS(block, cl_core.libraries);
+   else
+   ecl_library_close(block);
}
}
return block;
 }
 
Alexander

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Slime & ECL

2010-09-28 Thread Alexander Gavrilov 
Hi,

I've noticed that the slime debugger crashes when attempting
to display the variables for some bytecode compiled function.
This happens because bytecode closures for local flets appear
in the variable binding list. I have patched it in my local
copy of slime, but it would be nice if a permanent fix could
be developed:

@@ -440,11 +440,11 @@
 (defun frame-decode-env (frame)
   (let ((functions '())
 (blocks '())
 (variables '()))
 (setf frame (si::decode-ihs-env (second frame)))
-(dolist (record frame)
+(dolist (record (remove-if-not #'consp frame))
   (let* ((record0 (car record))
 (record1 (cdr record)))
(cond ((or (symbolp record0) (stringp record0))
   (setq variables (acons record0 record1 variables)))
  ((not (si::fixnump record0))

Alexander

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Another delay...

2010-09-27 Thread Alexander Gavrilov 
> in the release plans. This time it is the Common Lisp reader with a more or
> less serious bug report. It involves strtod(), atoi(), etc, functions are
> used by ECL which may be affected by the current C locale.
> 

Hi,

While updating hu.dwim.walker to work with the current
environment structure, I have found a serious bug in ecl:

> (defun test ()
(let ((a 5)) 
  (declare (special a))
  (flet ((x () a))
(let ((a 10))
  (x)

> (test)
5 

> (compile 'test)

> (test)
10


This happens because lexical special declarations are
not supposed to propagate to inner bindings. This appears
to fix it properly:

@@ -138,11 +138,11 @@
   (member name *global-vars* :test #'eq :key #'var-name))
 
 (defun special-variable-p (name)
   (or (si::specialp name)
   (check-global name)
-  (let ((v (cmp-env-search-var name)))
+  (let ((v (cmp-env-search-var name *cmp-env-root*)))
 ;; Fixme! Revise the declamation code to ensure whether
 ;; we also have to consider 'GLOBAL here.
 (and v (eq (var-kind v) 'SPECIAL)
 
 ;;;

Alexander

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] inexistant packages

2010-09-04 Thread Alexander Gavrilov 
> Blocking this propagation of removes may also have the effect
> of damaging packages that were already supposedly taken off 
> the list if somebody does a redundant make-package call.

Of course, this might be better fixed in make-package...

Incidentally, is this ghost package list thread-safe?
I don't see any obvious locking code.

Alexander

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] inexistant packages

2010-09-04 Thread Alexander Gavrilov 
> I think this time I got it right -- your change was not entirely correct:
> imagine a FASL that does not exit read_VV but starts a toplevel. Then
> cl_core.packages_to_be_created might have the wrong value.

Anything called before read_VV exits and restores the var will be
in the context that allows referencing undefined packages. The only
way to fix it is to decouple this read mode flag from the state of
packages_to_be_created list, and set it only for the duration of
the part of read_VV that actually reads the symbols.

All that this line does is properly propagate removes from the
list, which are done when nested fasl loads define packages:

> > -/* old_eptbc = cl_core.packages_to_be_created; */
> > +   if (old_eptbc != OBJNULL)
> > +   old_eptbc = cl_core.packages_to_be_created;

The bug was that it also lost the special OBJNULL state that
marks absense of any fasl-loading on the stack, so after any
one fasl was loaded, the reader became always permissive.

Blocking this propagation of removes may also have the effect
of damaging packages that were already supposedly taken off 
the list if somebody does a redundant make-package call.

Alexander

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] inexistant packages

2010-09-04 Thread Alexander Gavrilov 
> On Mon, Aug 30, 2010 at 10:04 AM, Juan Jose Garcia-Ripoll <
> Ok, that should be fixed now. We just have to make sure that no other errors
> went unnoticed due to the one we have just fixed.

This fixes the fix. Otherwise even swank cannot be loaded from fasl...

- src/c/read.d -
index c07f725..93fb398 100644
@@ -2537,7 +2537,8 @@ read_VV(cl_object block, void (*entry_point)(cl_object))
2, CAR(x), block->cblock.name);
}
} end_loop_for_on(x);
-/* old_eptbc = cl_core.packages_to_be_created; */
+   if (old_eptbc != OBJNULL)
+   old_eptbc = cl_core.packages_to_be_created;
if (VVtemp) {
block->cblock.temp_data = NULL;
block->cblock.temp_data_size = 0;

Alexander

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] SSE Intrinsics in ECL

2010-08-20 Thread Alexander Gavrilov 
On Thu, Aug 19, 2010 at 2:53 PM, Juan Jose Garcia-Ripoll
 wrote:
> I can wait until you fix the names. Or would you rather want me to include
> it, so that your contribution does not break while I work on the next
> release?

Actually, apart from the issue of merging conflicts, I'm also a bit
concerned about compiler compatibility since I only tested on one
setup: gcc + x86_64. Committing and running test builds would be a
good way to find out if there are any unexpected issues. Note that
since I don't understand how the autoconf stuff works, SSE is
automatically enabled in config.h by testing defines provided by the C
compiler (the condition should work correctly on gcc and msvc). On
32-bit x86 it is necessary to add -msse2 (for gcc) to CFLAGS.


Incidentally, maybe you could quickly look through the files and give
your impression of my naming choices on general grounds?

http://github.com/angavrilov/ecl-sse/blob/master/contrib/sse/sse.lsp
http://github.com/angavrilov/ecl-sse/blob/master/contrib/sse/sse-core.lsp
http://github.com/angavrilov/ecl-sse/blob/master/contrib/sse/sse-utils.lsp


A summary of these naming decisions is as follows:

0) Original intrinsic function name postfix meanings (invented by Intel):

- _ss = operates on the 0th single-float in the register
- _ps = operates on all 4 single-floats
- _sd = operates on the 0th double-float
- _pd = operates on all 2 double-floats
- _epi?? = operates on all ints of size ??
- _epu?? = operates on all unsigned ints of size ??
- _si128 = operates on the whole register as one big int

1) I dropped the _mm_ prefix, and instead named the package 'sse' to
allow casual use as "sse:something".

Pros: With packages it seems to produce redundant clutter.

Cons: The new Intel AVX instruction intrinsics use _mm256_ to
distinguish them (although first CPUs to support these instructions
are only due 2011). This can be solved by putting them in a different
package, but then it would be impossible to import both sse and
potential future avx definitions (not that it makes much sense to mix
the two).

2) I dropped "ep" from "epi" and "epu".

Pros: "e" is meaningless because I don't plan to support MMX due to
obsolescence. "p" is likewise pointless because all integer ops work
on the whole register.

Cons: dropping "p" makes conversion function naming somewhat awkward
when contrasted with "si32" to denote an ordinary integer, and when
compared with the "pi" below.

3) I renamed "si128" to "pi".

Rationale: It's too long and unlike the ordinary "epi". I hate it. "i"
alone is too short.

4) I renamed comparison functions using graphic characters, e.g. <=-ps
instead of _mm_cmple_ps

Rationale: Distinguishing "cmple", "cmplt" etc at a glance is quite
hard, at least for me.

Arithmetic ops are still called "add-ps" etc, because things like
"+ps", "+-ps", "--ps" and so on are ugly and even more confusing.

5) I added some new constants like 0.0-ps, true-ps, false-ps, 0-pi and
so on. Likewise macros if-ps, not-ps, neg-ps etc.

6) New lispy array access functions like aref-ps, row-major-aref-ps and so on.

They always ignore the precise element type, only checking that it's a
specialized array and 16 bytes are accessible after the specified
index. row-major-aref-prefetch-* even ignore array bounds, since the
underlying instructions are only caching hints and officially safe to
use with bad addresses.


I think that's all, but maybe I forgot something.

Alexander

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Type propagation

2010-08-13 Thread Alexander Gavrilov 
On Thu, Aug 12, 2010 at 11:12 PM, Juan Jose Garcia-Ripoll
 wrote:
> On Thu, Aug 12, 2010 at 4:54 PM, Alexander Gavrilov 
> wrote:
>>
>>  (loop for i fixnum from 0 below (- (min (array-total-size arr1)
>>                                          (array-total-size arr2))
>>                                     3) by 4
>
> This is the code that gets normally inlined. Can you try adding the
> following function to the same file and see whether it gets inlined by your
> modified compiler?
> (defun foo (arr1 arr2)
>   (declare (optimize (safety 0) (speed 3)))

OK, it seems that setting safety to 0 makes everything inline. But it
seems strange to me that at safety 1 array accesses are already
inlined without any bound checks, while relatively harmless arithmetic
is still done via function calls...

Alexander

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Type propagation

2010-08-12 Thread Alexander Gavrilov 
On Thu, Aug 12, 2010 at 2:27 AM, Juan Jose Garcia-Ripoll
 wrote:
> On Wed, Aug 11, 2010 at 5:29 PM, Alexander Gavrilov 
> wrote:
>>
>> Hi, I've finally got around to this, and after some investigation
>> implemented it using the static constant facility in cmpwt.lsp
>> instead:

Today I added definitions for a number of SSE intrinsic functions:

http://github.com/angavrilov/ecl-sse/blob/f9436efbf6b72544129d493a8342208392cf3354/contrib/sse/sse.lsp

However, when I try to use them, ECL generates correct code for SSE
operations, but fixnums are for some reason not handled inline:

(declaim (ftype (function ((array single-float) (array single-float))
t) add-floats))

(defun add-floats (arr1 arr2)
  (declare (optimize (speed 3) (safety 1)))
  (loop for i fixnum from 0 below (- (min (array-total-size arr1)
  (array-total-size arr2))
 3) by 4
 do (setf (sse:row-major-aref-ps arr1 i)
  (sse:add-ps (sse:row-major-aref-ps arr1 i)
  (sse:row-major-aref-ps arr2 i)

transforms to:

/*  function definition for ADD-FLOATS*/
/*  optimize speed 3, debug 3, space 0, safety 1  */
static cl_object L2add_floats(cl_object V1, cl_object V2)
{ VT3 VLEX3 CLSR3 STCK3
const cl_env_ptr cl_env_copy = ecl_process_env();
cl_object value0;
{
{
ecl_ihs_push(cl_env_copy,&ihs,VV[2],_ecl_debug_env);
TTL:
T0= cl_typep(2,V1,VV[0])  /*  TYPEP   */;
if (ecl_unlikely(!((T0)!=Cnil)))
 FEwrong_type_argument(VV[0],V1);
T0= cl_typep(2,V2,VV[0])  /*  TYPEP   */;
if (ecl_unlikely(!((T0)!=Cnil)))
 FEwrong_type_argument(VV[0],V2);
{cl_fixnum V3;/*  I   */
cl_fixnum V4;
V3= 0;
{cl_fixnum V5;
V5= ((V1)->array.dim);
{cl_fixnum V6;
V6= ((V2)->array.dim);
{cl_fixnum V7;
V7= (V5)<=(V6)?V5:V6;
V4= ecl_to_fixnum(ecl_minus(MAKE_FIXNUM(V7),MAKE_FIXNUM(3)));}}}
L8:;
if(!((V3)>=(V4))){
goto L12;}
goto L9;
L12:;
goto L10;
L10:;
{__m128 V5;
V5= _mm_loadu_ps((__m128*)(&(V1)->array.self.sf[V3]));
{__m128 V6;
V6= _mm_loadu_ps((__m128*)(&(V2)->array.self.sf[V3]));
{__m128 V7;
V7= _mm_add_ps(V5,V6);
(_mm_storeu_ps((__m128*)(&(V1)->array.self.sf[V3]),V7),V7);}}}
V3= ecl_to_fixnum(ecl_plus(MAKE_FIXNUM(V3),MAKE_FIXNUM(4)));
goto L8;
L9:;
value0=Cnil; cl_env_copy->nvalues=1;
ecl_ihs_pop(cl_env_copy);
return value0;
}
}
}}

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Type propagation

2010-08-12 Thread Alexander Gavrilov 
> On Wed, Aug 11, 2010 at 5:29 PM, Alexander Gavrilov 
> wrote:
> 
> > Hi, I've finally got around to this, and after some investigation
> > implemented it using the static constant facility in cmpwt.lsp
> > instead:
> 
> There are two problems with the static constant facility.
> 
> 1) Not all compilers allow initialization of global constants in a
> complicated way. MSVC chokes on many of the expressions we produce for lisp
> constants.

Which expressions exactly are they? Maybe they can be
fixed to be more compatible, or something?

> 2) Static constants are not allocated in the heap. That is a huge problem I
> did not realize until recently, because if a constant in a loaded file is
> still referenced _after_ the binary file is garbage collected and unloaded,
> then we have a problem. I am looking for a solution, but currently it seems
> disabling static constants is the only possibility.

If the values are immediately unboxed anyway (as should be
the case with SSE packs), that would never be the problem.
Again, maybe it is possible to dynamically restrict this
feature to cases where the boxed form is not actually used?

Static constants produce the fastest possible access code,
so I was actually considering implementing something like
them for SSE before I found that it was already done.

I wonder if it also might make sense to produce a style
warning when the compiler has to box SSE values. After
all, it eats away all performance gains, and really
shouldn't happen at all outside REPL & interpreted code.

Alexander

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Type propagation

2010-08-11 Thread Alexander Gavrilov 
On Sun, Jul 18, 2010 at 11:54 PM, Juan Jose Garcia-Ripoll
 wrote:
> On Sun, Jul 18, 2010 at 7:38 PM, Alexander Gavrilov 
>> Also, is it at all possible to support using constants of
>> these new types in compiled code without adding a readable
>> representation?
>
> You may want to have a look at cmpct.lsp The goal would be to add a case for
> SSE types and translate the SSE atomic constant into a call to
> LOAD-TIME-VALUE.

Hi, I've finally got around to this, and after some investigation
implemented it using the static constant facility in cmpwt.lsp
instead:

http://github.com/angavrilov/ecl-sse/commit/cb0efd01987c4dead7a94f8dc23ef8ee26353e9c

However, I see that this facility is completely disabled on MSVC. Do
you remember what the actual problems with it were, and is it perhaps
possible to disable only specific types that are broken instead of
everything?

Also, is it documented somewhere what aligment guarantees does Boehm
GC provide? It would be very good if the 32-byte objects of the
sse_pack type could be guaranteed to be 16-byte aligned (actually, the
current code might crash if that is not true). Using static constants
here has a nice property that the C compiler automatically ensures
proper alignment.

Alexander

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] Type propagation

2010-07-18 Thread Alexander Gavrilov 
> On Sat, Jun 5, 2010 at 11:54 AM, Alexander Gavrilov 
> wrote:
> 
> > > I have stripped down and reimplemented the type propagator. Right now it
> > is
> > > kind of stable and implements forward type propagation for most forms.
> >
> > I wonder how difficult might it be to add a few more primitive
> > unboxed types and builtins using them?
> 
> 
> It would be easy, just changing cmpffi.lsp to add them as C representations
> of certain lisp types, and then adding inline forms for certain operations,
> such as addition, subtraction etc, in cmpnum.lsp, plus some functions in the
> core to convert to/from them.

Today I tried to add some native support for the SSE2 data
types to ECL, and to a certain extent it seems to work:

http://github.com/angavrilov/ecl-sse/commit/cbe378d285bcdc90dadd43cd039ff8128e4c6850
http://github.com/angavrilov/ecl-sse/commit/c03f83265ea6c46d648e64957b9fb0b7009c03e7

I wonder if there are any immediately obvious errors.

Also, is it at all possible to support using constants of
these new types in compiled code without adding a readable
representation?

Alexander

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug

2010-07-14 Thread Alexander Gavrilov 
> On Tue, Jul 13, 2010 at 9:43 AM, Alexander Gavrilov 
> wrote:
> 
> > > On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov <
> > angavri...@gmail.com>wrote:
> > >
> > > > (defmethod foo ((bar t)) (declaim (optimize (speed 1
> > > >
> > >
> > > I did not change anything since yesterday and this works for me.
> > >
> >
> > This requires cmp.fas to be loaded. In my case it happens
> > automatically because I load ASDF from .eclrc
> >
> 
> I verified the problem and found a quick solution for it -- apparently there
> are some extensions to the bytecodes compiler that do not work so nicely as
> expected, I just avoided their use.

What about the other two issues revealed by this one?

Namely:

1. This macro expansion is wrong:

(PROGN
 (SI:WITH-BACKEND :C/C++
  (EVAL-WHEN (:COMPILE-TOPLEVEL) (C::PROCESS-DECLAIM-ARGS '((FOO :BYTECODES
  (EVAL-WHEN (:COMPILE-TOPLEVEL) (PROCLAIM '((FOO)
 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (MAPC 'PROCLAIM '((FOO)

The second eval-when should obviously be (MAPC 'PROCLAIM '((FOO))) too.
This is what caused the debugger break in the first place, revealing
the bytecode compiler usage issue.

2. At least on my system, the debugger segfaults on any attempt
   to restart after the break takes place.

> :continue
Debugger received error: Detected access to an invalid or protected
memory address.
Error flushed.
> :continue

gdb:

Program received signal SIGSEGV, Segmentation fault.
0x7fe2f248cf06 in guess_environment (env=0x7fe2f28c6000,
interpreter_env=0x4707f41) at
/home/.../SysAdm/ProgramAdm/ecl/src/c/compiler.d:521
521 cl_object record0 = ECL_CONS_CAR(record);
(gdb) p record
$1 = (cl_object) 0x1

Alexander

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug

2010-07-13 Thread Alexander Gavrilov 
> On Mon, Jul 12, 2010 at 5:09 PM, Juan Jose Garcia-Ripoll
>  wrote:
> > On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov 
> > wrote:
> >>
> >> (defmethod foo ((bar t)) (declaim (optimize (speed 1
> >
> > I did not change anything since yesterday and this works for me.
> >
> 
> Maybe Alexander did not rebuild from a clean local build tree?

I always rebuild using

make clean
./configure ...
make
sudo make install


By the way, is there a faster procedure in case
I want to try hacking something big in the C kernel?
This all is ok for a few short fixes, but would
quickly become annoying if repeated a lot.

Alexander

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug

2010-07-13 Thread Alexander Gavrilov 
> On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov 
> wrote:
> 
> > (defmethod foo ((bar t)) (declaim (optimize (speed 1
> >
> 
> I did not change anything since yesterday and this works for me.
> 

This requires cmp.fas to be loaded. In my case it happens
automatically because I load ASDF from .eclrc

Here is a session started from scratch:

$ ecl -norc
ECL (Embeddable Common-Lisp) 10.7.1
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.  
Top level in: #.
> (require 'asdf)

;;; Loading #P"/usr/lib64/ecl-10.7.1/asdf.fas"
;;; Loading #P"/usr/lib64/ecl-10.7.1/cmp.fas"
("ASDF" "CMP")
> (macroexpand-1 '(declaim (foo)))

(PROGN
 (SI:WITH-BACKEND :C/C++
  (EVAL-WHEN (:COMPILE-TOPLEVEL) (C::PROCESS-DECLAIM-ARGS '((FOO :BYTECODES
  (EVAL-WHEN (:COMPILE-TOPLEVEL) (PROCLAIM '((FOO)
 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (MAPC 'PROCLAIM '((FOO)
#
> (defmethod foo ((bar t)) (declaim (optimize (speed 1

Break

Available restarts:

1. (CONTINUE) Return from BREAK.
2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (PROGN (PROCLAIM '((OPTIMIZE (SPEED 
1)] In: #.
>> :pop

Debugger received error: Detected access to an invalid or protected memory 
address.
Error flushed.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug

2010-07-12 Thread Alexander Gavrilov 
On Sun, Jul 11, 2010 at 5:48 PM, Juan Jose Garcia-Ripoll
 wrote:
>> (defmacro x (v) t)
>> (defmethod foo (arg) (x (((arg)
>
> This should be compiling just fine now.

I've noticed some new bugs:

CL-USER[1]> (defmethod foo ((bar t)) (declaim (optimize (speed 1

Break
Available restarts:

1. (CONTINUE) Return from BREAK.
2. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (PROGN (PROCLAIM '((OPTIMIZE
(SPEED 1)] In: #.
** BREAK [LEVEL 2]> :continue
Debugger received error: Detected access to an invalid or protected
memory address.
Error flushed.
** BREAK [LEVEL 2]> :continue

gdb:

Program received signal SIGSEGV, Segmentation fault.
0x7fe2f248cf06 in guess_environment (env=0x7fe2f28c6000,
interpreter_env=0x4707f41) at
/home/.../SysAdm/ProgramAdm/ecl/src/c/compiler.d:521
521 cl_object record0 = ECL_CONS_CAR(record);
(gdb) p record
$1 = (cl_object) 0x1

Issues seen here:

1. declaim generates a broken proclaim call for the bytecode compiler
2. the bytecode compiler evaluates the eval-when even though it is not
a top-level form
3. the debugger crashes (even :exit doesn't work)

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list

[Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug

2010-07-10 Thread Alexander Gavrilov 
There is a serious bug in the new way of representing
macros during compilation.

(defmacro x (v) t)
(defmethod foo (arg) (x (((arg)

If the above code is compiled via compile-file, the
following error appears:


 Error:
  in file foo.lisp, position 22
  at (DEFMETHOD FOO ...)
  * The macro form (DEFMETHOD FOO (ARG) (X (((ARG) was not expanded 
successfully.
Error detected:
In form
(((ARG)))
FUNCTION: Not a valid argument ((ARG)).


The cause for this is that now the macro is stored only
in the environment, so when defmethod's macroexpander
calls (coerce body 'function) in order to exploit the
bytecode compiler's walker, it has no way to know
about the macro, and tries to make sense of (((ARG)))
as a function call. It is also obvious that with less
convoluted cases it might finish without an error, but
mess up whatever data defmethod tries to gather due to
incomplete expansion.

I have no ideas about fixing this, so I just report it.



Also, here are some fixes for things with less convoluted causes:

Fixes errors about variable CONSTANTLY-NIL being unset:

diff --git a/src/clos/slot.lsp b/src/clos/slot.lsp
index c25039a..c169611 100644
--- a/src/clos/slot.lsp
+++ b/src/clos/slot.lsp
@@ -98,8 +98,8 @@
   ;;
   (if (constantp form)
   (let ((value (eval form)))
-   (cond ((null value) ''si::constantly-nil)
- ((eq value t) ''si::constantly-t)
+   (cond ((null value) '#'si::constantly-nil)
+ ((eq value t) '#'si::constantly-t)
  (t `(constantly ,form
   `#'(lambda () ,form)))
 


Fixes errors about T not being a list during calls to make-instance:

diff --git a/src/clos/standard.lsp b/src/clos/standard.lsp
index 72ee9c6..8bc77c7 100644
--- a/src/clos/standard.lsp
+++ b/src/clos/standard.lsp
@@ -724,7 +724,7 @@ because it contains a reference to the undefined class~%  
~A"
   ;; First get all initargs which have been declared in the given
   ;; methods, then check the list of initargs declared in the slots
   ;; of the class.
-  (unless (eq methods t)
+  (unless (or (eq methods t) (eq cached-keywords t))
 (do* ((name-loc initargs (cddr name-loc))
  (allow-other-keys nil)
  (allow-other-keys-found nil)



Stops invalid errors about (ignorable #'local-function):

diff --git a/src/cmp/cmpenv-declare.lsp b/src/cmp/cmpenv-declare.lsp
index 1d69d80..e4ae9be 100644
--- a/src/cmp/cmpenv-declare.lsp
+++ b/src/cmp/cmpenv-declare.lsp
@@ -52,6 +52,11 @@
name)))
   tail)
 
+(defun valid-ignore-decl-name-p (name)
+  (or (symbolp name)
+  (and (consp name)
+   (eq (first name) 'function
+
 (defun collect-declared (type var-list tail)
   (declare (si::c-local))
   (cmpassert (proper-list-p var-list #'symbolp)
@@ -76,11 +81,11 @@ and a possible documentation string (only accepted when 
DOC-P is true)."
do (case decl-name
 (SPECIAL)
 (IGNORE
- (cmpassert (proper-list-p decl-args #'symbolp)
+ (cmpassert (proper-list-p decl-args #'valid-ignore-decl-name-p)
 "Syntax error in declaration ~s" decl)
  (setf ignored (parse-ignore-declaration decl-args -1 ignored)))
 (IGNORABLE
- (cmpassert (proper-list-p decl-args #'symbolp)
+ (cmpassert (proper-list-p decl-args #'valid-ignore-decl-name-p)
 "Syntax error in declaration ~s" decl)
  (setf ignored (parse-ignore-declaration decl-args 0 ignored)))
 (TYPE



Stops invalid errors about (notinline (setf foo)):

diff --git a/src/cmp/cmpenv-fun.lsp b/src/cmp/cmpenv-fun.lsp
index 54cf600..679fa17 100644
--- a/src/cmp/cmpenv-fun.lsp
+++ b/src/cmp/cmpenv-fun.lsp
@@ -133,7 +133,7 @@
  collect (cons name t
 
 (defun declare-notinline (fname-list &optional (env *cmp-env*))
-  (unless (every #'symbolp fname-list)
+  (unless (every #'si::valid-function-name-p fname-list)
 (cmperr "Not a valid argument to NOTINLINE declaration~%~4I~A"
 fname-list))
   (cmp-env-extend-declaration 'INLINE

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list