Hey guys,
Once closures become part of Jolt, we'll be able to write Michael's
function,
void f() {
static int x = 0;
...
x++;
...
}
as
(define f
(let ((x 0))
(lambda ()
(... (set x (+ x 1)) ...))))
which I think is pretty nice - i.e., easy for the programmer to write, and
confines x in f, just as you'd expect. I wonder if this already works with
Michael FIG's patch...
Cheers,
Alex
On Thu, Apr 3, 2008 at 1:16 PM, Gavin Romig-Koch <[EMAIL PROTECTED]> wrote:
> Michael Haupt wrote:
>
> > Hi Gavin,
> >
> > Am 02.04.2008 um 19:14 schrieb Gavin Romig-Koch:
> >
> > > Is it your intent that this would give you the ability to change the
> > > machine code generated by Jolt? Or is this meant to be a way to reserve
> > > and
> > > refer to memory within the machine code for use as variables?
> > >
> >
> > the ultimate purpose would be the latter; changing the machine code
> > would then also be possible, but that's not what I want to do. It's rather
> > about approaching something like inline caches (other than those already
> > present in the id model).
> >
>
> Well, on modern hardware and modern OSs, I really don't think nestling the
> inline caches amongst code makes sense - it plays havoc with the cpu's
> memory cache lines, and disallows any use of the code in a multi-threaded or
> multi-processed way. Much better, I think, to allocate the caches out of
> thread local or process local memory. But ...
>
> This is a sketch of how I would go about this, as a first attempt:
>
> I'd use "actives" to provide the interface from the code that uses these
> inline caches to the code that implements them. Actives would allow the
> user these inline caches treat them like variables, independent of how they
> are implemented under the covers. An active is very much like a syntax
> macro, except that where as a syntax macro gets "expanded" when the syntax
> macro gets called like a function, an active gets "expanded" when it is
> either referenced or assigned to like a variable. Look in Compiler.st to
> see how actives are implemented, also I'll give you an example of their use
> below.
>
> If you just wanted to implement the caches in process lifetime memory
> (like "C" local statics), then when a new inline cache is defined, you will
> need to get access to the current compiler with a syntax macro, get access
> to the GlobalEnvironment through that compiler, add a new variable to the
> GlobalEnviroment that won't be confused with user defined variables, and
> then create the actives that will reference this global variable. See
> Compiler.st for the implementation of Compiler and GlobalEnvironment.
>
> If you want to nestle the inline caches into the machine code itself, it's
> a bit more compilcated. When a new inline cache is defined, you need to use
> the code in CodeGenerator-XXX.st to generate the needed space for the inline
> cache and the branch around it, and then create the active to reference the
> space created. The active would use "Label"s to keep track of where in the
> actual code the inline cache ends up. Currently lables are only used for
> branch and jump targets, so you might need to invent a new kind of label for
> tracking a storage location, but maybe you can just add some new methods to
> the current implementation. Again see Compiler.st for the implementation
> of Label. Slightly more interesting and more general would be to invent a
> new intermediate Instruction (see Instruction.st) that meant "reserve space
> in the code for data", and then expand that Instruction in each of the
> different CodeGenderators. Slightly more interesting would to change the
> CodeGenerator to be able to put this reserved space before the start of the
> function (or after the end) to avoid having to jump around the space.
>
> Yet even more interesting, if your willing to alter to code on the fly,
> would be to actually alter the code on the fly, rather than have the code
> examine a variable. This would be largely the same as the above, except
> that instead of altering a variable when one wanted to change the inline
> cache, one would actually alter the call or jump instruction that used the
> inline cache.
>
>
> -gavin...
>
>
>
>
>
>
>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
