[Gcl-devel] Re: [Axiom-developer] Re: lisp

[Camm Maguire]

Greetings!  Yes, thanks!  Just confirmed that doing so shaved 1/3 off
the regression suite time.

It appears that AXIOM is making use of the .fn files in a slightly
different way than GCL itself -- namely automatically loading the .fn
file of the same base name when compiling a file the second time.
(I'm still looking for the spot in the compiler source where this
happens, can't seem to find it yet.)  If this is the case, and if a
new lisp process is started for every compile-file, then the benefits
of the .fn files will only accrue to calls within the file itself.
I.e. GCL will compile a function taking real C arguments, and if
another function calls it in the same file, the call will be done via
a C function pointer set to the first compiled function address and
loading arguments directly onto the C stack.  Calls from other files
will load values onto the lisp value stack and pass through a section
of GCL code which will make the call via a jump table.  This will
still be faster than having the function break apart the values from
the lisp value stack itself, but might be further improved.

In general, the optimal situation would be to load sys-proclaim.lisp
files made from the .fn files in all layers and subdirectories, dump
the image, and then this to compile the second pass.  All
proclamation information is now permanently in the image.

In the future, I would like to make this easier to use, but this will
surely wait for a long time.  The best idea I have at present is to
store the lisp source for each function in the function symbol's
plist, recompile the function whenever new info is acquired on one of
its calls, and then perhaps put in some algorithm to dump the lisp
source to save space when all calls have been proclaimed, though one
could always redefine the functions later and miss thereby the info
required to make the updates.  

Anyway, this whole concept of the compiler getting smarter as it
builds the image is quite special to lisp, it appears, as in C, for
example, all of this information must be explicitly provided by the
user in the form of included static header files.

Take care,

root <address@hidden> writes:

> Camm,
> 
> The .fn processing machinery is there. All you need to do to speed
> up axiom is to do a build, touch the int/*.{lsp|lisp} files, and
> then 'make'. This will trigger a second round of compiles. Since
> the first round of compiles wrote the .fn files they will be available
> for the second round of compiles and the type optimizations occur.
> 
> I need to add these steps to the build but there are other high
> priority items to fix first.
> 
> Tim
> 
> 
> 

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