unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: guile-devel@gnu.org
Subject: a rehash of the question of optimizing some prompt ideoms
Date: Fri, 30 Aug 2013 20:54:35 +0200	[thread overview]
Message-ID: <2849568.naTrYEPBA4@warperdoze> (raw)

Hi all,

In the wake of the wowely code Andy Mark and Noah have been producing
I want to lift the question of what we can do to compile some
delimeted continuation code effeciently.

Delimeted continuations can be looked upon as a generalization of
common lisps tagbody e.g. it's trivial to produce tagbody semantics
with the help of prompts. Now a quesiton is how we should make sure
that most sane code that can be compiled to goto's in the rtl backend
really get that far. As I understand the cps compiler is well suited
to take on this task. But we should not aim towards atgbody, but also
generators and similar constructs. To see what kind of semantics to
support maybe the code in 
 
  https://gitorious.org/guile-coroutines/guile-
coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine.scm

Can help as well as the example in the same repo,

https://gitorious.org/guile-coroutines/guile-
coroutines/source/fc49d41dfa0cc0647aaeeddf8fb15d55dc2fb6ef:stis/coroutine/test.scm

So what can we do in rtl that we cannot do before? To note here is
that in rtl we can basically allocate a region of the register space
for e.g. a generator. The nice thing with rtl is that all functions
are executed at the end of the register space and therefore we could
basically use named gotos to jump between the different
generators located at different stack areas. This is not possible in a
stack based VM. So not only do we skip expensive function call's but
tear down and setup of the stack is not needed. Of cause to be
able to take advantage of this not all generators can be used in such
a scheme. (It would be nice to get Academic references for this) but
it should be doable. 

We would need some more one more instruction from RTL, namely named
gotos.

It's also perhaps possible to enlarge the ideas to separate where
functions are evaluated and where the "local rigister area" of the 
generator is 
situated. E.g. An area allocated from the heap. But this lead to a
complete redesign of RTL but it would could be a cool concept.

WDYT?




             reply	other threads:[~2013-08-30 18:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 18:54 Stefan Israelsson Tampe [this message]
2013-08-31  4:35 ` a rehash of the question of optimizing some prompt ideoms Mark H Weaver
2013-08-31  4:56   ` Mark H Weaver
2013-09-01 20:34 ` Stefan Israelsson Tampe

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=2849568.naTrYEPBA4@warperdoze \
    --to=stefan.itampe@gmail.com \
    --cc=guile-devel@gnu.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).