Jonathan S. Shapiro wrote: >> If I understand you correctly, I believe the .NET VM takes this approach >> with its generics [1]. Generic functions are compiled as "shape-indexed" >> functions, where the actual code invoked operates on all objects of the >> same shape. Finding the right code to jump to involves indexing a sort >> of function descriptor. > > I don't think that works for us, because there is no single object shape > that can be known when the unit of compilation is compiled. Also, in > some cases we need to do (shape x type), because two objects of the same > shape may have different type class instantiations, and may therefore > require different expansions in our scheme.
Ah, so you're not dictionary-passing the type classes then. Are you monomorphizing everything? > Does the .NET core allow generics to be parameterized over non-primitive > value types (e.g. structs), or only over objects? Over any type. If it were just objects, there would be no need for this scheme, as the shape of an object handle in any function is the same (a pointer). >> ...the code body can be copied, and the >> template params are updated in-place. This is probably a pretty >> reasonable trade-off, though I'm not sure how expensive indexing is. >> Unpredictable indirect jumps are pretty expensive on modern CPUs. > > That doesn't sound like what I had in mind. What I had in mind is a > scheme where the binary code is instantiated differently for each (shape > x type) [yes, that can be optimized, but let's start with that]. So > there wouldn't be any indexing at runtime in the scheme that I have in > mind. I was mixing two issues in my description. There is a strong connection between polymorphism and separate compilation [1]; the technique I described is .NET's type-passing polymorphism. You're after a technique for deferred instantiation for separate compilation, which is a more limited case of the polymorphism problem. In that case, I think .NET's technique is what you described, minus the dispatch code. If you're using .NET's technique to compile polymorphic functions, I think eliminating the dispatch rules out polymorphic recursion. The only other polymorphism technique you didn't mention is is fully boxed representations, which is definitely not what you're after with BitC. Sandro [1] http://citeseer.ist.psu.edu/jones96using.html _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
