[Ecls-list] Help needed, really

[Juan Jose Garcia-Ripoll]

What I meant is the following: ECL does not gather specific information
about processor types and how they are used. Instead there are checks for C
types, sizes and precisions , some of which are performed during the
"autoconf" phase, some others when ECL is compiled. This information is
available at runtime via the FFI package, size-of function and multiple
constants (c-uint-max, etc).

Is this enough?

It depends. OpenAxiom contains a mixture of C++ and lisp code and decides
how to compile the former based on the later. It does so using specific
information about the system that the lisp implementation provides:
processor type and ABI type (64-bit or 32-bit) It is assumed that the
implementation must provide this because it is a compiler, even if we do not
directly use that.

Problem is I do not really know how to provide this in a way which is both
portable and future proof.

Autoconf tests are known to be broken, as processor names do not work on
various platforms. THe notion of 64-bit or 32-bit is ambiguous unless we
restrict ourselves to "pointer sizes" and in that case it is provided by ECL
in the FFI. But I presume that what is being asked for is what DS mentioned
about specific ABI names, but that means adding extra logic to autoconf,
something which I do not know how to maintain -- and do not have the time
to.

Juanjo
On Thu, Dec 30, 2010 at 3:25 PM, Pascal J. Bourguignon <
pjb at informatimago.com> wrote:

>
> I have no preconceived idea about your problem, however, I will note
> that:
>
> Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> writes:
>
> > Since ECL does not really care about the processor type, it is fine
> > with it, and just works: it only relies on information provided by the
> > compiler, such as type sizes, alignments, and the like, which are
> > found at compilation time.
>
> Time of compilation of what?
>
>
> While for C code, compilation time is a hard boundary, for lisp code it
> is less.
>
> ------------------------------------------------------------------------
> (defvar *int-size* 0)
> (defvar *example*  0)
> (eval-when (:compile-toplevel)
>  (defparameter *example*  42)
>  (defparameter *int-size* (c:size-of c:int))) ; or whatever syntax
> ------------------------------------------------------------------------
>
> (compile-file "example.lisp")
> --> #P"example.fas"
>    NIL
>    NIL
>
> *example*  --> 42
> *int-size* --> ?
>
>
> So it seems to me that ecl could provide the information also at
> run-time.
>
> --
> __Pascal Bourguignon__                     http://www.informatimago.com/
> A bad day in () is better than a good day in {}.
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
>



-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110101/4ac554d9/attachment.html>