RTL Cache Cells

RTL Cache Cells

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Hello,

The RTL branch now has infrastructure for toplevel and module refs, which
is very exciting. Unfortunately, I can't figure out how to use it. :-(

In particular, I've been looking at module/system/vm/rtl.scm, and there are
two things I don't understand about cache cells.
  1. How do I choose the scope of a cache cell? It seems like making it the
name of the lambda I'm in would be fine, but that's not what the examples
in rtl.test do.
  2. How do different toplevel-refs share cache cells? A comment says that
they will, but the emit-cache-cell code doesn't seem to do any checking.
Does that still need to be implemented?

Oh, and as long as I'm at it,
  3. I see that the 'toplevel-ref' instruction in vm-engine.c expects a
variable object as its cache, but the 'cached-toplevel-ref' instruction
*appears* to be passing it a cache cell. I say "appears" because I see that
in intern-constant, cache cells are special-case objects that aren't
actually cached. So is a cache cell only a compile-time entity? How do they
work, anyway?

Thanks in advance,
Noah

[-- Attachment #2: Type: text/html, Size: 1379 bytes --]

Re: RTL Cache Cells

[Andy Wingo]

Hi,

On Thu 07 Feb 2013 04:09, Noah Lavine <noah.b.lavine@gmail.com> writes:

> In particular, I've been looking at module/system/vm/rtl.scm, and there
> are two things I don't understand about cache cells.
>   1. How do I choose the scope of a cache cell? It seems like making it
> the name of the lambda I'm in would be fine, but that's not what the
> examples in rtl.test do.

You choose some identifier that is unique in your compilation unit.  Its
name doesn't matter; it won't be serialized anywhere.

>   2. How do different toplevel-refs share cache cells? A comment says
> that they will, but the emit-cache-cell code doesn't seem to do any
> checking. Does that still need to be implemented?

You make all toplevel references within one toplevel function share the
same identifier.  This includes nested refs.

The compiler joins identical refs because <cache-cell> is placed in an
equal?  vhash, and the default struct equal? function checks type,
shape, and field using equal?.  So it does the right thing.

> Oh, and as long as I'm at it,
>   3. I see that the 'toplevel-ref' instruction in vm-engine.c expects a
> variable object as its cache, but the 'cached-toplevel-ref' instruction
> *appears* to be passing it a cache cell. I say "appears" because I see
> that in intern-constant, cache cells are special-case objects that aren't
> actually cached. So is a cache cell only a compile-time entity? How do
> they work, anyway?

What happens is this: let's say you have a function:

  (lambda ()
    bar)

This function has a free variable, resolved at the toplevel.  We don't
know the module that `bar' will be resolved against -- it depends on the
module that is current when (lambda () bar) is evaluated.

So we compile this using an indirection -- a cache cell.  Actually there
are two indirections.  One is a one-word field, statically allocated in
the .data section of the ELF, which is either #f or a variable.  It's #f
at the beginning and a variable once the toplevel has been resolved to a
particular variable in a particular module.  This is the way a cache
cell gets written into an ELF file.  See rtl.scm:862.  Then the variable
itself is an indirection as well.

Cheers,

Andy
-- 
http://wingolog.org/