From: Mikael Djurfeldt <mdj@kvast.blakulla.net>
Cc: djurfeldt@nada.kth.se, Dirk Herrmann <dirk@ida.ing.tu-bs.de>,
guile-devel@gnu.org, Rob Browning <rlb@defaultvalue.org>
Subject: Re: expansion, memoization, and evaluation...
Date: Wed, 04 Dec 2002 11:55:20 +0100 [thread overview]
Message-ID: <xy73cpevysn.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <15853.47140.340761.46290@localhost.localdomain> (klaus schilling's message of "Wed, 4 Dec 2002 09:09:08 +0100")
klaus schilling <pessy@chez.com> writes:
> Mikael Djurfeldt writes:
> > If the optimizer does source --> source transformation it's reasonably
> > easy to use it together with an offline compiler. It's more difficult
> > to explain the memoized code to the compiler...
>
> How is code generated at run-time evaluated by eval , eval-string,
> or local-eval handled by the optimizer?
Clarification: The particular optimizer we're talking about here sits
just before method code is run for the first time, that is as a part
of the application of a generic method. It is supposed to mainly do
goops-specific optimizations.
Answer: The only way for eval, eval-string or local-eval to get to
code generated by the optimizer is by invoking a generic function.
This GF does type dispatch on its arguments. If the offline compiler,
through code analysis, has concluded that code will be needed for a
certain combination of arguments, the GF can select precompiled code.
If not, there are different possible alternatives to choose from:
Alt 1: Handle it as in the interpreter.
Alt 2: Same as alt 1, but invoke the compiler dynamically on the
output of the optimizer.
Alt 3: Invoke an unoptimized version of the method (with all internal
type dispatch intact).
Alt 3 is the "vanilla" way to do compilation. You see, I'm not
talking about peculiarities of goops putting constraints on how you
can do compilation. You can compile things standardly alright.
Rather, it's about novel opportunities.
M
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
prev parent reply other threads:[~2002-12-04 10:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 2:41 expansion, memoization, and evaluation Rob Browning
2002-12-04 2:57 ` Mikael Djurfeldt
2002-12-04 3:10 ` Rob Browning
2002-12-04 3:31 ` Mikael Djurfeldt
2002-12-04 4:07 ` Rob Browning
2002-12-04 7:07 ` Mikael Djurfeldt
2002-12-04 21:11 ` Rob Browning
2002-12-04 21:47 ` Mikael Djurfeldt
2002-12-05 0:07 ` Rob Browning
2002-12-05 16:27 ` Marius Vollmer
2002-12-05 17:07 ` Rob Browning
2002-12-04 8:09 ` klaus schilling
2002-12-04 10:55 ` Mikael Djurfeldt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xy73cpevysn.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me \
--to=mdj@kvast.blakulla.net \
--cc=dirk@ida.ing.tu-bs.de \
--cc=djurfeldt@nada.kth.se \
--cc=guile-devel@gnu.org \
--cc=rlb@defaultvalue.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).