Re: expansion, memoization, and evaluation...

[Rob Browning <rlb@defaultvalue.org>]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

>> and foo is a generic function, and last time through, bar and baz were
>> integers, but this time bar and baz are strings.  Would the current
>> behavior be for goops to check, notice this, and build a new
>> "precompiled" invocation for two strings?
>
> Yes.

OK.  Now I think I understand.

>> (Of course if the guile compiler were implemented targeting C, and if
>>  guile were to "Depends: gcc", we might be able to use dlopen/dlsym to
>>  support heavyweight online compilation.
>
> Yes, yes, yes!

FWIW I've actually been playing around with ksi, gcc, and the gcc
front-end/back-end stuff more, and there are some interesting
possibilities.  Imagine if you created a gcc front-end using guile
that linked any resulting binaries against libguile.  It seems like
this would mean you could take a very lazy approach to improving your
compiler.  At first, you might not do much better than guile does now,
just replacing (+ x y) with something like the following (I'm using
ksi-like syntax below, but ksi is just a thin wrapper around the
native "tree" structure used by all the front ends as input to gcc's
code generator):

  (call scm_add (ref x_4432) (ref y_2231))

but later, as we get smarter about flow analysis, etc. we might be
able in some cases to generate:

  (plus (ref x_4432) (ref y_2231))

which would be *way* faster.

(Note that no one should panic -- I'm not about to advocate we jump in
 this direction right now -- I'm just playing around to see what's
 possible).

One thing I'm not clear on at the moment -- the newer gcc's support
-foptimize-sibling-calls, which appears to work even for mutually
recursive functions, but I was wondering if there was any chance this
could work *across* .o files, or if it only worked within the same
object file.  Any gcc gurus about?

I'm presuming cross-boundary optimized tail calls would likely require
non-standard C calling conventions, and AFAIK gcc only supports one
calling convention for external functions.  Ideally, to be able to
generate *really* fast code across .o boundaries, we'd want to be able
to generate external function references that use a calling convention
that's tail-call friendly, and I'm not sure that's possible yet, or
even planned.

One other interesting possibility for a guile compiler as a gcc front
end would be the possibility of either embedding a copy of gcc's C
parser at guile compiler build time (or perhaps just adding hooks into
the existing gcc parser if the upstream were amenable) so that we can
do *real* C code preprocessing -- i.e. automatically extract C
function signatures for wrapper generation at compile time, add
precice gc annotations, or whatever (i.e. perhaps some of the
facinating stuff Tom Lord has suggested).

(Hmm I may have already mentioned some of this stuff -- I can't
 remember whether I that was here or in other private conversations
 :/)

> Maybe I shouldn't reveal this :), but I've seen the current goops as a
> large-scale experiment to test whether these crazy ideas really work
> in practise.  And they actually seem to.  I've made heavy use of goops
> in large systems consisting of maybe 50 modules, and I don't have any
> complaints on its performance.

Interesting.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel