Re: [Gcl-devel] small GCL issues

[Camm Maguire]

Greetings, and thanks!

Matt Kaufmann <address@hidden> writes:

...

> Please let me know if you have any suggestions for improvement.  Can
> you point me to a recent GCL already built at UT for which
> (get-internal-run-time) returns four values, so that I can try this
> out for that case?

/p/bin/gcl-2.6.10pre is the latest.  I don't plan anything else but
bugfixes as defined by failures in acl2,maxima,hol88 or axiom on the
various platforms, now in test.  I think you should see some speedup.  I
can post the breakdown of a run with the four values if you are
interested.  The big culprit is the second, the child user time, which
is gcc.  

There are gains to be had in addressing this interface, though I don't
think there is any point to gcl were it not to compile in some fashion
into the FSF compiler toolchain.  This design also is a major
portability gain, though perhaps the future will be 'one chip to rule
them all' :-)  Eventually gcl should become a gcc frontend.  This is far
in the future.  We already pre-compile cmpinclude.h, but this can be
made significantly smaller.  We could just leave gcc running and avoid
the startup costs.  But I don't plan to do anything about this now.  It
appears that gcl is quite competitive short of gcc as you state, and I
guess we'll have to live with this for the moment.

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