From: Andy Wingo <wingo@pobox.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Patches for wip-rtl
Date: Tue, 23 Apr 2013 12:13:05 +0200 [thread overview]
Message-ID: <87fvyhimha.fsf@pobox.com> (raw)
In-Reply-To: <CA+U71=MzQgcd6GJWeAHvwGV5sFutYVanB+GAeGgxtigVEKPpFQ@mail.gmail.com> (Noah Lavine's message of "Mon, 22 Apr 2013 22:38:02 -0400")
Heya,
On Tue 23 Apr 2013 04:38, Noah Lavine <noah.b.lavine@gmail.com> writes:
> I assume you're talking about the box-ref and box-set! stuff with
> checking for non-variables, right? I agree in general, but those
> instructions could plausibly be emitted for any code that uses module
> introspection to get its own variable objects, right?
Ah I see what you mean. There are two uses of variables in the VM: one
for calls to variable-ref or variable-set, and the other for internal
use. For the internal uses, we know the variable should indeed be a
variable and so we should emit the checks. For calls to variable-ref /
variable-set, I think it would be best if somehow the compiler could
replace those calls with (if (call variable? x) (primcall box-ref x)
(call error ...)). Dunno. WDYT?
> One thing that would be interesting - and I don't know if we do this
> now - is using different VMs for different parts of the
> code. Specifically, if the REPL ran in a different VM than user code,
> then the REPL wouldn't die in these cases. That might also enable
> cool debugging things, like single-stepping the user VM and examining
> its registers. I noticed that we already have support for changing the
> active VM. What do you think?
We can do that already to a degree... probably the best "fallback" that
we have is the stack VM, actually. What happens if you install traps on
the VM that call stack VM procedures and then you run an RTL function?
I would think that you should be able to do something useful there.
Just a thought!
Andy
--
http://wingolog.org/
next prev parent reply other threads:[~2013-04-23 10:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-20 23:30 Patches for wip-rtl Noah Lavine
2013-04-21 15:23 ` Noah Lavine
2013-04-21 15:50 ` Noah Lavine
2013-04-22 20:27 ` Andy Wingo
2013-04-23 1:34 ` Noah Lavine
2013-04-22 20:39 ` Andy Wingo
2013-04-23 2:38 ` Noah Lavine
2013-04-23 10:13 ` Andy Wingo [this message]
2013-05-05 1:29 ` Noah Lavine
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=87fvyhimha.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=noah.b.lavine@gmail.com \
/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).