On Tue, Apr 8, 2014 at 8:34 PM, Ben Kloosterman <[email protected]> wrote:
> Re self modifying - > > Are we sure that we cant call the compiler and compile this to a new > "assembly" and run that ? In most of these cases start-up time is not an > issue ( since reflection is slow anyway) . I really don't like self > modifying code... there are so many issues. > I hesitate to generalize from a limited number of examples, but let me talk for a moment about the two examples I have been thinking about. The first is bitblt. In the case of bitblt, the issue is that a given bitblt operation occurs at some bit offset relative to a word boundary. Depending on the particular bit offset, different shift instructions need to be emitted. The argument that determines the bit offset arrives as a general runtime value, but that value is then taken mod32 to arrive at a particular constant and thus a particular implementation of a *generic* algorithm. The modulus operation can be viewed as reducing the value to a limited number of (statically enumerable) constants, but the number of variations is such that we don't want to statically pre-emit all of the variations. This example seems closely related to dependent type. There are a (large but) limited number of concrete algorithm realizations that can be statically checked in advance. The dynamic question is limited to choosing which of the instantiations is to be used. The thing is: all of these can be checked in advance, and we can model what is happening as a template expansion that has been deferred to runtime. The reason we do not expand all of the cases at compile time is that there are an explosive number of cases. The loop unrolling case is qualitatively similar. It can be modeled as a template expansion whose implementation has been deferred to runtime. The problem with these two examples is that they are both examples of constant-driven polyinstantiation whose implementation has been deferred to runtime. I think it would be a mistake to imagine that these are the only cases. On the bright side, both of these examples can be statically checked by a relatively weak dependent type system. On the dark side, both rely on the ability of the (static) compiler to emit code that invokes a (dynamic) code generator. The difficulty is to know whether that invocation of the dynamic code generator is originating from the compiler or the program itself. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
