gcl-devel
[Top][All Lists]
Advanced

[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 18:42:11 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Vanuxem Gregory <address@hidden> writes:

> Hi,
> 
> Some correction about this incomprehensible e-mail.
> 
> >
> >
> > Greetings!
> >
> > Vanuxem Gregory <address@hidden> writes:
> >
> > > Serious question about GCL,
> 
> One question about GCL and multiple-precision
> floating-point computations.
> 
> > > I've lost your mail about (arbitrary float),
> > > But how do yo think peopole can implement arbitrary float in
> > gcl; whith MPFR
> 
> How do you think someone can implement arbitrary float (MPFR)
> in gcl ?
> 
> > > ?
> > > 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.
> 
> With a new 'switch ... case' ?
> 

Basically, yes.

> >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
> > example.
> >
> > 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.
> 
> Just for information.
> 
> 
> Here begins Post-Scriptum:
> 
> >
> > > Actually AXIOM doesn't compile with ANSI version ...
> 
> Sometimes I think about multiple-precision floating-point
> computations in GCL and connection with other CAS.

OK.

> CLOS require ANSI dialect isn't it?

Rather ANSI requires CLOS, but what has this to do with mfpr?

> 
> >
> > 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.
> >
> 
> Thanks for this information.
> 
> > 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.
> 
> Translation:
> 
> In some recent discussion, the notion of portable graphic library
> has been evoked and its utilization with graphic and documentation.
> I always think about a colossal work: notebook and
> interaction with literate programming. The graphic library
> has may be (for me) to be choosen such that:
> 
> i)  works under different OS
> ii) it is compliant with other projects
> 
> 
> > > 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...):
> 
> My branch of AXIOM has to be enhanced in four directions.
> Three types seem important (not for performance):
> Integer, Real and Rational.
> 

I don't understand what might be missing except for performance.
Please explain if you have the time.

> > >
> > > 1) 'Integer' in arbitrary integer:
> >             'GMP (realized)'
> >
> > Is this not already the case???
> >
> > > 2) 'Floating number' in arbitrary float (cf: Monagan, Michael
> > (1990)):    'ADD
> > > MPFR'
> >
> > 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.
> 
> This work is not destined to be included in axiom.
> 

Why not?

> >
> > > 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
> > here.
> >
> > 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.
> 
> Is there some specification about foreign language call in Common Lisp ?
> 

Not in the standard.  Each implementation does its own.  GCL's is
pretty flexible IMHO.

> > > 5) Documentation about what I say.
> > >
> >
> > Yes, please!
> 
> >
> > Take care,
> >
> 
> Cheers,
> 

Take care,

> 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
> >
> 
> 
> 
> 
> _______________________________________________
> 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]