[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)

From: Camm Maguire
Subject: Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Date: 06 May 2005 10:00:00 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Vanuxem Gregory <address@hidden> writes:

> Serious question about GCL,
> I've lost your mail about (arbitrary float),
> But how do yo think peopole can implement arbitrary float in gcl; whith MPFR
> ?
> With class or directly in num_arith... ?
> Camm... one Idea....?

For lack of a better idea, I was thinking of something along the lines
of what clisp does -- have a system parameter which sets the 'big
float' precision, and then define a 'big float' type with coercion
rules identical to that between the existing short float and long
float types.  This would all be in num_arith, just as the 'bignum'
integers are now.  I was not envisioning any compiler support, thought
this could be added at some point.  I.e. array's of bigfloats would be
array's of objects, as opposed to array's of 16byte float numbers, for

I don't see a reason to do this, however, unless there is a benefit to
an existing application.  Axiom does its own bigfloat stuff already,
as does maxima.  Now if we can demonstrate that performance gains along
the lines of what you are seeing with the gcd stuff in gmp can be had,
that is a good reason, and should motivate us to get this in quickly
provided that axiom and/or maxima expresses their intention to use it.
There is just so much to do, I don't want to work on stuff which won't
be used, at least not right now.

> Actually AXIOM doesn't compile with ANSI version ...

IMHO, a strength of GCL is that we support both CLtL1 and (work in
progress) ANSI dialects to allow existing applications to decide if
and when to migrate to ANSI.  maxima has migrated to ANSI, largely
because they have a sizeable staff of lisp volunteers who are used to
ANSI, which is a good reason.  ACL2 and AXIOM have not yet, as their
lisp teams are familiar with and find what they need in CLtL1.  In my
opinion, they should have the option of choosing if and when to migrate
in the context of their other development considerations.

If memory serves, plenty of lisp 'heavy-weights' don't use ansi
features, e.g. CLOS, presumably because they don't want the overhead.
If memory serves, Paul Graham said he's never used it, but double
check that before relying upon it.

I'm missing the connection of this statement to the one above ...

> I know that you work on tcl/tk, documentation and graphics , doesn't forget
> the concept of 'notebook'
> (literate programming and other things...).

I'm afraid I don't follow.

> Generally I work on UNIX* (linux and BSD*) but actually ((numerical stuff to
> implemenent: transcendental function for matrix (see Higham
> (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra (atlas, blas
> and lapack ...))
> I' am on Windows(R) (thanks M.Thomas ...).
> I think in AXIOM five things has to be seriously be enhanced (for future
> library use...):
> 1) 'Integer' in arbitrary integer:                                            
>         'GMP (realized)'

Is this not already the case???

> 2) 'Floating number' in arbitrary float (cf: Monagan, Michael (1990)):        
> 'ADD

Is this not already the case???  Or are we talking performance here?

> 3) 'Fraction Integer' with gmp (GMP)                                          
> 'GMP (realized)'
>       (cf:
> (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
>       I will update and explain this when time permits.

I agree presuming we can test exhaustively.  If there is interest in
axiom for this, I'll move the rational arithmetic accelerations into
soon to be released 2.6.7, otherwise it will wait for 2.7.0.

> 4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?

There is a recent thread on gcl-devel expressing my ideas on this.
All we really need is a little enhancement to unexec to store dynamic
relocation records in a dumped image.  Perhaps an unexecbfd might help

But even now this is far more serviceable than it used to be.  See the
example on linking in ddot from libblas recently posted to
address@hidden using compiler::link.

> 5) Documentation about what I say.

Yes, please!

Take care,

> Cheers,
> Greg
> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden la part de
> Camm Maguire
> Envoye : jeudi 5 mai 2005 21:02
> A : Mike Thomas
> Cc : address@hidden
> Objet : [Gcl-devel] Re: Dynamic Library Linking
> Greetings!
> "Mike Thomas" <address@hidden> writes:
> > Hi Camm.
> >
> > | This is indeed the short answer -- you can link in any new symbols you
> > | want that are not present in the original image via compiler::link.
> > | See the documentation for this function in gcl-si.{texi,info}.  What
> > | this essentially does is build a new gcl image using a fresh call to
> > | the system linker ld to modify the image symbol table with whatever
> > | new code or libraries you specify.  It has the disadvantage that the
> > | image is 'fresh' -- i.e. any work you may have done in the running
> > | image before compiling compiler::link is lost.  Such work can be
> > | respecified to run by hand in the fresh new image through one of
> > | compiler::link's arguments, but this is a bit awkward to use.
> > |7
> > | What I'd like to do in 2.7.0 is to allow the user to link in new
> > | dynamic libraries at runtime, modify the running image's symbol table,
> > | and allow this work to be preserved across image saves via
> > | si::save-system.  What this essentially means is that unexec needs to
> > | add a little section to the end of the dumped image containing
> > | relocation records for the new symbols for use by the system's dynamic
> > | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> >
> > If I understand you correctly, on Windows one could store the name of the
> > symbol and the name of the DLL from whence it came, then while resolving
> > references at ru(i)ntime to call LoadLibrary() and GetProcAddress() for
> each
> > pair as shown here:
> >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> > base/using_run_time_dynamic_linking.asp
> >
> > I believe that PE-COFF executables actually have a section for external
> > library references (ie references to DLL's) into which unexec might put
> this
> > kind of information so that the OS could automatically do the external
> > relocation work at image load time (though probably only for those
> > relocation records in the text sections I guess) .  This is all pretty
> hairy
> > though, especially as Windows moves towards 64 bits and whatever system
> > changes might come with that.
> >
> This is exactly the idea.  When we have time :-).
> Take care,
> > | A kludgy way of doing this without any special executable format
> > | knowledge might be to expand the explicit C plt table (mplt in plt.c)
> > | with a bunch of dummy entries referring to unused symbols in external
> > | shared libs, one of which we might provide for this purpose.  Then
> > | when new symbols are needed, these symbols could be changed.  This
> > | would still require us to be able to find the symbol in the image's
> > | symbol table, but at least we would not have to add any new sections,
> > | etc.  Of course this approach is rather awkward and limited too.
> >
> > It all sounds awkward to me as I'm pretty vague on all of this.
> >
> > Cheers
> >
> > Mike Thomas.
> >
> >
> >
> >
> >
> --
> Camm Maguire                                          address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]