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
