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
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc