[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: expansion, memoization, and evaluation...
From: |
Rob Browning |
Subject: |
Re: expansion, memoization, and evaluation... |
Date: |
Wed, 04 Dec 2002 18:07:17 -0600 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Mikael Djurfeldt <address@hidden> 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
- expansion, memoization, and evaluation..., Rob Browning, 2002/12/03
- Re: expansion, memoization, and evaluation..., Mikael Djurfeldt, 2002/12/03
- Re: expansion, memoization, and evaluation..., Rob Browning, 2002/12/03
- Re: expansion, memoization, and evaluation..., Mikael Djurfeldt, 2002/12/03
- Re: expansion, memoization, and evaluation..., Rob Browning, 2002/12/03
- Re: expansion, memoization, and evaluation..., Mikael Djurfeldt, 2002/12/04
- Re: expansion, memoization, and evaluation..., Rob Browning, 2002/12/04
- Re: expansion, memoization, and evaluation..., Mikael Djurfeldt, 2002/12/04
- Re: expansion, memoization, and evaluation...,
Rob Browning <=
- Re: expansion, memoization, and evaluation..., Marius Vollmer, 2002/12/05
- Re: expansion, memoization, and evaluation..., Rob Browning, 2002/12/05
Re: expansion, memoization, and evaluation..., klaus schilling, 2002/12/04