On Fri, 2008-03-28 at 10:02 -0400, Sandro Magi wrote: > Jonathan S. Shapiro wrote: > > 1. Include the ASTs (or equivalent) for that stuff in the > > dynamic library. Generate the code at dynamic load time > > or at run time. > > > > Issue: run-time subsystem complexity. > > Issue: LLVM is written in C++, so it would be difficult to ensure > > that the runtime is safe. On the other hand, there really > > doesn't appear to be any better alternative. > > What sort of safety properties are you interested in?
Memory safety at a minimum. Ideally, precise GC. > > [...] > > 3. Use a compilation strategy in which all argument sizes are > > fully parameterized. This is likely to yield low performance. > > By this, I suppose you mean pointer operations on a parameter require a > "size" parameter to also be passed in. Basically, a type-passing scheme > of sorts. Yes. Another way to look at this is that it's an extension of the Haskell typeclass dictionary to literals that describe offsets and sizes. > > 4. Compile down to a native-code "template" in which sizes and > > external references remain unresolved. Implement a low-level > > run-time instantiator for these templates. > > 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. Does the .NET core allow generics to be parameterized over non-primitive value types (e.g. structs), or only over objects? > ...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. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
