Using different C compilers or settings...

Hi,

Is there an easy way to use different C compilers or compiler settings  
when doing a compile-file? We would like to generate code for  
different processors from the same running image, and we're trying to  
figure out whether there is an easier way than to compile to C and  
then "manually" trigger the invocation of C compiler...

Any feedback is appreciated.

Best,
Pascal

--

-- 
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

Pascal Costanza, mailto:pc@..., http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Using different C compilers or settings...

On Mon, Mar 3, 2008 at 1:11 PM, Pascal Costanza <pc@...> wrote:
>  Is there an easy way to use different C compilers or compiler settings
>  when doing a compile-file? We would like to generate code for
>  different processors from the same running image, and we're trying to
>  figure out whether there is an easier way than to compile to C and
>  then "manually" trigger the invocation of C compiler...

Hi Pascal,

switching compilers is relatively easy, as far as all generated files
share the same dynamically or statically linked library as the core.

The relevant special variables are *cc*, *ld*, *cc-flags*, *ld-flags*,
*ld-bundle-flags* and *ld-shared-flags*, which define the name of the
compiler and of the linker (gcc, typically), and the flags for
compiling C files, and for linking executables, fasl files and shared
libraries.

These variables are used in cmpmain.lsp by a bunch of functions that
abstract the tasks of compiling and linking various types of binaries,
and their combination is done using two format strings *cc-format* and
*ld-format*, as you will easily deduce from the code.

If you just want to change the compiler optimization and code
generation settings, extending *cc-flags* is the preferred way.

Juano

--

-- 
Facultad de Fisicas, Universidad Complutense,

Re: Using different C compilers or settings...

Thanks a lot, we'll check this out...

Pascal

On 3 Mar 2008, at 14:24, Juan Jose Garcia-Ripoll wrote:

> On Mon, Mar 3, 2008 at 1:11 PM, Pascal Costanza <pc@...> wrote:
>> Is there an easy way to use different C compilers or compiler  
>> settings
>> when doing a compile-file? We would like to generate code for
>> different processors from the same running image, and we're trying to
>> figure out whether there is an easier way than to compile to C and
>> then "manually" trigger the invocation of C compiler...
>
> Hi Pascal,
>
> switching compilers is relatively easy, as far as all generated files
> share the same dynamically or statically linked library as the core.
>
> The relevant special variables are *cc*, *ld*, *cc-flags*, *ld-flags*,
> *ld-bundle-flags* and *ld-shared-flags*, which define the name of the
> compiler and of the linker (gcc, typically), and the flags for
> compiling C files, and for linking executables, fasl files and shared
> libraries.
>
> These variables are used in cmpmain.lsp by a bunch of functions that
> abstract the tasks of compiling and linking various types of binaries,
> and their combination is done using two format strings *cc-format* and
> *ld-format*, as you will easily deduce from the code.
>

backquote bug?

I thought I would try to build maxima with ecl, but ran into a problem.

Maxima defines this function:

(defun make-operation (.type .op .return)
  (or .return (setf .return .type))
  #'(lambda (bod env)
      (declare (ignore env))
      (loop for v in (cdr bod)
     when (eq t .type) collect v into body
     else
     collect `(the , .type ,v) into body
     finally (setq body `(, .op , <at> body))
     (return
       (if (eq t .return)
           body
           `(the , .return ,body))))))

And then uses it like so:

(setf (macro-function 'zot) (make-operation 'fixnum '+ nil))

ECL accepts this ok.  But then

(macroexpand-1 '(zot a b))

produces an error about TYPE being unbound.

This code works fine for the other lisps that maxima can be built with: 
 gcl, clisp, cmucl, sbcl, scl, openmcl, and others.

Building for solaris sparc

I tried to build ecl 0.9j-p1 on sparc and ran into a couple of issues.

First, a simple configure with all defaults, using gcc, doesn't quite 
work.  This is because when gmp is configured it wants to build a 64-bit 
version of gmp but the rest of ecl is built assuming a 32-bit version.  
When everything is linked together, the linker fails since the object 
files are incompatible.

My solution was to add CC=gcc CFLAGS=-m64 and LDFLAGS=-m64 to the 
configure command line.  This works.  Until sockets.lisp is built.  A 
patch is enclosed that allows sockets.lisp to be built, but I didn't try 
anything to see if the result actually works or not.

I also tried using the sun studio 11 compiler, but that doesn't work.  
Build errors.  If you're interested I can provide some more detail.

Ray

--- ecl-0.9j-linux/contrib/sockets/sockets.lisp	2007-10-14 04:04:42.000000000 -0400
+++ ecl-0.9j-sparc/contrib/sockets/sockets.lisp	2008-03-03 20:38:43.000000000 -0500
 <at>  <at>  -109,7 +109,7  <at>  <at> 

 (define-c-constants
   +af-inet+ "AF_INET"
-  +af-local+ "AF_LOCAL"
+  +af-local+ #-sun4sol2 "AF_LOCAL" #+sun4sol2 "AF_UNIX"
   +eagain+ "EAGAIN"
   +eintr+ "EINTR")

Re: backquote bug?

On Tue, Mar 4, 2008 at 2:53 AM, Raymond Toy <toy.raymond@...> wrote:
> I thought I would try to build maxima with ecl, but ran into a problem. [...]
>      collect `(the , .type ,v) into body
>  [...]
>  ECL accepts this ok.  But then
>
>  (macroexpand-1 '(zot a b))
>
>  produces an error about TYPE being unbound.

This bug has been fixed in the unreleased version, available in CVS.
It was related to the pattern ",[ ]*." being read as ",."

Juanjo

--

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Building for solaris sparc

On Tue, Mar 4, 2008 at 3:01 AM, Raymond Toy <toy.raymond@...> wrote:
> I tried to build ecl 0.9j-p1 on sparc and ran into a couple of issues.
>
>  First, a simple configure with all defaults, using gcc, doesn't quite
>  work.  This is because when gmp is configured it wants to build a 64-bit
>  version of gmp but the rest of ecl is built assuming a 32-bit version.
>  When everything is linked together, the linker fails since the object
>  files are incompatible.

Regarding the Solaris port, remeber this was the only major issue. The
GMP library wants to build with a different word size than what the C
compiler by default takes. It was for this reason that I introduced a
compilation flag named "--enable-slow-conf" that first configures the
GMP library and then configures ECL using the same flags. It should
still work.

>  My solution was to add CC=gcc CFLAGS=-m64 and LDFLAGS=-m64 to the
>  configure command line.  This works.  Until sockets.lisp is built.  A
>  patch is enclosed that allows sockets.lisp to be built, but I didn't try
>  anything to see if the result actually works or not.

Thanks, I will commit that patch.

>  I also tried using the sun studio 11 compiler, but that doesn't work.
>  Build errors.  If you're interested I can provide some more detail.

Are they C compliance errors? If so, then I might want to have a look,
because they might pop up in other platforms. If they are some linkage
errors, I really would like to help, but I currently do not have a
solaris machine to debug or even build ECL.

About new_cons branch

Hi,

it seems I am getting some real improvements there. As I mentioned,
creating the LIST type and moving NIL there, reduces quite
significantly the amount of checks to be done when looping over lists,
concatenating them, etc. By coding the list routines I am getting
speedups of up to 50% in some routines. Just to show this, the
following is a benchmark of current ECL (main branch, no improvements)

Name         Real(s)    Run(s)    GC(kb)    Repetitions
NCONC-2        0.488     .4783     15626        1000000
NCONC-3        .4998     .4925     31251        1000000
LIST*          0.897     .8823    156251        1000000
LIST           .8975     .8703    156251        1000000
APPEND         .8293     .8145    156251         100000
MAKE-LIST      .7632     .7528    156251         100000
COPY-LIST      0.823     .8045    156251         100000
COPY-ALIST     .8338     .8212    156251         100000
LAST-0         .4167     0.413         1        1000000
LAST-1         .4138     .4097         1        1000000
LAST-2         .4147     .4097         1        1000000

And this is what the new_cons branch produces

Name         Real(s)    Run(s)    GC(kb)    Repetitions
NCONC-2        .3175     .3117     15626        1000000
NCONC-3        .4317     .4247     31251        1000000
LIST*          .5905     .5797    156251        1000000
LIST           0.577     0.567    156251        1000000
APPEND         .4885     .4758    157814         100000

Re: backquote bug?

Juan Jose Garcia-Ripoll wrote:
> On Tue, Mar 4, 2008 at 2:53 AM, Raymond Toy <toy.raymond@...> wrote:
>   
>> I thought I would try to build maxima with ecl, but ran into a problem. [...]
>>      collect `(the , .type ,v) into body
>>  [...]
>>  ECL accepts this ok.  But then
>>
>>  (macroexpand-1 '(zot a b))
>>
>>  produces an error about TYPE being unbound.
>>     
>
> This bug has been fixed in the unreleased version, available in CVS.
> It was related to the pattern ",[ ]*." being read as ",."
>
>   
Heh, ok.  I'll try the CVS version.

Ray

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Building for solaris sparc

Juan Jose Garcia-Ripoll wrote:
> On Tue, Mar 4, 2008 at 3:01 AM, Raymond Toy <toy.raymond@...> wrote:
>   
>> I tried to build ecl 0.9j-p1 on sparc and ran into a couple of issues.
>>
>>  First, a simple configure with all defaults, using gcc, doesn't quite
>>  work.  This is because when gmp is configured it wants to build a 64-bit
>>  version of gmp but the rest of ecl is built assuming a 32-bit version.
>>  When everything is linked together, the linker fails since the object
>>  files are incompatible.
>>     
>
> Regarding the Solaris port, remeber this was the only major issue. The
> GMP library wants to build with a different word size than what the C
> compiler by default takes. It was for this reason that I introduced a
> compilation flag named "--enable-slow-conf" that first configures the
> GMP library and then configures ECL using the same flags. It should
> still work.
>
>   
Oh, I'm new to ecl and the mailing list, so I didn't know that.  I'll 
try that and let you know if it works.

>>  I also tried using the sun studio 11 compiler, but that doesn't work.
>>  Build errors.  If you're interested I can provide some more detail.
>>     
>
> Are they C compliance errors? If so, then I might want to have a look,
> because they might pop up in other platforms. If they are some linkage
> errors, I really would like to help, but I currently do not have a